Bug#917595: umoci: FTBFS (cannot find package "github.com/fatih/color")

[Santiago Vila]

Package: src:umoci
Version: 0.4.0+dfsg-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-arch
dh build-arch --buildsystem=golang --with=golang
   dh_update_autotools_config -a -O--buildsystem=golang
   dh_autoreconf -a -O--buildsystem=golang
   dh_auto_configure -a -O--buildsystem=golang
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>/umoci-0.4.0+dfsg'
COMMIT=1 COMMIT_NO=1 /usr/bin/make doc
make[2]: Entering directory '/<>/umoci-0.4.0+dfsg'
go-md2man -in doc/man/umoci-unpack.1.md -out doc/man/umoci-unpack.1
go-md2man -in doc/man/umoci-raw-runtime-config.1.md -out 
doc/man/umoci-raw-runtime-config.1
go-md2man -in doc/man/umoci-config.1.md -out doc/man/umoci-config.1
go-md2man -in doc/man/umoci-ls.1.md -out doc/man/umoci-ls.1
go-md2man -in doc/man/umoci-remove.1.md -out doc/man/umoci-remove.1

[... snipped ...]

src/github.com/openSUSE/umoci/oci/config/generate/save.go
src/github.com/openSUSE/umoci/oci/config/generate/spec.go
src/github.com/openSUSE/umoci/oci/config/generate/spec_test.go
src/github.com/openSUSE/umoci/oci/layer/generate.go
src/github.com/openSUSE/umoci/oci/layer/generate_test.go
src/github.com/openSUSE/umoci/oci/layer/tar_extract.go
src/github.com/openSUSE/umoci/oci/layer/tar_extract_test.go
src/github.com/openSUSE/umoci/oci/layer/tar_generate.go
src/github.com/openSUSE/umoci/oci/layer/tar_generate_test.go
src/github.com/openSUSE/umoci/oci/layer/tar_unix.go
src/github.com/openSUSE/umoci/oci/layer/unpack.go
src/github.com/openSUSE/umoci/oci/layer/unpack_test.go
src/github.com/openSUSE/umoci/oci/layer/utils.go
src/github.com/openSUSE/umoci/oci/layer/utils_test.go
src/github.com/openSUSE/umoci/pkg/fseval/fseval.go
src/github.com/openSUSE/umoci/pkg/fseval/fseval_default.go
src/github.com/openSUSE/umoci/pkg/fseval/fseval_rootless.go
src/github.com/openSUSE/umoci/pkg/idtools/idtools.go
src/github.com/openSUSE/umoci/pkg/idtools/idtools_test.go
src/github.com/openSUSE/umoci/pkg/mtreefilter/mask.go
src/github.com/openSUSE/umoci/pkg/mtreefilter/mask_test.go
src/github.com/openSUSE/umoci/pkg/rootlesscontainers-proto/rootlesscontainers_generate.go
src/github.com/openSUSE/umoci/pkg/system/mknod_linux.go
src/github.com/openSUSE/umoci/pkg/system/mknod_linux_test.go
src/github.com/openSUSE/umoci/pkg/system/utime_linux.go
src/github.com/openSUSE/umoci/pkg/system/utime_linux_test.go
src/github.com/openSUSE/umoci/pkg/system/xattr_linux.go
src/github.com/openSUSE/umoci/pkg/unpriv/unpriv.go
src/github.com/openSUSE/umoci/pkg/unpriv/unpriv_test.go
src/github.com/openSUSE/umoci/pkg/unpriv/unpriv_utimes_test.go
src/github.com/openSUSE/umoci/third_party/shared/util.go
src/github.com/openSUSE/umoci/third_party/user/lookup.go
src/github.com/openSUSE/umoci/third_party/user/lookup_unix.go
src/github.com/openSUSE/umoci/third_party/user/user.go
src/github.com/openSUSE/umoci/third_party/user/user_test.go
cd obj-x86_64-linux-gnu && go install 
-gcflags=all=\"-trimpath=/<>/umoci-0.4.0\+dfsg/obj-x86_64-linux-gnu/src\"
 
-asmflags=all=\"-trimpath=/<>/umoci-0.4.0\+dfsg/obj-x86_64-linux-gnu/src\"
 -v -p 1 github.com/openSUSE/umoci/cmd/umoci github.com/openSUSE/umoci/mutate 
github.com/openSUSE/umoci/oci/cas github.com/openSUSE/umoci/oci/cas/dir 
github.com/openSUSE/umoci/oci/casext 
github.com/openSUSE/umoci/oci/config/convert 
github.com/openSUSE/umoci/oci/config/generate 
github.com/openSUSE/umoci/oci/layer github.com/openSUSE/umoci/pkg/fseval 
github.com/openSUSE/umoci/pkg/idtools github.com/openSUSE/umoci/pkg/mtreefilter 
github.com/openSUSE/umoci/pkg/rootlesscontainers-proto 
github.com/openSUSE/umoci/pkg/system github.com/openSUSE/umoci/pkg/unpriv 
github.com/openSUSE/umoci/third_party/shared 
github.com/openSUSE/umoci/third_party/user
src/github.com/apex/log/handlers/cli/cli.go:12:2: cannot find package 
"github.com/fatih/color" in any of:
/usr/lib/go-1.10/src/github.com/fatih/color (from $GOROOT)

/<>/umoci-0.4.0+dfsg/obj-x86_64-linux-gnu/src/github.com/fatih/color 
(from $GOPATH)
src/github.com/apex/log/handlers/cli/cli.go:13:2: cannot find package 
"github.com/mattn/go-colorable" in any of:
/usr/lib/go-1.10/src/github.com/mattn/go-colorable (from $GOROOT)

/<>/umoci-0.4.0+dfsg/obj-x86_64-linux-gnu/src/github.com/mattn/go-colorable
 (from $GOPATH)
dh_auto_build: cd obj-x86_64-linux-gnu && go install 
-gcflags=all=\"-trimpath=/<>/umoci-0.4.0\+dfsg/obj-x86_64-linux-gnu/src\"
 
-asmflags=all=\"-trimpath=/<>/umoci-0.4.0\+dfsg/obj-x86_64-linux-gnu/src\"
 -v -p 1 github.com/openSUSE/umoci/cmd/umoci github.com/openSUSE/umoci/mutate 
github.com/openSUSE/umoci/oci/cas github.com/openSUSE/umoci/oci/cas/dir 
github.com/openSUSE/umoci/oci/casext 
github.com/openSUSE/umoci/oci/config/convert 
github.com/openSUSE/umoci/oci/config/generate 
github.com/openSUSE/umoci/oci/layer github.com/openSUSE/umoci/pkg/fseval 

Bug#917594: sparse: FTBFS (failing tests)

[Santiago Vila]

Package: src:sparse
Version: 0.5.2-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules binary-arch
dh binary-arch
   dh_update_autotools_config -a
   dh_autoreconf -a
   dh_auto_configure -a
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build -- SPARSE_VERSION="\$(VERSION) (Debian: 0.5.2-2)" PREFIX=/usr 
PKGCONFIGDIR=/usr/lib/x86_64-linux-gnu/pkgconfig V=1
make -j1 "SPARSE_VERSION=\$(VERSION) (Debian: 0.5.2-2)" PREFIX=/usr 
PKGCONFIGDIR=/usr/lib/x86_64-linux-gnu/pkgconfig V=1
make[2]: Entering directory '/<>'
gcc-8 -o test-lexing.o -c -O2 -finline-functions -fno-strict-aliasing -g -Wall 
-Wwrite-strings -DGCC_BASE=\"/usr/lib/gcc/x86_64-linux-gnu/8/\" 
-DMULTIARCH_TRIPLET=\"x86_64-linux-gnu\" -Wp,-MD,./.test-lexing.o.d  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 test-lexing.c
gcc-8 -o target.o -c -O2 -finline-functions -fno-strict-aliasing -g -Wall 
-Wwrite-strings -DGCC_BASE=\"/usr/lib/gcc/x86_64-linux-gnu/8/\" 
-DMULTIARCH_TRIPLET=\"x86_64-linux-gnu\" -Wp,-MD,./.target.o.d  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 target.c
gcc-8 -o parse.o -c -O2 -finline-functions -fno-strict-aliasing -g -Wall 
-Wwrite-strings -DGCC_BASE=\"/usr/lib/gcc/x86_64-linux-gnu/8/\" 
-DMULTIARCH_TRIPLET=\"x86_64-linux-gnu\" -Wp,-MD,./.parse.o.d  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 parse.c
gcc-8 -o tokenize.o -c -O2 -finline-functions -fno-strict-aliasing -g -Wall 
-Wwrite-strings -DGCC_BASE=\"/usr/lib/gcc/x86_64-linux-gnu/8/\" 
-DMULTIARCH_TRIPLET=\"x86_64-linux-gnu\" -Wp,-MD,./.tokenize.o.d  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 tokenize.c

[... snipped ...]

error: actual error text does not match expected error text.
error: see typeof-noderef.c.error.* for further investigation.
--- typeof-noderef.c.error.expected 2018-12-26 21:08:15.289676014 +
+++ typeof-noderef.c.error.got  2018-12-26 21:08:15.289676014 +
@@ -0,0 +1,6 @@
+typeof-noderef.c:7:30: warning: incorrect type in initializer (different 
modifiers)
+typeof-noderef.c:7:30:expected int *ptr3
+typeof-noderef.c:7:30:got int [noderef] *ptr
+typeof-noderef.c:8:29: warning: incorrect type in initializer (different 
modifiers)
+typeof-noderef.c:8:29:expected int *ptr4
+typeof-noderef.c:8:29:got int [noderef] *ptr
info: test 'typeof-noderef.c' is known to fail
 TESTtypeof-safe (typeof-safe.c)
Using command   : ../sparse typeof-safe.c
Expecting exit value: 0
error: actual error text does not match expected error text.
error: see typeof-safe.c.error.* for further investigation.
--- typeof-safe.c.error.expected2018-12-26 21:08:15.297675854 +
+++ typeof-safe.c.error.got 2018-12-26 21:08:15.297675854 +
@@ -0,0 +1,9 @@
+typeof-safe.c:9:30: warning: incorrect type in initializer (different 
modifiers)
+typeof-safe.c:9:30:expected int *ptr3
+typeof-safe.c:9:30:got int [safe] *ptr
+typeof-safe.c:10:29: warning: incorrect type in initializer (different 
modifiers)
+typeof-safe.c:10:29:expected int *ptr4
+typeof-safe.c:10:29:got int [safe] *ptr
+typeof-safe.c:13:13: warning: incorrect type in assignment (different 
modifiers)
+typeof-safe.c:13:13:expected int [safe] *[assigned] ptr
+typeof-safe.c:13:13:got int *
info: test 'typeof-safe.c' is known to fail
 TEST-Wtypesign (typesign.c)
Using command   : ../sparse -Wtypesign typesign.c
Expecting exit value: 0
 TESTVarargs bogus warning regression test #1 (varargs1.c)
Using command   : ../sparse varargs1.c
Expecting exit value: 0
 TESTwide character constants (wide.c)
Using command   : ../sparse wide.c
Expecting exit value: 0
Out of 288 tests, 277 passed, 11 failed (10 of them are known to fail)
make[2]: *** [Makefile:242: check] Error 1
make[2]: Leaving directory '/<>'
dh_auto_test: make -j1 check "SPARSE_VERSION=\$(VERSION) (Debian: 0.5.2-2)" 
PREFIX=/usr PKGCONFIGDIR=/usr/lib/x86_64-linux-gnu/pkgconfig V=1 returned exit 
code 2
make[1]: *** [debian/rules:21: override_dh_auto_test] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:15: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -B"
but it also fails here:

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

where you can get a full build

Bug#917597: FTBFS: test failures

[Steve McIntyre]

Package: src:pytest-qt
Version: 2.3.1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi!

I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines, so this rebuild is to identify packages that
might have problems with this configuration.

While doing that, I've found that pytest-qt fails multiple tests in
its testsuite. I've tested further and I can reproduce the same thing
in a normal amd64 build too, so it's not an architecture-specific
problem.

...
tests/test_basics.py [ 10%]
tests/test_exceptions.py .   [ 14%]
tests/test_logging.py ...F.  [ 23%]
tests/test_modeltest.py .[ 33%]
tests/test_qtest_proxies.py ..x. [ 36%]
tests/test_wait_signal.py .. [ 51%]
 [ 74%]
..s...ss [ 97%]
.[ 98%]
tests/test_wait_until.py ..  [100%]

=== FAILURES ===
___ test_logging_mark_with_invalid_argument 

testdir = 

def test_logging_mark_with_invalid_argument(testdir):
"""
Test qt_log_ignore mark with invalid keyword argument.

:type testdir: _pytest.pytester.TmpTestdir
"""
testdir.makepyfile(
"""
import pytest

@pytest.mark.qt_log_ignore('match-mark', does_not_exist=True)
def test1():
pass
"""
)
res = testdir.runpytest()
lines = [
'*= ERRORS =*',
'*_ ERROR at setup of test1 _*',
"*ValueError: Invalid keyword arguments in {'does_not_exist': True} 
"
"for qt_log_ignore mark.",

# summary
'*= 1 error in*',
]
>   res.stdout.fnmatch_lines(lines)
E   Failed: nomatch: '*= ERRORS =*'
E   and: '= test session starts 
=='
E   and: '= test session starts 
=='
E   and: 'platform linux -- Python 3.7.2rc1, pytest-3.10.1, py-1.7.0, 
pluggy-0.8.0'
E   and: 'PyQtAPI 1.0 -- Qt runtime 2.5 -- Qt compiled 3.5'
E   and: 'rootdir: 
/tmp/pytest-of-sbuild/pytest-0/test_logging_mark_with_invalid_argument0, 
inifile:'
E   and: 'plugins: qt-2.3.1'
E   and: 'collected 1 item'
E   and: ''
E   and: 'test_logging_mark_with_invalid_argument.py E  
   [100%]'
E   and: ''
E   fnmatch: '*= ERRORS =*'
E  with: ' ERRORS 
'
E   fnmatch: '*_ ERROR at setup of test1 _*'
E  with: '___ ERROR at setup of test1 
'
E   nomatch: "*ValueError: Invalid keyword arguments in {'does_not_exist': 
True} for qt_log_ignore mark."
E   and: ''
E   and: 'self = '
E   and: "item = "
E   and: ''
E   and: 'def pytest_runtest_setup(self, item):'
E   and: "if item.get_marker('no_qt_log'):"
E   and: 'return'
E   and: "m = item.get_marker('qt_log_ignore')"
E   and: 'if m:'
E   and: "if not set(m.kwargs).issubset(set(['extend'])):"
E   and: 'raise ValueError("Invalid keyword arguments 
in {0!r} for "'
E   and: '>"qt_log_ignore 
mark.".format(m.kwargs))'
E   fnmatch: "*ValueError: Invalid keyword arguments in {'does_not_exist': 
True} for qt_log_ignore mark."
E  with: "E   ValueError: Invalid keyword arguments in 
{'does_not_exist': True} for qt_log_ignore mark."
E   nomatch: '*= 1 error in*'
E   and: ''
E   and: 
'/<>/.pybuild/cpython3_3.7_pytestqt/build/pytestqt/logging.py:28: 
ValueError'
E   and: '=== warnings summary 
==='
E   and: 'test_logging_mark_with_invalid_argument.py::test1'
E   and: '  
/<>/.pybuild/cpython3_3.7_pytestqt/build/pytestqt/logging.py:26: 
RemovedInPytest4Warning: MarkInfo objects are deprecated as they contain merged 
marks which are hard to deal with correctly.'
E   and: '  Please use node.get_c

Bug#917598: petsc4py FTBFS error: ‘SNESTEST’ undeclared

[peter green]

package: petsc4py
version: 3.10.0-2
severity: serious

While trying to get the petsc/slepc/etc stack in raspbian buster into a 
consistent state I ran into the following error with petsc4py. I was also able 
to reproduce this in a Debian sid amd64 environment, so it's not raspbian 
specific.

mpicc -pthread -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -fPIC 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -DPETSC_DIR=/usr/lib/petscdir/petsc3.10/arm-linux-gnueabihf-real 
-I/usr/include/scotch -I/usr/include/hdf5/openmpi -I/usr/include/hypre 
-I/usr/include/superlu-dist -I/usr/include/superlu -I/usr/include/suitesparse 
-I/usr/lib/petscdir/petsc3.10/arm-linux-gnueabihf-real/include -Isrc/include 
-I/usr/lib/python2.7/dist-packages/numpy/core/include -I/usr/include/python2.7 -c 
src/PETSc.c -o build/temp.linux-armhf-2.7/src/PETSc.o
In file included from src/PETSc.c:4:
src/petsc4py.PETSc.c: In function 'initPETSc':
src/petsc4py.PETSc.c:284319:43: error: 'SNESTEST' undeclared (first use in this 
function); did you mean 'SNESType'?
   __pyx_t_7 = __pyx_f_8petsc4py_5PETSc_S_(SNESTEST); if (unlikely(!__pyx_t_7)) 
__PYX_ERR(37, 7, __pyx_L1_error)
   ^~~~
   SNESType
src/petsc4py.PETSc.c:284319:43: note: each undeclared identifier is reported 
only once for each function it appears in
error: command 'mpicc' failed with exit status 1

Searching for SNESTEST on codesearch.debian.net reveals the following in the 
dolfin changelog.

  * create patch PETSc_3.10_SNESTEST_removed.patch to work with
*PETSc 3.10 (SNESTEST has been removed). Thanks Jed Brown. Presumablly a 
similar fix is needed in petsc4py. *

Bug#880351: trapperkeeper-status-clojure: FTBFS: Test failures

[Cyril Brulebois]

Hi,

Cyril Brulebois  (2018-12-28):
> It was a bit curious at first since I couldn't reproduce it in my sid
> amd64 devel chroot, but could in my sid amd64 sbuild chroot… Checking
> strace's output, it seemed like it might be that some leftover from a
> previous test might have been missing:
> 
> […]/test/./target/empty.ini
> 
> so I've tried sorting the tests to run, and I've got a reproducible
> success, both inside devel & sbuild chroots.

Based on slightly different results in #907765 (where order matters but
natural sorting doesn't work[1]), I've decided to propose a different
patch: I've chosen to encode a sequence of tests that makes the test
suite run OK. This way, it should be obvious when new tests are added,
so that one can find and document a suitable sequence of tests.

 1. https://bugs.debian.org/907765#25


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
diff -Nru trapperkeeper-status-clojure-0.7.1/debian/changelog trapperkeeper-status-clojure-0.7.1/debian/changelog
--- trapperkeeper-status-clojure-0.7.1/debian/changelog	2017-08-05 22:05:17.0 +
+++ trapperkeeper-status-clojure-0.7.1/debian/changelog	2018-12-29 00:14:15.0 +
@@ -1,3 +1,13 @@
+trapperkeeper-status-clojure (0.7.1-2) UNRELEASED; urgency=medium
+
+  * Fix FTBFS by running tests in a specific order. Instead of blindly
+sorting the results of the find command and trusting it to be right,
+encode a suitable sequence of tests (Closes: #880351). Also make sure
+to error out when tests are added or removed, to make sure this
+sequence get refreshed when needed.
+
+ -- Cyril Brulebois   Sat, 29 Dec 2018 00:14:15 +
+
 trapperkeeper-status-clojure (0.7.1-1) unstable; urgency=medium
 
   * Initial release (Closes: #855744)
diff -Nru trapperkeeper-status-clojure-0.7.1/debian/rules trapperkeeper-status-clojure-0.7.1/debian/rules
--- trapperkeeper-status-clojure-0.7.1/debian/rules	2017-08-05 22:05:17.0 +
+++ trapperkeeper-status-clojure-0.7.1/debian/rules	2018-12-29 00:13:56.0 +
@@ -40,6 +40,18 @@
 	markdown $< >> $@
 	cat debian/footer.html >> $@
 
+# Tests can't run in a random order (#880351):
+override_dh_auto_test: ORDERED_TESTS=puppetlabs/trapperkeeper/services/status/check_test.clj puppetlabs/trapperkeeper/services/status/status_core_test.clj puppetlabs/trapperkeeper/services/status/status_proxy_service_test.clj puppetlabs/trapperkeeper/services/status/status_service_test.clj
+override_dh_auto_test: EXPECTED=$(shell echo "$(ORDERED_TESTS)" | sed 's/ /\n/g' | sort | xargs)
+override_dh_auto_test: FOUND=$(shell cd test && find -name '*.clj' | sed 's,^[.]/,,' | sort | xargs)
 override_dh_auto_test:
-	(cd test && find . -name "*.clj" | \
-		xargs --verbose clojure -cp $(CURDIR)/$(PRODUCED_JAR):$(CLASSPATH):$(TEST_CLASSPATH))
+	# Make sure to detect when tests appear or disappear:
+	@if [ "$(FOUND)" != "$(EXPECTED)" ]; then \
+		echo "E: sanity check failed, available tests don't match known tests:"; \
+		echo "- found:$(FOUND)"; \
+		echo "- expected: $(EXPECTED)"; \
+		echo "=> Please update ORDERED_TESTS in debian/rules accordingly"; \
+		exit 1; \
+	fi
+	# Run tests:
+	(cd test && clojure -cp $(CURDIR)/$(PRODUCED_JAR):$(CLASSPATH):$(TEST_CLASSPATH) $(ORDERED_TESTS))


signature.asc
Description: PGP signature

Bug#904363: python3-applicationinsights: fails to install with Python 3.7

[Steve McIntyre]

Control: tag -1 +ftbfs

This same problem also makes the package FTBFS:

...
  File 
"/build/python-applicationinsights-0.11.0/applicationinsights/channel/contracts/__init__.py",
 line 7, in 
from .RemoteDependencyData import RemoteDependencyData
  File 
"/build/python-applicationinsights-0.11.0/applicationinsights/channel/contracts/RemoteDependencyData.py",
 line 256
def async(self):
^
SyntaxError: invalid syntax
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: 
python3.7 setup.py test 
dh_auto_test: pybuild --test -i python{version} -p "3.7 3.6" returned exit code 
13
make: *** [debian/rules:6: build] Error 25
...

On Mon, Jul 23, 2018 at 04:32:16PM +0200, Andreas Beckmann wrote:
>Package: python3-applicationinsights
>Version: 0.11.0-1
>Severity: serious
>User: debian...@lists.debian.org
>Usertags: piuparts
>Control: block 902788 with -1 
>
>Hi,
>
>during a test with piuparts I noticed your package failed to install. As
>per definition of the release team this makes the package too buggy for
>a release, thus the severity.
>
>From the attached log (scroll to the bottom...):
>
>  Setting up python3-applicationinsights (0.11.0-1) ...
>File 
> "/usr/lib/python3/dist-packages/applicationinsights/channel/contracts/RemoteDependencyData.py",
>  line 256
>  def async(self):
>  ^
>  SyntaxError: invalid syntax
>  
>  dpkg: error processing package python3-applicationinsights (--configure):
>   installed python3-applicationinsights package post-installation script 
> subprocess returned error exit status 1
>
>
>"async" has become a reserved keyword in Python 3.7
>
>
>cheers,
>
>Andreas


-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Das Mohapatra

Bug#916673: mandos : Depends: libgnutls30 (< 3.6.0) but 3.6.5-2 is to be installed

[Steinar H. Gunderson]

On Mon, Dec 17, 2018 at 10:57:44AM +0200, Adrian Bunk wrote:
> Package: mandos
> Version: 1.7.20-1
> Severity: serious
> 
> The following packages have unmet dependencies:
>  mandos : Depends: libgnutls28-dev (< 3.6.0) but 3.6.5-2 is to be installed or
>libgnutls30 (< 3.6.0) but 3.6.5-2 is to be installed
> 
> 
> Additionally, the libgnutls28-dev alternative of the dependencies
> looks wrong - this should likely just be libgnutls30.

The reason for the -dev dependency appears to be that the Python code does
something like

  from ctypes.util import find_library
  find_library('gnutls')

but that works just fine even without the -dev package installed (so either
libgnutls28 or libgnutls30 ought to do).

Actually, I wonder if using ${shlibs:Depends} would be fine, even for the
Python code. At least it would make transitioning this package much easier. :-)
Or move back to using python-gnutls; NEWS indicates that ctypes was used
because python-gnutls didn't support GnuTLS 3.3 at the time, but
python-gnutls indicates it has supported GnuTLS 3.4 since 2016.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#880320: ssl-utils-clojure: FTBFS: Test failures

[Cyril Brulebois]

Control: reopen -1
Control: found -1 0.8.3-1

Cyril Brulebois  (2018-12-28):
> > Relevant part (hopefully):
> > >   at clojure.core$load_libs.invokeStatic(core.clj:5775)
> > >   at clojure.core$load_libs.doInvoke(core.clj:5758)
> > >   at clojure.lang.RestFn.applyTo(RestFn.java:137)
> > >   at clojure.core$apply.invokeStatic(core.clj:648)
> > >   at clojure.core$apply.invoke(core.clj:641)
> > >   at clojure.core$require.invokeStatic(core.clj:5858)
> > >   at clojure.core$require.doInvoke(core.clj:5796)
> > >   at clojure.lang.RestFn.invoke(RestFn.java:457)
> > >   at 
> > > puppetlabs.ssl_utils.extensions_utils_test$eval4329$loading__1497__auto4330.invoke(extensions_utils_test.clj:1)
> > >   at 
> > > puppetlabs.ssl_utils.extensions_utils_test$eval4329.invokeStatic(extensions_utils_test.clj:1)
> > >   at 
> > > puppetlabs.ssl_utils.extensions_utils_test$eval4329.invoke(extensions_utils_test.clj:1)
> > >   at clojure.lang.Compiler.eval(Compiler.java:6927)
> > >   at clojure.lang.Compiler.eval(Compiler.java:6916)
> > >   at clojure.lang.Compiler.load(Compiler.java:7379)
> > >   ... 12 more
> > > debian/rules:28: recipe for target 'override_dh_auto_test' failed

[…]

> I can't reproduce this issue in sid today, so I'm closing this bug
> report for the time being. Feel free to cc me, should this FTBFS
> be reproducible on your side.

Reopening as I was finally able to reproduce this issue on a test
machine kindly provided by Santiago[1], but also locally by adding a
“| sort -R” call after the “find” one in override_dh_auto_test and
trying a build a few times.

 1. https://bugs.debian.org/907765#15

I've checked that using “sort” or “sort -r” both give positive results,
and I'll propose a patch encoding one of the known-good sequence, as
already done in other packages[2,3].

 2. https://bugs.debian.org/907765#25
 3. https://bugs.debian.org/880351#19

(This package and a few others migrated to testing while this RC bug
was closed, but they'll get kicked out again if this bug doesn't get
resolved.)

I intend to NMU this package in a few days, like the other ones.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#847613: ITP: nextcloud-client -- desktop client for nextcloud

[Sandro Knauß]

Hey Lev,

sorry I havn't seen, that you already took the task of packaging nextcloud-
desktop for Debian. I started already to copy the work done at owncloud-client 
to nextcloud-desktop and also got something, that is quite ready for usage.
I published my work at salsa:
https://salsa.debian.org/owncloud-team/nextcloud-desktop

maybe we can join our forces to get a working package ready soon.

Also I want to invite you to the pkg-ownload team, as the both clients have a 
lot in common, it makes sense in my point of view to work together.

I really don't want to take over this package. I'm really happy if you care 
about the package. But as I already put effort to this, that may help your 
work. 

Never the less if you finished your work, I can sponsor it, if you want.

Regards,

sandro

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

Bug#880320: ssl-utils-clojure: FTBFS: Test failures

[Cyril Brulebois]

Control: tag -1 patch

Cyril Brulebois  (2018-12-29):
> Reopening as I was finally able to reproduce this issue on a test
> machine kindly provided by Santiago[1], but also locally by adding a
> “| sort -R” call after the “find” one in override_dh_auto_test and
> trying a build a few times.
> 
>  1. https://bugs.debian.org/907765#15
> 
> I've checked that using “sort” or “sort -r” both give positive results,
> and I'll propose a patch encoding one of the known-good sequence, as
> already done in other packages[2,3].
> 
>  2. https://bugs.debian.org/907765#25
>  3. https://bugs.debian.org/880351#19

[…]

> I intend to NMU this package in a few days, like the other ones.

You'll find attached the prospective patch.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
diff -Nru ssl-utils-clojure-0.8.3/debian/changelog ssl-utils-clojure-0.8.3/debian/changelog
--- ssl-utils-clojure-0.8.3/debian/changelog	2017-08-05 17:17:48.0 +
+++ ssl-utils-clojure-0.8.3/debian/changelog	2018-12-29 00:54:20.0 +
@@ -1,3 +1,13 @@
+ssl-utils-clojure (0.8.3-2) UNRELEASED; urgency=medium
+
+  * Fix FTBFS by running tests in a specific order. Instead of blindly
+sorting the results of the find command and trusting it to be right,
+encode a suitable sequence of tests (Closes: #880320). Also make sure
+to error out when tests are added or removed, to make sure this
+sequence get refreshed when needed.
+
+ -- Cyril Brulebois   Sat, 29 Dec 2018 00:54:20 +
+
 ssl-utils-clojure (0.8.3-1) unstable; urgency=medium
 
   * Initial release (Closes: #855740)
diff -Nru ssl-utils-clojure-0.8.3/debian/rules ssl-utils-clojure-0.8.3/debian/rules
--- ssl-utils-clojure-0.8.3/debian/rules	2017-08-05 17:17:48.0 +
+++ ssl-utils-clojure-0.8.3/debian/rules	2018-12-29 00:54:02.0 +
@@ -24,10 +24,21 @@
 	rm -f $(CURDIR)/$(PRODUCED_JAR)
 	rm -rf $(CURDIR)/doc/html
 
+# Tests can't run in a random order (#880320):
+override_dh_auto_test: ORDERED_TESTS=puppetlabs/ssl_utils/core_test.clj puppetlabs/ssl_utils/extensions_utils_test.clj puppetlabs/ssl_utils/simple_test.clj
+override_dh_auto_test: EXPECTED=$(shell echo "$(ORDERED_TESTS)" | sed 's/ /\n/g' | sort | xargs)
+override_dh_auto_test: FOUND=$(shell cd test && find -name '*.clj' | sed 's,^[.]/,,' | sort | xargs)
 override_dh_auto_test:
-	dh_auto_test
-	(cd test && find . -name "*_test.clj" | \
-		xargs --verbose clojure -cp $(CURDIR)/$(PRODUCED_JAR):$(CLASSPATH):$(TEST_CLASSPATH))
+	# Make sure to detect when tests appear or disappear:
+	@if [ "$(FOUND)" != "$(EXPECTED)" ]; then \
+		echo "E: sanity check failed, available tests don't match known tests:"; \
+		echo "- found:$(FOUND)"; \
+		echo "- expected: $(EXPECTED)"; \
+		echo "=> Please update ORDERED_TESTS in debian/rules accordingly"; \
+		exit 1; \
+	fi
+	# Run tests:
+	(cd test && clojure -cp $(CURDIR)/$(PRODUCED_JAR):$(CLASSPATH):$(TEST_CLASSPATH) $(ORDERED_TESTS))
 
 get-orig-source:
 	uscan --download-version $(DEB_VERSION_UPSTREAM) --force-download --rename


signature.asc
Description: PGP signature

Bug#917271: yamllint: requires module pkg_resources but does not depend on it

[Philipp Huebner]

Hi,

Am 25.12.18 um 11:15 schrieb Jack Henschel:
> I just installed the `yamllint` package on a pretty fresh Debian Stretch
> system. When running it for the first time the following error occured:
[...]
> Please add the package `python3-pkg-resources` to the Depends-field of
> `yamllint`.

thanks a lot for your report, you're spot on - but not the first.

This has been reported several times already (#860075, #908114) and is
fixed in newer versions of the package - to be part of the next stable
release.

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



signature.asc
Description: OpenPGP digital signature

Bug#917524: initramfs-tools: Upgrade from initramfs-tools package fails

[Ben Hutchings]

Control: reassign -1 udev
Control: forcemerge 917261 -1

This looks like a known udev regression, which is fixed in version
240-2.

Ben.

-- 
Ben Hutchings
Life is what happens to you while you're busy making other plans.
  - John Lennon



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

Bug#916134: linux-image-4.18.0-3-amd64: 4.18.0-3 fails to boot, 0-2 works.

[Ben Hutchings]

Control: forcemerge 914495 -1

I'm assuming this report is about the same bug as all the similar
reports about i915 regressions in version 4.18.20, so I'm merging (and
closing) it.

The bug should be fixed in 4.19 which is now in testing.

Ben.

-- 
Ben Hutchings
Life is what happens to you while you're busy making other plans.
  - John Lennon



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

Bug#916510: duplicate

[Ben Hutchings]

Control: forcemerge 914495 -1

On Sat, 2018-12-15 at 09:26 +0100, Patrik Kluba wrote:
> Sorry, just noticed that this report duplicates several other
> reported bugs.
> But also found a suspected solution elsewhere:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=108984
> https://bugs.freedesktop.org/show_bug.cgi?id=108850

Assuming that this was the same bug, I'm merging your bug report with
the others (and so closing it).

Ben.

-- 
Ben Hutchings
Life is what happens to you while you're busy making other plans.
  - John Lennon



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

Bug#917601: Problem with softhsm use of statoverrides?

[Steve McIntyre]

Package: src:softhsm
Version: 2.4.0-0.1
Severity: important

Hi!

Several times today on my build farm I've seen this problem occur when
installing packages, mostly via "apt-get build-dep ." .

...
dpkg: unrecoverable fatal error, aborting:
 unknown group 'softhsm' in statoverride file
E: Sub-process /usr/bin/dpkg returned an error code (2)
E: Failed to process build dependencies
...

I had softhsm packages installed as build-deps for
mod-gnutls. Removing and re-installing the softhsm packages fixes
things for me.

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

Kernel: Linux 4.9.0-8-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)

Bug#917600: puppetlabs-ring-middleware-clojure: FTBFS (failing tests)

[Santiago Vila]

Package: src:puppetlabs-ring-middleware-clojure
Version: 1.0.0-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --with javahelper --with jh_maven_repo_helper
   dh_update_autotools_config -i
   dh_autoreconf -i
   jh_linkjars -i
   debian/rules override_jh_build
make[1]: Entering directory '/<>'
cat debian/header.html > /<>/CHANGELOG.html
sed -i'' -e 's#@TITLE@#1.0.0#g' /<>/CHANGELOG.html
markdown /<>/CHANGELOG.md >> /<>/CHANGELOG.html
cat debian/footer.html >> /<>/CHANGELOG.html
cat debian/header.html > /<>/CONTRIBUTING.html
sed -i'' -e 's#@TITLE@#How to contribute#g' /<>/CONTRIBUTING.html
markdown /<>/CONTRIBUTING.md >> /<>/CONTRIBUTING.html

[... snipped ...]

xargs --verbose clojure -cp 
/<>/puppetlabs-ring-middleware.jar:/usr/share/java/clojure.jar:/usr/share/java/clj-time.jar:/usr/share/java/cheshire.jar:/usr/share/java/tools.logging.jar:/usr/share/java/prismatic-schema.jar:/usr/share/java/puppetlabs-http-client.jar:/usr/share/java/kitchensink.jar:/usr/share/java/ssl-utils.jar:/usr/share/java/ring-core.jar:/usr/share/java/slingshot.jar:/usr/share/java/trapperkeeper-test.jar:/usr/share/java/trapperkeeper-webserver-jetty9.jar:/usr/share/java/kitchensink-test.jar:/usr/share/java/compojure.jar:/usr/share/java/tools.reader.jar:/usr/share/java/tools.macro.jar)
clojure -cp 
/<>/puppetlabs-ring-middleware.jar:/usr/share/java/clojure.jar:/usr/share/java/clj-time.jar:/usr/share/java/cheshire.jar:/usr/share/java/tools.logging.jar:/usr/share/java/prismatic-schema.jar:/usr/share/java/puppetlabs-http-client.jar:/usr/share/java/kitchensink.jar:/usr/share/java/ssl-utils.jar:/usr/share/java/ring-core.jar:/usr/share/java/slingshot.jar:/usr/share/java/trapperkeeper-test.jar:/usr/share/java/trapperkeeper-webserver-jetty9.jar:/usr/share/java/kitchensink-test.jar:/usr/share/java/compojure.jar:/usr/share/java/tools.reader.jar:/usr/share/java/tools.macro.jar
 ./puppetlabs/ring_middleware/core_test.clj 
./puppetlabs/ring_middleware/utils_test.clj 
./puppetlabs/ring_middleware/testutils/common.clj 
WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: 
puppetlabs.kitchensink.core, being replaced by: 
#'puppetlabs.kitchensink.core/boolean?
WARNING: uuid? already refers to: #'clojure.core/uuid? in namespace: 
puppetlabs.kitchensink.core, being replaced by: 
#'puppetlabs.kitchensink.core/uuid?
Exception in thread "main" java.io.FileNotFoundException: Could not locate 
puppetlabs/ring_middleware/testutils/common__init.class or 
puppetlabs/ring_middleware/testutils/common.clj on classpath. Please check that 
namespaces with dashes use underscores in the Clojure file name., 
compiling:(/<>/test/./puppetlabs/ring_middleware/core_test.clj:1:1)
at clojure.lang.Compiler.load(Compiler.java:7526)
at clojure.lang.Compiler.loadFile(Compiler.java:7452)
at clojure.main$load_script.invokeStatic(main.clj:278)
at clojure.main$script_opt.invokeStatic(main.clj:338)
at clojure.main$script_opt.invoke(main.clj:333)
at clojure.main$main.invokeStatic(main.clj:424)
at clojure.main$main.doInvoke(main.clj:387)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.lang.Var.applyTo(Var.java:702)
at clojure.main.main(main.java:37)
Caused by: java.io.FileNotFoundException: Could not locate 
puppetlabs/ring_middleware/testutils/common__init.class or 
puppetlabs/ring_middleware/testutils/common.clj on classpath. Please check that 
namespaces with dashes use underscores in the Clojure file name.
at clojure.lang.RT.load(RT.java:463)
at clojure.lang.RT.load(RT.java:426)
at clojure.core$load$fn__9115.invoke(core.clj:6046)
at clojure.core$load.invokeStatic(core.clj:6045)
at clojure.core$load.doInvoke(core.clj:6029)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invokeStatic(core.clj:5848)
at clojure.core$load_one.invoke(core.clj:5843)
at clojure.core$load_lib$fn__9060.invoke(core.clj:5888)
at clojure.core$load_lib.invokeStatic(core.clj:5887)
at clojure.core$load_lib.doInvoke(core.clj:5868)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invokeStatic(core.clj:659)
at clojure.core$load_libs.invokeStatic(core.clj:5925)
at clojure.core$load_libs.doInvoke(core.clj:5909)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invokeStatic(core.clj:659)
at clojure.core$require.invokeStatic(core.clj:5947)
at clojure.core$require.doInvoke(core.clj:5947)
at clojure.lang.RestFn.invoke(RestFn.java:2422)
at 
puppetlabs.ring_middleware.core_test$eval2694$loading__9001__auto2695.invoke(core_test.clj:1)
at 
puppetlabs.ring_middleware.core_test$eval26

Bug#917602: python-fitsio 0.9.11+dfsg-4: FTBFS, alignment problem

[Steve McIntyre]

Source: python-fitsio
Version: 0.9.11+dfsg-4
Severity: important
User: debian-...@lists.debian.org
Usertags: alignment

Hi!

I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning in future to move all of our 32-bit armel/armhf builds to
using arm64 machines, so this rebuild is to identify packages that
might have problems with this configuration.

A feature of the arm64 kernel is that it does *not* support fixing up
code with broken alignment, so code that might have built and run OK
on our older armel/armhf build machines due to kernel fixups will now
fail.

When building your package, I've found a bus error (aka alignment
fault). The full log is online at

  
https://www.einval.com/debian/arm/rebuild-logs/armel/FAIL/python-fitsio_0.9.11+dfsg-4_armel.log

for reference

I've done a quick bit of debugging to find the source of the
bug. Here's a gdb stacktrace to demonstrate the problem. I'm not sure
if the likely culprit is the test code here, or the underlying
library.

(sid-armel)steve@maul:~/debian/build/python-fitsio/python-fitsio-0.9.11+dfsg$ 
gdb /usr/bin/python2.7 ./.pybuild/cpython2_2.7_fitsio/build/core
...
warning: Could not load shared library symbols for fitsio/_fitsio_wrap.so.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".
Core was generated by `python2.7 -m unittest discover -v'.
Program terminated with signal SIGBUS, Bus error.
#0  ffi8fi8 (input=input@entry=0x7, ntodo=ntodo@entry=1, scale=, 
zero=0, output=output@entry=0xff861368, status=status@entry=0xff868554) at 
putcolj.c:1900
1900putcolj.c: No such file or directory.
(gdb) bt
#0  ffi8fi8 (input=input@entry=0x7, ntodo=ntodo@entry=1, scale=, 
zero=0, output=output@entry=0xff861368, status=status@entry=0xff868554) at 
putcolj.c:1900
#1  0xf5074ae4 in ffpcljj (fptr=0x1, colnum=-149821080, firstrow=, firstelem=, nelem=1, array=0x2303cef, status=0xff868554) 
at putcolj.c:1442
#2  0xf5074ce4 in ffpcljj (fptr=, colnum=, 
firstrow=, firstelem=1, nelem=1, array=0x2303cef, 
array@entry=0x1, status=status@entry=0xff868554)
at putcolj.c:1371
#3  0xf50669c4 in ffpcl (status=0xff868554, array=0x1, nelem=1, firstelem=1, 
firstrow=-768257499031892296, colnum=, datatype=, 
fptr=)
at putcol.c:739
#4  ffpcl (fptr=, datatype=, colnum=, firstrow=1, firstelem=1, nelem=1, array=0x2303cef, status=0xff868554) at 
putcol.c:668
#5  0xf55699e0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


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

Kernel: Linux 4.9.0-8-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)

Bug#917600: puppetlabs-ring-middleware-clojure: FTBFS (failing tests)

[Cyril Brulebois]

Control: tag -1 patch

Hi,

Santiago Vila  (2018-12-29):
>   xargs --verbose clojure -cp 
> /<>/puppetlabs-ring-middleware.jar:/usr/share/java/clojure.jar:/usr/share/java/clj-time.jar:/usr/share/java/cheshire.jar:/usr/share/java/tools.logging.jar:/usr/share/java/prismatic-schema.jar:/usr/share/java/puppetlabs-http-client.jar:/usr/share/java/kitchensink.jar:/usr/share/java/ssl-utils.jar:/usr/share/java/ring-core.jar:/usr/share/java/slingshot.jar:/usr/share/java/trapperkeeper-test.jar:/usr/share/java/trapperkeeper-webserver-jetty9.jar:/usr/share/java/kitchensink-test.jar:/usr/share/java/compojure.jar:/usr/share/java/tools.reader.jar:/usr/share/java/tools.macro.jar)
> clojure -cp 
> /<>/puppetlabs-ring-middleware.jar:/usr/share/java/clojure.jar:/usr/share/java/clj-time.jar:/usr/share/java/cheshire.jar:/usr/share/java/tools.logging.jar:/usr/share/java/prismatic-schema.jar:/usr/share/java/puppetlabs-http-client.jar:/usr/share/java/kitchensink.jar:/usr/share/java/ssl-utils.jar:/usr/share/java/ring-core.jar:/usr/share/java/slingshot.jar:/usr/share/java/trapperkeeper-test.jar:/usr/share/java/trapperkeeper-webserver-jetty9.jar:/usr/share/java/kitchensink-test.jar:/usr/share/java/compojure.jar:/usr/share/java/tools.reader.jar:/usr/share/java/tools.macro.jar
>  ./puppetlabs/ring_middleware/core_test.clj 
> ./puppetlabs/ring_middleware/utils_test.clj 
> ./puppetlabs/ring_middleware/testutils/common.clj 
> WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: 
> puppetlabs.kitchensink.core, being replaced by: 
> #'puppetlabs.kitchensink.core/boolean?
> WARNING: uuid? already refers to: #'clojure.core/uuid? in namespace: 
> puppetlabs.kitchensink.core, being replaced by: 
> #'puppetlabs.kitchensink.core/uuid?
> Exception in thread "main" java.io.FileNotFoundException: Could not locate 
> puppetlabs/ring_middleware/testutils/common__init.class or 
> puppetlabs/ring_middleware/testutils/common.clj on classpath. Please check 
> that namespaces with dashes use underscores in the Clojure file name., 
> compiling:(/<>/test/./puppetlabs/ring_middleware/core_test.clj:1:1)
>   at clojure.lang.Compiler.load(Compiler.java:7526)
>   at clojure.lang.Compiler.loadFile(Compiler.java:7452)
>   at clojure.main$load_script.invokeStatic(main.clj:278)
>   at clojure.main$script_opt.invokeStatic(main.clj:338)
>   at clojure.main$script_opt.invoke(main.clj:333)
>   at clojure.main$main.invokeStatic(main.clj:424)
>   at clojure.main$main.doInvoke(main.clj:387)
>   at clojure.lang.RestFn.applyTo(RestFn.java:137)
>   at clojure.lang.Var.applyTo(Var.java:702)
>   at clojure.main.main(main.java:37)
> Caused by: java.io.FileNotFoundException: Could not locate 
> puppetlabs/ring_middleware/testutils/common__init.class or 
> puppetlabs/ring_middleware/testutils/common.clj on classpath. Please check 
> that namespaces with dashes use underscores in the Clojure file name.
>   at clojure.lang.RT.load(RT.java:463)
>   at clojure.lang.RT.load(RT.java:426)
>   at clojure.core$load$fn__9115.invoke(core.clj:6046)
>   at clojure.core$load.invokeStatic(core.clj:6045)
>   at clojure.core$load.doInvoke(core.clj:6029)
>   at clojure.lang.RestFn.invoke(RestFn.java:408)
>   at clojure.core$load_one.invokeStatic(core.clj:5848)
>   at clojure.core$load_one.invoke(core.clj:5843)
>   at clojure.core$load_lib$fn__9060.invoke(core.clj:5888)
>   at clojure.core$load_lib.invokeStatic(core.clj:5887)
>   at clojure.core$load_lib.doInvoke(core.clj:5868)
>   at clojure.lang.RestFn.applyTo(RestFn.java:142)
>   at clojure.core$apply.invokeStatic(core.clj:659)
>   at clojure.core$load_libs.invokeStatic(core.clj:5925)
>   at clojure.core$load_libs.doInvoke(core.clj:5909)
>   at clojure.lang.RestFn.applyTo(RestFn.java:137)
>   at clojure.core$apply.invokeStatic(core.clj:659)
>   at clojure.core$require.invokeStatic(core.clj:5947)
>   at clojure.core$require.doInvoke(core.clj:5947)
>   at clojure.lang.RestFn.invoke(RestFn.java:2422)
>   at 
> puppetlabs.ring_middleware.core_test$eval2694$loading__9001__auto2695.invoke(core_test.clj:1)
>   at 
> puppetlabs.ring_middleware.core_test$eval2694.invokeStatic(core_test.clj:1)
>   at puppetlabs.ring_middleware.core_test$eval2694.invoke(core_test.clj:1)
>   at clojure.lang.Compiler.eval(Compiler.java:7062)
>   at clojure.lang.Compiler.eval(Compiler.java:7051)
>   at clojure.lang.Compiler.load(Compiler.java:7514)
>   ... 9 more
> make[1]: *** [debian/rules:27: override_dh_auto_test] Error 123
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:12: build-indep] Error 2
> dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
> status 2
> 

Please find attached a patch similar to those submitted in #907765,
#880320, #880351. I intend to NMU this package in a fe

Bug#917516: anbox: does not pull binder or ashmem kernel drivers as dependency

[Svetlana Tkachenko]

File/directory /use/share/doc/anbox/ does not exist.

Bug#890190: edge_flip_delay

[M. S.]

Hi, I cant read the first messages, but I assume this here has nothing to do 
with the wall-plugin as the wall-plugin is disabled here for me in Mint Mate.

The problem is that the viewport/cube rotates immediately, correct? So it cant 
be the wall-plugin.

There is a missing edge_flip_DELAY in the "rotate"-plugin, or someone has to 
make edge_flip from "rotate" plugin getting a delay by 'edge_delay' in 
general-settings.

Please fix this soon, coders...its no fun at all to see the same problem since 
YEARS. Many thanks in advance

Bug#917516: anbox: does not pull binder or ashmem kernel drivers as dependency

[Shengjing Zhu]

Svetlana Tkachenko  于 2018年12月29日周六 09:59写道：

> File/directory /use/share/doc/anbox/ does not exist.
>

Sorry for the typo, sending from my mobile phone.

It's /usr/, you should also find it in package's description.

>

Bug#913663: Bug#917592: libterm-termkey-perl: FTBFS (failing tests)

[gregor herrmann]

On Sat, 29 Dec 2018 00:25:25 +, Santiago Vila wrote:

> Package: src:libterm-termkey-perl
> Version: 0.16-3
> Severity: serious
> Tags: ftbfs

> I tried to build this package in buster but it failed:

> Test Summary Report
> ---
> t/05flags.t   (Wstat: 11 Tests: 2 Failed: 0)
>   Non-zero wait status: 11
>   Parse errors: Bad plan.  You planned 4 tests but ran 2.

Same in #917497.

Both tests fail during build and not during autopkgtests (locally and
on r-b/ci.debian.net).

After thinking a bit I tried:

#v+
--- a/debian/rules
+++ b/debian/rules
@@ -4,4 +4,4 @@
dh $@

 override_dh_auto_test:
-   TERM=vt100 dh_auto_test
+   TERM=vt100 prove --blib --verbose t/*.t
#v-

(which happens during autopkgtest), and, tataa!, the tests also pass
during build.

So the question is why dh_auto_test fails.


For dh_auto_test we have:

   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/libterm-termkey-perl-0.16'
TERM=vt100 dh_auto_test
perl Build test --verbose 1


Sticking `TERM=vt100 perl Build test --verbose 1' into debian/rules
also makes the test pass. -- Ok …


So why does dh_auto_test fail? What has changed here? perl?
debhelper? Something else?


From the debhelper changelog:

debhelper (11.5.4) unstable; urgency=medium

  [ Niels Thykier ]
  * Dh_Lib.pm: Reopen stdin to read from /dev/null in doit (and its sibling
functions) to prevent issues when stdin is open in write-only mode
(which is what nohup(1) does).  Thanks to Julian Gilbey for reporting
the issue and providing a sample patch for it as well.
(Closes: #913663)


Can this be related? (The failing test operate on \*STDIN.)
Cc'ing the debhelper bug and debhelper maintainers …


Cheers,
gregor


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Victor Wooten: Me & My Bass Guitar


signature.asc
Description: Digital Signature

Bug#917524: initramfs-tools: Upgrade from initramfs-tools package fails

[Jürgen Göricke]

Hello Ben,

I already installed udev 240-2, but the bug in the initramfs-tools package 
still exists.
This is not surprising, because udev was installed a few days ago without any 
errors.
Only by installing the package "initramfs-tools" (version: 0.132: all) the 
installation error occurred.

Can you please check again where exactly the error is?
Thanks a lot!

Below I have listed the packages installed on my system.


$  dpkg -l | grep udev
ii udev 240-2 amd64 /dev/ and hotplug management daemon

$  dpkg -l | grep initramfs-tools
iF initramfs-tools 0.132 all generic modular initramfs generator (automation)

Best regards


Jürgen


pgpxdxyUN_lry.pgp
Description: Digitale Signatur von OpenPGP

Bug#917390: avr-gcc version mismatch

[Brian Holaday]

Adding Microchips Support Responses.

Case Comments
Comment
*Created By: Brian Holaday
 (12/28/2018 12:12 PM)*
Created Attachment: Shot2.png
*Created By: Brian Holaday
 (12/28/2018 12:11 PM)*
Hi Amit,

Looking at your screenshots I see that the GCC-AVR compiler is installed on
Windows automatically. On Linux this is packaged as (gcc-avr) or
downloading the toolkit manually for each project.

I have created a debian bug request:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917390 and reached the
developer to see if we can get the versioning fixed in gcc-avr on build. If
you look at the screenshot I attached their is a version mismatch between
the downloaded version and packaged version in debian.

The project is also here: https://salsa.debian.org/debian/gcc-avr/branches

** Again if we can wait for Hakan (developer) for packing gcc-avr to fix
this then it would be much easier using one tool for install than providing
a backup install to /opt/ like I suggested. It almost might be easier also
to reach out to the debian packaging team to see if MP LAB X and the other
toolkits could be complied into a package. **

Link #1: https://wiki.debian.org/HowToPackageForDebian (Packaging)
Link #2: https://www.debian.org/doc/manuals/maint-guide/ (Guidance)
Link #3: You could email ha...@debian.org if you have questions : at least
I came to him for reporting.

I just would hate to see MP LAB X be complied from their own tool base but
rather use what has been set up.
*Created By: Amit Shali
 (12/28/2018 5:34 AM)*
Hi Brian,

Thanks for reporting this.

I was able to replicate the AVR and AVRASM 2 toolchain selection issue
under Ubuntu 16.04.

Steps to replicate:
a. Create a new standalone project under MPLAB X IDE
b. Select ATMEGA328P and Atmel-ICE
c. AVR or AVRASM 2 isn’t selectable

However, this issue didn't occur on my Windows machine.
I have attached screenshots from my Windows machine.

We will investigate this in depth.
I will keep you posted on the updates on this.

Regards,
Amit
*Created By: Brian Holaday
 (12/27/2018 1:12 AM)*
I figured out the issue with my Debian install and MPLab X. I will share
the results below after looking at patching:

Please correct: http://microchipdeveloper.com/install:mplabx-lin64

Debian: Ubuntu and Mint: (dpkg)
#sudo dpkg --add-architecture i386
#sudo apt-get install libc6:i386 libx11-6:i386 libxext6:i386
libstdc++6:i386 libexpat1:i386
#sudo apt-get install gcc-avr avr-libc

Attempt #1: Fail on GCC-AVR
MPLAB X requires gcc-avr to be installed if using an ATMEGA* however I
found out that for now this package on Debian needs re-worked with
versioning for this to work on MPLAB X. I did install this package and a
toolchain became available however the packaging was off with versioning on
Debian and the developer pushing this package.

(https://packages.debian.org/stretch/gcc-avr)

Manual Package: GCC-AVR Official
I then tried to download the AVR Toolchain Proper Link: (
http://ww1.microchip.com/downloads/en/DeviceDoc/avr8-gnu-toolchain-3.6.2.1759-linux.any.x86_64.tar.gz
)

Command:
#wget
http://ww1.microchip.com/downloads/en/DeviceDoc/avr8-gnu-toolchain-3.6.2.1759-linux.any.x86_64.tar.gz

#gunzip -k avr8-gnu-toolchain-3.6.2.1759-linux.any.x86_64.tar.gz
#mkdir /opt/avr-gcc
#mv avr8-gnu-toolchain-3.6.2.1759-linux.any.x86_64.tar.gz /opt/avr-gcc

I then added the New Toolchain to MPLAB X : Project Selection works: All is
good.


Final:
What was wrong was I had thought the package avr-gcc used by Debian was
current. It appears that on build it is missing several items and I have
filed a bug with the developer to see if we can get this fixed and/or move
the toolchain to /opt/ or you could even include this on install as you did
another toolchain. Ideally I would use /opt to export your toolchains and
configure MPLAB to pick them up rather than depend on a second package.

I personally use avrdude for programming and am building a tool for the AVR
ICE on a breadboard - I would almost like to see MP LAB X use GCC rather
than use Java as more open source projects come to live.
*Created By: Brian Holaday
 (12/26/2018 12:05 AM)*
Created Attachment: A1.png

On Fri, Dec 28, 2018 at 2:40 PM Brian Holaday 
wrote:

> FYI:
>
> On Fri, Dec 28, 2018 at 12:16 PM Brian Holaday 
> wrote:
>
>>
>> FYI:
>>
>> -- Forwarded message -
>> From: Brian Holaday 
>> Date: Fri, Dec 28, 2018 at 11:47 AM
>> Subject: Re: avr-gcc version mismatch
>> To: Hakan Ardo 
>>
>>
>> Hi Hakan,
>>
>> #1. I have attached a screenshot below just in case you need to see where
>> I am seeing the error after installing MP Lab X. I also included some
>> directions I followed for the install if you wanted to test MP LAB X.
>>
>> #2. I will check out the git package 

Bug#917603: python3-yaml: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working

[Niels Thykier]

Package: python3-yaml
Version: 3.13-1
Severity: normal

Hi,

I spotted this in the CI job of britney2[1].

"""
tests/test_autopkgtest.py::T::test_alternative_gcc
  /usr/lib/python3/dist-packages/yaml/constructor.py:126: DeprecationWarning: 
Using or importing the ABCs from 'collections' instead of from 
'collections.abc' is deprecated, and in 3.8 it will stop working
if not isinstance(key, collections.Hashable):
"""

The code in question at the time of reporting (highlighed with "^"-marks):

"""
def construct_mapping(self, node, deep=False):
if not isinstance(node, MappingNode):
raise ConstructorError(None, None,
"expected a mapping node, but found %s" % node.id,
node.start_mark)
mapping = {}
for key_node, value_node in node.value:
key = self.construct_object(key_node, deep=deep)
if not isinstance(key, collections.Hashable):
^
raise ConstructorError("while constructing a mapping", 
node.start_mark,
"found unhashable key", key_node.start_mark)
value = self.construct_object(value_node, deep=deep)
mapping[key] = value
return mapping
"""

Presumably this is (or will be) fixed in a new upstream release but it
might make sense to cherry-pick that fix for buster to avoid breakage
in sid + buster at the moment.

Thanks,
~Niels

[1] https://salsa.debian.org/release-team/britney2/-/jobs/99062

Bug#917604: libavcodec57 v. 7:3.4.3-1 has depended from libx264-152

[Сергей Фёдоров]

Package: libavcodec57
Version: 7:3.4.3-1
Severity: important
Tags: a11y

Dear Maintainer,

When it is installed a packet libavcodec57 v. 7:3.4.3-1
(FFmpeg library with de/encoders for audio/video codecs - runtime files)
it is issued a message «It has depended from libx264-152  but it is not
 installable», but  there is «libx264-148» or «libx264-155» only.

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8), 
LANGUAGE=ru_RU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libavcodec57 depends on:
ii  libavutil55 7:3.4.3-1
ii  libc6   2.28-3
ii  libcairo2   1.16.0-2
ii  libcrystalhd3   1:0.0~git20110715.fdd2f19-13
ii  libglib2.0-0    2.58.1-2
ii  libgsm1 1.0.13-4+b2
ii  liblzma5    5.2.2-1.3
ii  libmp3lame0 3.100-2+b1
ii  libopenjp2-7    2.3.0-1.1
ii  libopus0    1.3-1
ii  librsvg2-2  2.44.10-1
ii  libshine3   3.1.1-2
ii  libsnappy1v5    1.1.7-1
ii  libspeex1   1.2~rc1.2-1+b2
ii  libswresample2  7:3.4.3-1
ii  libtheora0  1.1.1+dfsg.1-14+b1
ii  libtwolame0 0.3.13-4
ii  libva2  2.3.0-2
ii  libvorbis0a 1.3.6-1
ii  libvorbisenc2   1.3.6-1
ii  libvpx5 1.7.0-3
ii  libwavpack1 5.1.0-5
ii  libwebp6    0.6.1-2
ii  libwebpmux3 0.6.1-2
pn  libx264-152 
ii  libx265-160 2.8-4
ii  libxvidcore4    2:1.3.5-1
ii  libzvbi0    0.2.35-15
ii  zlib1g  1:1.2.11.dfsg-1

libavcodec57 recommends no packages.

libavcodec57 suggests no packages.

Bug#917359: wine32: regedit doesn't paint at Deb's wine, but winehq.org's regedit paints.

[Bernhard Übelacker]

Dear Maintainer,
as far as I found is the problem related to:
  debian/patches/generate/icons.patch

That strips away the ico files from being included in the
resources in regedit. But the treeview seems just to be shown when 
programs/regedit/treeview.c:InitTreeViewImageLists was able to
load the ico resources. The same might be true for the listview,
because a package build just with folder.ico,folderopen.ico,computer.ico
did just show the treeview (left), but not the list view (right).

This got possibly introduced in 3.14-2:
  * Rebuild automatically generated icon files.

(I would have tested, but unfortunately snapshot.debian.org
is currently "503 Service Unavailable".)

That patch might remove icons from other programs unnoticed, too.

Kind regards,
Bernhard

# buster i386 qemu VM

apt update
apt dist-upgrade

apt install xserver-xorg lightdm openbox

apt install wine

systemctl start lightdm

# login

export DISPLAY=:0
wine regedit

-> debian binary 4.0~rc2-1 shows the bug in plain buster


##


apt install devscripts dpkg-dev
apt build-dep wine

mkdir source/wine/orig -p
cdsource/wine/orig
apt source wine
cd


cd source/wine
cp orig try1 -a
cd try1/wine-4.0~rc2
dpkg-buildpackage

dpkg -i fonts-wine_4.0~rc2-1_all.deb libwine_4.0~rc2-1_i386.deb  
wine_4.0~rc2-1_all.deb wine32_4.0~rc2-1_i386.deb 

-> self built binary 4.0~rc2-1 shows the bug in plain buster


##




for p in `find -type f -iname "*.patch"`; do sed -i 's/^description: /Subject: 
/i' $p; done
for p in `find -type f -iname "*.patch"`; do sed -i 's/^author: /From: /i' $p; 
done


export 
DIR=/home/bernhard/data/emu/pc/qemu/machines/debian-10-buster-i386_minimal/sshfs/home/benutzer/source/wine/try3/wine-4.0~rc2
git am $DIR/debian/patches/debianization/addons.patch
git am $DIR/debian/patches/debianization/makefile.patch
git am $DIR/debian/patches/debianization/version-string.patch
git am $DIR/debian/patches/debianization/winemenubuilder.patch
git am $DIR/debian/patches/debianization/wineserver-persistence.patch

git am $DIR/debian/patches/disable/tests.patch
git am $DIR/debian/patches/disable/line-wrapping.patch
git am $DIR/debian/patches/disable/addons-download.patch
git am $DIR/debian/patches/disable/po-modifications.patch
git am $DIR/debian/patches/disable/blacklist-extensions.patch

git am $DIR/debian/patches/generate/icons.patch
git am $DIR/debian/patches/generate/opengl.patch
git am $DIR/debian/patches/generate/unicode.patch
git am $DIR/debian/patches/generate/request.patch

git am $DIR/debian/patches/binary-indep/manpages.patch
git am $DIR/debian/patches/binary-indep/sfnt2fon.patch

git am $DIR/debian/patches/fixes/arm.patch
git am $DIR/debian/patches/fixes/arm64.patch
git am $DIR/debian/patches/fixes/gstbase.patch
git am $DIR/debian/patches/fixes/printer-resolution.patch
git am $DIR/debian/patches/fixes/temporary-directory.patch

git am $DIR/debian/patches/warnings/arm-messages.patch
git am $DIR/debian/patches/warnings/arm-longdouble.patch
git am $DIR/debian/patches/warnings/arm64-array-bounds.patch
git am $DIR/debian/patches/warnings/arm64-excess-precision.patch
git am $DIR/debian/patches/warnings/arm64-unused-functions.patch
git am $DIR/debian/patches/warnings/arm64-uninitialized-variables.patch

git am $DIR/debian/patches/warnings/array-bounds.patch
git am $DIR/debian/patches/warnings/dword64-winmm.patch
git am $DIR/debian/patches/warnings/format-overflow.patch
git am $DIR/debian/patches/warnings/unused-functions.patch
git am $DIR/debian/patches/warnings/argument-promotion.patch
git am $DIR/debian/patches/warnings/discarded-qualifiers.patch
git am $DIR/debian/patches/warnings/uninitialized-variables.patch






bernhard@rechner:/home/bernhard/data/entwicklung/2018/wine/wine-git/wine-git$ 
git am $DIR/debianization/addons.patch
Wende an: adjust search paths for addon installers
bernhard@rechner:/home/bernhard/data/entwicklung/2018/wine/wine-git/wine-git$ 
git am $DIR/debianization/makefile.patch
Wende an: don't append wine to the default path settings
bernhard@rechner:/home/bernhard/data/entwicklung/2018/wine/wine-git/wine-git$ 
git am $DIR/debianization/version-string.patch
Wende an: winelib: Append '(Debian)' at the end of the version string.
bernhard@rechner:/home/bernhard/data/entwicklung/2018/wine/wine-git/wine-git$ 
git am $DIR/debianization/winemenubuilder.patch
Wende an: call wineDEBSUFFIX instead of wine from desktop launchers
bernhard@rechner:/home/bernhard/data/entwicklung/2018/wine/wine-git/wine-git$ 
git am $DIR/debianization/wineserver-persistence.patch
Wende an: fix wineserver manpages for Debian's default persistence value
bernhard@rechner:/home/bernhard/data/entwicklung/2018/wine/wine-git/wine-git$ 
git am $DIR/disable/tests.patch
Wende an: drop generated sources from tests Makefiles
bernhard@rechner:/home/bernhard/data/entwicklung/2018/wine/wine-git/wine-git$ 
git am $DIR/disable/line-wrapping.patch
Wende an: disable manual line wrapping in makefiles
bernhard@rechner:/home/bernhard/data/entwi

Bug#908834: please build libzstd udeb so that btrfs-progs can use zstd in Debian Installer

[Nicholas D Steeves]

Hi Alex, Cyril, Dimitri, and anyone else reading this,

On Wed, Nov 28, 2018 at 08:41:18PM +0100, Alex Mestiashvili wrote:
> 
> Hi Nicholas, it is in the new queue:
> 
>  https://ftp-master.debian.org/new/libzstd_1.3.5+dfsg-2.html
> 
> We just need to wait or ?

I fear that waiting will put us too close to the freeze, and then it
will be an inappropriate time to make these changes.  I've asked
#ftp-masters on irc.oftc about the status of libzstd in NEW (2 months
and counting)

Cyril and Dimitri, if either of you have a chance to ask an ftp-master
for feedback, and it wouldn't be too much of a bother, would you
please?

Thanks!

Merry Christmas,
Nicholas


signature.asc
Description: PGP signature

Bug#913663: Bug#917592: libterm-termkey-perl: FTBFS (failing tests)

[Niels Thykier]

gregor herrmann:
> On Sat, 29 Dec 2018 00:25:25 +, Santiago Vila wrote:
> 
>> Package: src:libterm-termkey-perl
>> Version: 0.16-3
>> Severity: serious
>> Tags: ftbfs
> 
>> I tried to build this package in buster but it failed:
> 
>> Test Summary Report
>> ---
>> t/05flags.t   (Wstat: 11 Tests: 2 Failed: 0)
>>   Non-zero wait status: 11
>>   Parse errors: Bad plan.  You planned 4 tests but ran 2.
> 
> Same in #917497.
> 
> Both tests fail during build and not during autopkgtests (locally and
> on r-b/ci.debian.net).
> 
> After thinking a bit I tried:
> 
> #v+
> --- a/debian/rules
> +++ b/debian/rules
> @@ -4,4 +4,4 @@
> dh $@
> 
>  override_dh_auto_test:
> -   TERM=vt100 dh_auto_test
> +   TERM=vt100 prove --blib --verbose t/*.t
> #v-
> 
> [...] 
> 
> From the debhelper changelog:
> 
> debhelper (11.5.4) unstable; urgency=medium
> 
>   [ Niels Thykier ]
>   * Dh_Lib.pm: Reopen stdin to read from /dev/null in doit (and its sibling
> functions) to prevent issues when stdin is open in write-only mode
> (which is what nohup(1) does).  Thanks to Julian Gilbey for reporting
> the issue and providing a sample patch for it as well.
> (Closes: #913663)
> 
> 
> Can this be related? (The failing test operate on \*STDIN.)
> Cc'ing the debhelper bug and debhelper maintainers …
> 
> 
> Cheers,
> gregor
> 
> 

Hi gregor,

Indeed, that could be related.

To confirm it, please consider editing/patching
lib/Debian/Debhelper/Dh_Lib.pm by finding the "_doit" function and
commenting out the following line[1]:

"""
open(STDIN, '<', '/dev/null') or error("redirect STDIN failed: $!");
"""

If your test starts working again after that has been removed, then we
confirmed that is the problem.

Can you elaborate a bit more on what libterm-termkey-perl expects from
STDIN here?  A tty perhaps?  Does/did it work under nohup (without the
debhelper work around to make nohup work)?

Thanks,
~Niels

[1] Introduced in fff0f01c4ceb910ec4d0455718a2f60e22463792 but the
entire commit is not directly revertable.

Bug#917562: [Pkg-javascript-devel] Bug#917562: data/features directory is missing in node-caniuse-lite

[Pirate Praveen]

On 2018, ഡിസംബർ 29 12:29:12 AM IST, Jonas Smedegaard  wrote:
>Quoting Pirate Praveen (2018-12-28 19:19:12)
>> When trying to build autoprefixer.js which build depends on
>> node-caniuse-lite, I got this error and upon inspection I found
>> data/features directory is missing.
>> 
>> ERROR in /usr/lib/nodejs/caniuse-lite/data/features.js
>> Module not found: Error: Can't resolve './features/aac' in
>> '/usr/lib/nodejs/caniuse-lite/data'
>>  @ /usr/lib/nodejs/caniuse-lite/data/features.js 1:22-47
>>  @ /usr/lib/nodejs/caniuse-lite/dist/unpacker/features.js
>>  @ /usr/lib/nodejs/caniuse-lite/dist/unpacker/index.js
>>  @ /usr/lib/nodejs/autoprefixer/lib/autoprefixer.js
>> 
>> I was not able to figure out why this is not working now. Need help.
>
>Upstream source seems to include some tests not tried during build.
>
>I suggest to enable those during build and the autopkgtest framework.
>
>I mean, make sure that something works - anything at all - before 
>debugging why integration with something specific like autoprefixer.

We are regenerating files in data directory for dfsg, now we already know 
data/features is not generated (data/region was regenerated as expected). There 
was no error or useful messages during generation of these.

>
> - Jonas

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#900305: Please add Recommends: elpa-imenu-list to enable document structure sidebar

[Nicholas D Steeves]

Control: tag -1 +pending

Hi David,

On Mon, May 28, 2018 at 04:39:37PM -0400, Nicholas D Steeves wrote:
> Source: markdown-mode
> Version: 2.3+154-1
> Severity: normal
> 
> Hi,
> 
> I just noticed that markdown-mode prominently advertises support for
> imenu-list sidebars that display document structure
>   https://jblevins.org/projects/markdown-mode/

Sorry it took me so long to follow up on this.  I remembered that you
ACKed adding this as a Suggests some time ago, so made the change just
now.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#908834: please build libzstd udeb so that btrfs-progs can use zstd in Debian Installer

[Dimitri John Ledkov]

On Sat, 29 Dec 2018 at 15:54, Nicholas D Steeves  wrote:
>
> Hi Alex, Cyril, Dimitri, and anyone else reading this,
>
> On Wed, Nov 28, 2018 at 08:41:18PM +0100, Alex Mestiashvili wrote:
> >
> > Hi Nicholas, it is in the new queue:
> >
> >  https://ftp-master.debian.org/new/libzstd_1.3.5+dfsg-2.html
> >
> > We just need to wait or ?
>
> I fear that waiting will put us too close to the freeze, and then it
> will be an inappropriate time to make these changes.  I've asked
> #ftp-masters on irc.oftc about the status of libzstd in NEW (2 months
> and counting)
>
> Cyril and Dimitri, if either of you have a chance to ask an ftp-master
> for feedback, and it wouldn't be too much of a bother, would you
> please?


I'm happy. From btrfs-progs point of view, it simply needs a binNMU to
pick up and start using libzstd udeb which release team can schedule.

-- 
Regards,

Dimitri.

Bug#911927: [Pkg-erlang-devel] Bug#911927: Please remove the bad directive

[Thomas Goirand]

On Dec 29, 2018 08:15, Philipp Huebner  wrote:
>
> Hello Thomas, 
>
> ejabberd maintainer here! 
>
> Am 26.10.18 um 13:04 schrieb Thomas Goirand: 
> > After further investigation, removing: 
> > 
> > BindToDevice=lo 
> > 
> > and rebooting fixes the problem. Could you please remove it from the 
> > empd.socket file, so that users don't have to override it in 
> > /etc/systemd please? 
> [...]
> We could agree on priorities as done in other .d directories, 
> so ejabberd would make it lo only, and if rabbitmq-server is installed 
> as well it would change it back to undefined (all interfaces). 

This looks like a very good idea. There is though one case I wonder how to 
handle. What if one installs both rabbitmq and ejabberd on the same server? 
Hopefully documentation will be enough, so please make sure it is well 
documented on the ejabber package.

IMO the default behavior must be the one from Stretch so that upgrading a 
rabbitmq cluster to Buster doesn't break the world.

Cheers,

Thomas Goirand (zigo)

Bug#917605: rainloop: Depends on libphp-predis, which is scheduled for removal (per #915069)

[Niels Thykier]

Package: rainloop
Version: 1.11.1-1
Severity: serious

Hi,

The rainloop package currently depends on libphp-predis, which is
scheduled for removal (see #915069 for the details).  AFAICT, the
replacement for libphp-predis is php-nrk-predis (which is a newer
version of the same code just using a different package name).

Please consider migrating rainloop to php-nrk-predis soon.  As it is,
rainloop plus libphp-predis will be removed from testing before buster
is released.

Thanks,
~Niels

Bug#917516: anbox: does not pull binder or ashmem kernel drivers as dependency

[Svetlana Tkachenko]

Thanks Shengjing,

1) the readme says "In order to run Android system inside container, you need 
two kernel
modules: ashmem_linux and binder_linux. Since Debian kernel 4.17, these
two modules are enabled. You can find theme at,
/lib/modules/`uname -r`/kernel/drivers/android/binder_linux.ko and
/lib/modules/`uname -r`/kernel/drivers/staging/android/ashmem_linux.ko." but it 
does not say how to load these mobules; it turned out to be "modprobe 
binder_linux" and "modprobe ashmem_linux" but this took several guesses (I 
tried the full path too). Perhaps the readme should be clarified to include 
this correct command.

2) if configuration is required, perhaps an ncurses wizard similar to that of 
mysql (where it sets the root password) should be offered, or at least a dialog 
"this package requires additional configuration, please check the readme here 
at /usr/share/doc/anbox/ for details" should be shown

3) Continuing usage after following the steps suggested in the readme,

/var/lib/anbox$ sudo lsmod | grep linux
ashmem_linux 16384 0
binder_linux 135168 0
/var/lib/anbox$ file android.img
android.img: Squashfs filesystem, little endian, version 4.0, 325898705 bytes,
2116 inodes, blocksize: 131072 bytes, created: Fri Jul 20 01:19:03 2018
/var/lib/anbox$ anbox session-manager
[ 2018-12-29 05:57:18] [daemon.cpp:61@Run] Failed to connect to socket 
/run/anbox-container.socket: No such file or directory
/var/lib/anbox$

-- 
Svetlana

Bug#917457: libilmbase23: 2.3.0-3 bumped so name without transition (breaks digikam, gimp, ...)

[Andreas Metzler]

On 2018-12-27 "Matteo F. Vescovi"  wrote:
> Hi!

> On 2018-12-27 at 19:38 (+01), Eric Valette wrote:
>> Package: libilmbase23
>> Version: 2.3.0-3
>> Severity: critical
>> Justification: breaks unrelated software

> [...]

> Well, 2.3.0-3 revision is still in the experimental suite.
> That's the right place to prepare a transition, indeed.
> We're working on it, along with openexr.

Hello,

please re-open. The package is in Debian. We have a bug tracking system
for packages in Debian, where we track open issues and users can check
for known breakage.

cu Andreas

PS: Thanks, Eric for testing packages in experimental!
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#917603: python3-yaml: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working

[Niels Thykier]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/yaml/pyyaml/pull/181


On Sat, 29 Dec 2018 05:40:43 +0100 Niels Thykier  wrote:
> Package: python3-yaml
> Version: 3.13-1
> Severity: normal
> 
> Hi,
> 
> I spotted this in the CI job of britney2[1].
> 
> [...]
> 
> Presumably this is (or will be) fixed in a new upstream release but it
> might make sense to cherry-pick that fix for buster to avoid breakage
> in sid + buster at the moment.
> 
> Thanks,
> ~Niels
> 
> [1] https://salsa.debian.org/release-team/britney2/-/jobs/99062
> 
> 


Hi,

The pyyaml upstream seems to be in a ... "interesting" state at the
moment with the 4.X major version.

Anyway, I found a pull request submitted upstream that (among other)
fixes this issue and added it as a "forwarded" for this bug.  From this
branch/PR, please cherry-pick the following commit (also attached):

https://github.com/yaml/pyyaml/pull/181/commits/7eaa43474d0f6ecca5f89287ba27f420702523cc

Thanks,
~Niels

From 7eaa43474d0f6ecca5f89287ba27f420702523cc Mon Sep 17 00:00:00 2001
From: Florian Bruhin 
Date: Wed, 27 Jun 2018 14:50:15 +0200
Subject: [PATCH] Import Hashable from collections.abc

In Python 3.7, importing ABCs directly from the 'collections' module shows a
warning (and in Python 3.8 it will stop working) - see
https://github.com/python/cpython/commit/c66f9f8d3909f588c251957d499599a1680e2320

Since this is only done in lib3/ which is Python 3 only, we can unconditionally
import it from collections.abc instead.

This fixes the following DeprecationWarning:

.../site-packages/yaml/__init__.py:75: in load
return loader.get_single_data()
.../site-packages/yaml/constructor.py:37: in get_single_data
return self.construct_document(node)
.../site-packages/yaml/constructor.py:46: in construct_document
for dummy in generator:
.../site-packages/yaml/constructor.py:398: in construct_yaml_map
value = self.construct_mapping(node)
.../site-packages/yaml/constructor.py:204: in construct_mapping
return super().construct_mapping(node, deep=deep)
.../site-packages/yaml/constructor.py:126: in construct_mapping
if not isinstance(key, collections.Hashable):
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

name = 'Hashable'

def __getattr__(name):
# For backwards compatibility, continue to make the collections ABCs
# through Python 3.6 available through the collections module.
# Note, no new collections ABCs were added in Python 3.7
if name in _collections_abc.__all__:
obj = getattr(_collections_abc, name)
import warnings
warnings.warn("Using or importing the ABCs from 'collections' instead "
  "of from 'collections.abc' is deprecated, "
  "and in 3.8 it will stop working",
> DeprecationWarning, stacklevel=2)
E   DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
---
 lib3/yaml/constructor.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib3/yaml/constructor.py b/lib3/yaml/constructor.py
index 981543a..193d91d 100644
--- a/lib3/yaml/constructor.py
+++ b/lib3/yaml/constructor.py
@@ -5,7 +5,7 @@
 from .error import *
 from .nodes import *
 
-import collections, datetime, base64, binascii, re, sys, types
+import collections.abc, datetime, base64, binascii, re, sys, types
 
 class ConstructorError(MarkedYAMLError):
 pass
@@ -123,7 +123,7 @@ def construct_mapping(self, node, deep=False):
 mapping = {}
 for key_node, value_node in node.value:
 key = self.construct_object(key_node, deep=deep)
-if not isinstance(key, collections.Hashable):
+if not isinstance(key, collections.abc.Hashable):
 raise ConstructorError("while constructing a mapping", node.start_mark,
 "found unhashable key", key_node.start_mark)
 value = self.construct_object(value_node, deep=deep)


signature.asc
Description: OpenPGP digital signature

Bug#917509: theme-d-gnome: FTBFS (dh_auto_configure fails)

[Tommi Höynälänmaa]

Sorry, I misinterpreted the log. The error is probably caused by missing 
dependencies in gnome/Makefile.am. A fix is coming soon.


 - Tommi


On 28.12.2018 20:00, Santiago Vila wrote:

On Fri, Dec 28, 2018 at 07:51:27PM +0200, Tommi Höynälänmaa wrote:

Hi


Is there a pending upload of guile-gnome-platform for unstable which
is required for theme-d-gnome to build properly also in unstable?

Note: The build log says --with-guile-gnome=2.16.5 but current version
is 2.16.4-5. Could this small mismatch be the problem?

This may cause problems but the main thing is that packages
theme-d-translator and theme-d-stdlib are not present in the build
environment (at least the correct versions are not).

Hmm, but I'm not installing build-dependencies by hand.

I'm using sbuild (and reproducible-builds is using pbuilder)
which should already ensure that the "correct" versions are installed.

Actually, either the version currently available in unstable is ok,
or otherwise the build would fail with "unsatisfiable build-depends".

So: How do you know that the build is using "incorrect versions" and
what exactly do you mean by "incorrect versions"?

I'm a little bit confused.

Thanks.

Bug#917606: RFP: python-deprecated -- Python decorator to deprecate old classes, function, or methods

[Daniel Stender]

Package: wnpp
Severity: wishlist

* Package name: python-deprecated
  Version : 1.2.4
  Upstream Author : Laurent Laporte 
* URL : https://github.com/tantale/deprecated
* License : Expat
  Programming Lang: Python
  Description : Python decorator to deprecate old classes, function, or 
methods

Little tool for marking things in Python code as deprecated. Like 
python-deprecation
which is already in the archive [1], however bloscpack >= 0.16.0 [2] uses this 
one.

Thanks,
DS

[1] https://tracker.debian.org/pkg/python-deprecation

[2] https://tracker.debian.org/pkg/bloscpack

Bug#917546: binutils-xtensa-lx106 is a wrong name

[Oleksij Rempel]

Hi,

in my experience with xtensa, it has some basic customizable
core/instruction set (in this case it is lx106) which is then optimized
for some application (for example for esp8266). At the end, this
toolchain won't be able to build binary for different lx106 based
hardware. In this case the naming is wrong. It should be:
binutils-xtensa-lx106-esp8266
binutils-espressif-esp8266
binutils-xtensa-lx106-espressif-esp8266
or some thing like this...

If debian maintainers will decide to include this toolchain, then we
need to develop unified naming shema for this kind of toolchains,
because we already have completely opened firmware based on xtenas for
different hardware, see firmware-ath9k-htc package. Extra toolchain for
this package will make step forward reproducible builds.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Bug#917457: libilmbase23: 2.3.0-3 bumped so name without transition (breaks digikam, gimp, ...)

[Matteo F. Vescovi]

Andreas,

I'll open a specific transition bug report for that, once I've tested all
r-deps but not earlier.

Thus, I'll leave this bug report closed since it tracks another issue (or
feature, at your choice ;) ).

Cheers.

Il giorno sab 29 dic 2018, 07:19 Andreas Metzler  ha
scritto:

> On 2018-12-27 "Matteo F. Vescovi"  wrote:
> > Hi!
>
> > On 2018-12-27 at 19:38 (+01), Eric Valette wrote:
> >> Package: libilmbase23
> >> Version: 2.3.0-3
> >> Severity: critical
> >> Justification: breaks unrelated software
>
> > [...]
>
> > Well, 2.3.0-3 revision is still in the experimental suite.
> > That's the right place to prepare a transition, indeed.
> > We're working on it, along with openexr.
>
> Hello,
>
> please re-open. The package is in Debian. We have a bug tracking system
> for packages in Debian, where we track open issues and users can check
> for known breakage.
>
> cu Andreas
>
> PS: Thanks, Eric for testing packages in experimental!
> --
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'
>

Bug#917593: mpd: FTBFS ('_IO_off64_t' has not been declared)

[Max Kellermann]

On 2018/12/29 01:25, Santiago Vila  wrote:
> In file included from /usr/include/libroar/libroar.h:173,
>  from /usr/include/roaraudio.h:133,
>  from src/output/plugins/RoarOutputPlugin.cxx:36:
> /usr/include/libroar/vio_stdio.h:50:46: error: '_IO_off64_t' has not been 
> declared
>  int roar_vio_to_stdio_lseek (void *__cookie, _IO_off64_t *__pos, int __w);

This is clearly a libroar bug and has nothing to do with MPD.

Upstream bug report (for MPD):
https://github.com/MusicPlayerDaemon/MPD/issues/377

See https://github.com/MusicPlayerDaemon/MPD/commit/06ca08ce555 for my
opinion on this bug.

Bug#917130: gimp: crashes at start: segmentation fault in g_slice_alloc() (memory corruption?)

[積丹尼 Dan Jacobson]

Indeed with G_SLICE=debug-blocks it starts, but still says
 
GEGL-Message: 15:02:47.435: Module 
'/usr/lib/x86_64-linux-gnu/gegl-0.4/exr-save.so' load error: 
libIlmImf-2_2.so.23: cannot open shared object file: No such file or directory
GEGL-Message: 15:02:47.499: Module 
'/usr/lib/x86_64-linux-gnu/gegl-0.4/exr-load.so' load error: 
libIlmImf-2_2.so.23: cannot open shared object file: No such file or directory
Failed to execute child process “dbus-launch” (No such file or directory)
(gimp:7862): Gtk-WARNING **: 15:02:47.681: Unable to locate theme engine in 
module_path: "pixmap",
/usr/lib/gimp/2.0/plug-ins/file-exr/file-exr: error while loading shared 
libraries: libIlmImf-2_2.so.23: cannot open shared object file: No such file or 
directory
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
(gimp:7862): GLib-GObject-CRITICAL **: 15:02:55.648: g_object_unref: assertion 
'G_IS_OBJECT (object)' failed

G_SLICE=debug-blocks G_MESSAGES_DEBUG=all gave:

GEGL-Message: 15:07:29.514: Module 
'/usr/lib/x86_64-linux-gnu/gegl-0.4/exr-save.so' load error: 
libIlmImf-2_2.so.23: cannot open shared object file: No such file or directory
GEGL-Message: 15:07:29.578: Module 
'/usr/lib/x86_64-linux-gnu/gegl-0.4/exr-load.so' load error: 
libIlmImf-2_2.so.23: cannot open shared object file: No such file or directory
(gimp:8067): GLib-DEBUG: 15:07:29.580: posix_spawn avoided (fd close requested) 
Failed to execute child process “dbus-launch” (No such file or directory)
(gimp:8067): GLib-DEBUG: 15:07:29.652: posix_spawn avoided (fd close requested) 
(gimp:8067): GdkPixbuf-DEBUG: 15:07:29.658: gdk_pixbuf_from_pixdata() called on:
(gimp:8067): GdkPixbuf-DEBUG: 15:07:29.658: Encoding raw
(gimp:8067): GdkPixbuf-DEBUG: 15:07:29.658: Dimensions: 64 x 64
(gimp:8067): GdkPixbuf-DEBUG: 15:07:29.658: Rowstride: 256, Length: 16408
(gimp:8067): GdkPixbuf-DEBUG: 15:07:29.658: Copy pixels == false
(gimp:8067): Gtk-WARNING **: 15:07:29.664: Unable to locate theme engine in 
module_path: "pixmap",
(gimp:8067): GdkPixbuf-DEBUG: 15:07:30.110: gdk_pixbuf_from_pixdata() called on:
(gimp:8067): GdkPixbuf-DEBUG: 15:07:30.110: Encoding rle
(gimp:8067): GdkPixbuf-DEBUG: 15:07:30.110: Dimensions: 22 x 22
(gimp:8067): GdkPixbuf-DEBUG: 15:07:30.110: Rowstride: 88, Length: 1606
(gimp:8067): GdkPixbuf-DEBUG: 15:07:30.110: Copy pixels == true
/usr/lib/gimp/2.0/plug-ins/file-exr/file-exr: error while loading shared 
libraries: libIlmImf-2_2.so.23: cannot open shared object file: No such file or 
directory
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
(file-rawtherapee:8080): GLib-DEBUG: 15:07:30.160: posix_spawn avoided (fd 
close requested) 
(file-darktable:8082): GLib-DEBUG: 15:07:30.172: posix_spawn avoided (fd close 
requested) 
(gimp:8067): GLib-GObject-CRITICAL **: 15:07:34.515: g_object_unref: assertion 
'G_IS_OBJECT (object)' failed

The rest of the commands you gave me failed to start gimp. I did add the
symbols packages yet.

Bug#917266: [debian-mysql] Bug#917266: Bug#917266: missing /usr/include/mysql

[Scott Kitterman]

On Fri, 28 Dec 2018 16:41:33 +0200 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?= 
 wrote:
> Hello!
> 
> pe 28. jouluk. 2018 klo 15.33 Scott Kitterman (deb...@kitterman.com) 
kirjoitti:
> >
> > I did add a symlink as in the attached patch and postfix builds again.  I
> > don't have a good way to do run-time testing, so I don't know if there are 
any
> > further changes needed, but this at least fixes package building.
> 
> If you use Salsa to make a merge request you will get gitlab-ci
> testing for free, also run-time.
> 
> See easy instructions at https://wiki.debian.org/Teams/MySQL/patches
> 
> I really strongly recommend you take a shot at using Salsa and
> Gitlab-CI that it has built-in.

I've submitted the merge request:

https://salsa.debian.org/mariadb-team/mariadb-10.3/merge_requests/8

Setting up CI on my branch to test something I've already built and tested 
locally seems overkill.  The run-time testing I was referring to was of 
postfix using the mysql compatibility links, not mariadb.

Scott K

Bug#917407: related issues

[Johannes Schauer]

On Thu, 27 Dec 2018 14:50:11 + "Bernhard M. Wiedemann" 
 wrote:
> https://bugzilla.opensuse.org/show_bug.cgi?id=1049186
> and https://bugs.python.org/issue34033
> could be related.

I don't think that's likely because:

 - the hashes are reproducible across multiple runs if the same method was used
 - this effect only first showed up in Python 3.7 but not earlier

> Would be interesting to see a hex diff of indeterministic .pyc files.

Please find a xz-compressed diffoscope attached.


pyc.diffoscope.xz
Description: application/xz


signature.asc
Description: signature

Bug#906688: ruby-netrc: FTBFS in buster/sid (test_missing_environment fails)

[Hideki Yamane]

Hi,

 It builds well with cowbuilder, at least (I don't know why...)


-- 
Hideki Yamane 

Bug#916287: po2oo unusable

[Stuart Prescott]

Hi Mechtilde

Thanks for the update.

> the error message doesn't tell where the problem is.
> 
> After downgrading it doesn't work too. So I test it with a new template.
> 
> Then it works.

Can I just double check that I have understood the report -- you have a 
bad.po and when using po2oo on bad.po, you get the crash «ValueError: 
invalid tab-delimited line: '#\n'» that doesn't tell you where the error is 
located within the input file.

Can you provide that bad po file or some other minimal reproduce case? 
(including the command used)

The error appears to be in the output stage, so I'm not sure if source 
information will be available, but we can always look.

thanks
Stuart


-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#917389: bugs.debian.org: please close down the debian-maintainers pseudo-package

[Mattia Rizzolo]

On Fri, 28 Dec 2018, 8:36 a.m. Don Armstrong  On Thu, 27 Dec 2018, Mattia Rizzolo wrote:
> > While chasing down unused things, like the debian-maintainers@nm.d.o
> > alias, I noticed the debian-maintainers pseudo-package is still
> > available.
> >
> > Would it be possible to close or remove the pseudo-package?
> > What are the required steps?
>
> We can mark it deprecated; it should probably stay around so that no one
> can accidentally create a package called debian-maintainer.
>

Can we remove the mail alias after doing so?

Bug#915559: coreutils: Use renameat2 from glibc instead of syscall

[Johannes Schauer]

On Sun, 23 Dec 2018 12:56:55 -0500 Michael Stone  wrote:
> Please just wait

I take that means that you intend to apply the fix I proposed?

The problem now became more dire for fakechroot because mv(1) is now used in
the maintainer script of dash (during the diversion process). So as of a few
days ago it is now impossible to use debootstrap with fakechroot.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#917525: poppler: CVE-2018-20551: reachable abort in AnnotRichMedia::Content::Content at Annot.cc:6432

[Salvatore Bonaccorso]

Source: poppler
Version: 0.69.0-2
Severity: important
Tags: patch security upstream

Hi,

The following vulnerability was published for poppler.

CVE-2018-20551[0]:
| A reachable Object::getString assertion in Poppler 0.72.0 allows
| attackers to cause a denial of service due to construction of invalid
| rich media annotation assets in the AnnotRichMedia class in Annot.c.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-20551
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20551
[1] https://gitlab.freedesktop.org/poppler/poppler/issues/703
[2] 
https://gitlab.freedesktop.org/poppler/poppler/commit/7f87dc10b6adccd6d1b977a28b064add254aa2da

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#917124: lvm2 logical volumes are not properly initialized

[Rafał Olejnik]

On Thu, 27 Dec 2018 23:09:29 +0100 Michael Biebl  wrote:
> Am 27.12.18 um 22:59 schrieb Ben Caradoc-Davies:
> > Thanks, Michael. Confirmed fixed for me in 240-2.
>
> Thanks for the confirmation.
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?

>


Tested on my hosts now and works too, however i still see messages 
during a boot, did you see them too while testing this fix?


lvm2-activation-generator: lvmconfig failed

lvm2-activation-generator: Activation generator failed.

--
Regards,
Rafał Olejnik

Bug#917377: tar: CVE-2018-20482

[Salvatore Bonaccorso]

Control: tags -1 + fixed-upstream

On Wed, Dec 26, 2018 at 09:57:29PM +0100, Salvatore Bonaccorso wrote:
> Source: tar
> Version: 1.30+dfsg-3
> Severity: important
> Tags: security upstream
> 
> Hi,
> 
> The following vulnerability was published for tar.
> 
> CVE-2018-20482[0]:
> | GNU Tar through 1.30, when --sparse is used, mishandles file shrinkage
> | during read access, which allows local users to cause a denial of
> | service (infinite read loop in sparse_dump_region in sparse.c) by
> | modifying a file that is supposed to be archived by a different user's
> | process (e.g., a system backup running as root).

This has been fixed upstream, I think this would be good to have
already fixed in buster in time. It does not look severe enought for
stretch to have a DSA for it, but it might be good to fix this issue
as well in stable via a point release.

Regards,
Salvatore

Bug#917526: libxsmm: CVE-2018-20541 CVE-2018-20542

[Salvatore Bonaccorso]

Source: libxsmm
Version: 1.9-1
Severity: important
Tags: patch security upstream
Forwarded: https://github.com/hfp/libxsmm/issues/287

Hi,

The following vulnerabilities were published for libxsmm.

CVE-2018-20541[0]:
| There is a heap-based buffer overflow in libxsmm_sparse_csc_reader at
| generator_spgemm_csc_reader.c in LIBXSMM 1.10, a different
| vulnerability than CVE-2018-20542 (which is in a different part of the
| source code and is seen at different addresses).

CVE-2018-20542[1]:
| There is a heap-based buffer-overflow at generator_spgemm_csc_reader.c
| (function libxsmm_sparse_csc_reader) in LIBXSMM 1.10, a different
| vulnerability than CVE-2018-20541 (which is in a different part of the
| source code and is seen at a different address).

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-20541
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20541
[1] https://security-tracker.debian.org/tracker/CVE-2018-20542
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20542
[2] https://github.com/hfp/libxsmm/issues/287

Regards,
Salvatore

Bug#917527: linux-image-4.18.0-0.bpo.3-amd64: i915 module loading hangs

[Vincent Danjean]

Package: src:linux
Version: 4.18.20-2~bpo9+1
Severity: critical
Justification: breaks the whole system

  Hi,

  After upgrading from bpo.1, my system is unusable
with a black screen. The blackscreen starts at
boot time (way before kdm), when the resolution
usually changes.
  Using another computer, I was able to login remotely.
I can observe that i915 does not load. Trying to load
it with modprobe or even with insmod leads to the
command hanging (C-c is able to stop it).
I looked insmod with strace. The hang occurs in
finit_module.
  I see nothing with dmesg nor in /var/log/syslog

  I workaround the problem by installing the
current kernel (from testing), it 4.19.0-1-amd64

  Regards,
Vincent

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: EG45M-DS2H
product_version: 
chassis_vendor: Gigabyte Technology Co., Ltd.
chassis_version: 
bios_vendor: Award Software International, Inc.
bios_version: F5C N:071209
board_vendor: Gigabyte Technology Co., Ltd.
board_name: EG45M-DS2H
board_version: 

** Network interface configuration:

auto lo
iface lo inet loopback




iface static inet static
address 192.168.1.7
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
dns-search varennes.fr

iface dhcp inet dhcp

iface aure inet dhcp
pre-up ifconfig $IFACE up
pre-up iwlist $IFACE scan
wireless-essid Aure
wireless-key **
wireless-channel 11
wireless-ap F2:AD:66:40:52:E8

iface dino inet dhcp
wireless-mode managed
wireless-essid dino
wireless-key1 **

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 4 Series Chipset DRAM Controller 
[8086:2e20] (rev 03)
Subsystem: Gigabyte Technology Co., Ltd GA-EP45-DS5/GA-EG45M-DS2H 
Motherboard [1458:5000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:02.0 VGA compatible controller [0300]: Intel Corporation 4 Series Chipset 
Integrated Graphics Controller [8086:2e22] (rev 03) (prog-if 00 [VGA 
controller])
Subsystem: Gigabyte Technology Co., Ltd GA-EG45M-DS2H Mainboard 
[1458:d000]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:02.1 Display controller [0380]: Intel Corporation 4 Series Chipset 
Integrated Graphics Controller [8086:2e23] (rev 03)
Subsystem: Gigabyte Technology Co., Ltd GA-EG45M-DS2H Mainboard 
[1458:d000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:1a.0 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB 
UHCI Controller #4 [8086:3a37] (prog-if 00 [UHCI])
Subsystem: Gigabyte Technology Co., Ltd Motherboard [1458:5004]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd

00:1a.1 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB 
UHCI Controller #5 [8086:3a38] (prog-if 00 [UHCI])
Subsystem: Gigabyte Technology Co., Ltd Motherboard [1458:5004]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd

00:1a.2 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB 
UHCI Controller #6 [8086:3a39] (prog-if 00 [UHCI])
Subsystem: Gigabyte Technology Co., Ltd Motherboard [1458:5004]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd

00:1a.7 USB controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB2 
EHCI Controller #2 [8086:3a3c] (prog-if 20 [EHCI])
Subsystem: Gigabyte Technology Co., Ltd Motherboard [1458:5006]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:1b.0 Audio device [0403]: Intel Corporation 82801JI (ICH10 Family) HD Audio 
Controller [8086:3a3e]
Subsystem: Gigabyte Technology C

Bug#917522: pcmanfm: Some keyboard navigation shortcuts in PCManFM no longer working

[Michael Weghorn]

On 28/12/2018 07.25, Asho Yeh wrote:
> Package: pcmanfm
> Version: 1.3.1-1
> Severity: normal
> 
> a few keyboard shortcuts for navigating directories in PCManFM (Alt+Home 
> to
> return to ~/, Alt+Up to go to parent folder) no longer work.
> [...]

There's also an upstream bug for this that has a patch attached that's
waiting for review: https://sourceforge.net/p/pcmanfm/bugs/1085/

Best regards,
 Michael


PS: It seems that two bug reports were accidently created; #917523 has
the same content.



signature.asc
Description: OpenPGP digital signature

Bug#914632: uw-imap: CVE-2018-19518

[Moritz Mühlenhoff]

On Wed, Dec 26, 2018 at 05:20:40PM +0100, Magnus Holmgren wrote:
> > CVE-2018-19518[0]:
> > | University of Washington IMAP Toolkit 2007f on UNIX, as used in
> > | imap_open() in PHP and other products, launches an rsh command (by
> > | means of the imap_rimap function in c-client/imap4r1.c and the
> > | tcp_aopen function in osdep/unix/tcp_unix.c) without preventing
> > | argument injection, 
> 
> I'm wondering if anyone would complain if I'd disable RSH (SSH) connections 
> altogether.

Full ack, that seems like the most sensible fix.

Cheers,
Moritz

Bug#917529: aptitude: Eat a lot of memories to resolve conflicts, and spend a lot of seconds.

[Kyuma Ohta]

Package: aptitude
Version: 0.8.11-6
Severity: important

Dear Maintainer,

In this version of aptitude, trying to install packages have conflicts
dependencies, spend a lot of time to resolve and eat a lot of memories.
Eats > 8GB of memories on resolving, and sometimes not resolved.
Not stopping resolving at this situation, and need to abort APTITUDE
(via CTRL-C).

Regards,
Ohta.

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

aptitude version information:
aptitude 0.8.11
Compiler: g++ 8.2.0
Compiled against:
  apt version 5.0.2
  NCurses version 6.1
  libsigc++ version: 2.10.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.1.20181013
  cwidget version: 0.5.17
  Apt version: 5.0.2

aptitude linkage:
linux-vdso.so.1 (0x7ffea9fbe000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7ffa43087000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7ffa4304d000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7ffa4301f000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7ffa43016000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7ffa42f1)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7ffa42def000)
libboost_iostreams.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x7ffa42dcf000)
libboost_system.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x7ffa42dc8000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7ffa42b9d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7ffa42b7c000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7ffa429f9000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7ffa42876000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7ffa4285a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7ffa42699000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7ffa4267f000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7ffa42461000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7ffa4244e000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7ffa42228000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7ffa42009000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 
(0x7ffa41f6e000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7ffa41f48000)
/lib64/ld-linux-x86-64.so.2 (0x7ffa43713000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7ffa41f43000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7ffa41f39000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7ffa41f2e000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.11-6
ii  libapt-pkg5.0 1.8.0~alpha3
ii  libboost-iostreams1.67.0  1.67.0-11
ii  libboost-system1.67.0 1.67.0-11
ii  libc6 2.28-3
ii  libcwidget3v5 0.5.17-11
ii  libgcc1   1:8.2.0-13
ii  libncursesw6  6.1+20181013-1
ii  libsigc++-2.0-0v5 2.10.1-1
ii  libsqlite3-0  3.26.0+fossilbc891ac6b-1
ii  libstdc++68.2.0-13
ii  libtinfo6 6.1+20181013-1
ii  libxapian30   1.4.9-1

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  1.2.0-13
ii  sensible-utils 0.0.12

Versions of packages aptitude suggests:
ii  apt-xapian-index0.49
ii  aptitude-doc-en [aptitude-doc]  0.8.11-6
ii  aptitude-doc-ja [aptitude-doc]  0.8.11-6
ii  debtags 2.1.5
ii  tasksel 3.49

-- no debconf information

Bug#917528: debci: debug packages aren't available in debci testing

[Sylvestre Ledru]

Package: debci
Version: 1.11
Severity: normal

Dear Maintainer,

In testing, dbgsym packages aren't available.
Example:
https://ci.debian.net/data/autopkgtest/testing/amd64/l/llvm-toolchain-7/1593778/log.gz

While they are with unstable:
https://ci.debian.net/data/autopkgtest/unstable/amd64/l/llvm-toolchain-7/1592623/log.gz

For consistency, we should have debug packages also available for
debci in testing.

Thanks
Sylvestre


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

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

Versions of packages debci depends on:
ii  adduser   3.117
ii  amqp-tools0.8.0-1+b3
ii  bsdmainutils  11.1.2+b1
ii  curl  7.61.0-1
ii  dctrl-tools   2.24-2+b1
ii  debootstrap   1.0.106
ii  devscripts2.18.3
ii  fonts-font-awesome5.0.10+really4.7.0~dfsg-1
ii  jq1.5+dfsg-2+b1
ii  libjs-bootstrap   3.3.7+dfsg-2
ii  libjs-jquery  3.2.1-1
ii  libjs-jquery-flot 0.8.3+dfsg-1
ii  patchutils0.3.4-2
ii  ruby  1:2.5.1
ii  ruby-activerecord 2:4.2.10-1
ii  ruby-bunny2.9.2-1
ii  ruby-sinatra  1.4.8-1
ii  ruby-sinatra-contrib  1.4.7-1
ii  ruby-sqlite3  1.3.13-1+b2
ii  ruby-thor 0.19.4-1
ii  sudo  1.8.23-1

Versions of packages debci recommends:
pn  moreutils  
ii  ntp1:4.2.8p11+dfsg-1

Versions of packages debci suggests:
pn  apt-cacher-ng  

-- Configuration Files:
/etc/sudoers.d/debci [Errno 13] Permission non accordée: '/etc/sudoers.d/debci'

-- no debconf information

Bug#906870: xul-ext-certificatepatrol no longer works with firefox-esr 60

[Moritz Mühlenhoff]

On Fri, Dec 28, 2018 at 12:15:22AM +0100, Christoph Biedl wrote:
> To be honest, I lack the skills to check whether this actually happened
> (probably yes), and is usable to re-create certpatrol for webext
> (hopefully yes). And I haven't checked yet whether certpatrol upstream
> is willing to do the job. Allow me some time to resolve this.

Sure, let's take the time to sort this out, then.

> Otherwise, I wouldn't mind to keep this in unstable for the sake of some
> spin-offs/forks that still support xul, like pale moon - but I
> understand if people consider this something Debian isn't intended for.

We shouldn't keep these packaged for unpackaged forks, the impact
on Firefox users installing a broken package exceeeds the usefulness
of that use case by far.

Cheers,
Moritz

Bug#916845: needrestart: README.nagios.md refers to undistributed file ex/nagios/needrestart-nagios

[Patrick Matthäi]

tag #916845 + pending
thanks

Am 19.12.2018 um 13:06 schrieb Jean-Michel Vourgère:
> Package: needrestart
> Version: 3.3-2
> Severity: normal
>
> Dear Maintainer,
>
> Please distribute de ex/nagios/needrestart-nagios as documentation.
> It is missing.
>
> Alternatively, it would make sense to copy it directly in
> /etc/sudoers.d/ since it is only for user nagios and it include the -p
> parameter that prevent automatic restarts. Some people might disagree, though.
>
> Thank you :)

Hi,

I have added it as an example file

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#917303: Request for help with MariaDB 10.3 / libdbd-mysql-perl packaging

[Otto Kekäläinen]

Hello!

pe 28. jouluk. 2018 klo 11.09 Georg Richter (ge...@mariadb.com) kirjoitti:
>
> Hi Otto,
>
> no clue about dbd-mysql - we reported several bugs (and sent fixes), but 
> didn't get feedback since more than a year. Why don't you ship DBD-mariadb 
> instead?

Gregor Hermann, do you want to switch to DBD-mariadb instead?

For the record, I don't have any plans to package DBD-mariadb as I
have no Perl expertise.

Bug#917519: Unable to open subsequent YouTube videos when not starting a new session

[Sebastian Ramacher]

On 2018-12-28 06:58:41, Andoru wrote:
> Package: vlc
> Version: 3.0.5-1
> Severity: normal
> 
> I started noticing issues with playing YouTube videos through VLC as soon
> as I upgraded to version 3.0.4-4. When trying to play multiple YouTube
> videos, one after the other, VLC throws in an error saying it's unable to
> open the link.
> This happens as follows:
> Open new VLC session -> Paste in a video URL -> Plays video -> The video
> ends -> Paste in another video URL -> Error -> Paste the same video URL, or
> another one -> Error -> Rinse & Repeat -> Error
> 
> This however doesn't happen if I enqueue the video URLs, for example:
> Open new VLC session -> Paste in a video URL -> Pauses video playback after
> it starts -> Paste in a video URL (or multiple ones), and hit 'Enqueue'
> instead of Play -> Resumes playback -> Video ends -> Plays next video
> without errors
> 
> Another thing that curiously doesn't trigger the error is if:
> Open new VLC session -> Paste in a video URL -> Plays video -> Stops the
> video before it finishes -> Hit play again, making VLC replay the same video
> 
> Hopefully my explanation makes sense.
> Not sure if this is an issue only at my end, or a proper bug.
> 
> Here's what's displayed in the error window:
> 
> > Your input can't be opened:
> > VLC is unable to open the MRL 'https://www.youtube.com
> > /watch?v=PBFPJ3_6ZWs'. Check the log for details.
> 
> Here's the verbose log from the "Messages" window:
> 
> https://hastebin.com/raw/edobizocov

Just in case:

| main debug: processing request item: watch?v=hz_mMLhUinw, node: Playlist, 
skip: 0
| main debug: rebuilding array of current - root Playlist
| main debug: rebuild done - 7 items, index 6
| main debug: starting playback of new item
| main debug: resyncing on watch?v=hz_mMLhUinw
| main debug: watch?v=hz_mMLhUinw is at 6
| main debug: creating new input thread
| main debug: Creating an input for 'watch?v=hz_mMLhUinw'
| main debug: requesting art for new input thread
| main debug: using timeshift granularity of 50 MiB
| main debug: using default timeshift path
| main debug: `https://www.youtube.com/watch?v=hz_mMLhUinw' gives access 
`https' demux `any' path `www.youtube.com/watch?v=hz_mMLhUinw'
| main debug: creating demux: access='https' demux='any' 
location='www.youtube.com/watch?v=hz_mMLhUinw' file='(null)'
| main debug: looking for access_demux module matching "https": 17 candidates
| main debug: no access_demux modules matched
| main debug: creating access: https://www.youtube.com/watch?v=hz_mMLhUinw
| main debug: looking for access module matching "https": 28 candidates
| main debug: looking for tls client module matching "any": 1 candidates
| gnutls debug: using GnuTLS version 3.6.5
| main debug: looking for meta fetcher module matching "any": 1 candidates
| lua debug: Trying Lua scripts in 
/home/andoru/.local/share/vlc/lua/meta/fetcher
| lua debug: Trying Lua scripts in 
/usr/lib/x86_64-linux-gnu/vlc/lua/meta/fetcher
| lua debug: Trying Lua scripts in /usr/share/vlc/lua/meta/fetcher
| main debug: no meta fetcher modules matched
| main debug: looking for art finder module matching "any": 2 candidates
| lua debug: Trying Lua scripts in /home/andoru/.local/share/vlc/lua/meta/art
| lua debug: Trying Lua scripts in /usr/lib/x86_64-linux-gnu/vlc/lua/meta/art
| lua debug: Trying Lua playlist script 
/usr/lib/x86_64-linux-gnu/vlc/lua/meta/art/00_musicbrainz.luac
| lua debug: skipping script (unmatched scope) 
/usr/lib/x86_64-linux-gnu/vlc/lua/meta/art/00_musicbrainz.luac
| lua debug: Trying Lua playlist script 
/usr/lib/x86_64-linux-gnu/vlc/lua/meta/art/01_googleimage.luac
| lua debug: skipping script (unmatched scope) 
/usr/lib/x86_64-linux-gnu/vlc/lua/meta/art/01_googleimage.luac
| lua debug: Trying Lua playlist script 
/usr/lib/x86_64-linux-gnu/vlc/lua/meta/art/02_frenchtv.luac
| lua debug: skipping script (unmatched scope) 
/usr/lib/x86_64-linux-gnu/vlc/lua/meta/art/02_frenchtv.luac
| lua debug: Trying Lua playlist script 
/usr/lib/x86_64-linux-gnu/vlc/lua/meta/art/03_lastfm.luac
| lua debug: skipping script (unmatched scope) 
/usr/lib/x86_64-linux-gnu/vlc/lua/meta/art/03_lastfm.luac
| lua debug: Trying Lua scripts in /usr/share/vlc/lua/meta/art
| main debug: no art finder modules matched
| qt debug: IM: Setting an input
| gnutls debug: loaded 133 trusted CAs from system
| main debug: using tls client module "gnutls"
| main debug: resolving www.youtube.com ...
| gnutls debug: TLS handshake: Resource temporarily unavailable, try again.
| gnutls debug: TLS handshake: Success.
| gnutls debug: - safe renegotiation (RFC5746) enabled
| gnutls debug: - extended master secret (RFC7627) enabled
| gnutls debug: - false start (RFC7918) enabled
| http debug: out SETTINGS (0x04) frame of 30 bytes, flags 0x00, global
| http debug: out HEADERS (0x01) frame of 251 bytes, flags 0x05, stream 1
| http debug: in SETTINGS (0x04) frame of 18 bytes, flags 0x00, global
| http debug: setting: Concurrent streams (0x0003): 100
| http deb

Bug#917530: perldoc formatting unfortunately degraded by upstream compatability fix

[Anthony DeRobertis]

Package: perl-doc
Version: 5.28.1-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In f2ee4cb897ec9dd3338abcd0e9a42cb41ce9a173[0] upstream worked around
reported issues with perldoc by changing the default formatter to ToText
(from ToTerm) and also getting rid of automatically setting pager
options (like -R to less). 

This, of course, also removed all bold/underline/etc. from the output,
making perldoc less readable.

- From reading through the various related bugs (e.g., [1]) it seems like
they switched away from using groff (via ToMan) because Mac OS Sierra
has a groff without Unicode support. That obviously doesn't apply to
Debian, so it seems we could have nice rendering without any pager
workarounds just by changing the default back to Pod::Perldoc::ToMan.

Or at least a note in README.Debian about adding something like one of
these to .bashrc:

export PERLDOC=-oTerm PERLDOC_PAGER='less -R' # works like Stretch, Jessie
export PERLDOC=-oMan  # works like Wheezy

[0]: 
https://perl5.git.perl.org/perl.git/commit/f2ee4cb897ec9dd3338abcd0e9a42cb41ce9a173
[1]: https://rt.cpan.org/Public/Bug/Display.html?id=120229

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages perl-doc depends on:
ii  perl  5.28.1-3

perl-doc recommends no packages.

Versions of packages perl-doc suggests:
ii  groff-base   1.22.3-10
ii  konqueror [man-browser]  4:18.04.0-1+b2
ii  man-db [man-browser] 2.8.4-3

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCXCXtuhUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf4WmgCfeiTVl76yHBuWJTrEy3XJfMhQorkA
n02XnQ95YomQyzy/WHvImWA5MD9w
=dQql
-END PGP SIGNATURE-

Bug#917531: ITP: libcxx-serial: Cross-platform c++ serial ports library

[Alec Leamas]

Package: wnpp
Severity: wishlist
Owner: Alec Leamas 

* Package name: cxx-serial
  Version : 1.2.1
  Upstream Author : William Goodall
* URL : http://wjwwood.io/serial/
* License : Expat
  Programming Lang: C++
  Description : C++, cross-platform serial communications library

This is a dependency for opencpn, #907065, new for 4.8.8.

The name is somewhat ad-hoc, upstream name is serial. However, libserial
is already in debian using another upstream.

Bug#917532: RFP: fava -- web interface for the Beancount accounting tool

[Stefano Zacchiroli]

Package: wnpp
Severity: wishlist

* Package name: fava
  Version : 1.9
  Upstream Author : Dominik Aumayr 
* URL : https://beancount.github.io/fava/
* License : MIT
  Programming Lang: Python
  Description : web interface for the Beancount accounting tool

Fava is a web interface for the double-entry bookkeeping software Beancount
with a focus on features and usability.

Beancount is packaged in Debian as "beancount".

Bug#917533: linux-image-4.9.0-8-marvell: nfs-kernel-server leaks ports and triggers rkhunter/unhide-tcp

[Ian Campbell]

Package: src:linux
Version: 4.9.130-2
Severity: normal
Tags: upstream

Dear Maintainer,

Every few days rkhunter starts reporting in its daily report:

Warning: Hidden ports found:
 Port number: TCP:697

Which corresponds to running unhide-tcp:

# unhide-tcp --lsof
Unhide-tcp 20130526
Copyright © 2013 Yago Jesus & Patrick Gouin
License GPLv3+ : GNU GPL version 3 or later
http://www.unhide-forensics.info
Used options: use_lsof 
[*]Starting TCP checking

Found Hidden port that not appears in ss: 697
lsof reports :
[*]Starting UDP checking
root@armitage:~# unhide-tcp --netstat
Unhide-tcp 20130526
Copyright © 2013 Yago Jesus & Patrick Gouin
License GPLv3+ : GNU GPL version 3 or later
http://www.unhide-forensics.info
Used options: use_netscape 
[*]Starting TCP checking

Found Hidden port that not appears in netstat: 697

Running `service nfs-kernel-server restart` clears it up for a day or two. I
think this corresponds to the report at https://lwn.net/Articles/648417/.

This report was gathered while running 4.9.130-2 but I had already installed
(but not rebooted into) a new locally rebooted version (4.9.144-1~hellion.0)
which corresponds to pkg-kernel git's stretch branch at d9cfad89feb2 ('Revert
"tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()"') plus
backports of:

8d1b8c62e080 SUNRPC: Refactor TCP socket timeout code into a helper function
3ffbc1d65583 net/sunrpc/xprt_sock: fix regression in connection error reporting.
9b30889c548a SUNRPC: Ensure we always close the socket after a connection shuts 
down

Where the first two are needed for a clean backport of the third which is:

commit 9b30889c548a4d45bfe6226e58de32504c1d682f
Author: Trond Myklebust 
Date:   Mon Feb 5 10:20:06 2018 -0500

SUNRPC: Ensure we always close the socket after a connection shuts down

Ensure that we release the TCP socket once it is in the TCP_CLOSE or
TCP_TIME_WAIT state (and only then) so that we don't confuse rkhunter
and its ilk.

Signed-off-by: Trond Myklebust 

I have a second system, also armel, running the same kernel and also serving
NFS where this is not happening. It's logs lack the:

[83135.994133] nfsd: last server has exited, flushing export cache
[83137.951143] NFSD: starting 90-second grace period (net c0590248)

which is seen on this system and which I think might correspond to the issue
recurring. The other system is perhaps bit busier with NFS traffic overall.

One final piece of information is that I was previously running (for about a
month if my logs are to be believed) linux-image-4.9.0-0.bpo.8-marvell:armel
4.9.110-3+deb9u5~deb8u1 on Jessie userspace and this was not happening. It only
started when I upgraded to Stretch's userspace and kernel (4.9.130-2). I don't
immediately see anything in `git log v4.9.110..v4.9.130 -- net/sunrpc/` which
would explain the change though. The upgrade to stretch took rkhunter from
1.4.2-0.4+deb8u1 to 1.4.2-6+deb9u1, which did include a bump to the default
configuration file, although I also can't see a smoking gun there based on what
etckeeper says changed (but if I were a betting many I would guess it was a
change to the detection process which exposed this rather than a kernel
regression).

I'm next going to reboot into my locally built kernel with the (likely/hopeful)
fix applied. I'll follow up in a few days (maybe a week to be sure) if I don't
see this issue recurring. If it is looking positive at that point I'll also
ping davem and Trond to requests upstream backports.

Thanks,
Ian.

-- Package-specific info:
** Version:
Linux version 4.9.0-8-marvell (debian-ker...@lists.debian.org) (gcc version 
6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 Debian 4.9.130-2 (2018-10-27)

** Command line:
console=ttyS0,115200 root=/dev/ram initrd=0xa0,0x90 ramdisk=32768

** Not tainted

** Kernel log:
[7.882180] raid6: using intx1 recovery algorithm
[7.903700] async_tx: api initialized (async)
[7.911087] xor: measuring software checksum speed
[7.955195]arm4regs  :   725.000 MB/sec
[7.999190]8regs :   435.000 MB/sec
[8.043196]32regs:   633.000 MB/sec
[8.047417] xor: using function: arm4regs (725.000 MB/sec)
[8.097711] md: raid6 personality registered for level 6
[8.103102] md: raid5 personality registered for level 5
[8.108456] md: raid4 personality registered for level 4
[8.154600] md: raid10 personality registered for level 10
[8.423667] random: crng init done
[8.427094] random: 7 urandom warning(s) missed due to ratelimiting
[9.166444] EXT4-fs (dm-0): mounting ext3 file system using the ext4 
subsystem
[9.200619] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: 
(null)
[   12.160956] input: gpio_keys as /devices/platform/gpio_keys/input/input0
[   12.306034] m25p80 spi0.0: m25p128 (

Bug#917468: missing SVN repository data

[Geert Stappers]

At https://anonscm.debian.org/ is text saying
  an archive of VCS repositories can be found on 
https://alioth-archive.debian.org/

But under https://alioth-archive.debian.org/svn/ is _no_ pelican.tar.xz


Unless a pelican SVN repo shows up, I will make git repo from scratch.

Bug#887394: Packaging Veyon (was: Re: Accepted italc 1:3.0.3+dfsg1-2 (source) into unstable)

[Mike Gabriel]

Hi Tobi,

On  Do 27 Dez 2018 17:07:20 CET, Tobias Junghans wrote:


Hi Mike,

Am Freitag, 7. Dezember 2018, 10:45:16 CET schrieb Mike Gabriel:

> * as of upcoming 4.1.6 release you should reconsider to not repack the
> source tarball as all unused source files (except for
> x11vnc/libvncserver) will get stripped anyway
> (https://github.com/veyon/veyon/commit/
> cc54151fb31524bd67a6160acaac1204f55e9ccd).

That is great news!!! When is the due date of 4.1.6. Will you make it
for Debian buster's soft freeze (midst of February)?
https://wiki.debian.org/DebianBuster


FYI: 4.1.6 has been released about 1 week ago and includes most of your
patches.

Best regards

Tobias


I will wait for the ftp-masters to ACCEPT (or REJECT) the veyon upload  
that's currenty in Debian's NEW queue and once it got accepted, I will  
asap upload the new version.


Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp2PPB6HuHw6.pgp
Description: Digitale PGP-Signatur

Bug#917534: ifupdown2 fails to start network configuration

[Joerg Dorchain]

Package: ifupdown2
Version: 1.2.2-1
Severity: serious
Justification: renders system unusable

Hello,

with this package and this version, my system comes up without any
networking configured, giving an error message at startup

Fri Dec 28 10:38:52 2018: networking: Configuring network interfaces
Fri Dec 28 10:38:52 2018: Traceback (most recent call last):
Fri Dec 28 10:38:52 2018:   File "/sbin/ifup", line 26, in 
Fri Dec 28 10:38:52 2018: from ifupdown.log import log
Fri Dec 28 10:38:52 2018:   File "/usr/share/ifupdown2/ifupdown/log.py", line 
163, in 
Fri Dec 28 10:38:52 2018: log = Log()
Fri Dec 28 10:38:52 2018:   File "/usr/share/ifupdown2/ifupdown/log.py", line 
65, in __init__
Fri Dec 28 10:38:52 2018: self.syslog_handler = 
logging.handlers.SysLogHandler(address=address, facility=facility)
Fri Dec 28 10:38:52 2018:   File "/usr/lib/python2.7/logging/handlers.py", line 
761, in __init__
Fri Dec 28 10:38:52 2018: self._connect_unixsocket(address)
Fri Dec 28 10:38:52 2018:   File "/usr/lib/python2.7/logging/handlers.py", line 
804, in _connect_unixsocket
Fri Dec 28 10:38:52 2018: self.socket.connect(address)
Fri Dec 28 10:38:52 2018:   File "/usr/lib/python2.7/socket.py", line 228, in 
meth
Fri Dec 28 10:38:52 2018: return getattr(self._sock,name)(*args)
Fri Dec 28 10:38:52 2018: socket.error: [Errno 2] No such file or directory

My system is running on sysvinit.

An acceptable proposal would be to log to stderr until /dev/log has been setup

The init script used looks as follows:

## BEGIN INIT INFO
# Provides:  networking ifupdown
# Required-Start:mountkernfs $local_fs urandom $syslog
# Required-Stop: $local_fs
# Default-Start: S
# Default-Stop:  0 6
# Short-Description: Raise network interfaces.
# Description:   Prepare /run/network directory, ifstate file and raise 
network interfaces, or take them down.
### END INIT INFO

exec /usr/share/ifupdown2/sbin/start-networking "$@"


Bye,

Joerg


signature.asc
Description: PGP signature

Bug#887394: Packaging Veyon (was: Re: Accepted italc 1:3.0.3+dfsg1-2 (source) into unstable)

[Mike Gabriel]

Hi Tobi,

On  Do 27 Dez 2018 17:07:20 CET, Tobias Junghans wrote:


Hi Mike,

Am Freitag, 7. Dezember 2018, 10:45:16 CET schrieb Mike Gabriel:

> * as of upcoming 4.1.6 release you should reconsider to not repack the
> source tarball as all unused source files (except for
> x11vnc/libvncserver) will get stripped anyway
> (https://github.com/veyon/veyon/commit/
> cc54151fb31524bd67a6160acaac1204f55e9ccd).

That is great news!!! When is the due date of 4.1.6. Will you make it
for Debian buster's soft freeze (midst of February)?
https://wiki.debian.org/DebianBuster


FYI: 4.1.6 has been released about 1 week ago and includes most of your
patches.

Best regards

Tobias


in some previous mail, you mentioned that you have dropped some copies  
of code (or that it is possible to do that when repacking).


Can you be more specific on that?

Thanks,
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp_jfJun3G5z.pgp
Description: Digitale PGP-Signatur

Bug#917431: debian-policy: virtual packages: logind, default-logind

[Simon McVittie]

On Fri, 28 Dec 2018 at 02:52:09 +0900, Ansgar Burchardt wrote:
> Adam Borowski writes:
> > Thus, the wording would be (as proposed by fsateler):
> >
> > logind: an org.freedesktop.login1 D-Bus API implementation
> >
> > default-logind: should be provided by the distribution's default logind
> > provider (currently pam-systemd)
> 
> So any provider of logind would have to provide the full interface of
> the current interface (including future updates)?

Presumably a package that Provides: logind (= 123) would be expected to
provide the same D-Bus APIs that the logind in systemd 123 did.

Some of logind's APIs are not D-Bus APIs: in addition to D-Bus, it
has an ad-hoc form of IPC using files in /run. I think the files and
their contents themselves are not considered to be public API, but the
functions in libsystemd that read those files are. This is used by other
packages, notably dbus-daemon (which should not normally use D-Bus APIs
itself because that would be a circular dependency) for its deprecated
at_console policy, and policykit-1 for many of its policies.

Are packages that provide logind expected to create the same files in
/run so that libsystemd APIs will work as intended?

> You can start logind without libpam-systemd, it just wouldn't know about
> any session.  So it is about providing hooks to register sessions with
> logind.

A *working* org.freedesktop.login1 implementation, then, perhaps? (If an
implementation of logind doesn't know about login sessions then it can't
really be said to be working correctly.)

smcv

Bug#917509: theme-d-gnome: FTBFS (dh_auto_configure fails)

[Tommi Höynälänmaa]

Hi

Guile is being updated to version 2.2 in Debian. Consequently my old 
packages using guile 2.0 are not fixed anymore. You should upgrade to 
theme-d-gnome version 0.7.4, which is currently in unstable. I'm afraid 
you have to wait until guile-gnome-platform 2.16.5 is available in Debian.


 - Tommi

Bug#917532: RFP: fava -- web interface for the Beancount accounting tool

[Stefano Zacchiroli]

A package skeleton is now available on salsa:

  https://salsa.debian.org/python-team/applications/fava

Help and co-maintainers are welcome.

(It's not clear to me if I should do anything else, other than creating
the project on salsa, to make sure other members of PAPT can directly
commit to the repo. If so, I'd appreciate someone letting me know.)

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#916646: cannot reproduce

[Robert Lemmen]

hi andreas,

thanks for the report, but I can't reproduce the issue at all, and it
does not make much sense to me from the logs. I tried piuparts as well
as a handful of manual install-upgrade-remove cases in a docker image.

Could you tell me how exactly piuparts was invoked for this? Does it
still happen to you?

thanks  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: PGP signature

Bug#917532: RFP: fava -- web interface for the Beancount accounting tool

[Stefano Zacchiroli]

Looks like a fava dependency is missing in Debian: [python3-]markdown2,
https://pypi.org/project/markdown2/ (There's python3-markdown in the
archive, but that's a different one: https://pypi.org/project/Markdown/)

Volunteers to package markdown2 are welcome; I'm not going to package it
myself.

Cheers.
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#917509: theme-d-gnome: FTBFS (dh_auto_configure fails)

[Santiago Vila]

On Fri, Dec 28, 2018 at 12:15:22PM +0200, Tommi Höynälänmaa wrote:

> Guile is being updated to version 2.2 in Debian. Consequently my old
> packages using guile 2.0 are not fixed anymore. You should upgrade to
> theme-d-gnome version 0.7.4, which is currently in unstable. I'm afraid you
> have to wait until guile-gnome-platform 2.16.5 is available in Debian.

Hi. Sorry, I try not to report any bugs if the package has a different
version in testing and unstable, but I missed this one because 0.7.4
was uploaded yesterday afternoon.

However, I see that 0.7.4-1 still fails in reproducible-builds.

Is the failure in reproducible-builds different than the one I got in
testing? Can you take a look at the failure in reproducible-builds?

Thanks.

Bug#917196: transition: qtbase-opensource-src

[Emilio Pozuelo Monfort]

On 27/12/2018 23:18, Lisandro Damián Nicanor Pérez Meyer wrote:
> qtbase has been built everywhere, so all the rdeps can now be binNMUed. Worst 
> case scenario they will wait for the relevant rdeps to get built.

Scheduled.

Emilio

Bug#917535: debian-archive-keyring: ftp-master key for buster

[Niels Thykier]

Package: debian-archive-keyring
Version: 2017.5
Severity: serious

Hi,

We need new archive signing keys for buster, so we can include them in
a debian-archive-keyring upload before the buster release.

Thanks,
~Niels

(If we need a better template, please help us with an update to
https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList/, which
currently uses #860830 as a reference)

Bug#917536: debian-archive-keyring: release key for buster

[Niels Thykier]

Package: debian-archive-keyring
Version: 2017.5
Severity: serious

Hi,

We need a new release signing key for buster so we can include it in a
debian-archive-keyring upload before the buster release.

Thanks,
~Niels

(If we need a better template, please help us with an update to
https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList/, which
currently uses #860831 as a reference)

Bug#917261: linux-image-4.19.0-1-amd64: /dev/mapper symlink for dm-crypt volume containing / not created on system startup

[Michael Biebl]

Am 28.12.18 um 07:04 schrieb Ben Hutchings:

> And if you downgrade udev and libudev1 to version 239-15, that will
> trigger an update of the 4.19 initramfs (only) and you should then be
> able to boot with Linux 4.19.

Or upgrade to udev 240-2, which should fix this issue.






signature.asc
Description: OpenPGP digital signature

Bug#917124: lvm2 logical volumes are not properly initialized

[Michael Biebl]

Am 28.12.18 um 09:40 schrieb Rafał Olejnik:
> lvm2-activation-generator: lvmconfig failed
> 
> lvm2-activation-generator: Activation generator failed.

Those error messages are unrelated to this particular issue. They are
caused by the latest lvm2 update.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917164



signature.asc
Description: OpenPGP digital signature

Bug#913046: libjs-cryptojs: Please upgrade to 3.1.9

[Xavier]

Hello,

do you want that we take maintenance of this package under JS-Team umbrella

Cheers,
Xavier

Bug#917174: davmail: FTBFS with libjackrabbit-java 2.18.0

[Alexandre Rossi]

Hi,

> unfortunately davmail fails to build from source with
> libjackrabbit-java 2.18.0. Long deprecated methods have been removed.
> Your package build-depends on a very old version of jackrabbit (2.4.3).
>
> See also the deprecated list that explains which methods should be
> used instead.
>
> https://jackrabbit.apache.org/api/2.14/deprecated-list.html

Thanks for reporting. It would have been great to have the heads up on
this before the upload to unstable, as I now cannot upload any new
version of davmail before fixing this bug.

Fixing this is not trivial for me because I do not know well the
davmail codebase. I hope to get upstream's help on this because I'm
not confident I can fix this alone in the coming days. Anyway I'll
try.

Alex

Bug#917516: anbox: does not pull binder or ashmem kernel drivers as dependency

[Svetlana Tkachenko]

~$ systemctl status anbox-container-manager
● anbox-container-manager.service - Anbox Container Manager
 Loaded: loaded (/lib/systemd/system/anbox-container-manager.service; enabled 
Active: inactive (dead)
Condition: start condition failed at Fri 2018-12-28 15:00:14 AEDT; 7h ago
 Docs: man:anbox(1)
~$ journalctl -u anbox-container-manager.service
-- Logs begin at Wed 2018-12-26 10:59:10 AEDT, end at Fri 2018-12-28 22:03:36 
A-- No entries --
~$

Bug#917185: udev 240-1 + sysvinit-core 2.93-1 break input devices + other problems

[Michael Biebl]

Am 28.12.18 um 01:41 schrieb Ricardo Peliquero:
> Thank you Michael,
> 
> I've just updated from 239-15 to 240-2; but, unfortunately, none of the
> problems were solved.
> 

Too bad, this sounded like it could be the same issue as #917124 :-/
Unfortunately I'm a bit at a loss atm.
I wonder if this is a sysvinit specific issue.
Unfortunately I'm not the best person to debug a sysvinit specific
problem, as I don't use sysvinit anymore.

Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#917537: ftp.debian.org: Please create security + backports archives for buster in preparation for the release

[Niels Thykier]

Package: ftp.debian.org
Severity: normal

Dear FTP masters,

Please create the security + backports archives for buster to enable
easier upgrades paths (a la "sed s/stretch/buster/").  This will make
it easier for e.g. DSA to perform upgrade tests of buildds and early
adopters of Debian services.

Furthermore, it will also enable us to verify that e.g. the security
archive for buster is working as intended before the release.

Thanks,
~Niels

Bug#917516: anbox: does not pull binder or ashmem kernel drivers as dependency

[Shengjing Zhu]

Svetlana Tkachenko  于 2018年12月28日周五 19:05写道：

>
> Condition: start condition failed at Fri 2018-12-28 15:00:14 AEDT; 7h ago
>

Please read /use/share/doc/anbox/README.Debian

You should download an Android image first.

Bug#917538: bugs.debian.org: Please add release tags for "bookworm" ("bookworm", "bookwork-ignore", etc.)

[Niels Thykier]

Package: bugs.debian.org
Severity: minor

Hi,

Please perform the relevant updates to bugs.debian.org to include the
tags for the future release called "bookworm".

Our checklist includes the following which may be of help to perform
the change:

"""
   * [ ] Get that included in BTS tags:
 * @gTags in /srv/bugs.debian.org/etc/config on bugs-master.debian.org
 * bts_release_tags and bts_release_ignore_tags 
[[https://anonscm.debian.org/viewvc/webwml/webwml/english/Bugs/pkgreport-opts.inc?view=markup#l176|in
 webwml]]
"""

Thanks,
~Niels

Bug#907765: honeysql-clojure: FTBFS in buster/sid (Could not locate honeysql/format_test__init.class or honeysql/format_test.clj on classpath.)

[Santiago Vila]

On Fri, Dec 28, 2018 at 03:48:06AM +0100, Cyril Brulebois wrote:

> > but it also fails here:
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/honeysql-clojure.html
> 
> Last build there seems OK as well.

Yes, but only the last amd64 build. The last i386 build, which is not
very old, shows the same kind of failure I reported, which suggests
that the problem, random in nature, still seems to be there.

> > In reproducible builds it seems to be random, but I tried to build it
> > 50 times on GCE n1-standard-1 machines today and it failed each and
> > every time.  If you need a test machine to reproduce please say so.
> 
> Can you please double check what happens on your end, and close if this
> went away?

Double-checked today on both 1-XS and 1-S instances from Scaleway and I
still get a 100% failure rate. I've put a bunch of build logs here:

https://people.debian.org/~sanvila/build-logs/honeysql-clojure/

I can offer a test machine where this happens all the time if you need
it to reproduce it. Please contact me privately for details.

Thanks.

Bug#917539: libreoffice: Please include patch to fix FTBFS on m68k

[John Paul Adrian Glaubitz]

Source: libreoffice
Version: 1:6.1.4-1
Severity: normal
Tags: patch upstream
User: debian-...@lists.debian.org
Usertags: m68k

Hello!

The attached patch should fix libreoffice on m68k, please apply :-).

Forwarded upstream as [1].

Thanks,
Adrian

> [1] https://gerrit.libreoffice.org/#/c/65684/

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Fix incorrect parameter type to std::min() on m68k
Author: John Paul Adrian Glaubitz 
Last-Update: 2018-12-28

--- libreoffice-6.1.4.orig/cppu/source/typelib/typelib.cxx
+++ libreoffice-6.1.4/cppu/source/typelib/typelib.cxx
@@ -1660,7 +1660,7 @@ extern "C" sal_Int32 typelib_typedescrip
 #ifdef __m68k__
 // Anything that is at least 16 bits wide is aligned on a 
16-bit
 // boundary on the m68k default abi
-sal_Int32 nMaxAlign = std::min(rMaxIntegralTypeSize, 2);
+sal_Int32 nMaxAlign = std::min(rMaxIntegralTypeSize, 
sal_Int32( 2 ));
 nStructSize = (nStructSize + nMaxAlign -1) / nMaxAlign * 
nMaxAlign;
 #else
 // Example: A { double; int; } structure has a size of 16 
instead of 10. The

Bug#917431: debian-policy: virtual packages: logind, default-logind

[Adam Borowski]

On Thu, Dec 27, 2018 at 06:28:04PM +, Sean Whitton wrote:
> Could you provide an actual diff to be applied to policy.git, please?

Sure, what about:?

diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst
index 679a187..633c14e 100644
--- a/policy/upgrading-checklist.rst
+++ b/policy/upgrading-checklist.rst
@@ -39,6 +39,14 @@ The sections in this checklist match the values for the
 except in the two anomalous historical cases where normative
 requirements were changed in a minor patch release.
 
+Unreleased
+--
+
+virtual
+New ``logind`` and ``default-logind`` virtual packages for a package
+providing logind API (over D-Bus and /run/), and for Debian's preferred
+implementation, respectively.
+
 Version 4.3.0
 -
 
diff --git a/virtual-package-names-list.yaml b/virtual-package-names-list.yaml
index afb76a3..de54e32 100644
--- a/virtual-package-names-list.yaml
+++ b/virtual-package-names-list.yaml
@@ -110,6 +110,10 @@ virtualPackages:
description: provides the D-Bus well-known session bus for most or all user 
login sessions
  - name: default-dbus-session-bus
description: Debian's preferred implementation of dbus-session-bus, 
possibly architecture-specific
+ - name: logind
+   description: an org.freedesktop.login1 D-Bus API implementation (versioned)
+ - name: default-logind
+   description: Debian's preferred implementation of logind, possibly 
architecture-specific (versioned)
 
 # Documentation
 

> Please follow the style for the other default-* packages listed there.

There's exactly one (dbus-session-bus).

> Ansgar's suggestion should probably be included, too.

To keep the wording terse I appended just "(versioned)" -- I see no
precedent for such a marking, but I hope this is clear enough.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.

Bug#917540: deepin-qt5dxcb-plugin: FTBFS with Qt 5.11.3

[Lisandro Damián Nicanor Pérez Meyer]

Source: deepin-qt5dxcb-plugin
Version: 1.1.20-1
Severity: serious
Justification: FTBFS

Hi! Your package is FTBFS with Qt 5.11.3 due to it's version check. Nothing has
changed with respect to 5.11.2 so it should just build with the correct version
check fix.

Thanks in advance, Lisandro.

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#917541: ITP - Python-xxhash - Python Binding for xxHash

[Michal Arbet]

Package: wnpp
Severity: wishlist
Owner: Michal Arbet 

* Package name: python3-xxhash
  Version : 1.0.1
  Upstream Author : Yue Du 
* URL : *https://github.com/ifduyue/python-xxhash
*
* License : BSD-2-clause
  Programming Lang: Python
  Description :  Python Binding for xxHash

Python Binding for xxHash

 - This package provides Python Binding for xxHash.
 - I will maintain it inside a packaging team Debian Openstack

Bug#917084: Possible fix?

[Er_Maqui]

Hi,

Maybe on next release this bug have been resolved?
I'm already waiting for testing if it's ok or not.

If there's not any work on this release for this bug, or it's going to take
"long time" the release, then I need to find a workaround for re-enabling
gitlab (I have only SSL access to the web).


Thanks,

https://maqui.darkbolt.net/
Linux registered user ~#363219
PGP keys avaiables at KeyServ. ID: 0x4233E9F2
Los hombres somos esclavos de la historia

Bug#917489: duplicate of #916922 in src:migrate

[Robin Jarry]

Control: reassign -1 src:migrate 0.11.0-4
Control: affects -1 src:buildbot

Bug#659926: [Pkg-xfce-devel] Bug#659926: Bug#659926: xfce4-appfinder: Displays non-valid items.

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2012-02-15 at 08:46 -0200, Sergio Cipolla wrote:
> Well, it was even a bit useful as some application I used (and
> removed) quite some time ago left a custom menu category in
> /etc/xdg/menus (not any official package) and so I could delete it as
> it showed on the appfinder ;)
> But then it seems that the git version has evolved and so maybe I
> should try it to see if this issue is still present.
> 
Hi,

were you able to test this?

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlwmEx0ACgkQ3rYcyPpX
RFtNcggAvxanGPA3jRybCUf+cKy0joVAwmMXbZNnKhKkWz1hB9P6YpTleFlUxKDZ
kG0CE4zwiA31L5QyTgFmq4a2w78ZTJ/LqJoPQrRuOF5CiYer6n+Jfm3G/u5vuWBh
hrVPOYH0UxI2WJfNi1MReeM1KAq4wskRw0iy3aLXIJEy1Dj+vuSP4hzSgrlABkRt
7GUHj7Wn7lXzowoMcxpvtY/z18tBzNWh7LP3F1cQLfwwixNieqFhlpkisGmz7fkW
rB264P9gUTqojf2ld8796VFFtWP9vbM9kvnD/RU6Ejqt3soHA5ua7YJoVBE8EArL
nLh+bMd4zUByeUQukN1Ka9fsVGzQ/A==
=Yo8L
-END PGP SIGNATURE-

Bug#633445: [Pkg-xfce-devel] Bug#633445: xfce4-appfinder: slow startup with errors

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2011-07-10 at 13:33 +0200, Marco Milone wrote:
> I notice that when I launch xfce4-appfinder it waits many seconds to shows up.
> If I launch it in a terminal I can see these errors:

Hi,

sorry for the (extra) long delay in replying. Does this still happen on
current xfce4-appfinder version in stable or unstable?

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlwmEuwACgkQ3rYcyPpX
RFuRzAgAt/doNASlb539Wnf/nG53z1BoSG+MfUFbuzQspaJrlUvKbsDLqKsmc+V+
r+Z/lC5XmRQF7d0cO6ZHbLkv+mm2ZtrQi2GzksX34Z1ARmK7mnj4sUnb+tNPL/4s
uOVZWKjA0MGmptH8M1G06WncdwUAutOgTAQ6uMvJhaoy9AqDnyDHEJO2qOX0sy/c
qYAkotqvrRaZHQzq49XoSVdcgAVXQx5VZf59m8/q/pRV7iHnX8BHo2ShYClCTcHH
2zsTA4aAh6NXeC5Ob8sgbDVVHBq3xPl779YQNRzy8TyiqoHIAOoBUDX4YtlptaSb
zlHZTM8YitzmCAt0cSvpJd84A3gvvA==
=Bc0j
-END PGP SIGNATURE-

Bug#872914: [Pkg-xfce-devel] Bug#872914: xfce4-appfinder: don't focus automatically in Mate

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2017-08-22 at 13:53 +0200, Luffah wrote:
> Package: xfce4-appfinder
> Version: 4.12.0-2
> Severity: minor
> 
> Dear Maintainer,
> 
> I used xfce4-appfinder in Mate (because it is better structured than the
> mate launcher),
> but when i run the app it does not take the focus.
> (... for a launcher it can be a problem)

Hi,

I'm unsure if you still have the issue, but it's likely an issue with the Mate
window manager badly interacting with the “single instance” DBus activation, I
guess. I don't think there's much which can be done on xfce4-appfinder here.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlwmE8IACgkQ3rYcyPpX
RFuyJQf/VseeALr8/WIpTDJYP/dZ1TEsTb+f3Kl0g+wSaABbRzhNeAZaGZirJGh9
zRtKPSGHZGbmcQloObn/KvnsB/0+cJGEeiBuxTNtkMaQIMzRiRV+/0a84z9Gf928
1+Hpi6CUG+MctI6gDE2RfFgg4rtK8tIdQnLQlJzc8plHO3wLFWLh84+YWUodbNjV
4+KKJcFFPYI4N/AanHkaOslKtsJUjUcnf3RCFUfaEvW458U5CzQwZJ1SlYMNPDAw
ectptAcA0patxIjq9+DqfH6yAdkcK4G8HsvgA4jmS3UnlqF4rF0yV/8qBJO78jCm
AjuHbX+6Z6syM2oIl8h1a1HSDhsZ2g==
=CjrY
-END PGP SIGNATURE-

Bug#917542: RFS: udftools/2.1-1 [RC]

[Pali Rohár]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "udftools"

 * Package name: udftools
   Version : 2.1-1
   Upstream Author : Pali Rohár 
 * URL : https://github.com/pali/udftools
 * License : GPL-2+
   Section : otherosfs

It builds those binary packages:

  udftools   - tools for UDF filesystems and DVD/CD-R(W) drives

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/udftools


Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/u/udftools/udftools_2.1-1.dsc

More information about udftools can be obtained from 
https://github.com/pali/udftools.

Changes since the last upload:

 * New upstream release (Closes: #916006)
 * Update Standards-Version to 4.3.0
 * Update to debhelper 11
 * Update copyright and signing-key.asc


Regards,
 Pali Rohár


signature.asc
Description: PGP signature

Bug#894824: popt FTCBFS: api-sanity-checker dependency unsatisfiable

[Niels Thykier]

On Fri, 6 Apr 2018 13:45:25 -0400 Michael Jeanson 
wrote:
> On 2018-04-04 11:24, Helmut Grohne wrote:
> > Source: popt
> > Version: 1.16-11
> > Tags: patch
> > User: helm...@debian.org
> > Usertags: rebootstrap
> > 
> > popt fails to cross build from source, because its build dependency on
> > api-sanity-checker is unsatisfiable. In general, Architecture: all
> > packages can never satisfy cross Build-Depends unless marked Multi-Arch:
> > foreign. In this case however, api-sanity-checker is entirely
> > unnecessary, because it is only used for testing and we cannot test
> > during cross builds anyway. Thus annotating the dependency with
> >  is sufficient to get satisfiable cross Build-Depends again. I
> > used reproducible builds to verify that this change does not affect the
> > resulting binary packages. Please consider applying the attached patch.
> > 
> > Helmut
> > 
> 
> Hi,
> 
> Thanks for the patch, I've applied it in git, I'll wait on some other
> changes to upload unless this is blocking something on your side?
> 
> Regards,
> 
> Michael
> 
> 

Hi Michael,

Could I perhaps convince you to do an upload with this patch in time for
buster?  It will enable us to remove one hack/work around in the
"bootstrap.sh" script currently in use for bootstrapping new
architectures (as well as improve our cross-building stats for buster).
  Also, you mention that you have applied it in git but I cannot see it
in salsa (admittedly, I only checked the master branch).  Have you
perhaps forgotten to push it?

If you would like some additional changes/improvements to popt (albeit
unrelated to this bug), then I can think of:

 * The override for dh_auto_build might be redundant now that debhelper
   passes --disable-silent-rules (as of debhelper/9.20140613)

 * The popt looks like a package that might be able to build with
   "Rules-Requires-Root: no" set in the Source in d/control.
   - If that fails in sid because the upstream build system relies on
 root, please set "Rules-Requires-Root: binary-targets" explicitly.
 This will enable us to flip the default and make "(fake)root"
 opt-in rather than opt-out in the future.

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature