Bug#876241: debian-policy: Produce HTML output that doesn't try to load any JavaScript

[Sean Whitton]

Package: debian-policy
Version: 4.1.0.0
Severity: normal
Control: block 871944 by -1
User: debian-pol...@packages.debian.org
Usertags: packaging

Per the discussion in #871944, at least for now we intend the version of
Policy published on www.debian.org to be free of JavaScript.  So we need
to include a JavaScript-free version in our package.

Assuming that search is the only use made of JavaScript by Sphinx, here
is somewhere to start:
https://stackoverflow.com/questions/31951553/customizing-sphinx-to-avoid-generating-search-box

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

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

Versions of packages debian-policy depends on:
ii  libjs-sphinxdoc  1.5.6-2

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn  doc-base  

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#875535: closed by Matthias Klumpp <m...@debian.org> (Re: Bug#875878: ldc 1.3 doesn't build any of it's reverse dependencies)

[Nobuhiro Iwamatsu]

Hi,

sambamba package has not fixed this problem with ldc 1:1.4.0-1.
Also, I confirmed that diet-ng fixed this problem.

-
 dpkg-buildpackage -rfakeroot -us -uc
dpkg-buildpackage: info: source package sambamba
dpkg-buildpackage: info: source version 0.6.6-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Andreas Tille 
 dpkg-source --before-build sambamba-0.6.6
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
dh clean --buildsystem=meson
   dh_auto_clean -O--buildsystem=meson
   dh_autoreconf_clean -O--buildsystem=meson
   dh_clean -O--buildsystem=meson
 dpkg-source -b sambamba-0.6.6
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building sambamba using existing ./sambamba_0.6.6.orig.tar.gz
dpkg-source: info: building sambamba in sambamba_0.6.6-1.debian.tar.xz
dpkg-source: info: building sambamba in sambamba_0.6.6-1.dsc
 debian/rules build
dh build --buildsystem=meson
   dh_update_autotools_config -O--buildsystem=meson
   dh_autoreconf -O--buildsystem=meson
   dh_auto_configure -O--buildsystem=meson
meson .. --wrap-mode=nodownload --buildtype=plain
--prefix=/usr --sysconfdir=/etc --localstatedir=/var
--libdir=lib/x86_64-linux-gnu --libexecdir=lib/x86_64-linux-gnu
Warning: You are using 'ANSI_X3.4-1968' which is not a a
Unicode-compatible locale.
You might see errors if you use UTF-8 strings as filenames, as
strings, or as file contents.
Please switch to a UTF-8 locale for your platform.
The Meson build system
Version: 0.42.1
Source dir: /home/iwa/t3/sambamba-0.6.6
Build dir: /home/iwa/t3/sambamba-0.6.6/obj-x86_64-linux-gnu
Build type: native build
Project name: Sambamba
Native D compiler: ldc2 (llvm 1.4.0)
Appending DFLAGS from environment: '-O2 -g -release'
Appending LDFLAGS from environment: '-Wl,-z,relro'
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (0.29)
Native dependency undead found: YES 1.0.7
Native dependency biod found: YES 0.1.0
Native dependency liblz4 found: YES 1.8.0
Native dependency htslib found: YES 1.5-1
Program ldmd2 found: YES (/usr/bin/ldmd2)
Program mkdir found: YES (/bin/mkdir)
Build targets in project: 2
   dh_auto_build -O--buildsystem=meson
ninja -j8 -v
[1/74] ldc2  -Isambamba@exe -I. -I.. -I/usr/include/d/
-I/usr/include/htslib -enable-color -O2 -g -release  -of
'sambamba@exe/main.d.o' -c ../main.d
../sambamba/utils/common/readstorage.d(22): Deprecation: module
std.c.stdlib is deprecated - Import core.stdc.stdlib or
core.sys.posix.stdlib instead
../sambamba/utils/common/readstorage.d(23): Deprecation: module
std.c.string is deprecated - Import core.stdc.string instead
../sambamba/utils/common/readstorage.d(23): Deprecation: module
std.c.string is deprecated - Import core.stdc.string instead
../sambamba/sort.d(45): Deprecation: module std.c.stdlib is deprecated
- Import core.stdc.stdlib or core.sys.posix.stdlib instead
../sambamba/sort.d(46): Deprecation: module std.c.string is deprecated
- Import core.stdc.string instead
../sambamba/markdup.d(37): Deprecation: module std.c.stdlib is
deprecated - Import core.stdc.stdlib or core.sys.posix.stdlib instead
../sambamba/depth.d(1154): Deprecation: Implicit string concatenation
is deprecated, use "mapping_quality > 0 and " ~ "not duplicate and "
instead
../sambamba/depth.d(1155): Deprecation: Implicit string concatenation
is deprecated, use "not duplicate and " ~ "not failed_quality_control"
instead
[2/74] ldc2  -Isambamba@exe -I. -I.. -I/usr/include/d/
-I/usr/include/htslib -enable-color -O2 -g -release  -of
'sambamba@exe/sambamba_index.d.o' -c ../sambamba/index.d
[3/74] ldc2  -Isambamba@exe -I. -I.. -I/usr/include/d/
-I/usr/include/htslib -enable-color -O2 -g -release  -of
'sambamba@exe/sambamba_fixbins.d.o' -c ../sambamba/fixbins.d
[4/74] ldc2  -Isambamba@exe -I. -I.. -I/usr/include/d/
-I/usr/include/htslib -enable-color -O2 -g -release  -of
'sambamba@exe/sambamba_depth.d.o' -c ../sambamba/depth.d
FAILED: sambamba@exe/sambamba_depth.d.o
ldc2  -Isambamba@exe -I. -I.. -I/usr/include/d/ -I/usr/include/htslib
-enable-color -O2 -g -release  -of 'sambamba@exe/sambamba_depth.d.o'
-c ../sambamba/depth.d
../sambamba/depth.d(1154): Deprecation: Implicit string concatenation
is deprecated, use "mapping_quality > 0 and " ~ "not duplicate and "
instead
../sambamba/depth.d(1155): Deprecation: Implicit string concatenation
is deprecated, use "not duplicate and " ~ "not failed_quality_control"
instead
/usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x1a)[0x7fec38558cda]
/usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1(_ZN4llvm3sys17RunSignalHandlersEv+0x56)[0x7fec38556fc6]
/usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1(+0x86e0e3)[0x7fec385570e3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7fec376d10c0]
ldc2(+0x2d6242)[0x59e7bce242]
ldc2(+0x35b517)[0x59e7c53517]
ldc2(+0x35babb)[0x59e7c53abb]
ldc2(+0x31e1d0)[0x59e7c161d0]

Bug#876227: release.debian.org: nmu: cheese, gnome-dvb-daemon, grilo-plugins, gstreamer-vaapi, webkit2gtk

[Matteo F. Vescovi]

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

Hi team!

A new version of gst-plugins-bad1.0 was uploaded yesterday and all its
reverse dependencies are now in need of a binNMU to fix the wrong shlibs
versioning.

  nmu cheese_3.26.0-1 . ANY . -m 'Rebuild against new gst-plugins-bad1.0 
version'
  nmu gnome-dvb-daemon_1:0.2.91~git20170110-2 . ANY . -m 'Rebuild against new 
gst-plugins-bad1.0 version'
  nmu grilo-plugins_0.3.5-2 . ANY . -m 'Rebuild against new gst-plugins-bad1.0 
version'
  nmu gstreamer-vaapi_1.12.2-1 . ANY . -m 'Rebuild against new 
gst-plugins-bad1.0 version'
  nmu webkit2gtk_2.18.0-2 . ANY . -m 'Rebuild against new gst-plugins-bad1.0 
version'

Thanks.


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

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

Bug#848982: wpasupplicant fails to connect to WPA Enterprise network with 2.6-2

[Daniel Reichelt]

I'm suffering the very same problem than the OP with my employer's WiFi
network.


> If I downgrade libssl1.0.2 to 1.0.2j-1 then I can connect to the
> WPA-EAP network without problem.

Good catch downgrading openssl! I can confirm the WiFi connection to
work up to libssl1.0.2-4 [1], so I guess the fix for #736687 is to blame
for this [2]:

 * Mark RC4 and 3DES as weak which removes them from the SSL/TLS
protocol (Closes: #736687).



As a *dirty* workaround, I

- re-upgraded to libssl1.0.2ll-2/stretch
- renamed /sbin/wpa_supplicant and put a wrapper script in its place
- which sets LD_LIBRARY_PATH to a location containing libssl.so.1.0.2
from [1] and then starts the renamed wpa_supplicant binary with the
original command-line parameters.



HTH,

Daniel



[1]
http://snapshot.debian.org/package/openssl1.0/1.0.2j-4/#libssl1.0.2_1.0.2j-4

[2]
https://anonscm.debian.org/viewvc/pkg-openssl/openssl/branches/openssl1.0/debian/patches/Mark-3DES-and-RC4-ciphers-as-weak.patch?revision=865=markup=log



signature.asc
Description: OpenPGP digital signature

Bug#820119: [www.debian.org] validation errors: cannot convert character reference to number X because character not in internal character set

[Laura Arjona Reina]

Hello all
Now that we are using the more modern tool onsgmls instead of nsgmls in our
"validate" script:

https://anonscm.debian.org/cgit/debwww/cron.git/tree/scripts/validate

I've returned to this bug.

The output of the validate script for the files containing "emojis" didn't
change much:

 Errors validating
/srv/www.debian.org/www/international/l10n/po/en_GB.it.html: ***
Line 122, character 357:  cannot convert character reference to number
128513 because character not in internal character set

I was a bit surprised that we are still getting these errors, because if I pass
the online w3c validator https://validator.w3.org/ or even a manual onsgmls
command in the machine that builds the website:

onsgmls -E0 -s /path/to/dtd /path/to/file

in both cases I don't get any error.
So I've looked at the "validate" script and played a bit with the options set
there, and I'd like to bring to your attention the lines L363-376:

# Determine whether we're dealing with HTML or XHTML and set the SP
# environment accordingly.
if ($xhtml{$htmlLevel}) {
$ENV{'SGML_CATALOG_FILES'} = $xhtmlCatalog;
$ENV{'SP_ENCODING'} = 'xml';
} else {
$ENV{'SGML_CATALOG_FILES'} = $htmlCatalog;
if (defined $charset) {
$ENV{'SP_ENCODING'} = $charset;
} else {
$ENV{'SP_ENCODING'} = "ISO-8859-1";
}
}
$ENV{'SP_CHARSET_FIXED'} = 1

If I comment this last line (and thus, letting onsgmls run in not fixed mode), I
get no errors validating the file.

I've read the documentation about these options:

http://openjade.sourceforge.net/doc/charset.htm

but frankly I don't understand it very much.

I've done:

larjona@wolkenstein:~$ sudo -u debwww env | grep SP_

and it returns nothing, so I guess only the environment set in "validate" script
is taken into account, if we don't set the variables there, defaults rule.

I've modified and run a copy of the validate script, making it print some values
when checking a file, and document type is correctly detected (HTML 4.01
Strict), as well as charset (utf-8).

I'm not sure I can safely comment the line 376

$ENV{'SP_CHARSET_FIXED'} = 1;

to avoid the errors, or even comment the whole paragraph, and trust onsgmls to
do the right thing.

Anybody with more experience in this can help?

Thanks
--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#781051: php-wikidiff2: Not configured correctly when short_open_tag is false

[Kunal Mehta]

On Mon, 23 Mar 2015 20:59:36 +0100 Sebastien Koechlin
 wrote
> Can you switch to "https://anonscm.debian.org/cgit/collab-maint/wikidiff2.git/commit/?id=d83ceb2ff550ff0831738cda29477cbe46e64281>.

wikidiff2 1.4.1+ no longer includes a PHP file anyways.

-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#873094: RFS: granite/0.4.1-1 [ITP]

[yang]

Hi,
Thank very much for your interest. I've fixed them.

2017-09-20 4:46 GMT+08:00 Jeremy Bicha :
> debian/control:
> - Please remove or update the Vcs fields
> - Please drop the Pre-Depends lines
> - Maybe https://github.com/elementary/granite is a better homepage?
>
> debian/rules:
> - Please drop the dh_builddeb rule. xz is already the default
> - Please use c4 for the makeshlibs rule
>
> debian/changelog:
> - I think it is appropriate to keep the old changelog entries since
> this package was only removed from Debian 6 months ago.
>
> debian/copyright:
> - Please update the Source line to point to github since that's where
> your watch file points
>
> Please use automatic debug packages. In particular, see the top
> section (before Summary) of
> https://wiki.debian.org/AutomaticDebugPackages
>
> Thanks,
> Jeremy Bicha

Bug#876033: primusrun doesn't find libGL.so.1

[Bernd Vaske]

Hello,

the problem comes from the transition of mesa to glvnd.
A workaround is to link the missing libs from

/usr/lib/x86_64-linux-gnu/libGL.so.1 to 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1

and
/usr/lib/i386-linux-gnu/libGL.so.1 to 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1


That will result in primusrun starting again but most likely resulting 
in a black window for the application which is started.


To get primusrun to work properly you have to start it with 
__GLVND_DISALLOW_PATCHING=1


example:

__GLVND_DISALLOW_PATCHING=1 primusrun glxgears

Best regards

Bug#876222: Should be in "contrib", not "main"

[Wookey]

On 2017-09-19 12:27 -0700, Josh Triplett wrote:
> Package: mali-midgard-dkms
> Severity: serious
> 
> The package description says:
> 
> > This provides the kernel module for the ARM Mali 'midgard' GPU series
> > in dkms format. This covers the 6xx and 7xx GPU hardware devices. You
> > need this kernel module as well the binary drivers to make the
> > hardware work.
> 
> If that's the case, and this kernel module doesn't do any good without
> the binary drivers, then this package should go to "contrib", not
> "main".

That's a good point. The plan was always to upload it to contrib originally,
but clearly I have failed to actually do so.
 
> If this kernel module has uses without the binary drivers (e.g. if it
> can be made to work with the reverse-engineered driver instead), then
> the description should make that clear.

The mali reverse-engineering effort has recently restarted after being
moribund for a few years, (https://github.com/yuq/mesa-lima) and it's
possible that this driver will be useful there, but I don't know that
yet. I'll check with that project and unless there is a prospect of
this driver being used by free software I'll move it.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Bug#876238: gcc-cross-support: FTBFS, wants to regenerate debian/control with more and renamed packages

[Andreas Beckmann]

Source: gcc-cross-support
Version: 3
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

gcc-cross-support FTBFS in experimental, tries to regenerate
debian/control in order to rename several packages and add a bunch of
new ones.

Given that the package hasn't seen any upload in the last two years,
maybe it's not needed for the current cross compilers and should rather
be removed than fixed :-)

Build log is attached.


Andreas


gcc-cross-support_3.log.gz
Description: application/gzip

Bug#876220: libglvnd0:amd64: KDE will not start due to undefined symbol

[Matt Stamp]

Package: libglvnd0
Version: 0.2.999+git20170802-4
Severity: normal

Dear Maintainer,

An upgrade of libgl1:amd64 broken XServer and it cannot start.

[32.012] (EE) Failed to load /usr/lib/xorg/modules/extensions/libglx.so: /
usr/lib/x86_64-linux-gnu/libGL.so.1: undefined symbol: _glapi_tls_Current
[32.012] (EE) Failed to load module "glx" (loader failed, 7)

root@fusion:/home/matt# ldd -r /usr/lib/x86_64-linux-gnu/libGL.so.1
linux-vdso.so.1 (0x7ffdc5b64000)
libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 
(0x7f810f231000)
libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 
(0x7f810ef63000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f810ed5f000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f810eb42000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f810e7a5000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 
(0x7f810e465000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 
(0x7f810e253000)
/lib64/ld-linux-x86-64.so.2 (0x7f810f6ee000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 
(0x7f810e02b000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 
(0x7f810de27000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 
(0x7f810dc21000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x7f810da0c000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f810d804000)
undefined symbol: _glapi_tls_Current(/usr/lib/x86_64-linux-gnu/libGL.so.1)

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

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

Versions of packages libglvnd0:amd64 depends on:
ii  libc6  2.24-17

libglvnd0:amd64 recommends no packages.

libglvnd0:amd64 suggests no packages.

-- no debconf information

Bug#876221: log uninitialized stack in non-default configuration [CVE-2017-0380]

[Peter Palfrader]

Package: tor
Severity: serious
Version: 0.2.7.2-alpha-1
Control: forwarded -1 https://bugs.torproject.org/23490

tor could log uninitialized stack when a certain hidden service error occurred
while SafeLogging was disabled.

This is also tracked as TROVE-2017-008 and CVE-2017-0380.

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#786402: New repository on github

[Elena ``of Valhalla'']

More info.

The original author has left_ the project, it has been migrated over
to github_ and they are thinking to change_ the name.

.. _left: https://forum.valentina-project.org/t/i-am-leaving-the-project/1628
.. _github: https://github.com/valentina-project/vpo2
.. _change: https://forum.valentina-project.org/t/new-name-for-valentina/1839
-- 
Elena ``of Valhalla''

Bug#854062: xournal: Hangs upon pressing Ctrl-S (for saving)

[Ondřej Lhoták]

I was experiencing the same issue. The file selection dialog for both
the Save As and Export to PDF actions did not appear, and Xournal would
hang.

I deselected Use XInput in the Options menu. That fixed the issue. Both
Save As and Export to PDF work for me when Use XInput is deselected.

This seems to be related to upstream bug 170:
https://sourceforge.net/p/xournal/bugs/170/

Bug#876228: twm should recommend menu

[Kacper Gutowski]

Package: twm
Version: 1:1.0.9-1+b1
Severity: minor

Currently twm package has a hard dependency on the menu package
but twm can work just fine without it except not showing Debian
menu in default configuration.  I thinks it should use Recommends
field instead.

-k

Bug#876235: python-autobahn: missing B-D: openstack-pkg-tools

[Andreas Beckmann]

Source: python-autobahn
Version: 17.7.1+dfsg1-1
Severity: serious
Justification: fails to build from source

Hi,

python-autobahn/experimental FTBFS with

dh: Unknown sequence /usr/share/openstack-pkg-tools/pkgos.make (choose
from: binary binary-arch binary-indep build build-arch build-indep clean
install install-arch install-indep)


Andreas


python-autobahn_17.7.1+dfsg1-1.log.gz
Description: application/gzip

Bug#876236: xmlelements: FTBFS with python3.6 as a supported version

[Andreas Beckmann]

Source: xmlelements
Version: 1.0~prerelease-1
Severity: serious
Justification: fails to build from source

Hi,

xmlelements FTBFS (at least) since python3.6 became a supported python3
version:

 debian/rules build
dh build --with=python2,python3
   dh_update_autotools_config
   dh_auto_configure
   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/xmlelements-1.0~prerelease'
set -xe; \
for py in python2.7 python3.6 python3.5; do \
$py setup.py build; \
done
+ python2.7 setup.py build
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
copying xe.py -> build/lib.linux-x86_64-2.7
+ python3.6 setup.py build
/bin/sh: 3: python3.6: not found
debian/rules:10: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 127
make[1]: Leaving directory '/build/xmlelements-1.0~prerelease'
debian/rules:28: recipe for target 'build' failed
make: *** [build] Error 2


Andreas


xmlelements_1.0~prerelease-1.log.gz
Description: application/gzip

Bug#876240: libghc-xmonad-contrib-dev: unmet dependency libghc-x11-xft-dev-0.3.1-c557c

[Sacha Delanoue]

Package: libghc-xmonad-contrib-dev
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I tried to install libghc-xmonad-contrib-dev by doing
`apt install libghc-xmonad-contrib-dev` on an up-to-date 9.1 Debian.
The install failed with the following information:

The following packages have unmet dependencies:
 libghc-xmonad-contrib-dev : Depends: libghc-x11-xft-dev-0.3.1-c557c
E: Unable to correct problems, you have held broken packages.

I am no expert in Debian, but a search on the Internet lead me to this:
https://unix.stackexchange.com/a/392888 stating that this kind of errors
in expected in Sid. But since I am using stable I reported it.


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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libghc-xmonad-contrib-dev depends on:
ii  ghc [libghc-unix-dev-2.7.2.0-220bd]  8.0.1-17+b1
ii  libc6 
2.24-11+deb9u1

pn  libghc-base-dev-4.9.0.0-5e731
pn  libghc-containers-dev-0.5.7.1-8be09  
pn  libghc-directory-dev-1.2.6.2-958b8   
ii  libghc-extensible-exceptions-dev [libghc-extensible-excepti  0.1.1.4-8
pn  libghc-filepath-dev-1.4.1.0-6e799
ii  libghc-mtl-dev [libghc-mtl-dev-2.2.1-3d1c9]  2.2.1-5
ii  libghc-old-locale-dev [libghc-old-locale-dev-1.0.0.7-38cd4]  1.0.0.7-5
pn  libghc-old-time-dev-1.1.0.3-cc184
pn  libghc-process-dev-1.4.2.0-e39cb 
pn  libghc-random-dev-1.1-84324  
ii  libghc-utf8-string-dev [libghc-utf8-string-dev-1.0.1.1-6f2d 
1.0.1.1-4+b1

ii  libghc-x11-dev [libghc-x11-dev-1.6.1.2-588a9]1.6.1.2-7
pn  libghc-x11-xft-dev-0.3.1-c557c   
ii  libghc-xmonad-dev [libghc-xmonad-dev-0.12-b943d] 0.12-5+b1
ii  libgmp10 
2:6.1.2+dfsg-1

ii  libx11-6 2:1.6.4-3
ii  libx11-dev   2:1.6.4-3
ii  libxext6 
2:1.3.3-1+b2

ii  libxft2  2.3.2-1+b2
ii  libxinerama-dev 
2:1.1.3-1+b3
ii  libxinerama1 
2:1.1.3-1+b3

ii  libxrandr2   2:1.5.1-1

libghc-xmonad-contrib-dev recommends no packages.

Versions of packages libghc-xmonad-contrib-dev suggests:
ii  libghc-xmonad-contrib-doc   0.12-3
pn  libghc-xmonad-contrib-prof  

Bug#876229: apport: FTBFS: B-D: libglib2.0-0-dbg is no longer available

[Andreas Beckmann]

Source: apport
Version: 2.20.4-2
Severity: serious
Justification: fails to build from source

# apt-get build-dep apport
Reading package lists... Done
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 builddeps:apport : Depends: libglib2.0-0-dbg but it is not installable
E: Unable to correct problems, you have held broken packages.


Andreas

Bug#871806: uscan: (dpkg, git-buildpackage) accept/mangle/store signed git tags in cases where upstream does not publish detached sigs on tarballs

[Tomasz Buchert]

On 16/08/17 21:01, Daniel Kahn Gillmor wrote:
> Hi Guillem--
>
> On Thu 2017-08-17 01:05:46 +0200, Guillem Jover wrote:
> > It seems to me like you are perhaps trying to reimplement dpkg source
> > format «3.0 (git)» (described in man dpkg-source)? :)
>
> Thanks for that pointer, it does seem similar.
>
> I was hoping that we could produce an actual orig.tar.gz (so that the
> rest of the tools could use it as they have traditionally) and then some
> extra thing outside of the orig.tar.gz that, combined with the tarball,
> could be used to recreate the .git/ repository well enough to be able to
> (a) recreate the tarball, and (b) cryptographically verify the tag.
>
> this would solve my use case (being able to record and ship upstream's
> cryptographic signatures, when upstream "releases" with signed tags)
> without requiring the rest of the debian infrastructure to cope with git
> bundles as "orig.tar.gz-equivalent" blobs.
>
> But if there's a plan for "3.0 (git)" to become acceptable in debian,
> then it does seem like that might be the simplest way to move forward.
>
> i'll play around with git-bundle to try to understand it better.  from a
> scan of dpkg-source(1) and the various git manpages that i'm used to
> reading, i don't understand what .gitshallow or .git/shallow are
> supposed to do.  Does it get shipped alongside the .git?  does
> .git/shallow have meaning for other tools that i should be aware of?
>
>  --dkg

Hey all,

one of pristine-tar maintainers here. Daniel's ideas made me think a
lot about this stuff recently. I've just found
https://github.com/cgwalters/git-evtag: it does not solve the problem
at hand, but the idea of solving the problem "upstream", i.e., in git,
seems reasonable to me.

So let's assume that git-archive can produce a reproducible,
uncompressed tarball, given a particular githash. Why not ask
interested upstream developers to do something like that:

  git tag -s TAGNAME -m "$(git archive --format tar HEAD | sha512sum)"

The tag proves:
  (1) the history in the git repository, as always
  (2) but also that a tar generated from this tag should have a particular 
sha512 hash

You can see how this works end-to-end: if we want to take a particular
git tag and release it in Debian, we just generate the tarball and
extract the associated tag as a crypto-proof.

Such tagging may be prohibitive for every commit, though, since it's
rather expensive to compute (or not, I just run the above command in a
fresh clone of linux kernel source and it took 9s with fs caches, and
interestingly the same with caches dropped, weird). But it should be
totally fine at least for "release tags". The cool thing is that it
could be upstreamed in git, as a flag to git-tag, or at least provided
as an extension, such as git-atag (aka git-archive-tag, you get the
idea).

What do you think?

Tomasz


signature.asc
Description: PGP signature

Bug#876232: quassel-irssi: FTBFS with GCC 7 thanks to usage of -Werror

[Andreas Beckmann]

Source: quassel-irssi
Version: 0~git20170114-1
Severity: serious
Justification: fails to build from source

Hi,

quassel-irssi FTBFS (at least) since GCC 7 was made the default compiler
(and added some new warnings):


   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/quassel-irssi-0~git20170114'
/usr/bin/make -C core
make[2]: Entering directory '/build/quassel-irssi-0~git20170114/core'
cc -std=gnu11 -Wall -Wextra -Werror -g -O2 -I/usr/include/irssi//src/ 
-I/usr/include/irssi//src/core/ -I/usr/include/irssi//src/fe-common/ 
-I/usr/include/irssi//src/fe-common/core/ -I/usr/include/irssi//src/fe-text/ 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-DUOFF_T_LONG -fPIC -DHAVE_OPENSSL -I/usr/include/quasselc -Wmissing-prototypes 
-Wmissing-declarations  -Wdate-time -D_FORTIFY_SOURCE=2  -c -o 
quasselc-connector.o quasselc-connector.c
quasselc-connector.c: In function 'handle_sync':
quasselc-connector.c:146:6: error: this statement may fall through 
[-Werror=implicit-fallthrough=]
if(!fnc)
  ^
quasselc-connector.c:148:3: note: here
   case Displayed:
   ^~~~
quasselc-connector.c:156:6: error: this statement may fall through 
[-Werror=implicit-fallthrough=]
if(!fnc)
  ^
quasselc-connector.c:158:3: note: here
   case TempRemoved:
   ^~~~
quasselc-connector.c:211:6: error: this statement may fall through 
[-Werror=implicit-fallthrough=]
if(!fnc)
  ^
...


Andreas


quassel-irssi_0~git20170114-1.log.gz
Description: application/gzip

Bug#876239: reproducible: re-deploy cbxi4a (disk failure)

[Vagrant Cascadian]

Package: jenkins.debian.org
Severity: normal
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

cbxi4a-armhf-rb.debian.net had a critical disk failure.

It's been reinstalled, so the ssh keys have changed:

256 SHA256:C8nL+YAOEhjWYH2tkeoP00sfiWi4bI2ZlI400idPBqU root@cbxi4a (ECDSA)
256 SHA256:oxxy+996R6nClC9ors/Py20vsJEjN2HrGgzvhsSwKfw root@cbxi4a (ED25519)
2048 SHA256:EDUXTiDwa7/W2WAooNdHJNTJJd+GJZypCsqcJ7axLEM root@cbxi4a (RSA)

hostname, ip address, ssh port should all be the same, and it hasn't
been removed from jenkins git... so everything just needs to be
re-deployed on the new install.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#875771: nmu: libnettle6_3.3-1+b1 liblzma5_5.2.2-1.2+b1 libdb5.35.3.28-12+b1 libselinux1_5.2.2-1.2+b1

[Adam D. Barratt]

On Tue, 2017-09-19 at 19:38 +0100, Adam D. Barratt wrote:
> Scheduled as:
> 
> nmu 4 lzma . ANY . -m "Rebuild with current sbuild to fix changelog
> date"
> nmu 3 lzma . ANY . stretch . -m "Rebuild with current sbuild to fix
> changelog date"
> nmu nettle db5.3 libselinux . ANY . stretch . -m "Rebuild with
> current sbuild to fix changelog date"

I forgot about the fun wanna-build feature of not exposing the binNMU
version for most suites, so rescheduled the last set as explicit +b2
(after the initial set got rejected for being +b1 and stable already
having that version).

> (The former being required because both unstable and stretch
> currently
> contain lzma 9.22-2+b2, and not fixing the issue in unstable seems
> silly.)
> 

Regards,

Adam

Bug#841733: Transition Opencv 3.1

[Nobuhiro Iwamatsu]

Hi,

2017-09-19 17:55 GMT+09:00 Mattia Rizzolo :
> On Tue, Sep 19, 2017 at 12:37:54PM +0900, Nobuhiro Iwamatsu wrote:
>> The following packages can be migrated with OpenCV 3.2:
>
> I should check again whether something changed since I last did my
> rebuild in July, but:
>
>> freecad
>
> this is not involved in the transition AFAIK
>
>> ros-opencv-apps
>
> this one failed for me

If we build this correctly, we need to build ros-vision-opencv first.

>
>> visp
>
> this for me failed to build on armhf
>
>> caffe
>> Not yet check
>> NOTE:  #875723
>
> also fails on armhf

This package  has long been FTBFS on armhf.

>
>> caffe-contrib
>> Not yet check
>> NOTE:  #875723
>
> failed
>
>> digikam
>> FTBFS / #841412
>> NOTE:  FTBFS on unstable #876154
>
> it built fine in july
>
>> mldemos
>> FTBFS /  #861270
>> NOTE: no rdeps: could be removed from testing
>
> it's already out of testing, so really don't bother about it.
>
>> nomacs
>> FTBFS
>> NOTE:  FTBFS on unstable  #876153
>
> previous version (-8) built fine for me

876153 is not a bug related to opencv, it is a symbol bug.

>
>
>
> BTW, I can see some free time popping up in the near future, so I should
> be able to get back on working on this from where I left it on July.
>
> No, about whether going with OCV 3.2 or 3.3… I'd kind of prefer to go
> with 3.2, as we have been test building and worked on it for a while,
> rather than risk to find ourselves in yet more failures to handle, not
> to say it would need to pass NEW again, which is kind of crowded right
> now...
>

I did not understand the meaning of "NEW", but I agree to target the
first transition as 3.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  `-

Best regards,
  Nobuhiro


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

Bug#876230: ssh-askpass-fullscreen: FTBFS: undefined reference to symbol 'XUngrabServer'

[Andreas Beckmann]

Source: ssh-askpass-fullscreen
Version: 0.4-0.1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

ssh-askpass-fullscreen/experimental FTBFS in a current
sid/experimental environment:

 debian/rules build
dh build
   dh_update_autotools_config
   dh_auto_configure
   dh_auto_build
make -j1
make[1]: Entering directory '/build/ssh-askpass-fullscreen-0.4'
cc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-fdebug-prefix-map=/build/ssh-askpass-fullscreen-0.4=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now -o 
ssh-askpass-fullscreen ssh-askpass-fullscreen.c `pkg-config --libs gtk+-2.0` 
`pkg-config --cflags gtk+-2.0`
ssh-askpass-fullscreen.c: In function 'passphrase_dialog':
ssh-askpass-fullscreen.c:275:40: warning: passing argument 1 of 
'gdk_pixbuf_new_from_xpm_data' from incompatible pointer type 
[-Wincompatible-pointer-types]
  pixbuf = gdk_pixbuf_new_from_xpm_data(ocean_stripes);
^
In file included from /usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf.h:34:0,
 from /usr/include/gtk-2.0/gdk/gdkpixbuf.h:37,
 from /usr/include/gtk-2.0/gdk/gdkcairo.h:28,
 from /usr/include/gtk-2.0/gdk/gdk.h:33,
 from /usr/include/gtk-2.0/gdk/gdkprivate.h:30,
 from /usr/include/gtk-2.0/gdk/gdkx.h:30,
 from ssh-askpass-fullscreen.c:43:
/usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf-core.h:351:12: note: expected 
'const char **' but argument is of type 'char **'
 GdkPixbuf *gdk_pixbuf_new_from_xpm_data (const char **data);
^~~~
/usr/bin/ld: /tmp/cc2IPa2e.o: undefined reference to symbol 'XUngrabServer'
//usr/lib/x86_64-linux-gnu/libX11.so.6: error adding symbols: DSO missing from 
command line
collect2: error: ld returned 1 exit status
Makefile:2: recipe for target 'all' failed
make[1]: *** [all] Error 1
make[1]: Leaving directory '/build/ssh-askpass-fullscreen-0.4'
dh_auto_build: make -j1 returned exit code 2
debian/rules:6: recipe for target 'build' failed
make: *** [build] Error 2


Andreas


ssh-askpass-fullscreen_0.4-0.1.log.gz
Description: application/gzip

Bug#876231: ruby-nmatrix: FTBFS with GCC 7: error: call of overloaded 'abs(nm::Rational&)' is ambiguous

[Andreas Beckmann]

Package: ruby-nmatrix
Version: 0.1.0~rc3-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

ruby-nmatrix FTBFS (at least) since GCC 7 was made the default compiler:

In file included from math.cpp:125:0:
math/idamax.h: In instantiation of 'int nm::math::idamax(size_t, DType*, int) 
[with DType = nm::Rational; size_t = long unsigned int]':
math/getrf.h:153:44:   required from 'int nm::math::getrf_nothrow(int, int, 
DType*, int, int*) [with bool RowMajor = true; DType = nm::Rational]'
math/getrf.h:211:37:   required from 'int nm::math::getrf(CBLAS_ORDER, int, 
int, DType*, int, int*) [with DType = nm::Rational]'
math/getrf.h:234:22:   required from 'int nm::math::clapack_getrf(CBLAS_ORDER, 
int, int, void*, int, int*) [with DType = nm::Rational]'
math.cpp:1295:3:   required from here
math/idamax.h:60:15: error: call of overloaded 'abs(nm::Rational&)' 
is ambiguous
 dmax = abs(dx[0]);
~~~^~~
In file included from /usr/include/c++/7/cstdlib:75:0,
 from /usr/include/c++/7/bits/stl_algo.h:59,
 from /usr/include/c++/7/algorithm:62,
 from math.cpp:116:
/usr/include/stdlib.h:735:12: note: candidate: int abs(int)
 extern int abs (int __x) __THROW __attribute__ ((__const__)) __wur;
^~~
In file included from /usr/include/c++/7/cstdlib:77:0,
 from /usr/include/c++/7/bits/stl_algo.h:59,
 from /usr/include/c++/7/algorithm:62,
 from math.cpp:116:
/usr/include/c++/7/bits/std_abs.h:56:3: note: candidate: long int std::abs(long 
int)
   abs(long __i) { return __builtin_labs(__i); }
   ^~~
/usr/include/c++/7/bits/std_abs.h:61:3: note: candidate: long long int 
std::abs(long long int)
   abs(long long __x) { return __builtin_llabs (__x); }
   ^~~
/usr/include/c++/7/bits/std_abs.h:70:3: note: candidate: constexpr double 
std::abs(double)
   abs(double __x)
   ^~~
/usr/include/c++/7/bits/std_abs.h:74:3: note: candidate: constexpr float 
std::abs(float)
   abs(float __x)
   ^~~
/usr/include/c++/7/bits/std_abs.h:78:3: note: candidate: constexpr long double 
std::abs(long double)
   abs(long double __x)
   ^~~


Full log attached.

Andreas


ruby-nmatrix_0.1.0~rc3-2.log.gz
Description: application/gzip

Bug#876233: backuppc: Can't backup IPv6-only hosts due to IPv4-only DNS lookups

[Axel Beckert]

Package: backuppc
Severity: important
Version: 3.3.1-4
Tags: ipv6

I have more and more IPv6-only hosts. But if I add one of them to
hosts.cfg, I always get "host not found" as error message.

In the documentation under "How BackupPC Finds Hosts", it says:

> First DNS is used to lookup the IP address given the client's name
> using perl's gethostbyname() function. This should succeed for
> machines that have fixed IP addresses that are known via DNS. You can
> manually see whether a given host have a DNS entry according to perl's
> gethostbyname function with this command:
>
> perl -e 'print(gethostbyname("myhost") ? "ok\n" : "not found\n");'

Example:

→ host ipv6.google.com
ipv6.google.com is an alias for ipv6.l.google.com.
ipv6.l.google.com has IPv6 address 2a00:1450:4016:80a::200e
$ perl -e 'print(gethostbyname("ipv6.google.com") ? "ok\n" : "not found\n");'
not found

So I can't backup this host despite SSH has no problem at all to reach
that host.

BackupPC should probably move to use Socket.pm's getaddrinfo instead as
it is IP-version agnostic.

So far I found no configuration-only workaround (i.e. disabling DNS
lookups at all as SSH does that already.)

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

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

Bug#780606: Bug# [...]

[Michael Lustfield]

To be blunt, I struggled very hard to follow the text you wrote.. especially
true for the github bug report. I have done my best to understand what the
intended message was, but if I misunderstood then I apologize in advance.


On Mon, 18 Sep 2017 14:55:12 -0400
PICCORO McKAY Lenz  wrote:
> the insane amout of dependences make the work of this package a hard made..
> 
> but a way to do its:
> 
> 1) makde a package that only use the downloaded sources that ship all
> depends

This sounds like you're suggesting that we actually make use of content within
the vendor/ directories. If that's the case then we'll need to discuss DFSG in a
bit more depth because this will cause a clear violation.

In fact, I'm aware of sources within gogs/gitea that *DOES* *NOT* meet DFSG,
and some of it never will. If this is something you're not equally aware of, I
would encourage you to review the source code within a gitea/gogs release.

Each dependency needs to be individually packaged and reviewed for DFSG
standards. This work has revealed a lot of issues that have now been resolved
(in Gitea). Unfortunately, the author/owner of gogs has no interest in adopting
these changes. (details need not be repeated here)

> 2) in the way the depends get packaged in debian, so make it depends on gogs

I do not believe we will ever see Gogs made available within Debian, at least
not given present-day circumstances.

Regardless, it would be woefully inappropriate for a gitea package to depend on
a gogs package to find build dependencies. Besides, the two have different
dependencies (gitea requires more because of more features).

It could be considered fortunate that the packaging I've done for gitea
dependencies is available for gogs. If gogs ever becomes a suitable candidate
for inclusion in Debian, there will likely be a relatively complete set of
dependencies already in place.

> the other way its that do not make usage of thos depends pacakges that
> change too many in the time!

I didn't follow this at all.


On Mon, 18 Sep 2017 15:08:21 -0400
PICCORO McKAY Lenz  wrote:

> Debian packaging pretend to made a simple gogs virtual package provided by
> gitea..
> 
> the gitea package roadmap pretend to separate from gogs, and are complety
> different..

I don't understand the usage of "pretend" in this context. The current
packaging I have been working on offers a gogs meta package that selects gitea.
This does not mean gitea is pretending to be gogs. It is a
relatively-compatible alternative.

I have not decided if I will keep this or not, but I consider worrying about it
to be about the lowest thing on my priorities list.

> gogs are focused on simplicity, no new features and only security fixeds
> gitea are focused on new features and changes too many ..

This is very much *not* the difference between the two. Gitea is a fork of gogs
that was created for entirely different reasons. Many of those reasons are why
gogs is not likely to ever exist in Debian repos. 


>>> < re: your github bug report >

Conforming to Debian policy does not come later, it comes first. Until I have a
proper Debianized package, I will not release Gitea into Debian. I /do/
however, have a lot of progress made and only a few more new dependencies that
need to pass through NEW.

If you would like to help, check out the "(un)reproducible" column here:
https://udd.debian.org/dmd/?michael%40lustfield.net#versions

Those issues need to be resolved before introducing additional packages into
Debian. Additional dependencies are needed for gitea.

-- 
Michael Lustfield

Bug#876144: lists.debian.org: Request for new mailing list: pkg-gnupg-maint

[Alexander Wirt]

On Tue, 19 Sep 2017, Daniel Kahn Gillmor wrote:

> On Tue 2017-09-19 07:18:24 +0200, Alexander Wirt wrote:
> > This is one of the examples we will probably not accept,
> 
> thanks for the prompt response, Alex.
> 
> > but we will discuss that internally again.
> 
> If you decide to not accept it, where do you recommend for packaging
> teams to have team-specific conversations that are not specifically bug
> reports?
> 
> should we adopt non-debian channels or private mail for those
> discussions?  Or is there some other recommended approach?
I am not exactly sure about the best proposal yet. Do you really need a
mailinglist for that or would some kind of maintaineralias (via tracker)
work? We are currently working on ideas. l.d.o unfortunately isn't the right
place for such tiny (sorry) maintainer lists, our tools and manpower do not 
scale well. 

One of my ideas was to improve tracker.d.o and maybe provide some (external?)
service for archiving mails (similar to gmane) with hyperkitty (the mailman3
archiver). What do you think about it? Would the combination of tracker and
an archiver work for you? 

Thanks in advance
Alex


signature.asc
Description: PGP signature

Bug#876161: ITP: RESTEasy 3.0 -- Framework for RESTful Web services and Java applications

[Timo Aaltonen]

Package: wnpp
Severity: wishlist

Package name: resteasy3.0
Version : 3.0.19
Upstream Author : Red Hat Inc.
URL : http://rest-easy.org
License : Apache-2.0/LGPL-2.1+/LGPL-3/BSD-2-clause
Programming Lang: java
Description : RESTEasy 3.0 -- Framework for RESTful Web services and
 Java applications


This is another temporary forward-port (besides tomcat8.0) for
dogtag-pki, which was broken by RESTEasy 3.1.0. Having this version in
sid allows working on the FreeIPA stack while upstream is porting
dogtag-pki to current versions.

Bug#876162: scim FTCBFS: wrongly uses AC_CHECK_FILE for build requirements

[Helmut Grohne]

Source: scim
Version: 1.4.18-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

scim fails to cross build from source, because it wrongly uses
AC_CHECK_FILE in configure.ac. That macro is intended to figure out
whether a file exists on the host machine. However it is used in some
(not all) cases to discover files on the build machine. For the latter a
simple test -f works. After doing so, scim cross builds successfully.
Please consider applying the attached patch.

Helmut
From: Helmut Grohne 
Subject: fix cross compilation

We are not interested in whether these .xsl files exist on the host machine,
but want to know whether they exist on the build machine. Thus AC_CHECK_FILE
must not be used.

Index: scim-1.4.18/configure.ac
===
--- scim-1.4.18.orig/configure.ac
+++ scim-1.4.18/configure.ac
@@ -131,20 +131,14 @@
 AC_SUBST(XSLTPROC)
 
 # Checks if docbook-style-xsl is available
-AC_CHECK_FILE(
- [/usr/share/sgml/docbook/xsl-stylesheets/html/tldp-html.xsl],
- [DOCBOOK_XSL=/usr/share/sgml/docbook/xsl-stylesheets/html/tldp-html.xsl],
- [AC_CHECK_FILE(
-  [/usr/share/sgml/docbook/xsl-stylesheets/html/docbook.xsl],
-  [DOCBOOK_XSL=/usr/share/sgml/docbook/xsl-stylesheets/html/docbook.xsl],
-   [AC_CHECK_FILE(
-[/usr/share/xml/docbook/stylesheet/nwalsh/current/html/docbook.xsl],
-[DOCBOOK_XSL=/usr/share/xml/docbook/stylesheet/nwalsh/current/html/docbook.xsl],
-[DOCBOOK_XSL=no]
-)]
-  )]
-)
-
+AC_MSG_CHECKING(docbook xsl)
+DOCBOOK_XSL=no
+for f in /usr/share/sgml/docbook/xsl-stylesheets/html/tldp-html.xsl /usr/share/sgml/docbook/xsl-stylesheets/html/docbook.xsl /usr/share/xml/docbook/stylesheet/nwalsh/current/html/docbook.xsl; do
+  test -f "$f" || continue
+  DOCBOOK_XSL=$f
+  break
+done
+AC_MSG_RESULT($DOCBOOK_XSL)
 AC_SUBST(DOCBOOK_XSL)
 
 AM_CONDITIONAL(HAVE_DOCBOOK, test x$DOCBOOK_XSL != xno)

Bug#874679: libssh2: Fails to build on stable if libssl-dev is installed

[Mikhail Gusarov]

fixed 874679 1.8.0-1
thanks

Actually, 1.8.0-1 already has this option, so there ain't much to do 
here.


On 19 Sep 2017, at 8:22, Mikhail Gusarov wrote:


Hello Wookey,

On 8 Sep 2017, at 17:52, Wookey wrote:

So it seems that the package should declare a build-conflicts with 
libssl-dev.


The better way to fix it is to explicitly build --without-openssl.

I'll do it shortly.

Mikhail.

Bug#875944: mailpost failure

[Harald Dunkel]

PS: Somehow I screwed up the news.pod file. Attached are better
patches.

Harri

Index: inn2-2.6.1/doc/pod/news.pod
===
--- inn2-2.6.1.orig/doc/pod/news.pod
+++ inn2-2.6.1/doc/pod/news.pod
@@ -29,6 +29,13 @@ field body.  Thanks to Kamil Jonca for t
 
 =item *
 
+Fixed a bug in B that was rejecting articles containing header
+fields whose length exceeded 998 bytes.  This limitation is for the
+length of a single line of a header field, not for the whole header
+field.
+
+=item *
+
 The default value for the I parameter in F
 has changed.  TLS-level compression is now disabled by default, to comply
 with the best current practices for a secure use of TLS in application
Index: inn2-2.6.1/frontends/inews.c
===
--- inn2-2.6.1.orig/frontends/inews.c
+++ inn2-2.6.1/frontends/inews.c
@@ -34,7 +34,6 @@
 #define HEADER_DELTA		20
 #define GECOSTERM(c)		\
 	((c) == ',' || (c) == ';' || (c) == ':' || (c) == LPAREN)
-#define HEADER_STRLEN		998
 
 typedef enum _HEADERTYPE {
 HTobs,
@@ -122,7 +121,7 @@ static HEADER	Table[] = {
 static void
 QuitServer(int x)
 {
-char	buff[HEADER_STRLEN];
+char	buff[MED_BUFFER];
 char	*p;
 
 if (Spooling)
@@ -196,13 +195,22 @@ TrimSpaces(char *p)
 static char *
 NextHeader(char *p)
 {
-for ( ; ; p++) {
-	if ((p = strchr(p, '\n')) == NULL)
+char *q;
+for (q = p; ; p++) {
+if ((p = strchr(p, '\n')) == NULL) {
 die("article is all headers");
-	if (!ISWHITE(p[1])) {
-	*p = '\0';
-	return p + 1;
-	}
+}
+/* Check the maximum length of a single line. */
+if (p - q + 1 > MAXARTLINELENGTH) {
+die("header line too long");
+}
+/* Check if there is a continuation line for the header. */
+if (ISWHITE(p[1])) {
+q = p + 1;
+continue;
+}
+*p = '\0';
+return p + 1;
 }
 }
 
@@ -796,7 +804,7 @@ OfferArticle(char *buff, bool Authorized
 {
 fprintf(ToServer, "post\r\n");
 SafeFlush(ToServer);
-if (fgets(buff, HEADER_STRLEN, FromServer) == NULL)
+if (fgets(buff, MED_BUFFER, FromServer) == NULL)
 sysdie(Authorized ? "Can't offer article to server (authorized)"
   : "Can't offer article to server");
 return atoi(buff);
@@ -866,8 +874,8 @@ main(int ac, char *av[])
 struct passwd	*pwp;
 char		*article;
 char		*deadfile;
-char		buff[HEADER_STRLEN];
-char		SpoolMessage[HEADER_STRLEN];
+char		buff[MED_BUFFER];
+char		SpoolMessage[MED_BUFFER];
 bool		DoSignature;
 bool		AddOrg;
 size_t		Length;
@@ -987,7 +995,7 @@ main(int ac, char *av[])
 	setbuf(ToServer, xmalloc(BUFSIZ));
 	fprintf(ToServer, "mode reader\r\n");
 	SafeFlush(ToServer);
-	if (fgets(buff, HEADER_STRLEN, FromServer) == NULL)
+	if (fgets(buff, MED_BUFFER, FromServer) == NULL)
 sysdie("cannot tell server we're reading");
 	if ((j = atoi(buff)) != NNTP_ERR_COMMAND)
 	i = j;
@@ -1024,13 +1032,6 @@ main(int ac, char *av[])
 /* Do final checks. */
 if (i == 0 && HDR(_control) == NULL)
 die("article is empty");
-for (hp = Table; hp < ARRAY_END(Table); hp++)
-	if (hp->Value && (int)strlen(hp->Value) + hp->Size > HEADER_STRLEN)
-die("%s header is too long", hp->Name);
-for (i = 0; i < OtherCount; i++)
-	if ((int)strlen(OtherHeaders[i]) > HEADER_STRLEN)
-die("header too long (maximum length is %d): %.40s...",
-HEADER_STRLEN, OtherHeaders[i]);
 
 if (Dump) {
 	/* Write the headers and a blank line. */
Index: inn2-2.6.1/doc/pod/news.pod
===
--- inn2-2.6.1.orig/doc/pod/news.pod
+++ inn2-2.6.1/doc/pod/news.pod
@@ -23,6 +23,12 @@ authentication credentials are concerned
 
 =item *
 
+B now removes empty header fields before attempting to post
+articles, and keeps trace of them in the X-Mailpost-Empty-Hdrs: header
+field body.  Thanks to Kamil Jonca for the bug report.
+
+=item *
+
 The default value for the I parameter in F
 has changed.  TLS-level compression is now disabled by default, to comply
 with the best current practices for a secure use of TLS in application
Index: inn2-2.6.1/frontends/mailpost.in
===
--- inn2-2.6.1.orig/frontends/mailpost.in
+++ inn2-2.6.1/frontends/mailpost.in
@@ -84,6 +84,8 @@ die "Directory $Tmpdir is not writable\n
 if ($debugging || $opt_n) {
 $Sendmail = "cat" ;
 $WhereTo = "cat" ;
+} else {
+$Sendmail = sprintf($Sendmail, $Maintainer);
 }
 
 #
@@ -150,6 +152,8 @@ my $hdr = undef;
 my $txt = undef;
 my $message_id ;
 my $subject = "(NONE)";
+my @emptyHdrs = ();
+my $emptyHdrsString;
 
 $_ = ;
 if (!$_) {
@@ -213,6 +217,13 @@ for (;;) {
 next if /^Approved:\s/sio && defined($approved);
 next if /^Distribution:\s/sio && 

Bug#835002: [546b2fd] Fix for Bug#835002 committed to git

[Anton Gladky]

tags 835002 + pending
thanks

Hello,

 The following change has been committed for this bug by
 Anton Gladky  on Tue, 19 Sep 2017 08:15:26 +0200.
 The fix will be in the next upload. 

Remove Christophe from uploaders. (Closes: #835002)




You can check the diff of the fix at:

;a=commitdiff;h=546b2fd

Bug#873241: cockpit: failing autopkgtests related to phantomjs

[Martin Pitt]

Control: tag -1 pending

Jeremy Bicha [2017-08-25 13:13 -0400]:
> cockpit's autopkgtests are failing on Ubuntu 17.10 "artful" now.
> 
> http://autopkgtest.ubuntu.com/packages/c/cockpit/artful/amd64
> 
> Error: PhantomJS or driver broken

With 
https://anonscm.debian.org/cgit/collab-maint/cockpit.git/commit/?id=099db0e1a55
this failure now gets ignored, I'm afraid I don't have a good short-term answer
for this either.

In exchange I added a new small "smoke test":

  
https://anonscm.debian.org/cgit/collab-maint/cockpit.git/commit/?id=44e70ed6954

This can now run in containers and thus will actually run on Debian's
infrastructure too.

Martin

Bug#874579: Pending fixes for bugs in the libhibernate-validator-java package

[pkg-java-maintainers]

tag 874579 + pending
thanks

Some bugs in the libhibernate-validator-java package are closed in
revision 0d79f6cee7bdf590f50d9ff9ba818282455f2079 in branch 'master'
by Markus Koschany

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/libhibernate-validator-java.git/commit/?id=0d79f6c

Commit message:

Add jboss-logging-tools.patch and provide the missing source files manually.

The packaging was incomplete because generated classes were not created at
build time. Apparently this is caused by a wrong or outdated invocation of 
the
jboss-logging-processor in pom.xml. This package still requires an older
version of jboss-logging-tools which behaves differently. This patch works
around the issue by applying the sources manually. They were created with
version 1.0.1.Final of jboss-logging-tools and then Log_$logger.java was
patched to fix a missing override. For more information see #874579.

Closes: #874579

Bug#876144: lists.debian.org: Request for new mailing list: pkg-gnupg-maint

[Daniel Kahn Gillmor]

On Tue 2017-09-19 08:17:15 +0200, Alexander Wirt wrote:
> I am not exactly sure about the best proposal yet. Do you really need a
> mailinglist for that or would some kind of maintaineralias (via tracker)
> work? We are currently working on ideas. l.d.o unfortunately isn't the right
> place for such tiny (sorry) maintainer lists, our tools and manpower do not 
> scale well. 

no need to apologize -- it's true that the list is relatively small (a
half-dozen people contributing at most).  I can also check with GnuPG
upstream whether they'd be willing to have just us use
gnupg-de...@gnupg.org for debian packaging-related discussion, which
might be easiest.

> One of my ideas was to improve tracker.d.o and maybe provide some (external?)
> service for archiving mails (similar to gmane) with hyperkitty (the mailman3
> archiver). What do you think about it? Would the combination of tracker and
> an archiver work for you? 

it sounds like it could work.  I'd be happy to see an archiver like
notmuch be made useful too, though i don't have the time to maintain it
either.

--dkg

Bug#876140: strip-nondeterminism: log which handlers "strip-nd"s a file

[Chris Lamb]

tags 876140 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/reproducible/strip-nondeterminism.git/commit/?id=aa9c3110421ebc6d845a06c9bd56e924c314aa57


Regards,

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

Bug#874579: hibernate-validator: incomplete packaging, missing classes make r-deps unusable

[Markus Koschany]

Control: tags -1 pending

tl;dr

I'm going to upload a new revision of libhibernate-validator-java. I
have spent several hours investigating the issue and found out that the
annotation processor of jboss-logging-tools 2.1.0 behaves somehow
differently and the translationFilesPath option is currently not
recognized. (I have checked that the option exists in 2.1.0) I have
built the source files with version 1.0.1.Final of jboss-logging-tools
on my local machine, implemented some missing methods and patched
libhibernate-validator-java. Finally PDFsam works.


I have read the documentation at [1] and [2] and searched the internet
for further information about the problem but did not manage to find a
working solution with jboss-logging-tools 2.1.0. The relevant part in
pom.xml is:



org.bsc.maven
maven-processor-plugin
2.0.2


${project.build.directory}/generated-sources/logging


org.jboss.logging.processor.apt.LoggingToolsProcessor

-AloggingVersion=3.0
-AtranslationFilesPath=${project.basedir}/src/main/resources -source 1.6
-target 1.6 -sourcepath
${project.build.directory}/generated-sources/jaxb -encoding
UTF-8



process
generate-sources

process





org.jboss.logging
jboss-logging-processor
1.0.1.Final





With version 1.0.1.Final of jboss-logging-tools the translationFilesPath
option is recognized but for unknown reasons this doesn't work with
2.1.0 anymore. I have also added jboss-logging-annotations and
jboss-logging-processor as build-dependencies but also to no avail. The
processor org.jboss.logging.processor.apt.LoggingToolsProcessor seems
correct to me.

I have explored some other routes but eventually decided that I want to
do something else for a change again.

[1] https://jboss-logging.github.io/jboss-logging-tools/#example-use-cases
[2] https://bsorrentino.github.io/maven-annotation-plugin/usage.html



signature.asc
Description: OpenPGP digital signature

Bug#876168: ITP: ruby-debugger-ruby-core-source -- Provide Ruby core source files

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

from rubygems.org/gems/debugger-ruby_core_source
dependency of gitlab 9.5

see https://lists.debian.org/debian-ruby/2017/09/msg00015.html for a
discussion







signature.asc
Description: OpenPGP digital signature

Bug#876147: [Debian-med-packaging] Bug#876147: camp: FTBFS on ppc64 and sparc64: FUNCTIONMAPPING/call error

[Flavien Bridault]

Hello,

Thanks for your report. I wonder if the issue is not because of the cast
to , whereas the function declared in
function_mapping.cpp:55 uses . I would like to try to simply test
 instead of  but I don't know how I can test that
myself.

If you have the time to test that, please do so otherwise I will try to
find how I can emulate those archs.

Cheers,


Le 19/09/2017 à 03:37, Aaron M. Ucko a écrit :
> Source: camp
> Version: 0.8.1-1
> Severity: important
> Tags: upstream
> Justification: fails to build from source (but built successfully in the past)
> User: debian-powe...@lists.debian.org
>
> Builds of camp 0.8 for ppc64 and sparc64 (both non-release
> architectures, admittedly) have been failing with nearly identical errors.
>
> ppc64: /<>/test/qt/functionmapping.cpp(97): error: in 
> "FUNCTIONMAPPING/call": check metaclass->function("f4").call(object, 
> camp::Args(1, 4, 15)).to() == 20 has failed [22 != 20]
>
> sparc64: /<>/test/qt/functionmapping.cpp(97): error: in 
> "FUNCTIONMAPPING/call": check metaclass->function("f4").call(object, 
> camp::Args(1, 4, 15)).to() == 20 has failed [21 != 20]
>
> Both are big-endian 64-bit architectures, but so is s390x, which
> (perhaps by chance?) ran into no trouble on this front.
>
> Could you please take a look?
>
> Thanks!
>

-- 
*Flavien BRIDAULT*
Ingénieur de Recherche

fbrida...@ircad.fr

*IRCAD France*
1, place de l'Hôpital - 67091 Strasbourg Cedex - FRANCE

http://www.ircad.fr/ 



signature.asc
Description: OpenPGP digital signature

Bug#876173: libreswan: [INTL:pt] Updated Portuguese translation for debconf messages

[Pedro 'm42' Ribeiro]

Package: libreswan
Version: 3.20-7
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for libreswan's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the 
Portguese Translation Team .

--
Best Regards,

"Traduz" - Portuguese Translation Team
http://www.debianpt.org

# Portuguese translation for libreswan debconf messages.
# Copyright (C) 2007 Pedro Ribeiro 
# This file is distributed under the same license as the libreswan package.
# Pedro Ribeiro , 2007-2010, 2017
#
msgid ""
msgstr ""
"Project-Id-Version: libreswan_3.20-7\n"
"Report-Msgid-Bugs-To: libres...@packages.debian.org\n"
"POT-Creation-Date: 2012-11-25 19:54-0500\n"
"PO-Revision-Date: 2017-09-11 10:28+0100\n"
"Last-Translator: Pedro Ribeiro \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../libreswan.templates:1001
msgid "Autostart Libreswan at boot?"
msgstr "Iniciar o Libreswan automaticamente no arranque?"

#. Type: boolean
#. Description
#: ../libreswan.templates:1001
msgid ""
"It is possible to have Libreswan (ipsec) to start automatically at boot time "
"by adding its init script (/etc/init.d/ipsec) to the boot sequence. Most  "
"people will prefer to configure the daemon before enabling autostart. To  "
"enable it manually, simply run \"update-rc.d ipsec defaults\"."
msgstr ""
"É possível ter o Libreswan (ipsec) iniciar automaticamente no arranque da "
"máquina ou acrescentar o seu script de arranque (/etc/init.d/ipsec) à "
"sequência de arranque. A maioria preferirá configurar o daemon antes de "
"activar o arranque automático. Para o activar manualmente, basta correr "
"\"update-rc.d ipsec defaults\"."

#. Type: boolean
#. Description
#: ../libreswan.templates:2001
msgid "Restart Libreswan now?"
msgstr "Reiniciar o Libreswan agora?"

#. Type: boolean
#. Description
#: ../libreswan.templates:2001
msgid ""
"Restarting Libreswan is recommended, since if there is a security fix, it "
"will not be applied until the daemon restarts. Most people expect the daemon "
"to restart, so this is generally a good idea. However, this might take down "
"existing connections and then bring them back up, so if you are using such "
"an Libreswan tunnel to connect for this update, restarting is not "
"recommended."
msgstr ""
"Reiniciar o Libreswan é recomendado, uma vez que se houver uma correcção de "
"segurança não será activada até que o daemon reinicie. A maioria das pessoas "
"espera que isto aconteça, portanto é normalmente uma boa ideia. No entanto "
"isto pode interromper ligações activas e recuperá-las (incluindo a ligação "
"actualmente em uso para esta actualização, portanto recomenda-se que o "
"daemon não seja reiniciado se está a usar um túnel para administração)."

#. Type: boolean
#. Description
#: ../libreswan.templates:3001
msgid "Use an X.509 certificate for this host?"
msgstr "Quer usar um certificado X.509 para esta máquina?"

#. Type: boolean
#. Description
#: ../libreswan.templates:3001
msgid ""
"An X.509 certificate for this host can be automatically created or imported. "
"It can be used to authenticate IPsec connections to other hosts and is the "
"preferred way of building up secure IPsec connections. The other possibility "
"would be to use shared secrets (passwords that are the same on both sides of "
"the tunnel) for authenticating a connection, but for a larger number of "
"connections, key based authentication is easier to administer and more "
"secure."
msgstr ""
"Este instalador pode criar automaticamente ou importar um certificado X.509 "
"para esta máquina. Este certificado pode ser usado para autenticar ligações "
"IPSec a outras máquinas e é o método preferido para criar ligações IPSec "
"seguras. A outra possibilidade é usar segredos partilhados (passwords iguais "
"de um e de outro lado do túnel IPSec) para autenticar uma ligação, mas para "
"um grande número de ligações a autenticação baseada em chaves é mais fácil "
"de administrar e mais segura."

#. Type: boolean
#. Description
#: ../libreswan.templates:3001
msgid ""
"Alternatively you can reject this option and later use the command \"dpkg-"
"reconfigure libreswan\" to come back."
msgstr ""
"Em alternativa, pode rejeitar esta opção agora e usar o comando \"dpkg-"
"reconfigure libreswan\" mais tarde."

#. Type: select
#. Choices
#: ../libreswan.templates:4001
msgid "create"
msgstr "criar"

#. Type: select
#. Choices
#: ../libreswan.templates:4001
msgid "import"
msgstr "importar"

#. Type: select
#. Description
#: ../libreswan.templates:4002
msgid "Methods for using a X.509 certificate to authenticate this host:"
msgstr "Métodos para usar um certificado X.509 para autenticar esta máquina:"

#. Type: select
#. Description
#: ../libreswan.templates:4002
msgid ""
"It 

Bug#872259: sagemath: FTBFS with Sphinx 1.6: TypeError: frompickle() takes exactly 3 arguments (4 given)

[Tobias Hansen]

Control: tags -1 +pending

Fixed in git, but we need for a libgap-sage update before the next upload.

Bug#876160: xfsdump FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: xfsdump
Version: 3.1.6+nmu2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

xfsdump fails to cross build from source, because it doesn't pass --host
to ./configure. After adding the missing option, it cross builds
successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru xfsdump-3.1.6+nmu2/debian/changelog 
xfsdump-3.1.6+nmu3/debian/changelog
--- xfsdump-3.1.6+nmu2/debian/changelog 2017-02-25 19:47:46.0 +0100
+++ xfsdump-3.1.6+nmu3/debian/changelog 2017-09-19 07:56:37.0 +0200
@@ -1,3 +1,10 @@
+xfsdump (3.1.6+nmu3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass --host to ./configure (closes: #-1)
+
+ -- Helmut Grohne   Tue, 19 Sep 2017 07:56:37 +0200
+
 xfsdump (3.1.6+nmu2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru xfsdump-3.1.6+nmu2/debian/rules 
xfsdump-3.1.6+nmu3/debian/rules
--- xfsdump-3.1.6+nmu2/debian/rules 2017-02-25 19:47:46.0 +0100
+++ xfsdump-3.1.6+nmu3/debian/rules 2017-09-19 07:56:34.0 +0200
@@ -1,7 +1,11 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
 export DH_VERBOSE=1
 export LOCAL_CONFIGURE_OPTIONS=CFLAGS=-D_FILE_OFFSET_BITS=64
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+LOCAL_CONFIGURE_OPTIONS += --build=$(DEB_BUILD_GNU_TYPE) 
--host=$(DEB_HOST_GNU_TYPE)
+endif
 
 package=xfsdump
 

Bug#876144: lists.debian.org: Request for new mailing list: pkg-gnupg-maint

[Daniel Kahn Gillmor]

On Tue 2017-09-19 07:18:24 +0200, Alexander Wirt wrote:
> This is one of the examples we will probably not accept,

thanks for the prompt response, Alex.

> but we will discuss that internally again.

If you decide to not accept it, where do you recommend for packaging
teams to have team-specific conversations that are not specifically bug
reports?

should we adopt non-debian channels or private mail for those
discussions?  Or is there some other recommended approach?

All the best,

--dkg


signature.asc
Description: PGP signature

Bug#875967: publicsuffix: FTBFS - UnicodeDecodeError during tests

[Daniel Kahn Gillmor]

Control: forcemerge 874688 875967

On Sat 2017-09-16 18:10:05 +0200, Andreas Beckmann wrote:
> the last upload of publicsuffix did FTBFS:
>
> https://buildd.debian.org/status/fetch.php?pkg=publicsuffix=all=20170828.2009-1=1504820937=0

yep, that was due to a bug in libpsl (#874688), so it would have been
fixed with a give-back to the buildd network.

since that bug has since been fixed with a new upload of libpsl, the
latest upload of publicsuffix (from about an hour ago) should rebuild
fine.

thanks for the heads-up!

--dkg

Bug#872490: vdr-plugin-osdteletext FTBFS with vdr 2.3.8

[Holger Schröder]

This version build and works with vdr 2.3.x


https://github.com/rofafor/vdr-plugin-osdteletext


Greetings

        Holger...

Bug#876166: ITP: gnome-shell-extension-tilix-shortcut -- Adds easy to use configurable keyboard shortcut for tilix

[Jonathan Carter]

Package: wnpp
Severity: wishlist
Owner: Jonathan Carter 

* Package name: gnome-shell-extension-tilix-shortcut
  Version : 1.0.0-1
  Upstream Author : Jonathan Carter 
* URL : https://git.bluemosh.com/bluemosh/gse-tilix-shortcut/
* License : GPL-2
  Programming Lang: Javascript
  Description : Adds easy to use configurable keyboard shortcut for tilix

Configuring a system-wide default for launching a terminal in
Gnome is way more tedious than it needs to be.

This extension adds an easy method for configuring this system-wide.

Bug#876135: RM: moodle -- RoQA; outdated, open security issues

[Joost van Baal-Ilić]

On Mon, Sep 18, 2017 at 10:43:54PM +0200, Moritz Muehlenhoff wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> Please remove moodle. It was blocked out of stable for a long time, #807317
> hasn't seen any followup on the call for help and the version which is now
> in unstable is no longer supported with security updates (only 3.x is).

ACK, indeed it should get removed from unstable; thanks for filing this bug.

Bye,

Joost



signature.asc
Description: Digital signature

Bug#841733: Transition Opencv 3.1

[Mattia Rizzolo]

On Tue, Sep 19, 2017 at 12:37:54PM +0900, Nobuhiro Iwamatsu wrote:
> The following packages can be migrated with OpenCV 3.2:

I should check again whether something changed since I last did my
rebuild in July, but:

> freecad

this is not involved in the transition afaik

> ros-opencv-apps

this one failed for me

> visp

this for me failed to build on armhf

> caffe
> Not yet check
> NOTE:  #875723

also fails on armhf

> caffe-contrib
> Not yet check
> NOTE:  #875723

failed

> digikam
> FTBFS / #841412
> NOTE:  FTBFS on unstable #876154

it built fine in july

> mldemos
> FTBFS /  #861270
> NOTE: no rdeps: could be removed from testing

it's already out of testing, so really don't bother about it.

> nomacs
> FTBFS
> NOTE:  FTBFS on unstable  #876153

previous version (-8) built fine for me



BTW, I can see some free time popping up in the near future, so I should
be able to get back on working on this from where I left it on July.

No, about whether going with OCV 3.2 or 3.3… I'd kind of prefer to go
with 3.2, as we have been test building and worked on it for a while,
rather than risk to find ourselves in yet more failures to handle, not
to say it would need to pass NEW again, which is kind of crowded right
now...

-- 
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#876175: manila: [INTL:pt] Updated Portuguese translation for debconf messages

[Pedro 'm42' Ribeiro]

Package: manila
Version: 1:3.0.0-5
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for manila's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the 
Portguese Translation Team .

--
Best Regards,

"Traduz" - Portuguese Translation Team
http://www.debianpt.org

# manila debconf portuguese messages
# Copyright (C) 2012 the manila'S COPYRIGHT HOLDER
# This file is distributed under the same license as the manila package.
# Pedro Ribeiro , 2012, 2017
#
msgid ""
msgstr ""
"Project-Id-Version: manila_1:3.0.0-5\n"
"Report-Msgid-Bugs-To: man...@packages.debian.org\n"
"POT-Creation-Date: 2016-03-29 13:41+\n"
"PO-Revision-Date: 2017-09-11 10:43+0100\n"
"Last-Translator: Pedro Ribeiro \n"
"Language-Team: Potuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../manila-common.templates:2001
msgid "Set up a database for Manila?"
msgstr "Configurar uma base de dados para o Manila?"

#. Type: boolean
#. Description
#: ../manila-common.templates:2001
msgid ""
"No database has been set up for Manila to use. Before continuing, you should "
"make sure you have the following information:"
msgstr ""
"Não foi definida nenhuma base de dados para ser usada pelo Manila. Antes de "
"continuar, certifique-se que tem a seguinte informação:"

#. Type: boolean
#. Description
#: ../manila-common.templates:2001
msgid ""
" * the type of database that you want to use;\n"
" * the database server hostname (that server must allow TCP connections from "
"this\n"
"   machine);\n"
" * a username and password to access the database."
msgstr ""
" * o tipo de base de dados que quer usar;\n"
" * o nome do servidor (esse servidor deve aceitar ligações TCP a partir\n"
"desta máquina);\n"
" * o nome de utilizador e palavra passe para aceder à base de dados."

#. Type: boolean
#. Description
#: ../manila-common.templates:2001
msgid ""
"If some of these requirements are missing, do not choose this option and run "
"with regular SQLite support."
msgstr ""
"Se algum destes requisitos estiver em falta, rejeite esta opção e execute "
"com o suporte SQLite normal."

#. Type: boolean
#. Description
#: ../manila-common.templates:2001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"manila\"."
msgstr ""
"Pode mudar esta definição mais tarde ao executar \"dpkg-reconfigure -plow "
"manila\"."

#. Type: string
#. Description
#: ../manila-common.templates:3001
msgid "Authentication server hostname:"
msgstr "Nome do servidor de autenticação:"

#. Type: string
#. Description
#: ../manila-common.templates:3001
msgid ""
"Please specify the hostname of the authentication server. Typically this is "
"also the hostname of the OpenStack Identity Service (Keystone)."
msgstr ""
"Indique o nome do seu servidor de autenticação. Normalmente, é o nome do "
"seu Serviço de Identidade OpenStack (Keystone)."

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../manila-common.templates:4001
msgid "Authentication server tenant name:"
msgstr "Nome do 'tenant' do servidor de autenticação:"

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../manila-common.templates:4001
msgid "Please specify the authentication server tenant name."
msgstr "Indique, por favor, o nome do 'tenant' do servidor de autenticação."

#. Type: string
#. Description
#: ../manila-common.templates:5001
msgid "Authentication server username:"
msgstr "Nome de utilizador para o servidor de autenticação:"

#. Type: string
#. Description
#: ../manila-common.templates:5001
msgid "Please specify the username to use with the authentication server."
msgstr ""
"Indique, por favor, o nome de utilizador para o servidor de autenticação."

#. Type: password
#. Description
#: ../manila-common.templates:6001
msgid "Authentication server password:"
msgstr "Palavra chave do servidor de autenticação:"

#. Type: password
#. Description
#: ../manila-common.templates:6001
msgid "Please specify the password to use with the authentication server."
msgstr ""
"Indique, 

Bug#874679: libssh2: Fails to build on stable if libssl-dev is installed

[Mikhail Gusarov]

Hello Wookey,

On 8 Sep 2017, at 17:52, Wookey wrote:

So it seems that the package should declare a build-conflicts with 
libssl-dev.


The better way to fix it is to explicitly build --without-openssl.

I'll do it shortly.

Mikhail.

Bug#825949: pam_systemd(su:session): Cannot create session: Already running in a session

[Thomas D]

Dear maintainers,

I can confirm this bug is present in an up-to-date Stretch as of today.
Are there any plans on this being fixed in Stretch?

BR
Thomas

Bug#876167: libglibmm-2.4-dev: Please update to 2.54.1 to remove C++14 requirement

[Jonathan McDowell]

Package: libglibmm-2.4-dev
Version: 2.54.0-1
Severity: important
Tags: upstream

I have just tried to prepare a new upload of Pulseview to unstable only
to have it fail with:

In file included from 
/usr/include/glibmm-2.4/glibmm/containerhandle_shared.h:23:0,
 from /usr/include/glibmm-2.4/glibmm/arrayhandle.h:21,
 from /usr/include/glibmm-2.4/glibmm.h:92,
 from /usr/include/libsigrokcxx/libsigrokcxx.hpp:78,
 from /<>/main.cpp:25:
/usr/include/glibmm-2.4/glibmm/variant.h:2012:24: error: 'std::index_sequence' 
has not been declared
   std::index_sequence)
^~

It turns out this is due to the update of glibmm2.4 to 2.54.0 in
unstable, and its use of std::index_sequence which is only available
from C++14 onwards. I note that upstream released 2.54.1 yesterday which
includes a fix to not require C++14
(https://mail.gnome.org/archives/gnome-announce-list/2017-September/msg00019.html).

Please can you get the version in unstable updated to include at least
this fix as I suspect the C++14 requirement will cause more than just
Pulseview to FTBFS.

Thanks,
J.

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

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

Versions of packages libglibmm-2.4-dev depends on:
ii  libglib2.0-dev 2.54.0-1
ii  libglibmm-2.4-1v5  2.50.1-1
ii  libsigc++-2.0-dev  2.10.0-1
ii  pkg-config 0.29-4+b1

libglibmm-2.4-dev recommends no packages.

Versions of packages libglibmm-2.4-dev suggests:
pn  libglibmm-2.4-doc  
pn  libgtkmm-3.0-dev   

-- no debconf information

Bug#876171: glare: [INTL:pt] Updated Portuguese translation for debconf messages

[Pedro 'm42' Ribeiro]

Package: glance
Version: 2:13.0.0-4
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for glance's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the 
Portguese Translation Team .

--
Best Regards,

"Traduz" - Portuguese Translation Team
http://www.debianpt.org

# glare debconf portuguese messages
# Copyright (C) 2013 THE glare COPYRIGHT HOLDER
# This file is distributed under the same license as the glare package.
# Pedro Ribeiro , 2013-2014, 2017
#
msgid ""
msgstr ""
"Project-Id-Version: glare_0.1.0-3\n"
"Report-Msgid-Bugs-To: gl...@packages.debian.org\n"
"POT-Creation-Date: 2016-09-30 16:26+0200\n"
"PO-Revision-Date: 2017-09-11 10:07+0100\n"
"Last-Translator: Pedro Ribeiro \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../glare-common.templates:2001
msgid "Set up a database for Glare?"
msgstr "Configurar uma base de dados para o Glare?"

#. Type: boolean
#. Description
#: ../glare-common.templates:2001
msgid ""
"No database has been set up for Glare to use. Before continuing, you should "
"make sure you have the following information:"
msgstr ""
"Não foi definida nenhuma base de dados para uso do Glare. Antes de "
"continuar, deve certificar-se que tem a seguinte informação:"

#. Type: boolean
#. Description
#: ../glare-common.templates:2001
msgid ""
" * the type of database that you want to use;\n"
" * the database server hostname (that server must allow TCP connections from "
"this\n"
"   machine);\n"
" * a username and password to access the database."
msgstr ""
" * o tipo de base de dados que deseja usar;\n"
" * o nome da máquina do servidor da base de dados (que tem que permitir\n"
"ligações TCP a partir desta máquina);\n"
" * um nome de utilizador e palavra-passe para aceder à base de dados."

#. Type: boolean
#. Description
#: ../glare-common.templates:2001
msgid ""
"If some of these requirements are missing, do not choose this option and run "
"with regular SQLite support."
msgstr ""
"Se não tem alguns destes requisitos, não escolha esta opção e corra com "
"suporte SQLite normal."

#. Type: boolean
#. Description
#: ../glare-common.templates:2001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"glare\"."
msgstr ""
"Pode mudar esta definição mais tarde executando \"dpkg-reconfigure -plow "
"glare\"."

#. Type: string
#. Description
#: ../glare-common.templates:3001
msgid "Authentication server hostname:"
msgstr "Nome do servidor de autenticação:"

#. Type: string
#. Description
#: ../glare-common.templates:3001
msgid ""
"Please specify the hostname of the authentication server. Typically this is "
"also the hostname of the OpenStack Identity Service (Keystone)."
msgstr ""
"Por favor especifique o nome de máquina do servidor de autenticação. "
"Tipicamente este é também o nome de máquina do Serviço de Identidade "
"OpenStack (Keystone)."

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../glare-common.templates:4001
msgid "Authentication server tenant name:"
msgstr "Nome do inquilino ('tenant') do servidor de autenticação:"

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../glare-common.templates:4001
msgid "Please specify the authentication server tenant name."
msgstr "Indique por favor o nome 'tenant' do servidor de autenticação."

#. Type: string
#. Description
#: ../glare-common.templates:5001
msgid "Authentication server username:"
msgstr "Nome de utilizador do servidor de autenticação:"

#. Type: string
#. Description
#: ../glare-common.templates:5001
msgid "Please specify the username to use with the authentication server."
msgstr ""
"Indique por favor o nome de utilizador a usar com o servidor de autenticação."

#. Type: password
#. Description
#: ../glare-common.templates:6001
msgid "Authentication server password:"
msgstr "Palavra-passe do servidor de autenticação:"

#. Type: password
#. Description
#: ../glare-common.templates:6001
msgid "Please specify the password to use with the 

Bug#876172: gnocchi: [INTL:pt] Updated Portuguese translation for debconf messages

[Pedro 'm42' Ribeiro]

Package: gnocchi
Version: 3.0.4-4
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for gnocchi's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the 
Portguese Translation Team .

--
Best Regards,

"Traduz" - Portuguese Translation Team
http://www.debianpt.org

# glance debconf portuguese messages
# Copyright (C) 2012 the glance'S COPYRIGHT HOLDER
# This file is distributed under the same license as the glance package.
# Pedro Ribeiro , 2012, 2017
#
msgid ""
msgstr ""
"Project-Id-Version: gnocchi_3.0.4-4\n"
"Report-Msgid-Bugs-To: gnoc...@packages.debian.org\n"
"POT-Creation-Date: 2016-03-29 13:10+\n"
"PO-Revision-Date: 2017-09-11 10:43+0100\n"
"Last-Translator: Pedro Ribeiro \n"
"Language-Team: Potuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: string
#. Description
#: ../gnocchi-common.templates:2001
msgid "Authentication server hostname:"
msgstr "Nome do servidor de autenticação:"

#. Type: string
#. Description
#: ../gnocchi-common.templates:2001
msgid ""
"Please specify the hostname of the authentication server for Gnocchi. "
"Typically this is also the hostname of the OpenStack Identity Service "
"(Keystone)."
msgstr ""
"Indique o nome do seu servidor de autenticação para o Gnocchi. Normalmente, "
"é o nome do seu Serviço de Identidade OpenStack (Keystone)."

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it parenthezised. Example for French:
#. locataire ("tenant")
#: ../gnocchi-common.templates:3001
msgid "Authentication server tenant name:"
msgstr "Nome do 'tenant' do servidor de autenticação:"

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it parenthezised. Example for French:
#. locataire ("tenant")
#: ../gnocchi-common.templates:3001
msgid "Please specify the authentication server tenant name."
msgstr "Indique, por favor, o nome do 'tenant' do servidor de autenticação."

#. Type: string
#. Description
#: ../gnocchi-common.templates:4001
msgid "Authentication server username:"
msgstr "Nome de utilizador para o servidor de autenticação:"

#. Type: string
#. Description
#: ../gnocchi-common.templates:4001
msgid "Please specify the username to use with the authentication server."
msgstr ""
"Indique, por favor, o nome de utilizador para o servidor de autenticação."

#. Type: password
#. Description
#: ../gnocchi-common.templates:5001
msgid "Authentication server password:"
msgstr "Palavra chave do servidor de autenticação:"

#. Type: password
#. Description
#: ../gnocchi-common.templates:5001
msgid "Please specify the password to use with the authentication server."
msgstr ""
"Indique, por favor, a palavra-chave para usar no servidor de autenticação."

#. Type: boolean
#. Description
#: ../gnocchi-common.templates:6001
msgid "Set up a database for Gnocchi?"
msgstr "Configurar uma base de dados para o Gnocchi?"

#. Type: boolean
#. Description
#: ../gnocchi-common.templates:6001
msgid ""
"No database has been set up for Gnocchi to use. Before continuing, you "
"should make sure you have the following information:"
msgstr ""
"Não foi definida nenhuma base de dados para ser usada pelo Gnocchi. Antes de "
"continuar, certifique-se que tem a seguinte informação:"

#. Type: boolean
#. Description
#: ../gnocchi-common.templates:6001
msgid ""
" * the type of database that you want to use;\n"
" * the database server hostname (that server must allow TCP connections from "
"this\n"
"   machine);\n"
" * a username and password to access the database."
msgstr ""
" * o tipo de base de dados que quer usar;\n"
" * o nome do servidor (esse servidor deve aceitar ligações TCP a partir\n"
"desta máquina);\n"
" * o nome de utilizador e palavra passe para aceder à base de dados."

#. Type: boolean
#. Description
#: ../gnocchi-common.templates:6001
msgid ""
"If some of these requirements are missing, do not choose this option and run "
"with regular SQLite support."
msgstr ""
"Se algum destes requisitos estiver em falta, rejeite esta opção e execute "
"com o suporte SQLite normal."

#. Type: boolean
#. Description
#: ../gnocchi-common.templates:6001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"gnocchi-common\"."
msgstr ""

Bug#876178: "Browse Network" gives difficult error message, consider recommending gvfs-backends

[chrysn]

Package: thunar
Version: 1.6.12-1
Severity: wishlist

Hello Thunar maintainers,

please consider recommending gvfs-backends in from Thunar. AFAICT, in a
default xfce4 installation, Thunar displays the "Browse Network"
(network://) area in its sidebar, but lacks the backends to actually
open it (message 'Failed to open "/ on ".' / 'The specified location is
not supported').

If you deem gvfs-backends too heavyweight for an XFCE4 desktop (I
counted 9 new packages on a almost fresh install: libcdio-...,
libgdata..., libgoa..., libnfs8, liboauth0, psmisc), please let me know
and I'd rephrase this as a bug against gvfs-backends, "please provide a
gvfs-backends-light" or similar (at least SSHFS and WebDAV are IMO
reasonably to be expected from a network-enabled distribution).

Other alternatives I'd see is giving a more descriptive error message
with installation instructions (of whose difficulties to get it right
upstream and cross-distribution I'm aware, thus my initial suggestion),
or hiding the network area completely when not supported.

Thanks for maintaining Thunar
chrysn

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

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

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-2
ii  exo-utils   0.10.7-1
ii  libatk1.0-0 2.26.0-2
ii  libc6   2.24-17
ii  libcairo2   1.15.8-0.1
ii  libdbus-1-3 1.11.16+really1.10.22-1
ii  libdbus-glib-1-20.108-2
ii  libexo-1-0  0.10.7-1
ii  libgdk-pixbuf2.0-0  2.36.5-4
ii  libglib2.0-02.54.0-1
ii  libgtk2.0-0 2.24.31-2
ii  libgudev-1.0-0  232-1
ii  libice6 2:1.0.9-2
ii  libnotify4  0.7.7-2
ii  libpango-1.0-0  1.40.12-1
ii  libsm6  2:1.2.2-1+b3
ii  libthunarx-2-0  1.6.12-1
ii  libxfce4ui-1-0  4.12.1-2
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  shared-mime-info1.8-1
ii  thunar-data 1.6.12-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.11.16+really1.10.22-1
ii  dbus-x11 [dbus-session-bus]   1.11.16+really1.10.22-1
ii  gvfs  1.30.4-1+b1
ii  libfontconfig12.12.3-0.2
ii  libfreetype6  2.8-0.2
ii  libpangocairo-1.0-0   1.40.12-1
ii  libpangoft2-1.0-0 1.40.12-1
ii  thunar-volman 0.8.1-2
ii  tumbler   0.1.32-1
ii  xdg-user-dirs 0.15-3
ii  xfce4-panel   4.12.1-2

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.3.1-4
ii  thunar-media-tags-plugin  0.2.1-1+b2

-- no debconf information

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature

Bug#876179: Existing bug with apache proxy_hcheck not fixed in the Debain repo

[Hosted Power Sales]

Package: apache2-bin

Version: 2.4.25-3+deb9u2
Severity: important
Issue:
 We encountered this bug most likely: 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60757

 
Whatever we do, we don't get the hccheck to run, it's very likely the above bug 
is present in the Debian repo.

 
The 2.4.25 isn't a very stable version overall it seems. Will there be any 
newer version in the repo in the future?

  Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
 Kernel: Linux 4.9.0-3-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
 Versions of packages apache2-bin depends on:
ii  libapr1                  1.5.2-5
ii  libaprutil1              1.5.4-3
ii  libaprutil1-dbd-sqlite3  1.5.4-3
ii  libaprutil1-ldap         1.5.4-3
ii  libc6                    2.24-11+deb9u1
ii  libldap-2.4-2            2.4.44+dfsg-5
ii  liblua5.2-0              5.2.4-1.1+b2
ii  libnghttp2-14            1.18.1-1
ii  libpcre3                 2:8.39-3
ii  libssl1.0.2              1.0.2l-2
ii  libxml2                  2.9.4+dfsg1-2.2+deb9u1
ii  perl                     5.24.1-3+deb9u1
ii  zlib1g                   1:1.2.8.dfsg-5
 apache2-bin recommends no packages.
 Versions of packages apache2-bin suggests:
pn  apache2-doc                                      
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  w3m [www-browser]                                0.5.3-34
 Versions of packages apache2 depends on:
ii  apache2-data         2.4.25-3+deb9u2
ii  apache2-utils        2.4.25-3+deb9u2
ii  dpkg                 1.18.24
ii  init-system-helpers  1.48
ii  lsb-base             9.20161125
ii  mime-support         3.60
ii  perl                 5.24.1-3+deb9u1
ii  procps               2:3.3.12-3
 Versions of packages apache2 recommends:
ii  ssl-cert  1.0.39
 Versions of packages apache2 suggests:
pn  apache2-doc                                      
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  w3m [www-browser]                                0.5.3-34
 Versions of packages apache2-bin is related to:
ii  apache2      2.4.25-3+deb9u2
ii  apache2-bin  2.4.25-3+deb9u2
 -- no debconf information

 

Bug#875944: mailpost failure

[Harald Dunkel]

I can't say anything about 10162, but I stumbled over the header-too-
long problem (https://inn.eyrie.org/trac/ticket/144, #10161) as well.

Attached you can find the patches for 10156 and 10161 suitable for
quilt.

Hope this helps

Regards
Harri
Index: inn2-2.6.1/doc/pod/news.pod
===
--- inn2-2.6.1.orig/doc/pod/news.pod
+++ inn2-2.6.1/doc/pod/news.pod
@@ -14,6 +14,12 @@ true and UTC is really the local time zo
 =item *
 
 Julien Elie has implemented in B the new COMPRESS command
+
+=item *
+
+B now removes empty header fields before attempting to post
+articles, and keeps trace of them in the X-Mailpost-Empty-Hdrs: header
+field body.  Thanks to Kamil Jonca for the bug report.
 described in draft-murchison-nntp-compress that extends the NNTP protocol
 to allow a connection to be effectively and efficiently compressed.
 News clients that also support that extension will be able to benefit
Index: inn2-2.6.1/frontends/mailpost.in
===
--- inn2-2.6.1.orig/frontends/mailpost.in
+++ inn2-2.6.1/frontends/mailpost.in
@@ -84,6 +84,8 @@ die "Directory $Tmpdir is not writable\n
 if ($debugging || $opt_n) {
 $Sendmail = "cat" ;
 $WhereTo = "cat" ;
+} else {
+$Sendmail = sprintf($Sendmail, $Maintainer);
 }
 
 #
@@ -150,6 +152,8 @@ my $hdr = undef;
 my $txt = undef;
 my $message_id ;
 my $subject = "(NONE)";
+my @emptyHdrs = ();
+my $emptyHdrsString;
 
 $_ = ;
 if (!$_) {
@@ -213,6 +217,13 @@ for (;;) {
 next if /^Approved:\s/sio && defined($approved);
 next if /^Distribution:\s/sio && defined($distribution);
 
+# Collect empty header field names.
+if (/^([^:]+):\s*$/) {
+# 975 = 998 - length("X-Mailpost-Empty-Hdrs: ")
+push(@emptyHdrs, $1) if length($1) < 975;
+next;
+}
+
 if (/^($exclude):\s*/sio) {
 	$real_news_hdrs .= "$_\n";
 	next;
@@ -314,6 +325,11 @@ $real_news_hdrs .= "Distribution: ${dist
 $real_news_hdrs .= "Approved: ${approved}\n" if defined($approved);
 $real_news_hdrs .= "References: ${references}\n" if defined($references);
 
+# Keep trace of empty header fields.
+$emptyHdrsString = join("\n\t", @emptyHdrs);
+$real_news_hdrs .= "X-Mailpost-Empty-Hdrs: $emptyHdrsString\n"
+if (length($emptyHdrsString) > 0);
+
 # Remove duplicate headers.
 my %headers = ();
 $real_news_hdrs =~ s/((.*?:) .*?($|\n)([ \t]+.*?($|\n))*)/$headers{lc$2}++?"":"$1"/ges;
@@ -329,7 +345,7 @@ if (!open TMPFILE,">$tmpfile") {
 if ($use_syslog) {
 syslog("err", "$msg") unless $debugging || -t STDERR;
 }
-open(TMPFILE, "|" . sprintf ($Sendmail, $Maintainer)) ||
+open(TMPFILE, "|" . $Sendmail) ||
 	die "die(no tmpfile): sendmail: $!\n" ;
 print TMPFILE <<"EOF";
 To: $Maintainer
@@ -516,7 +532,7 @@ sub mailArtAndDie {
 syslog("err", "$msg") if $use_syslog;
 print STDERR $msg,"\n" if -t STDERR ;
 
-open(SENDMAIL, "|" . sprintf ($Sendmail,$Maintainer)) ||
+open(SENDMAIL, "|" . $Sendmail) ||
 	die "die($msg): sendmail: $!\n" ;
 print SENDMAIL <<"EOF" ;
 To: $Maintainer
Index: inn2-2.6.1/doc/pod/news.pod
===
--- inn2-2.6.1.orig/doc/pod/news.pod
+++ inn2-2.6.1/doc/pod/news.pod
@@ -20,6 +20,13 @@ Julien Elie has implemented in B
 B now removes empty header fields before attempting to post
 articles, and keeps trace of them in the X-Mailpost-Empty-Hdrs: header
 field body.  Thanks to Kamil Jonca for the bug report.
+
+=item *
+
+Fixed a bug in B that was rejecting articles containing header
+fields whose length exceeded 998 bytes.  This limitation is for the
+length of a single line of a header field, not for the whole header
+field.
 described in draft-murchison-nntp-compress that extends the NNTP protocol
 to allow a connection to be effectively and efficiently compressed.
 News clients that also support that extension will be able to benefit
Index: inn2-2.6.1/frontends/inews.c
===
--- inn2-2.6.1.orig/frontends/inews.c
+++ inn2-2.6.1/frontends/inews.c
@@ -34,7 +34,6 @@
 #define HEADER_DELTA		20
 #define GECOSTERM(c)		\
 	((c) == ',' || (c) == ';' || (c) == ':' || (c) == LPAREN)
-#define HEADER_STRLEN		998
 
 typedef enum _HEADERTYPE {
 HTobs,
@@ -122,7 +121,7 @@ static HEADER	Table[] = {
 static void
 QuitServer(int x)
 {
-char	buff[HEADER_STRLEN];
+char	buff[MED_BUFFER];
 char	*p;
 
 if (Spooling)
@@ -196,13 +195,22 @@ TrimSpaces(char *p)
 static char *
 NextHeader(char *p)
 {
-for ( ; ; p++) {
-	if ((p = strchr(p, '\n')) == NULL)
+char *q;
+for (q = p; ; p++) {
+if ((p = strchr(p, '\n')) == NULL) {
 die("article is all headers");
-	if (!ISWHITE(p[1])) {
-	*p = '\0';
-	return p + 1;
-	}
+}
+/* Check the maximum length of a single line. */
+if (p - q + 1 > MAXARTLINELENGTH) {
+

Bug#875954: courier-mta: /usr/sbin/sendmail has wrong permissions

[Markus Wanner]

Control: tags -1 moreinfo

Hello Bernard,

thanks for taking time to file a bug report.

On 09/16/2017 03:47 PM, Bernard wrote:
> sendmail gets installed with setgid but has to be installed with setuid.

Could you please elaborate on why setgid is not enough (with the group
set to courier)? The change would grant extra permissions to sendmail,
which I'm hesitant to implement. Especially as I can successfully send
emails from normal user accounts using sendmail with setgid.

On 09/16/2017 07:23 PM, Willi Mann wrote:
> according to the previous maintainer, this bug was fixed in version
> 0.75.0-15. However, I never verified that (I reported the bug back
> then)

Thanks for this link. Interestingly, that very issue asked for the exact
opposite: changing from setuid to setgid. Willi Mann wrote this:

> Changing the permission from 4755 to 2755 (setgid instead of setuid bit) 
> solves 
> the issue.

Given the OP reports that sendmail currently has setgit set and that's
the case on my box as well, I conclude that Ondřej has properly applied
the patch asked for in #812235.

Kind Regards

Markus Wanner



signature.asc
Description: OpenPGP digital signature

Bug#876169: cinder: [INTL:pt] Updated Portuguese translation for debconf messages

[Pedro 'm42' Ribeiro]

Package: cinder
Version: 2:9.0.0-4
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for cinder's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the 
Portguese Translation Team .

--
Best Regards,

"Traduz" - Portuguese Translation Team
http://www.debianpt.org

# cinder debconf portuguese messages
# Copyright (C) 2013 THE CINDER COPYRIGHT HOLDER
# This file is distributed under the same license as the cinder package.
# Pedro Ribeiro , 2013-2014, 2017
#
msgid ""
msgstr ""
"Project-Id-Version: cinder_2:9.0.0-4\n"
"Report-Msgid-Bugs-To: cin...@packages.debian.org\n"
"POT-Creation-Date: 2016-03-29 12:24+\n"
"PO-Revision-Date: 2017-09-11 10:07+0100\n"
"Last-Translator: Pedro Ribeiro \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../cinder-common.templates:2001
msgid "Set up a database for Cinder?"
msgstr "Configurar uma base de dados para o Cinder?"

#. Type: boolean
#. Description
#: ../cinder-common.templates:2001
msgid ""
"No database has been set up for Cinder to use. Before continuing, you should "
"make sure you have the following information:"
msgstr ""
"Não foi definida nenhuma base de dados para uso do Cinder. Antes de "
"continuar, deve certificar-se que tem a seguinte informação:"

#. Type: boolean
#. Description
#: ../cinder-common.templates:2001
msgid ""
" * the type of database that you want to use;\n"
" * the database server hostname (that server must allow TCP connections from "
"this\n"
"   machine);\n"
" * a username and password to access the database."
msgstr ""
" * o tipo de base de dados que deseja usar;\n"
" * o nome da máquina do servidor da base de dados (que tem que permitir\n"
"ligações TCP a partir desta máquina);\n"
" * um nome de utilizador e palavra-passe para aceder à base de dados."

#. Type: boolean
#. Description
#: ../cinder-common.templates:2001
msgid ""
"If some of these requirements are missing, do not choose this option and run "
"with regular SQLite support."
msgstr ""
"Se não tem alguns destes requisitos, não escolha esta opção e corra com "
"suporte SQLite normal."

#. Type: boolean
#. Description
#: ../cinder-common.templates:2001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"cinder\"."
msgstr ""
"Pode mudar esta definição mais tarde executando \"dpkg-reconfigure -plow "
"cinder\"."

#. Type: string
#. Description
#: ../cinder-common.templates:3001
msgid "Authentication server hostname:"
msgstr "Nome do servidor de autenticação:"

#. Type: string
#. Description
#: ../cinder-common.templates:3001
msgid ""
"Please specify the hostname of the authentication server. Typically this is "
"also the hostname of the OpenStack Identity Service (Keystone)."
msgstr ""
"Por favor especifique o nome de máquina do servidor de autenticação. "
"Tipicamente este é também o nome de máquina do Serviço de Identidade "
"OpenStack (Keystone)."

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../cinder-common.templates:4001
msgid "Authentication server tenant name:"
msgstr "Nome do inquilino ('tenant') do servidor de autenticação:"

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../cinder-common.templates:4001
msgid "Please specify the authentication server tenant name."
msgstr "Indique por favor o nome 'tenant' do servidor de autenticação."

#. Type: string
#. Description
#: ../cinder-common.templates:5001
msgid "Authentication server username:"
msgstr "Nome de utilizador do servidor de autenticação:"

#. Type: string
#. Description
#: ../cinder-common.templates:5001
msgid "Please specify the username to use with the authentication server."
msgstr ""
"Indique por favor o nome de utilizador a usar com o servidor de autenticação."

#. Type: password
#. Description
#: ../cinder-common.templates:6001
msgid "Authentication server password:"
msgstr "Palavra-passe do servidor de autenticação:"

#. Type: password
#. Description
#: ../cinder-common.templates:6001
msgid "Please specify the 

Bug#876170: glance: [INTL:pt] Updated Portuguese translation for debconf messages

[Pedro 'm42' Ribeiro]

Package: glance
Version: 2:13.0.0-4
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for glance's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the 
Portguese Translation Team .

--
Best Regards,

"Traduz" - Portuguese Translation Team
http://www.debianpt.org

# glance debconf portuguese messages
# Copyright (C) 2012 the glance'S COPYRIGHT HOLDER
# This file is distributed under the same license as the glance package.
# Pedro Ribeiro , 2012, 2017
#
msgid ""
msgstr ""
"Project-Id-Version: glance_2:13.0.0-4\n"
"Report-Msgid-Bugs-To: gla...@packages.debian.org\n"
"POT-Creation-Date: 2016-03-29 13:00+\n"
"PO-Revision-Date: 2017-09-11 10:43+0100\n"
"Last-Translator: Pedro Ribeiro \n"
"Language-Team: Potuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: select
#. Choices
#: ../glance-common.templates:2001
msgid "keystone"
msgstr "keystone"

#. Type: select
#. Choices
#: ../glance-common.templates:2001
msgid "caching"
msgstr "caching"

#. Type: select
#. Choices
#: ../glance-common.templates:2001
msgid "keystone+caching"
msgstr "keystone+caching"

#. Type: select
#. Choices
#: ../glance-common.templates:2001
msgid "cachemanagement"
msgstr "cachemanagement"

#. Type: select
#. Choices
#: ../glance-common.templates:2001
msgid "keystone+cachemanagement"
msgstr "keystone+cachemanagement"

#. Type: select
#. Description
#: ../glance-common.templates:2002
msgid "Pipeline flavor:"
msgstr "Tipo de pipeline:"

#. Type: select
#. Description
#: ../glance-common.templates:2002
msgid "Please specify the flavor of the pipeline to be used by Glance."
msgstr "Por favor indique o tipo de pipeline a ser utilizado pelo Glance."

#. Type: select
#. Description
#: ../glance-common.templates:2002
msgid ""
"If you use the OpenStack Identity Service (Keystone), you might want to "
"select \"keystone\". If you don't use this service, you can safely choose "
"\"caching\" only."
msgstr ""
"Se usar o Serviço de Identidade OpenStack (Keystone), pode querer escolher "
"\"keystone\". Se não usar este serviço, apenas pode escolher com segurança "
"\"caching\"."

#. Type: string
#. Description
#: ../glance-common.templates:3001
msgid "Authentication server hostname:"
msgstr "Nome do servidor de autenticação:"

#. Type: string
#. Description
#: ../glance-common.templates:3001
msgid ""
"Please specify the hostname of the authentication server for Glance. "
"Typically this is also the hostname of the OpenStack Identity Service "
"(Keystone)."
msgstr ""
"Indique o nome do seu servidor de autenticação para o Glance. Normalmente, é "
"o nome do seu Serviço de Identidade OpenStack (Keystone)."

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it parenthezised. Example for French:
#. locataire ("tenant")
#: ../glance-common.templates:4001
msgid "Authentication server tenant name:"
msgstr "Nome do 'tenant' do servidor de autenticação:"

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it parenthezised. Example for French:
#. locataire ("tenant")
#: ../glance-common.templates:4001
msgid "Please specify the authentication server tenant name."
msgstr "Indique, por favor, o nome do 'tenant' do servidor de autenticação."

#. Type: string
#. Description
#: ../glance-common.templates:5001
msgid "Authentication server username:"
msgstr "Nome de utilizador para o servidor de autenticação:"

#. Type: string
#. Description
#: ../glance-common.templates:5001
msgid "Please specify the username to use with the authentication server."
msgstr ""
"Indique, por favor, o nome de utilizador para o servidor de autenticação."

#. Type: password
#. Description
#: ../glance-common.templates:6001
msgid "Authentication server password:"
msgstr "Palavra chave do servidor de autenticação:"

#. Type: password
#. Description
#: ../glance-common.templates:6001
msgid "Please specify the password to use with the authentication server."
msgstr ""
"Indique, por favor, a palavra-chave para usar no servidor de autenticação."

#. Type: boolean
#. Description
#: ../glance-common.templates:7001
msgid "Set up a database for Glance?"
msgstr "Configurar uma base de dados para o Glance?"

#. Type: boolean
#. Description
#: 

Bug#876174: magnum: [INTL:pt] Updated Portuguese translation for debconf messages

[Pedro 'm42' Ribeiro]

Package: magnum
Version: 3.1.1-5
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for magnum's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the 
Portguese Translation Team .

--
Best Regards,

"Traduz" - Portuguese Translation Team
http://www.debianpt.org

# magnum debconf portuguese messages
# Copyright (C) 2012 the magnum'S COPYRIGHT HOLDER
# This file is distributed under the same license as the magnum package.
# Pedro Ribeiro , 2012, 2017
#
msgid ""
msgstr ""
"Project-Id-Version: magnum_3.1.1-5\n"
"Report-Msgid-Bugs-To: mag...@packages.debian.org\n"
"POT-Creation-Date: 2016-03-29 13:38+\n"
"PO-Revision-Date: 2017-09-11 10:43+0100\n"
"Last-Translator: Pedro Ribeiro \n"
"Language-Team: Potuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../magnum-common.templates:2001
msgid "Set up a database for Magnum?"
msgstr "Configurar uma base de dados para o Magnum?"

#. Type: boolean
#. Description
#: ../magnum-common.templates:2001
msgid ""
"No database has been set up for Magnum to use. Before continuing, you should "
"make sure you have the following information:"
msgstr ""
"Não foi definida nenhuma base de dados para ser usada pelo Magnum. Antes de "
"continuar, certifique-se que tem a seguinte informação:"

#. Type: boolean
#. Description
#: ../magnum-common.templates:2001
msgid ""
" * the type of database that you want to use;\n"
" * the database server hostname (that server must allow TCP connections from "
"this\n"
"   machine);\n"
" * a username and password to access the database."
msgstr ""
" * o tipo de base de dados que quer usar;\n"
" * o nome do servidor (esse servidor deve aceitar ligações TCP a partir\n"
"desta máquina);\n"
" * o nome de utilizador e palavra passe para aceder à base de dados."

#. Type: boolean
#. Description
#: ../magnum-common.templates:2001
msgid ""
"If some of these requirements are missing, do not choose this option and run "
"with regular SQLite support."
msgstr ""
"Se algum destes requisitos estiver em falta, rejeite esta opção e execute "
"com o suporte SQLite normal."

#. Type: boolean
#. Description
#: ../magnum-common.templates:2001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"magnum-common\"."
msgstr ""
"Pode mudar esta definição mais tarde ao executar \"dpkg-reconfigure -plow "
"magnum-common\"."

#. Type: string
#. Description
#: ../magnum-common.templates:3001
msgid "Authentication server hostname:"
msgstr "Nome do servidor de autenticação:"

#. Type: string
#. Description
#: ../magnum-common.templates:3001
msgid ""
"Please specify the hostname of the authentication server. Typically this is "
"also the hostname of the OpenStack Identity Service (Keystone)."
msgstr ""
"Indique o nome do seu servidor de autenticação. Normalmente, é o nome do "
"seu Serviço de Identidade OpenStack (Keystone)."

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../magnum-common.templates:4001
msgid "Authentication server tenant name:"
msgstr "Nome do 'tenant' do servidor de autenticação:"

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../magnum-common.templates:4001
msgid "Please specify the authentication server tenant name."
msgstr "Indique, por favor, o nome do 'tenant' do servidor de autenticação."

#. Type: string
#. Description
#: ../magnum-common.templates:5001
msgid "Authentication server username:"
msgstr "Nome de utilizador para o servidor de autenticação:"

#. Type: string
#. Description
#: ../magnum-common.templates:5001
msgid "Please specify the username to use with the authentication server."
msgstr ""
"Indique, por favor, o nome de utilizador para o servidor de autenticação."

#. Type: password
#. Description
#: ../magnum-common.templates:6001
msgid "Authentication server password:"
msgstr "Palavra chave do servidor de autenticação:"

#. Type: password
#. Description
#: ../magnum-common.templates:6001
msgid "Please specify the password to use with the authentication server."
msgstr ""

Bug#876176: senlin: [INTL:pt] Updated Portuguese translation for debconf messages

[Pedro 'm42' Ribeiro]

Package: senlin
Version: 2.0.0-3
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for senlin's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the 
Portguese Translation Team .

--
Best Regards,

"Traduz" - Portuguese Translation Team
http://www.debianpt.org

# senlin debconf portuguese messages
# Copyright (C) 2012 the senlin'S COPYRIGHT HOLDER
# This file is distributed under the same license as the senlin package.
# Pedro Ribeiro , 2012, 2017
#
msgid ""
msgstr ""
"Project-Id-Version: senlin_2.0.0-3\n"
"Report-Msgid-Bugs-To: sen...@packages.debian.org\n"
"POT-Creation-Date: 2016-01-23 13:55+\n"
"PO-Revision-Date: 2017-09-11 10:43+0100\n"
"Last-Translator: Pedro Ribeiro \n"
"Language-Team: Potuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../senlin-common.templates:2001
msgid "Set up a database for Senlin?"
msgstr "Configurar uma base de dados para o Senlin?"

#. Type: boolean
#. Description
#: ../senlin-common.templates:2001
msgid ""
"No database has been set up for Senlin to use. Before continuing, you should "
"make sure you have the following information:"
msgstr ""
"Não foi definida nenhuma base de dados para ser usada pelo Senlin. Antes de "
"continuar, certifique-se que tem:"

#. Type: boolean
#. Description
#: ../senlin-common.templates:2001
msgid ""
" * the type of database that you want to use;\n"
" * the database server hostname (that server must allow TCP connections from "
"this\n"
"   machine);\n"
" * a username and password to access the database."
msgstr ""
" * o tipo de base de dados que quer usar;\n"
" * o nome do servidor (esse servidor deve aceitar ligações TCP a partir\n"
"desta máquina);\n"
" * o nome de utilizador e palavra passe para aceder à base de dados."

#. Type: boolean
#. Description
#: ../senlin-common.templates:2001
msgid ""
"If some of these requirements are missing, do not choose this option and run "
"with regular SQLite support."
msgstr ""
"Se algum destes requisitos estiver em falta, rejeite esta opção e execute "
"com o suporte SQLite normal."

#. Type: boolean
#. Description
#: ../senlin-common.templates:2001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"senlin-common\"."
msgstr ""
"Pode mudar esta definição mais tarde ao executar \"dpkg-reconfigure -plow "
"senlin-common\"."

#. Type: string
#. Description
#: ../senlin-common.templates:3001
msgid "Authentication server hostname:"
msgstr "Nome do servidor de autenticação:"

#. Type: string
#. Description
#: ../senlin-common.templates:3001
msgid ""
"Please specify the hostname of the authentication server. Typically this is "
"also the hostname of the OpenStack Identity Service (Keystone)."
msgstr ""
"Indique o nome do seu servidor de autenticação. Normalmente, é o nome do "
"seu Serviço de Identidade OpenStack (Keystone)."

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../senlin-common.templates:4001
msgid "Authentication server tenant name:"
msgstr "Nome do 'tenant' do servidor de autenticação:"

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../senlin-common.templates:4001
msgid "Please specify the authentication server tenant name."
msgstr "Indique, por favor, o nome do 'tenant' do servidor de autenticação."

#. Type: string
#. Description
#: ../senlin-common.templates:5001
msgid "Authentication server username:"
msgstr "Nome de utilizador para o servidor de autenticação:"

#. Type: string
#. Description
#: ../senlin-common.templates:5001
msgid "Please specify the username to use with the authentication server."
msgstr ""
"Indique, por favor, o nome de utilizador para o servidor de autenticação."

#. Type: password
#. Description
#: ../senlin-common.templates:6001
msgid "Authentication server password:"
msgstr "Palavra chave do servidor de autenticação:"

#. Type: password
#. Description
#: ../senlin-common.templates:6001
msgid "Please specify the password to use with the authentication server."
msgstr ""
"Indique, por favor, a 

Bug#876177: watcher: [INTL:pt] Updated Portuguese translation for debconf messages

[Pedro 'm42' Ribeiro]

Package: watcher
Version: 0.30.0-5
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for watcher's debconf messages.
Feel free to use it.

For translation updates please contact 'Last Translator' or the 
Portguese Translation Team .

--
Best Regards,

"Traduz" - Portuguese Translation Team
http://www.debianpt.org

# watcher debconf portuguese messages
# Copyright (C) 2013 THE Watcher COPYRIGHT HOLDER
# This file is distributed under the same license as the watcher package.
# Pedro Ribeiro , 2013-2014, 2017
#
msgid ""
msgstr ""
"Project-Id-Version: watcher_0.30.0-5\n"
"Report-Msgid-Bugs-To: watc...@packages.debian.org\n"
"POT-Creation-Date: 2016-03-29 12:24+\n"
"PO-Revision-Date: 2017-09-11 10:27+0100\n"
"Last-Translator: Pedro Ribeiro \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid "Set up a database for Watcher?"
msgstr "Configurar uma base de dados para o Watcher?"

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid ""
"No database has been set up for Watcher to use. Before continuing, you should "
"make sure you have the following information:"
msgstr ""
"Não foi definida nenhuma base de dados para uso do Watcher. Antes de "
"continuar, deve certificar-se que tem a seguinte informação:"

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid ""
" * the type of database that you want to use;\n"
" * the database server hostname (that server must allow TCP connections from "
"this\n"
"   machine);\n"
" * a username and password to access the database."
msgstr ""
" * o tipo de base de dados que deseja usar;\n"
" * o nome da máquina do servidor da base de dados (que tem que permitir\n"
"ligações TCP a partir desta máquina);\n"
" * um nome de utilizador e palavra-passe para aceder à base de dados."

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid ""
"If some of these requirements are missing, do not choose this option and run "
"with regular SQLite support."
msgstr ""
"Se não tem alguns destes requisitos, não escolha esta opção e corra com "
"suporte SQLite normal."

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"watcher\"."
msgstr ""
"Pode mudar esta definição mais tarde executando \"dpkg-reconfigure -plow "
"watcher\"."

#. Type: string
#. Description
#: ../watcher-common.templates:3001
msgid "Authentication server hostname:"
msgstr "Nome do servidor de autenticação:"

#. Type: string
#. Description
#: ../watcher-common.templates:3001
msgid ""
"Please specify the hostname of the authentication server. Typically this is "
"also the hostname of the OpenStack Identity Service (Keystone)."
msgstr ""
"Por favor especifique o nome de máquina do servidor de autenticação. "
"Tipicamente este é também o nome de máquina do Serviço de Identidade "
"OpenStack (Keystone)."

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../watcher-common.templates:4001
msgid "Authentication server tenant name:"
msgstr "Nome do inquilino ('tenant') do servidor de autenticação:"

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../watcher-common.templates:4001
msgid "Please specify the authentication server tenant name."
msgstr "Indique por favor o nome 'tenant' do servidor de autenticação."

#. Type: string
#. Description
#: ../watcher-common.templates:5001
msgid "Authentication server username:"
msgstr "Nome de utilizador do servidor de autenticação:"

#. Type: string
#. Description
#: ../watcher-common.templates:5001
msgid "Please specify the username to use with the authentication server."
msgstr ""
"Indique por favor o nome de utilizador a usar com o servidor de autenticação."

#. Type: password
#. Description
#: ../watcher-common.templates:6001
msgid "Authentication server password:"
msgstr "Palavra-passe do servidor de autenticação:"

#. Type: password
#. Description
#: ../watcher-common.templates:6001

Bug#876152: RFS: luakit/2017.08.10-1

[Andrey Rahmatullin]

Control: tags -1 + moreinfo

Even the mentors page lists lots of problems. Please fix them.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#737796: may be use the newly proposed License-grant field

[Dominique Dumont]

On Monday, 18 September 2017 22:48:30 CEST you wrote:
> I like this new feature and would be in favour making it real.

err, I'm not sure which new feature you refer to .. :-/

Do you mean the "support Files: paragraph with both abbreviated names and 
license paragraph" or the new License-Grant field ?

All the best
-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#876163: synergy FTCBFS: runs cmake for the build architecture

[Helmut Grohne]

Source: synergy
Version: 1.8.8-stable+dfsg.1-1
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

synergy fails to cross build from source, because it runs cmake for the
build architecture. Since coming up with the right flags for cmake, the
easiest way is to let dh_auto_configure do that. After doing so, the
build proceeds much further and fails with a qmake problem that needs to
be addressed in qt. Please consider applying the attached patch and
revisiting full cross compilation after #875199. Please close this bug
when addressing the cmake issue even if synergy does not cross build.

Helmut
diff --minimal -Nru synergy-1.8.8-stable+dfsg.1/debian/changelog 
synergy-1.8.8-stable+dfsg.1/debian/changelog
--- synergy-1.8.8-stable+dfsg.1/debian/changelog2017-03-12 
00:38:53.0 +0100
+++ synergy-1.8.8-stable+dfsg.1/debian/changelog2017-09-19 
08:25:50.0 +0200
@@ -1,3 +1,10 @@
+synergy (1.8.8-stable+dfsg.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Address FTCBFS: Run cmake for the host architecture. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 19 Sep 2017 08:25:50 +0200
+
 synergy (1.8.8-stable+dfsg.1-1) unstable; urgency=low
 
   * New upstream version.
diff --minimal -Nru synergy-1.8.8-stable+dfsg.1/debian/rules 
synergy-1.8.8-stable+dfsg.1/debian/rules
--- synergy-1.8.8-stable+dfsg.1/debian/rules2017-03-12 00:38:53.0 
+0100
+++ synergy-1.8.8-stable+dfsg.1/debian/rules2017-09-19 08:25:50.0 
+0200
@@ -18,23 +18,15 @@
 CFLAGS += $(CPPFLAGS)
 CXXFLAGS += $(CPPFLAGS)
 
-# These are used for cross-compiling and for saving the configure script
-# from having to guess our platform (since we know it already)
-DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
-DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
-
 # Run the test suite unless explicitly requested not to.
 ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
 TEST_TARGET = test
 endif
 
 
-builddir:
-   mkdir builddir
-
-config.h: CMakeLists.txt builddir
+config.h: CMakeLists.txt
dh_testdir
-   (cd builddir && cmake ..)
+   dh_auto_configure --buildsystem=cmake --builddirectory=builddir
 
 src/gui/Makefile:
(cd src/gui && qmake gui.pro "CONFIG+=release" 
"QMAKE_CFLAGS_RELEASE+=$(CFLAGS)" "QMAKE_CXXFLAGS_RELEASE+=$(CXXFLAGS)" 
"QMAKE_LFLAGS_RELEASE+=$(LDFLAGS)" "QMAKE_VERSION_STAGE=stable" 
"QMAKE_VERSION_REVISION=debian" -r)
@@ -50,18 +42,18 @@
 
 # Main targets.
 
-bin/unittests: builddir config.h
+bin/unittests: config.h
dh_testdir
(cd builddir && $(MAKE) VERBOSE=1)
 
-bin/synergy: builddir src/gui/Makefile
+bin/synergy: src/gui/Makefile
dh_testdir
(cd src/gui && $(MAKE))
 
 src/test/guitests/Makefile:
(cd src/test/guitests && qmake guitests.pro "CONFIG+=release" 
"QMAKE_CFLAGS_RELEASE+=$(CFLAGS)" "QMAKE_CXXFLAGS_RELEASE+=$(CXXFLAGS)" 
"QMAKE_LFLAGS_RELEASE+=$(LDFLAGS)" -r)
 
-bin/guitests: bin/synergy builddir src/test/guitests/Makefile
+bin/guitests: bin/synergy src/test/guitests/Makefile
dh_testdir
(cd src/test/guitests && $(MAKE))
 

Bug#876165: mark bin86 Multi-Arch: foreign

[Helmut Grohne]

Package: bin86
Version: 0.16.17-3.2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:mbr

mbr fails to cross build from source, because it fails running as86 from
the bin86 package. bin86 is installed for the host architecture, but it
should come from the build architecture. That can be done by marking it
Multi-Arch: foreign. I think such a marking is correct, because the
output of the tools in bin86 does not depend on the architecture it was
built on: It always operates on x86 assembly. Please consider applying
the attached patch.

Helmut
diff -u linux86-0.16.17/debian/changelog linux86-0.16.17/debian/changelog
--- linux86-0.16.17/debian/changelog
+++ linux86-0.16.17/debian/changelog
@@ -1,3 +1,10 @@
+linux86 (0.16.17-3.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark bin86 Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 19 Sep 2017 09:17:28 +0200
+
 linux86 (0.16.17-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u linux86-0.16.17/debian/control linux86-0.16.17/debian/control
--- linux86-0.16.17/debian/control
+++ linux86-0.16.17/debian/control
@@ -6,6 +6,7 @@
 
 Package: bin86
 Architecture: any
+Multi-Arch: foreign
 Priority: optional
 Depends: ${bin86:Depends}
 Conflicts: linux86

Bug#876143: [Pkg-utopia-maintainers] Bug#876143: udisks2-btrfs: Dependency on libblockdev-btrfs should be libblockdev-btrfs2

[Michael Biebl]

Control: severity -1 serious

Am 19.09.2017 um 01:41 schrieb Axel Beckert:
> Package: udisks2-btrfs
> Version: 2.7.3-3
> 
> Dear Utopia maintainers,
> 
> udisks2-btrfs depends on libblockdev-btrfs which doesn't exist.
> 
> What exists is libblockdev-btrfs2, so I assume there is a "2" missing in
> that dependency.

Indeed. Will be fixed in the next upload.
Thanks for spotting.




signature.asc
Description: OpenPGP digital signature

Bug#876055: Environment variable handling for reproducible builds

[Ximin Luo]

Simon McVittie:
> On Mon, 18 Sep 2017 at 18:00:51 -0700, Vagrant Cascadian wrote:
>> [..]
>>
>> I consider unintended variables that affect the build output a bug, and
>> variables designed and intended to change the behavior of the toolchain
>> expected, reasonable behavior.
> 
> There is a *huge* number of variables that are intended to change
> behaviour, and may or may not affect the behaviour of this specific
> package. Which of your categories are these in?
> 
> For example, basically any well-behaved programming language or
> programming-language-like environment has an equivalent of PYTHONPATH,
> PERL5LIB, PKG_CONFIG_PATH and similar variables, [..]
> 
> Similarly, there is an intractably huge number of environment variables
> that can affect the result of Automake and make. Do you know about all
> of them? Including RM, PC, AR, LOADLIBES (and those are just for make's
> implicit rules)? [..]
> 

I agree with this and this matches my own thoughts back in:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844431#324
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844431#369

> I think the assumption has to be that every environment variable is
> potentially intended to affect the build unless otherwise stated [..]
> [..] It would be most useful if we were to identify a
> restricted subset of environment variables for which there is consensus
> that the variable is meant to be merely user preference and shouldn't
> affect the build [..]
> 
> Perhaps those variables should be a whitelist, or perhaps there is
> some wording for Policy that would identify them while excluding the
> legitimately build-affecting ones - but either way I think the
> assumption should be "there is a limited subset of environment
> variables that are required to preserve reproducibility when varied,
> and the rest are uninteresting".
> 

These variables shouldn't be a whitelist because different buildsystems all the 
time can invent their own variables to affect themselves. We can't really 
"predict" something like PERL5LIB.

However, neither should it be a blacklist because different run-time programs 
invent their own variables all the time to affect themselves, but in a way that 
really should not affect build processes. I have to set LANG=XX.YY in my user 
environment, that doesn't mean that all my builds should run differently from 
people in other countries.

Therefore, I think it is better to try to reach some wording for Policy that 
communicates *intent*. Then, tools like dpkg-buildflag can have their own 
envvars that they force-set, which would be a subset of the ones allowed by 
Policy. Tools like reprotest can vary certain envvars that are "obviously" 
shouldn't affect the build like LC_ALL, USER, etc. Then in the middle there 
will be certain variables like RM and AR that could affect the build, which 
should be clear by Policy wording, but are too cumbersome to have 
dpkg-buildpackage try to enumerate a full whitelist and force-set them to a 
fixed value.

Interpreter variables like PER5LIB and PYTHONPATH we would have to assume fall 
in the first category ("they are allowed to affect the build output") even 
though arguably they are also "run-time variables" because they are very tied 
to the interpreter and probably only developers really want to set the for 
specific purposes.

So let's throw some wording out there already. To quote my earlier proposal:

> I would suggest amending:
> 
> - a set of environment variable values; and
> + a set of reserved environment variable values; and
> 
> then later:
> 
> + A "reserved" environment variable is defined as DEB_*, DPKG_*, 
> SOURCE_DATE_EPOCH, BUILD_PATH_PREFIX_MAP, variables listed by dpkg-buildflags 
> and other variables explicitly used by buildsystems to affect build output, 
> excluding any variables used by non-build programs to affect their behaviour. 
> Explicitly, this excludes TERM, HOME, LOGNAME, USER [..]

(The last time I erroneously included PATH in the final "excluded" list - 
because we have varied PATH but in a really trivial way on tests.r-b.org for 
ages - but I now agree with you that we shouldn't expect reproducibility when 
PATH is varied.)

My reasoning, as echoed by others on this thread already, was:

> some other variables are used by non-build tools, such as LC_*, USER, etc. 
> Since they affect non-build programs, they possibly may be set in a 
> developer's normal environment, so just running "debian/rules build" will 
> pick these up. Then, the build should stay the same despite these other 
> variables.

X

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

Bug#876225: Switch schroot to use overlay fs

[Vagrant Cascadian]

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

Branch for jenkins.debian.net "schroot-overlay" available at:

  
https://anonscm.debian.org/cgit/users/vagrant/jenkins.debian.net.git/log/?h=schroot-overlay

Patch included below for easy reference.

live well,
  vagrant

From e6fde8ffe8a01b594670e8dd1b9a9fd8a08a3f58 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 19 Sep 2017 13:15:19 -0700
Subject: [PATCH] Switch schroot to use overlay fs, as aufs is no longer
 supported out of the box in linux 4.x kernels.

---
 bin/schroot-create.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/schroot-create.sh b/bin/schroot-create.sh
index 5418b180..6c8bcb5b 100755
--- a/bin/schroot-create.sh
+++ b/bin/schroot-create.sh
@@ -275,7 +275,7 @@ sudo tee /etc/schroot/chroot.d/jenkins-"$TARGET" <<-__END__
type=directory
root-users=jenkins
source-root-users=jenkins
-   union-type=aufs
+   union-type=overlay
__END__
 
 echo "schroot $TARGET set up successfully in $SCHROOT_BASE/$TARGET - exiting 
now."
-- 
2.11.0



signature.asc
Description: PGP signature

Bug#876224: dak: dak rm -nR throws "SAWarning: Textual SQL expression"-warnings on stretch

[Niels Thykier]

Package: dak
Severity: minor

Doing a dak rm -nR on respighi (upgraded to stretch) gave the
following warning:

"""
/usr/lib/python2.7/dist-packages/sqlalchemy/sql/elements.py:3795: SAWarning: 
Textual SQL expression '\nSELECT s.source,...' should be explicitly 
declared as text('\nSELECT s.source,...') (this warning may be 
suppressed after 10 occurrences)
  {"expr": util.ellipses_string(element)})
# Broken Build-Depends:
"""

(actually, I think the warning appeared twice; once for Depends and once for 
Build-Depends, but scroll back buffer wasn't large enough to hold both).

The command still appears to function and produce the proper output
and accordingly the severity is "minor".

Thanks,
~Niels

Bug#835120: lintian: false positive: virtual-package-depends-without-real-package-depends for bacula-director

[Chris Lamb]

retitle 835120 lintian: false positive: 
virtual-package-depends-without-real-package-depends for bacula-director
thanks

Mattia Rizzolo wrote:

> > So it had nothing to do with experimental as I suspected first.
>
> Indeed it hasn't at all.

Retitling bug to match updated synopsis. :)


Regards,

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

Bug#874208: octave: audiodevinfo makes octave segfault when jackd is running

[Mike Miller]

On Tue, Sep 19, 2017 at 13:12:27 +0200, Peter P. wrote:
> Thank you Mike, switching to jackd2 does work for me as well! I am a bit
> hesitant to switch my system to jackd2 as there are some other
> applications that depend (more) on jackd1. I wonder if this workaround,
> for which I am very thankful, means that the crash with jackd1 will not
> me looked into further, or if it may be worked on nevertheless.

I also get success with jackd1:

$ jackd -r -d alsa -d hw:1 -D -r 44100 &
[1] 5042
jackd 0.125.0rc1
...
$ octave-cli -q
>> devs = audiodevinfo;  ## no crash
>> devs.output.Name
ans = HDA Intel HDMI: 0 (hw:0,3) (ALSA)
ans = HDA Intel HDMI: 1 (hw:0,7) (ALSA)
ans = HDA Intel HDMI: 2 (hw:0,8) (ALSA)
ans = HDA Intel HDMI: 3 (hw:0,9) (ALSA)
ans = HDA Intel HDMI: 4 (hw:0,10) (ALSA)
ans = hdmi (ALSA)
ans = default (ALSA)
ans = system (JACK Audio Connection Kit)
>> x = audioplayer (y, fs, nbits, 7);  ## jack ID == 7
>> play (x);  ## produces audio

I'm sorry but I use neither jackd1 nor jackd2, so this is probably as
far as I can investigate myself. And as far as I can tell they both work
with Octave. If you can investigate further and find what is causing
this on your system, please do report back. Or if you find that you can
reproduce this on a clean system and give instructions for how to do so,
someone may be able to help. But so far this looks unreproducible to me.

-- 
mike


signature.asc
Description: PGP signature

Bug#876217: Pending fixes for bugs in the libwww-dict-leo-org-perl package

[pkg-perl-maintainers]

tag 876217 + pending
thanks

Some bugs in the libwww-dict-leo-org-perl package are closed in
revision 0d8065f53978e208444a6000970a6be072a6e680 in branch 'master'
by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libwww-dict-leo-org-perl.git/commit/?id=0d8065f

Commit message:

New upstream release. Fixes "leo returns got HTTP error 301! at 
/usr/bin/leo line 250." (Closes: #876217)

Bug#876222: Should be in "contrib", not "main"

[Josh Triplett]

Package: mali-midgard-dkms
Severity: serious

The package description says:

> This provides the kernel module for the ARM Mali 'midgard' GPU series
> in dkms format. This covers the 6xx and 7xx GPU hardware devices. You
> need this kernel module as well the binary drivers to make the
> hardware work.

If that's the case, and this kernel module doesn't do any good without
the binary drivers, then this package should go to "contrib", not
"main".

If this kernel module has uses without the binary drivers (e.g. if it
can be made to work with the reverse-engineered driver instead), then
the description should make that clear.

- Josh Triplett

Bug#835120: lintian: false positive: virtual-package-depends-without-real-package-depends for bacula-director

[Chris Lamb]

Mattia Rizzolo wrote:

> trying to regenerate [the list] drops the bacula-director and
> bacula-sd-tools packages and adds bacula-director-database.

Is that incorrect?


Carsten Leonhardt wrote:

> Is there a reason to not update it during build?

(Yes; it downloads stuff from the internet.)


Regards,

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

Bug#876219: banshee: FTBFS: configure: error: missing required Mono 2.0 assembly: Mono.Posix.dll

[Andreas Beckmann]

Source: banshee
Version: 2.9.1-5
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

banshee/experimental FTBFS in sid/experimental with

...
checking for MONO_MODULE... yes
checking for dmcs... /usr/bin/mono-csc
checking for mono... /usr/bin/mono
checking for Mono 2.0 GAC for Mono.Posix.dll... not found
configure: error: missing required Mono 2.0 assembly: Mono.Posix.dll
...

Full log attached.


Andreas


banshee_2.9.1-5.log.gz
Description: application/gzip

Bug#867660: ball: FTBFS with sip 4.19.x: sip: File::CannotWrite has not been defined

[Andreas Tille]

On Tue, Sep 19, 2017 at 08:53:28PM +0300, Dmitry Shachnev wrote:
> Control: block 876205 by -1
> 
> On Tue, Sep 05, 2017 at 04:00:50PM +0300, Dmitry Shachnev wrote:
> > I just tested on a clean sid amd64 chroot (with sip 4.19 from experimental)
> > and all the tests pass for me:
> >
> >   100% tests passed, 0 tests failed out of 333
> >
> > Maybe it was some temporary issue?
> 
> I have just requested a transition slot for sip 4.19 upload, so this needs
> to be fixed soon, otherwise it will FTBFS.
> 
> At the same time, please call dh_sip helper after dh_install so that your
> package gets the right dependency on sip-abi-12.x.

I would love to upload as commited in Git (including the dh_sip call) but
when trying to build in a clean chroot I get:


...
99% tests passed, 4 tests failed out of 333

Total Test time (real) =  27.26 sec

The following tests FAILED:
 13 - Vector4_test (Failed)
 69 - Selectable_test (Failed)
159 - PTE_test (Failed)
160 - Atom_test (Failed)
Errors while running CTest
Makefile:95: recipe for target 'test' failed
...


Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#876223: yad: Table split lines are not showing

[Angela Ferreira]

Package: yad
Version: 0.38.2-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Nothing
   * What was the outcome of this action?
   * What outcome did you expect instead?
Dividers lines help in organizing a table. Content gets confusing 
without this split

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


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

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

Versions of packages yad depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u1
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.50.3-2
ii  libgtk-3-0   3.22.11-1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1

yad recommends no packages.

yad suggests no packages.

-- no debconf information

Bug#876226: yad: Please, update the version

[Angela Ferreira]

Package: yad
Version: 0.38.2-1
Severity: minor

Dear Maintainer,

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

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

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


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

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

Versions of packages yad depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u1
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.50.3-2
ii  libgtk-3-0   3.22.11-1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1

yad recommends no packages.

yad suggests no packages.

-- no debconf information

Bug#873094: RFS: granite/0.4.1-1 [ITP]

[Jeremy Bicha]

debian/control:
- Please remove or update the Vcs fields
- Please drop the Pre-Depends lines
- Maybe https://github.com/elementary/granite is a better homepage?

debian/rules:
- Please drop the dh_builddeb rule. xz is already the default
- Please use c4 for the makeshlibs rule

debian/changelog:
- I think it is appropriate to keep the old changelog entries since
this package was only removed from Debian 6 months ago.

debian/copyright:
- Please update the Source line to point to github since that's where
your watch file points

Please use automatic debug packages. In particular, see the top
section (before Summary) of
https://wiki.debian.org/AutomaticDebugPackages

Thanks,
Jeremy Bicha

Bug#876053: Acknowledgement (Swedish fakeroot translation out of date.)

[Sebastian Rasmussen]

tags: patch l10n

I got some comments from the people on the debian-l10n-swedish mailing list.
The attached .po-file adresses those issues.

 / Sebastian
# Swedish translations for fakeroot.
# Copyright (C) 2017 Free Software Foundation, Inc.
# Sebastian Rasmussen , 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: fakeroot 1.22-1\n"
"POT-Creation-Date: 2017-08-16 22:29-0400\n"
"PO-Revision-Date: 2017-09-20 00:22+0200\n"
"Last-Translator: Sebastian Rasmussen \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 2.0.3\n"

# type: TH
#. type: TH
#: ../doc/fakeroot.1:16
#, no-wrap
msgid "fakeroot"
msgstr "fakeroot"

#. type: TH
#: ../doc/fakeroot.1:16
#, no-wrap
msgid "5 October 2014"
msgstr "5:e oktober 2014"

# type: TH
#. type: TH
#: ../doc/fakeroot.1:16 ../doc/faked.1:16
#, no-wrap
msgid "Debian Project"
msgstr "Debian Project"

# type: TH
#. type: TH
#: ../doc/fakeroot.1:16
#, no-wrap
msgid "Debian manual"
msgstr "Debian manual"

# type: SH
#. Manpage by J.H.M. Dassen 
#. and Clint Adams
#. type: SH
#: ../doc/fakeroot.1:19 ../doc/faked.1:19
#, no-wrap
msgid "NAME"
msgstr "NAMN"

# type: Plain text
#. type: Plain text
#: ../doc/fakeroot.1:22
msgid ""
"fakeroot - run a command in an environment faking root privileges for file "
"manipulation"
msgstr ""
"fakeroot - utför ett kommando i en miljö som fejkar root-privilegier för "
"filmanipulation"

# type: SH
#. type: SH
#: ../doc/fakeroot.1:22 ../doc/faked.1:22
#, no-wrap
msgid "SYNOPSIS"
msgstr "SYNOPSIS"

# type: Plain text
#. type: Plain text
#: ../doc/fakeroot.1:38
msgid ""
"B B<[-l|--lib> I B<[--faked> IB<]> B<[-i> "
"IB<]> B<[-s> IB<]> B<[-u|--unknown-is-real ]> B<[-b|--"
"fd-base ]> B<[-h|--help ]> B<[-v|--version ]> B<[--]> B<[command]>"
msgstr ""
"B B<[-l|--lib> I B<[--faked> IB<]> B<[-"
"i> IB<]> B<[-s> IB<]> B<[-u|--unknown-is-real ]> B<[-b|--fd-"
"base ]> B<[-h|--help ]> B<[-v|--version ]> B<[--]> B<[kommando]>"

# type: SH
#. type: SH
#: ../doc/fakeroot.1:38 ../doc/faked.1:30
#, no-wrap
msgid "DESCRIPTION"
msgstr "BESKRIVNING"

# type: Plain text
#. type: Plain text
#: ../doc/fakeroot.1:49
msgid ""
"B runs a command in an environment wherein it appears to have root "
"privileges for file manipulation.  This is useful for allowing users to "
"create archives (tar, ar, .deb etc.) with files in them with root "
"permissions/ownership.  Without B one would need to have root "
"privileges to create the constituent files of the archives with the correct "
"permissions and ownership, and then pack them up, or one would have to "
"construct the archives directly, without using the archiver."
msgstr ""
"B utför ett kommando i en miljö där kommandot tror sig ha root-"
"privilegier för filmanipulering. Detta är användbart för att ge användare "
"möjlighet att skapa arkiv (tar, ar, .deb osv) som innehåller filer med root-"
"rättigheter/ägarskap. Utan B tvingas man att ha root-privilegier "
"för att skapa de filer arkivet består av med korrekt ägarskaps- och "
"rättighetsinformation, alternativt konstruera arkiven manuellt utan att "
"använda arkiveringsprogrammet."

# type: Plain text
#. type: Plain text
#: ../doc/fakeroot.1:61
msgid ""
"B works by replacing the file manipulation library functions "
"(chmod(2), stat(2) etc.) by ones that simulate the effect the real library "
"functions would have had, had the user really been root. These wrapper "
"functions are in a shared library B or similar "
"location on your platform.  The shared object is loaded through the "
"B mechanism of the dynamic loader. (See B(8))"
msgstr ""
"B arbetar genom att ersätta biblioteksfunktionerna för modifiering "
"av filrättigheter (chmod(2), stat(2), osv) med sådana som simulerar effekten "
"som de riktiga biblioteksfunktionerna skulle ha haft om användaren verkligen "
"varit root. Dessa funktioner finns samlade i biblioteket B som laddas genom B-mekanismen hos den "
"dynamiska länkaren. (Se B(8))"

# type: Plain text
#. type: Plain text
#: ../doc/fakeroot.1:71
msgid ""
"If you intend to build packages with B, please try building the "
"fakeroot package first: the \"debian/rules build\" stage has a few tests "
"(testing mostly for bugs in old fakeroot versions). If those tests fail (for "
"example because you have certain libc5 programs on your system), other "
"packages you build with fakeroot will quite likely fail too, but possibly in "
"much more subtle ways."
msgstr ""
"Om du planerar att bygga paket med hjälp av B, försök först att "
"bygga fakeroot-paketet: ”debian/rules build”-stadiet har ett par tester (som "
"mestadels testar efter buggar i gamla versioner av fakeroot).  Om dessa "
"tester misslyckas (till exempel på grund av att du har vissa libc5-program "
"på ditt system) så är det 

Bug#876218: libneo4j-client: FTBFS with "output truncated before the last format character"

[Andreas Beckmann]

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

Hi,

libneo4j-client/experimental FTBFS with GCC 7:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -pthread -Wpedantic -Wvla -g -O2 
-fdebug-prefix-map=/build/libneo4j-client-2.1.2=. -fstack-protector-strong 
-Wformat -Werror=format-security -
std=gnu11 -fvisibility=hidden -pipe -Wall -W -Werror -Wno-unused-parameter 
-Wno-missing-field-initializers -Wpointer-arith -Wstrict-prototypes -Wcast-qual 
-Wcast-align -Wno-error=unused-function -Wno-error=unused-variable -Wn
o-error=deprecated-declarations -c render.c  -fPIC -DPIC -o 
.libs/libneo4j_client_la-render.o
render.c: In function 'render_field':
render.c:610:17: error: '__builtin___snprintf_chk' output truncated before the 
last format character [-Werror=format-truncation=]
 if (snprintf(buf, sizeof(buf), "\\U%08X", codepoint) < 0)
 ^~~~
In file included from /usr/include/stdio.h:938:0,
 from neo4j-client.h:27,
 from render.h:20,
 from render.c:18:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:64:10: note: 
'__builtin___snprintf_chk' output 11 bytes into a destination of size 10
   return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
  ^~~~
__bos (__s), __fmt, __va_arg_pack ());
~
cc1: all warnings being treated as errors
Makefile:688: recipe for target 'libneo4j_client_la-render.lo' failed
make[4]: *** [libneo4j_client_la-render.lo] Error 1


Full log attached.


Andreas


libneo4j-client_2.1.2-1.log.gz
Description: application/gzip

Bug#876055: Environment variable handling for reproducible builds

[Ximin Luo]

Ximin Luo:
> [..]
> 
> (The last time I erroneously included PATH in the final "excluded" list - 
> because we have varied PATH but in a really trivial way on tests.r-b.org for 
> ages - but I now agree with you that we shouldn't expect reproducibility when 
> PATH is varied.)
> 

Actually thinking about it a bit more, the PATH point is a little subtle. It's 
certainly the case that (case a:) if I set PATH=/a vs PATH=/b and the files 
installed underneath /a and /b are *different*, then the build output must be 
"allowed" to vary since they will of course vary.

However if (case b:) I set PATH=/a vs PATH=/b but the files underneath those 
paths are exactly the same, then is it right that the build output still is 
allowed to vary - e.g. might embed the strings "/a" vs "/b" in them? I think 
this subtlety is why we had been varying PATH for ages on tests.r-b.org, 
because we were confusing the two questions together.

A strict interpretation of reproducibility might say "(a) can vary" except "(b) 
remains fixed", and vary PATH after checking that the different values still 
point to exactly the same file-trees.

However for the purposes of this thread, to simplify the discussion, I think we 
can for now say "(a) can vary, including (b)", so that we can ignore the 
semantics of PATH variables. Once we solve the other issues we could revisit 
this one.

X

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

Bug#876180: ITP: ruby-rblineprof -- line-profiler for ruby

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

from rubygems.org/gems/rblineprof
dependency of gitlab 9.5









signature.asc
Description: OpenPGP digital signature

Bug#876181: ITP: ruby-peek-rblineprof -- Peek into how much each line of your Rails application takes throughout a request

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

from rubygems.org/gems/peek-rblineprof
dependency of gitlab 9.5











signature.asc
Description: OpenPGP digital signature

Bug#876055: Environment variable handling for reproducible builds

[Ximin Luo]

Russ Allbery:
> [..]  It does mean that discovery of any new
> such environment variable would require a change to our whitelist in
> approach (3), so there would be some lag and the whitelist would become
> long over time (with a corresponding testing load).  But (3) does try to
> achieve that use case without trying to anticipate any possible
> environment variable setting.  It lets us be reactive to newly-discovered
> environment variables across which we want to stay reproducible.
> 

I can also see the merits in your (3) suggestion but I don't think it would be 
appropriate to hard-code the list in Policy, because it would be too hard to 
change it and then people might end up relying on a very-incomplete list and 
then do stupid stuff that was counter to the original intention of the 
discussions around the policy. It would be better to find a generic wording 
(with some examples) similar to what I suggested elsewhere.

>> Does everything in policy need to be rigorously testable?  or is it ok
>> to have Policy state the desired outcome even if we don't know how (or
>> don't have the resources) to test it fully today.
> 
> I don't think everything has to be rigorously testable, but I do think
> it's a useful canary.  If I can't test something, I start wondering
> whether that means I have problems with my underlying assumptions.
> 
> [..]

The "strict" interpretation is in principle testable though - we just have to 
collect enough environment variables and decide which category they fall under, 
and add that logic to our build tools.

I think in these early days, it would be fine for public package builders and 
reproducibility testers to do (3) as you suggested, i.e. 

- clean the environment
- set certain variables to a fixed value (the "whitelist") and record these in 
buildinfo

This "loose" interpretation of reproducibility still gives us some useful 
results, as well as testable reproducibility for end users, but as I said I 
don't think this should be Policy since the whitelist should be expanding quite 
quickly especially early on.

OTOH, developer reproducibility checkers (such as reprotest) can be a little 
bit more strict. I can imagine something like:

- reprotest runs 3 builds:
  - build 0 with current env
  - build 1 with current env + varying some "blacklist" envvars
  - build 2 with current env + varying some "non-whitelist" envvars

If there are differences between build 1 and build 2, then reprotest reports 
"unexpected envvar $XXX affected the build" and the developer can then either 
submit it for inclusion on the "whitelist" or the "blacklist" based on the 
Policy wording. If it ends up on the blacklist then they would also have to fix 
their own package to be invariant under that envvar.

So over time, this way we can build up a blacklist and a whitelist. But it 
shouldn't be in the original policy. And I don't think what I suggested above 
is a particularly disruptive or surprising process, especially since the 
"public" builders would only do the "looser" interpretation so people aren't 
bothered by bogus "unreproducible" reports.

X

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

Bug#875618: openblas: please enable build on s390x

[Sébastien Villemot]

Control: tags -1 = pending
Control: notforwarded -1

On Mon, Sep 18, 2017 at 01:56:23PM +0200, Sébastien Villemot wrote:
> On Thu, Sep 14, 2017 at 12:34:34PM +0200, Christian Borntraeger wrote:
> > On 09/14/2017 09:58 AM, Sébastien Villemot wrote:
> > > On Wed, Sep 13, 2017 at 08:33:08PM +, PICCA Frederic-Emmanuel wrote:
> > >>> Unfortunately it does not look that simple. OpenBLAS is optimized for 
> > >>> z13, but
> > >>> our s390x port is supposed to support all the z systems (see [1]).
> > >>
> > >> what about asking for a a z13-support package to the isa-support (source
> > >> package) maintainer. This way it could be possible to upload an optimise
> > >> vesion of openblas which can install on recent enought s390x machines.
> > > 
> > > I am not totally convinced by this solution. If we adopt it, somebody who
> > > installs e.g. octave on an old system-z machine will be hit by a failure 
> > > in the
> > > dpkg installation process, which needs manual intervention. This is 
> > > likely to
> > > generate problems in automated installers (and also confuse and annoy 
> > > system
> > > admins).
> > > 
> > >> the question will be then : does the buildd support these instructions ?
> > > 
> > > I leave that to the s390 porters to answer.
> > 
> > FWIW, some years ago I did the atlas port for s390x. For dynamic linking 
> > the atlas
> > build/package process did support the exploitation of ELF HW_CAPS. So you 
> > could 
> > build a z900 (generic) and a z13 variant which is then picked by the linker 
> > at 
> > runtime. No idea if openblas allows the same. Of course the static variant 
> > (.a) 
> > must be the generic one.
> 
> Thanks for your feedback. I have opened a request upstream about the need for 
> a
> z900 kernel, and for a dynamic selection between the z900 and z13 kernels
> (as OpenBLAS currently does on x86).

It turns out that there is already a support for generic System z, I had
overlooked that.

I have therefore pushed a changeset that builds a generic s390x binary.

However, upstream does not currently provide runtime detection, so owners of a
z13 system will have to recompile locally (as explained in README.Debian) in
order to get the best out of OpenBLAS (note that this is the same situation as
all the non-x86 archs).

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Bug#874208: octave: audiodevinfo makes octave segfault when jackd is running

[Peter P.]

* Mike Miller  [2017-09-08 17:26]:
> On Fri, Sep 08, 2017 at 10:55:21 +0200, Peter P. wrote:
> > The two other programs I have installed that are using libportaudio2 are
> > pure-data and audacity. And they both work with and without jack.
> 
> And here's what I just did to test locally. This is admittedly an
> absolutely minimal unconfigured jack setup.
> 
> $ sudo aptitude install -y --without-recommends jackd2
> $ jack_control start
> $ octave-cli
> >> devs = audiodevinfo;  ## no crash
> >> devs.output.Name
> ans = HDA Intel HDMI: 0 (hw:0,3) (ALSA)
> ans = HDA Intel HDMI: 1 (hw:0,7) (ALSA)
> ans = HDA Intel HDMI: 2 (hw:0,8) (ALSA)
> ans = HDA Intel HDMI: 3 (hw:0,9) (ALSA)
> ans = HDA Intel HDMI: 4 (hw:0,10) (ALSA)
> ans = hdmi (ALSA)
> ans = default (ALSA)
> ans = system (JACK Audio Connection Kit)
> 
> Seems to work for me.
Thank you Mike, switching to jackd2 does work for me as well! I am a bit
hesitant to switch my system to jackd2 as there are some other
applications that depend (more) on jackd1. I wonder if this workaround,
for which I am very thankful, means that the crash with jackd1 will not
me looked into further, or if it may be worked on nevertheless.

best, Peter

Bug#876185: Package is not installable with current evolution

[Michael Meskes]

Package: evolution-rss
Version: 0.3.95-7
Severity: grave

Subject says it all, the package either blocks evolution update or is 
uninstallable. 

Michael

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

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

Versions of packages evolution-rss depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  evolution3.24.5-3
ii  evolution-data-server3.24.5-6
ii  libatk1.0-0  2.26.0-2
ii  libc62.24-17
ii  libcairo-gobject21.14.10-1
ii  libcairo21.14.10-1
ii  libcamel-1.2-60  3.24.5-6
ii  libebackend-1.2-10   3.24.5-6
ii  libebook-1.2-19  3.26.0-1
ii  libebook-contacts-1.2-2  3.26.0-1
ii  libedata-book-1.2-25 3.24.5-6
ii  libedataserver-1.2-223.24.5-6
ii  libedataserverui-1.2-1   3.24.5-6
ii  libevolution 3.24.5-3
ii  libgcc1  1:7.2.0-5
ii  libgdk-pixbuf2.0-0   2.36.5-4
ii  libglib2.0-0 2.54.0-1
ii  libgtk-3-0   3.22.21-1
ii  libjavascriptcoregtk-4.0-18  2.18.0-2
ii  libnspr4 2:4.16-1
ii  libnss3  2:3.32-2
ii  libpango-1.0-0   1.40.12-1
ii  libpangocairo-1.0-0  1.40.12-1
ii  libsecret-1-00.18.5-3.1
ii  libsoup-gnome2.4-1   2.60.0-1
ii  libsoup2.4-1 2.60.0-1
ii  libsqlite3-0 3.20.1-1
ii  libstdc++6   7.2.0-5
ii  libwebkit2gtk-4.0-37 2.18.0-2
ii  libxml2  2.9.4+dfsg1-4

evolution-rss recommends no packages.

evolution-rss suggests no packages.

-- no debconf information

Bug#876186: freebsd-glue: fix ctfutils FTBFS on ppc64el

[Frédéric Bonnard]

Package: src:freebsd-glue
Version: 0.2.22
Tags: patch pending
User: debian-powe...@lists.debian.org
Usertags: ppc64el 

--

Dear maintainer,

I see that the package ctfutils fails to build on ppc64/ppc64el :
https://buildd.debian.org/status/logs.php?pkg=ctfutils=10.3%7Esvn297264-2=sid
On those architectures, the macro in 
./ctfutils-10.3~svn297264/sys/cddl/compat/opensolaris/sys/elf.h
#define __sElfN(x) typedef 
__CONCAT(__CONCAT(__CONCAT(Elf,__ELF_WORD_SIZE),_),x) x

does not have __ELF_WORD_SIZE defined.
This normally comes from freebsd-glue in /usr/include/freebsd/machine/elf.h 
where
we have :
#ifndef ELF_ARCH
#include /* ELF_ARCH */
#endif

and in machine/__get_elf_arch.h :
#define ELF_ARCH 21
#define __ELF_WORD_SIZE 64

On ppc64[el]; ELF_ARCH is already defined by linux-libc-dev in
/usr/include/powerpc64le-linux-gnu/asm/elf.h but I couldn't find any
reference to __ELF_WORD_SIZE. As ELF_ARCH is already define we just
skip inclusion of machine/__get_elf_arch.h and __ELF_WORD_SIZE.

Not sure if that is the good approach to solve that issue, but in the
attached patched, I ifndef-ed ELF_ARCH within get_elf_arch.c to always
include machine/__get_elf_arch.h but skip ELF_ARCH definition (will come
from signal.h that at some point includes asm/elf.h) if not needed while
still defining __ELF_WORD_SIZE.
It looks like letting ctfutils compile properly on ppc64[el] ; other
architecture shouldn't be impacted.

Regards.
F.
diff -Nru freebsd-glue-0.2.22/debian/changelog 
freebsd-glue-0.2.22+nmu1/debian/changelog
--- freebsd-glue-0.2.22/debian/changelog2016-03-05 15:44:54.0 
+
+++ freebsd-glue-0.2.22+nmu1/debian/changelog   2017-09-19 07:32:25.0 
+
@@ -1,3 +1,12 @@
+freebsd-glue (0.2.22+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * fix ctfutils package FTBFS on ppc64[el] : selectively export
+__ELF_WORD_SIZE and ELF_ARCH : on those archs ELF_ARCH is already defined
+in asm/elf.h but not __ELF_WORD_SIZE
+
+ -- Frédéric Bonnard   Tue, 19 Sep 2017 07:32:25 
+
+
 freebsd-glue (0.2.22) unstable; urgency=medium
 
   * Actually use the proper build architecture compiler
diff -Nru freebsd-glue-0.2.22/include/machine/elf.h 
freebsd-glue-0.2.22+nmu1/include/machine/elf.h
--- freebsd-glue-0.2.22/include/machine/elf.h   2014-08-25 19:40:16.0 
+
+++ freebsd-glue-0.2.22+nmu1/include/machine/elf.h  2017-09-18 
15:52:44.0 +
@@ -8,9 +8,7 @@
 #include 
 #include 
 
-#ifndef ELF_ARCH
-#include /* ELF_ARCH */
-#endif
+#include /* possible ELF_ARCH and 
__ELF_WORD_SIZE */
 
 #ifndef ELF_TARG_DATA
 #include 
diff -Nru freebsd-glue-0.2.22/src/get_elf_arch.c 
freebsd-glue-0.2.22+nmu1/src/get_elf_arch.c
--- freebsd-glue-0.2.22/src/get_elf_arch.c  2016-03-02 14:19:59.0 
+
+++ freebsd-glue-0.2.22+nmu1/src/get_elf_arch.c 2017-09-19 07:32:25.0 
+
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 
 int
 main (int argc, char **argv)
@@ -16,7 +17,9 @@
   if (read (fd, , sizeof (ehdr)) != sizeof (ehdr))
 perror ("read");
 
+#ifndef ELF_ARCH
   printf ("#define ELF_ARCH %u\n", ehdr.e_machine);
+#endif
   printf ("#define __ELF_WORD_SIZE %u\n", ehdr.e_ident[EI_CLASS] == ELFCLASS64 
? 64 : 32);
 
   close (fd);


pgpBNhfRw3j63.pgp
Description: PGP signature

Bug#870906: ITP: pynmea2 - pynmea2 is a python library for the NMEA 0183 protocol

[Herbert Fortes]

Hi Joachim Langenbach,


> > Hi Herbert,
> >
> > I managed to upload the version 1.9.0 and (hopefully) fixed your hints. May 
> > you
> > have a look at it?
> >

There are some adjusts to do:

debian/compat:

    - instead of '9' put '10' (number only)

debian/control:

 - Build-Depends entry: python3-all-dev can be removed.
   'cowbuilder' builds the package without it.
 - lintian needs an update. You can put '4.1.0'.
 - Testsuite can be removed. There is no 'debian/tests' dir.
 - Architecture: should be 'all'. (any is for programs like C, C++)
 - Depends entry: '${shlibs:Depends}' can be removed.
 - Provides entry can be removed.

debian/copyright:

    - Debian entry is missing. The file should look like this:

 Files: *
 Copyright: (C) 2013-2017 Tom Flanagan 
 License: MIT

 Files: debian/*
 Copyright: 2017 Your-name-here ||
 License: Choose-one (usually upstream choice)

 License: MIT
 Permission is hereby granted, free of charge, to any person obtaining
 blababla

 License: (If you choose something different add here)
 blablabla
 a copy of this software and associated documentation files


debian/rules:
 
    - I said about cleaning SOÛRCES.txt. You did right. But
  I learned something that looks better. Instead of an
  override_dh_auto_clean, 'egg-info' can be ignored if
  we use 'debian/source/options' file. One line in the
  file:
    |

 extend-diff-ignore="^[^/]+\.egg-info/"

| 
  Just in case, please see:
  
https://anonscm.debian.org/cgit/debian-science/packages/python-meshio.git/tree/debian/source/options


That's it. Let me know when you when the package
is ready.



regards,
Herbert

Bug#876189: honor dpkg-statsoverride in postinst

[Christian Ehrhardt]

Package: tomcat8
Version: 8.5.16-1

Hi,
I'm forwarding this as it was reported to Ubuntu but affecting both of us.
In the postinst there is a snippet already considering debconf for names:

db_get tomcat8/username && TOMCAT8_USER="$RET" ||
TOMCAT8_USER="tomcat8"
   db_get tomcat8/groupname && TOMCAT8_GROUP="$RET" ||
TOMCAT8_GROUP="tomcat8"
[...]
   chown -R $TOMCAT8_USER:adm /var/log/tomcat8 /var/cache/tomcat8
   chmod 750 /var/log/tomcat8 /var/cache/tomcat8

Not sure if that can be reasonably combined, but would it make sense to you
to combine that with dpkg-statoverride [1] somehow?

That would be to allow a user to override those permissions and retain them
across update/installs/reinstalls.

[1]: https://manpages.debian.org/wheezy/dpkg/dpkg-statoverride.8.en.html

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#876187: a failing dh_autoreconf -Dsomething fails to chdir back

[Helmut Grohne]

Package: dh-autoreconf
Version: 14
Severity: minor
User: helm...@debian.org
Usertags: rebootstrap

A failing dh_autoreconf -Dsomedir fails to chdir back and thus errors
out creating debian/autoreconf.after in the wrong directory.

Suppose the autoreconf call fails (=> severity=minor). Then doit raises
an exception and the "chdir $pwd;" call in the eval block is skipped.
The next "complex_doit("$find > debian/autoreconf.after");" operates in
the wrong directory and bad things happen.

I suggest pulling the final chdir and the initial getcwd out of the
eval block.

Helmut

Bug#876188: Wrong path in BackupPC_deleteFile

[martin f krafft]

Package: backuppc
Version: 3.3.1-4
Severity: normal
Tags: patch
File: /usr/share/backuppc/bin/BackupPC_deleteFile

--- /tmp/BackupPC_deleteFile2017-09-19 13:53:56.722030824 +0200
+++ BackupPC_deleteFile 2017-09-19 13:07:22.171540831 +0200
@@ -269,7 +269,7 @@
 use File::Glob ':glob';
 use Data::Dumper;  #Just used for debugging...

-use lib "/usr/share/BackupPC/lib";
+use lib "/usr/share/backuppc/lib";
 use BackupPC::Lib;
 use BackupPC::jLib;
 use BackupPC::Attrib qw(:all);






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

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

Versions of packages backuppc depends on:
ii  adduser3.116
pn  apache2 | httpd
pn  apache2-utils  
ii  bzip2  1.0.6-8.1
ii  debconf1.5.63
ii  dpkg   1.18.24
ii  iputils-ping   3:20161105-1
ii  libarchive-zip-perl1.59-1
ii  libc6  2.24-15
ii  libcgi-pm-perl 4.36-1
pn  libdigest-md5-perl 
ii  libperl5.26 [libio-compress-perl]  5.26.0-5
pn  libtime-parsedate-perl 
ii  libwww-perl6.15-2
ii  perl   5.26.0-5
ii  postfix [mail-transport-agent] 3.2.2-1
pn  samba-common-bin   
ii  smbclient  2:4.6.7+dfsg-1
ii  tar1.29b-2
ii  ucf3.0036

Versions of packages backuppc recommends:
pn  libfile-rsyncp-perl  
pn  libio-dirent-perl
ii  openssh-client [ssh-client]  1:7.5p1-5
pn  rrdtool  
ii  rsync3.1.2-2

Versions of packages backuppc suggests:
ii  chromium [www-browser] 60.0.3112.78-1
ii  firefox [www-browser]  55.0-2
ii  firefox-esr [www-browser]  52.3.0esr-2
pn  par2   
ii  w3m [www-browser]  0.5.3-34


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#872994: fuse-emulator-gtk: screen with wrong size at startup.

[Alberto Garcia]

Control: reassign 872994 libgtk-3.0 3.22.21-1
Control: affects 872994 fuse-emulator-gtk

Hi again,

I'm reassigning this bug, so here's the summary of the problem:

   "when I start fuse-emulator-gtk, it opens with a streched window
   size and does not show the bottom screen of ZX Spectrum.

   If I maximize the window, it shows all the zx spectrum screen, but
   in normal window size, it doesn't."

This is a problem that only happens with Wayland, and only in the GTK+
version of the Fuse emulator (the SDL build works fine), so I suspect
the problem is in the Wayland backend of GTK+.

I'm reassigning it to libgtk-3-0, although I have to say that I
also notice some other odd behaviour when I run the desktop with
WaylandEnable=true, especially the keyboard input is more unreliable.

I can reproduce it with:

   libgtk-3-03.22.21-1
   libglib2.0-0  2.54.0-1
   xwayland  2:1.19.3-2
   gdm3  3.26.0-1
   fuse-emulator-gtk 1.4.0+dfsg1-1

Berto

Bug#867727: Request for sponsoring Parlatype -- audio player for transcription

[Gabor Karsay]

Juhani Numminen schrieb am 2017-09-15 um 15:24:
debian/parlatype.manpages is only needed when upstream build system 
doesn't install the man pages, please remove it.

done

debian/watch can be updated to version 4 (changing the first line is 
enough).

done

Additionally removed build-dependency on libfile-fcntllock-perl and 
added copyright for translations.


For some reason after upload mentors claims there is no debhelper 
compatibility level set and a watchfile is missing although everything 
is set.


Best regards,
Gabor

Bug#876191: most: configure cannot be built from source

[Helmut Grohne]

Source: most
Version: 5.0.0a-4
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap

I was trying to fix a bug in most that requires modifying configure.
Thus I tried to regenerate it and ... failed.

It seems that configure was generated with autoconf2.61. The archive
does have autoconf 2.13, 2.64 and 2.69, but not 2.61. So I tried
autoconf 2.64 as that seemed closest. However autoheader2.64 failed:

| configure.ac:4: warning: AC_REQUIRE: `AC_PROG_CC' was expanded before it was 
required
| configure.ac:4: 
http://www.gnu.org/software/autoconf/manual/autoconf.html#Expanded-Before-Required
| ../../lib/autoconf/c.m4:429: AC_LANG_COMPILER(C) is expanded from...
| ../../lib/autoconf/lang.m4:329: AC_LANG_COMPILER_REQUIRE is expanded from...
| ../../lib/autoconf/lang.m4:372: AC_LANG_PREPROC_REQUIRE is expanded from...
| ../../lib/autoconf/general.m4:2549: AC_EGREP_CPP is expanded from...
| ../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...
| ../../lib/autoconf/general.m4:2042: AC_CACHE_VAL is expanded from...
| ../../lib/autoconf/general.m4:2063: AC_CACHE_CHECK is expanded from...
| ../../lib/autoconf/c.m4:543: AC_PROG_GCC_TRADITIONAL is expanded from...
| aclocal.m4:496: JD_ANSI_CC is expanded from...
| configure.ac:4: the top level
| configure.ac:4: warning: AC_REQUIRE: `AC_PROG_CPP' was expanded before it was 
required
| configure.ac:4: 
http://www.gnu.org/software/autoconf/manual/autoconf.html#Expanded-Before-Required
| ../../lib/autoconf/c.m4:336: AC_LANG_PREPROC(C) is expanded from...
| ../../lib/autoconf/lang.m4:372: AC_LANG_PREPROC_REQUIRE is expanded from...
| ../../lib/autoconf/general.m4:2549: AC_EGREP_CPP is expanded from...
| ../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...
| ../../lib/autoconf/general.m4:2042: AC_CACHE_VAL is expanded from...
| ../../lib/autoconf/general.m4:2063: AC_CACHE_CHECK is expanded from...
| ../../lib/autoconf/c.m4:543: AC_PROG_GCC_TRADITIONAL is expanded from...
| aclocal.m4:496: JD_ANSI_CC is expanded from...
| configure.ac:4: the top level
| configure.ac:4: warning: AC_REQUIRE: `AC_PROG_CC' was expanded before it was 
required
| configure.ac:4: 
http://www.gnu.org/software/autoconf/manual/autoconf.html#Expanded-Before-Required
| ../../lib/autoconf/c.m4:429: AC_LANG_COMPILER(C) is expanded from...
| ../../lib/autoconf/lang.m4:329: AC_LANG_COMPILER_REQUIRE is expanded from...
| ../../lib/autoconf/lang.m4:372: AC_LANG_PREPROC_REQUIRE is expanded from...
| ../../lib/autoconf/general.m4:2549: AC_EGREP_CPP is expanded from...
| ../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...
| ../../lib/autoconf/general.m4:2042: AC_CACHE_VAL is expanded from...
| ../../lib/autoconf/general.m4:2063: AC_CACHE_CHECK is expanded from...
| ../../lib/autoconf/c.m4:543: AC_PROG_GCC_TRADITIONAL is expanded from...
| aclocal.m4:496: JD_ANSI_CC is expanded from...
| configure.ac:4: the top level
| configure.ac:4: warning: AC_REQUIRE: `AC_PROG_CPP' was expanded before it was 
required
| configure.ac:4: 
http://www.gnu.org/software/autoconf/manual/autoconf.html#Expanded-Before-Required
| ../../lib/autoconf/c.m4:336: AC_LANG_PREPROC(C) is expanded from...
| ../../lib/autoconf/lang.m4:372: AC_LANG_PREPROC_REQUIRE is expanded from...
| ../../lib/autoconf/general.m4:2549: AC_EGREP_CPP is expanded from...
| ../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...
| ../../lib/autoconf/general.m4:2042: AC_CACHE_VAL is expanded from...
| ../../lib/autoconf/general.m4:2063: AC_CACHE_CHECK is expanded from...
| ../../lib/autoconf/c.m4:543: AC_PROG_GCC_TRADITIONAL is expanded from...
| aclocal.m4:496: JD_ANSI_CC is expanded from...
| configure.ac:4: the top level
| configure.ac:4: warning: AC_REQUIRE: `AC_PROG_CC' was expanded before it was 
required
| configure.ac:4: 
http://www.gnu.org/software/autoconf/manual/autoconf.html#Expanded-Before-Required
| ../../lib/autoconf/c.m4:429: AC_LANG_COMPILER(C) is expanded from...
| ../../lib/autoconf/lang.m4:329: AC_LANG_COMPILER_REQUIRE is expanded from...
| ../../lib/autoconf/lang.m4:372: AC_LANG_PREPROC_REQUIRE is expanded from...
| ../../lib/autoconf/general.m4:2549: AC_EGREP_CPP is expanded from...
| ../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...
| ../../lib/autoconf/general.m4:2042: AC_CACHE_VAL is expanded from...
| ../../lib/autoconf/general.m4:2063: AC_CACHE_CHECK is expanded from...
| ../../lib/autoconf/c.m4:543: AC_PROG_GCC_TRADITIONAL is expanded from...
| aclocal.m4:496: JD_ANSI_CC is expanded from...
| configure.ac:4: the top level
| configure.ac:4: warning: AC_REQUIRE: `AC_PROG_CPP' was expanded before it was 
required
| configure.ac:4: 
http://www.gnu.org/software/autoconf/manual/autoconf.html#Expanded-Before-Required
| ../../lib/autoconf/c.m4:336: AC_LANG_PREPROC(C) is expanded from...
| ../../lib/autoconf/lang.m4:372: AC_LANG_PREPROC_REQUIRE is expanded from...
| ../../lib/autoconf/general.m4:2549: AC_EGREP_CPP is expanded from...
| ../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...
|