Bug#937849: python-jedi: diff for NMU version 0.14.1-1.1

[Sandro Tosi]

Control: tags 937849 + pending


Dear maintainer,

I've prepared an NMU for python-jedi (versioned as 0.14.1-1.1) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

I didnt think a new upstream release is necessary to fix this bug, so in the
spirit of keeping the NMU as short as possible, i've prepared this one

Regards.

diff -Nru python-jedi-0.14.1/debian/changelog python-jedi-0.14.1/debian/changelog
--- python-jedi-0.14.1/debian/changelog	2019-07-22 18:24:39.0 -0400
+++ python-jedi-0.14.1/debian/changelog	2019-12-30 02:02:27.0 -0500
@@ -1,3 +1,10 @@
+python-jedi (0.14.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937849
+
+ -- Sandro Tosi   Mon, 30 Dec 2019 02:02:27 -0500
+
 python-jedi (0.14.1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru python-jedi-0.14.1/debian/control python-jedi-0.14.1/debian/control
--- python-jedi-0.14.1/debian/control	2018-12-31 05:33:46.0 -0500
+++ python-jedi-0.14.1/debian/control	2019-12-30 01:59:18.0 -0500
@@ -3,23 +3,14 @@
 Section: python
 Priority: optional
 Build-Depends: debhelper (>= 10), dh-python,
- python-all, python3-all,
- python-setuptools, python3-setuptools,
- python-pytest, python3-pytest,
- python-unittest2, python3-unittest2,
- python-docopt, python3-docopt,
+ python3-all,
+ python3-setuptools,
+ python3-pytest,
+ python3-unittest2,
+ python3-docopt,
 Standards-Version: 4.3.0
 Homepage: https://github.com/davidhalter/jedi
 
-Package: python-jedi
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}, python-parso (>= 0.3)
-Description: autocompletion tool for Python
- Jedi is an autocompletion tool for Python. It works. With and without syntax
- errors. Sometimes it sucks, but that's normal in dynamic languages. But it
- sucks less than other tools. It understands almost all of the basic Python
- syntax elements including many builtins.
-
 Package: python3-jedi
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}, python3-parso (>= 0.3)
diff -Nru python-jedi-0.14.1/debian/python-jedi.install python-jedi-0.14.1/debian/python-jedi.install
--- python-jedi-0.14.1/debian/python-jedi.install	2016-12-28 11:39:01.0 -0500
+++ python-jedi-0.14.1/debian/python-jedi.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-/usr/lib/python2.*
diff -Nru python-jedi-0.14.1/debian/rules python-jedi-0.14.1/debian/rules
--- python-jedi-0.14.1/debian/rules	2017-01-19 13:04:56.0 -0500
+++ python-jedi-0.14.1/debian/rules	2019-12-30 01:59:34.0 -0500
@@ -3,7 +3,7 @@
 export PYBUILD_DISABLE=test
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_installchangelogs:
 	dh_installchangelogs CHANGELOG.rst

Bug#937465: pykerberos: diff for NMU version 1.1.14-3.1

[Sandro Tosi]

Control: tags 937465 + patch


Dear maintainer,

I've prepared an NMU for pykerberos (versioned as 1.1.14-3.1). The diff
is attached to this message.

Regards.

diff -Nru pykerberos-1.1.14/debian/changelog pykerberos-1.1.14/debian/changelog
--- pykerberos-1.1.14/debian/changelog	2019-11-30 09:26:03.0 -0500
+++ pykerberos-1.1.14/debian/changelog	2019-12-30 01:53:20.0 -0500
@@ -1,3 +1,10 @@
+pykerberos (1.1.14-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937465
+
+ -- Sandro Tosi   Mon, 30 Dec 2019 01:53:20 -0500
+
 pykerberos (1.1.14-3) unstable; urgency=medium
 
   * Depend on dh-python.
diff -Nru pykerberos-1.1.14/debian/control pykerberos-1.1.14/debian/control
--- pykerberos-1.1.14/debian/control	2019-11-30 09:24:44.0 -0500
+++ pykerberos-1.1.14/debian/control	2019-12-30 01:52:41.0 -0500
@@ -6,9 +6,6 @@
 Build-Depends: debhelper (>= 9),
dh-python,
libkrb5-dev,
-   python (>= 2.6.6-3~),
-   python-all-dev,
-   python-setuptools,
python3-all-dev,
python3-setuptools
 Standards-Version: 4.4.0
@@ -16,21 +13,6 @@
 Vcs-Git: https://salsa.debian.org/agx/pykerberos.git
 Vcs-Browser: https://salsa.debian.org/agx/pykerberos
 
-Package: python-kerberos
-Architecture: any
-Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}
-Provides: ${python:Provides}
-Description: GSSAPI interface module - Python 2.x
- This Python package is a high-level wrapper for Kerberos (GSSAPI) operations.
- The goal is to avoid having to build a module that wraps the entire
- Kerberos.framework, and instead offer a limited set of functions that do what
- is needed for client/server Kerberos authentication based on
- .
- .
- Much of the C-code here is adapted from Apache's mod_auth_kerb-5.0rc7.
- .
- This package contains the Python 2.x module.
-
 Package: python3-kerberos
 Architecture: any
 Depends: lsb-release, ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
diff -Nru pykerberos-1.1.14/debian/rules pykerberos-1.1.14/debian/rules
--- pykerberos-1.1.14/debian/rules	2019-03-21 04:26:46.0 -0400
+++ pykerberos-1.1.14/debian/rules	2019-12-30 01:53:09.0 -0500
@@ -1,22 +1,4 @@
 #!/usr/bin/make -f
 
-PYTHONS:=$(shell pyversions -vr)
-PYTHON3S:=$(shell py3versions -vr)
-
 %:
-	dh $@ --buildsystem=python_distutils --with python2,python3
-
-override_dh_auto_install:
-	set -e && for pyvers in $(PYTHONS); do \
-		python$$pyvers setup.py install --install-layout=deb \
-			--root $(CURDIR)/debian/python-kerberos; \
-	done
-	set -e && for pyvers in $(PYTHON3S); do \
-		python$$pyvers setup.py install --install-layout=deb \
-			--root $(CURDIR)/debian/python3-kerberos; \
-	done
-
-override_dh_clean:
-	rm -rf build
-	dh_clean -O--buildsystem=python_distutils
-
+	dh $@ --buildsystem=pybuild --with python3

Bug#947758: buster-pu: package node-handlebars/3:4.1.0-1+deb10u1

[Xavier Guimard]

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

Hi,

node-handlebars is vulnearable to prototype pollution (CVE-2019-19919).
This patch is exactly the one of upstream.

Cheers,
Xavier
diff --git a/debian/changelog b/debian/changelog
index b985661..95811b9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+node-handlebars (3:4.1.0-1+deb10u1) buster; urgency=medium
+
+  * Team upload
+  * Disallow calling "helperMissing" and "blockHelperMissing" directly
+(Closes: CVE-2019-19919)
+
+ -- Xavier Guimard   Mon, 30 Dec 2019 07:46:39 +0100
+
 node-handlebars (3:4.1.0-1) unstable; urgency=medium
 
   * New upstream version 4.1.0 (Closes: #923042)
diff --git a/debian/patches/CVE-2019-19919.patch 
b/debian/patches/CVE-2019-19919.patch
new file mode 100644
index 000..f63f106
--- /dev/null
+++ b/debian/patches/CVE-2019-19919.patch
@@ -0,0 +1,213 @@
+Description: Disallow calling "helperMissing" and "blockHelperMissing" directly
+ Fix for CVE-2019-19919
+Author: Nils Knappmeier 
+Origin: upstream, https://github.com/wycats/handlebars.js/commit/2078c72
+Bug: https://github.com/wycats/handlebars.js/issues/1558
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2019-12-30
+
+--- a/lib/handlebars/compiler/javascript-compiler.js
 b/lib/handlebars/compiler/javascript-compiler.js
+@@ -311,7 +311,7 @@
+   // replace it on the stack with the result of properly
+   // invoking blockHelperMissing.
+   blockValue: function(name) {
+-let blockHelperMissing = this.aliasable('helpers.blockHelperMissing'),
++let blockHelperMissing = 
this.aliasable('container.hooks.blockHelperMissing'),
+ params = [this.contextName(0)];
+ this.setupHelperArgs(name, 0, params);
+ 
+@@ -329,7 +329,7 @@
+   // On stack, after, if lastHelper: value
+   ambiguousBlockValue: function() {
+ // We're being a bit cheeky and reusing the options value from the prior 
exec
+-let blockHelperMissing = this.aliasable('helpers.blockHelperMissing'),
++let blockHelperMissing = 
this.aliasable('container.hooks.blockHelperMissing'),
+ params = [this.contextName(0)];
+ this.setupHelperArgs('', 0, params, true);
+ 
+@@ -622,18 +622,31 @@
+   // If the helper is not found, `helperMissing` is called.
+   invokeHelper: function(paramSize, name, isSimple) {
+ let nonHelper = this.popStack(),
+-helper = this.setupHelper(paramSize, name),
+-simple = isSimple ? [helper.name, ' || '] : '';
++helper = this.setupHelper(paramSize, name);
+ 
+-let lookup = ['('].concat(simple, nonHelper);
++let possibleFunctionCalls = [];
++
++if (isSimple) { // direct call to helper
++  possibleFunctionCalls.push(helper.name);
++}
++// call a function from the input object
++possibleFunctionCalls.push(nonHelper);
+ if (!this.options.strict) {
+-  lookup.push(' || ', this.aliasable('helpers.helperMissing'));
++  
possibleFunctionCalls.push(this.aliasable('container.hooks.helperMissing'));
+ }
+-lookup.push(')');
+-
+-this.push(this.source.functionCall(lookup, 'call', helper.callParams));
++let functionLookupCode = ['(', 
this.itemsSeparatedBy(possibleFunctionCalls, '||'), ')'];
++let functionCall = this.source.functionCall(functionLookupCode, 'call', 
helper.callParams);
++this.push(functionCall);
+   },
+ 
++  itemsSeparatedBy: function(items, separator) {
++let result = [];
++result.push(items[0]);
++for (let i = 1; i < items.length; i++) {
++  result.push(separator, items[i]);
++}
++return result;
++  },
+   // [invokeKnownHelper]
+   //
+   // On stack, before: hash, inverse, program, params..., ...
+@@ -673,7 +686,7 @@
+   lookup[0] = '(helper = ';
+   lookup.push(
+ ' != null ? helper : ',
+-this.aliasable('helpers.helperMissing')
++this.aliasable('container.hooks.helperMissing')
+   );
+ }
+ 
+--- a/lib/handlebars/runtime.js
 b/lib/handlebars/runtime.js
+@@ -1,6 +1,7 @@
+ import * as Utils from './utils';
+ import Exception from './exception';
+-import { COMPILER_REVISION, REVISION_CHANGES, createFrame } from './base';
++import {COMPILER_REVISION, createFrame, REVISION_CHANGES} from './base';
++import {moveHelperToHooks} from './helpers';
+ 
+ export function checkRevision(compilerInfo) {
+   const compilerRevision = compilerInfo && compilerInfo[0] || 1,
+@@ -44,11 +45,14 @@
+ }
+ 
+ partial = env.VM.resolvePartial.call(this, partial, context, options);
+-let result = env.VM.invokePartial.call(this, partial, context, options);
++
++let optionsWithHooks = Utils.extend({}, options, {hooks: this.hooks});
++
++let result = env.VM.invokePartial.call(this, partial, context, 
optionsWithHooks);
+ 
+ if (result == null && env.compile) {
+   options.partials[options.name] = env.compile(partial, 
templateSpec.compilerOptions, env);
+-  result = options.parti

Bug#947757: pysparse: should this package be removed?

[Sandro Tosi]

Source: pysparse
Severity: serious

Hello,
it seeems to me there are several issues with this package:

* python2 only, and there's already another `python3-sparse` from another src
* no upstream commits since 2013, 
https://sourceforge.net/p/pysparse/git/commit_browser
* no upstream releases since 2010

If i dont hear back within a week with a good reason to keep this package in
Debian, i'll file for its removal.

Regards,
Sandro

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#936389: dfwinreg: diff for NMU version 20190122-1.1

[Sandro Tosi]

Dear maintainer,

I've prepared an NMU for dfwinreg (versioned as 20190122-1.1). The diff
is attached to this message.

Regards.

diff -Nru dfwinreg-20190122/debian/changelog dfwinreg-20190122/debian/changelog
--- dfwinreg-20190122/debian/changelog	2019-01-23 04:45:44.0 -0500
+++ dfwinreg-20190122/debian/changelog	2019-12-30 01:37:16.0 -0500
@@ -1,3 +1,10 @@
+dfwinreg (20190122-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #943012, #936389
+
+ -- Sandro Tosi   Mon, 30 Dec 2019 01:37:16 -0500
+
 dfwinreg (20190122-1) unstable; urgency=medium
 
   * New upstream version 20190122
diff -Nru dfwinreg-20190122/debian/control dfwinreg-20190122/debian/control
--- dfwinreg-20190122/debian/control	2019-01-23 04:45:15.0 -0500
+++ dfwinreg-20190122/debian/control	2019-12-30 01:36:58.0 -0500
@@ -4,37 +4,19 @@
 Maintainer: Debian Security Tools 
 Uploaders: Hilko Bengen 
 Build-Depends: debhelper (>= 12), dh-python,
- python-dtfabric (>= 20170524), python3-dtfabric (>= 20170524),
- python, python3,
- python-setuptools, python3-setuptools,
- python-dfdatetime (>= 20160814), python3-dfdatetime (>= 20160814),
- python-libregf (>=20150315), python3-libregf (>=20150315),
- python-mock, python3-mock,
- python-six (>= 1.1.0), python3-six (>= 1.1.0),
- python-yaml (>= 3.10),  python3-yaml (>= 3.10),
+ python3-dtfabric (>= 20170524),
+ python3-all,
+ python3-setuptools,
+ python3-dfdatetime (>= 20160814),
+ python3-libregf (>=20150315),
+ python3-mock,
+ python3-six (>= 1.1.0),
+ python3-yaml (>= 3.10),
 Standards-Version: 4.3.0
 Homepage: https://github.com/log2timeline/dfwinreg
 Vcs-Git: https://salsa.debian.org/pkg-security-team/dfwinreg.git
 Vcs-Browser: https://salsa.debian.org/pkg-security-team/dfwinreg
 
-Package: python-dfwinreg
-Architecture: all
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends},
- python-dtfabric (>= 20170524),
- python-dfdatetime (>= 20160814),
- python-libregf (>=20150315),
- python-mock,
- python-six (>= 1.1.0),
- python-yaml (>= 3.10)
-Description: Digital Forensics Windows Registry library for Python 2
- dfWinReg, or Digital Forensics Windows Registry, provides read-only
- access to Windows Registry objects. The goal of dfWinReg is to
- provide a generic interface for accessing Windows Registry objects
- that resembles the Registry key hierarchy as seen on a live Windows
- system.
- .
- This package contains the library for Python 2.
-
 Package: python3-dfwinreg
 Architecture: all
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends},
diff -Nru dfwinreg-20190122/debian/rules dfwinreg-20190122/debian/rules
--- dfwinreg-20190122/debian/rules	2019-01-14 04:46:40.0 -0500
+++ dfwinreg-20190122/debian/rules	2019-12-30 01:37:11.0 -0500
@@ -7,19 +7,16 @@
 export PYBUILD_NAME:=dfwinreg
 
 %:
-	dh $@ --with=python2,python3 --buildsystem=pybuild
+	dh $@ --with=python3 --buildsystem=pybuild
 
 override_dh_install:
 	dh_install
 	mv debian/python3-dfwinreg/usr/share/doc/dfwinreg \
 	   debian/python3-dfwinreg/usr/share/doc/python3-dfwinreg
-	mv debian/python-dfwinreg/usr/share/doc/dfwinreg \
-	   debian/python-dfwinreg/usr/share/doc/python-dfwinreg
 	find ./debian -name "LICENSE" -delete
 
 override_dh_auto_test:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-	python run_tests.py
 	python3 run_tests.py
 endif
 

Bug#945193: O: libvigraimpex -- C++ computer vision library

[Andreas Metzler]

On 2019-11-21 Daniel Stender  wrote:
> Package: wnpp
> Severity: normal

> I'm orphaning this package due to retirement.

Hello,

I intend to keep this in shape to the best I can do with QA uploads. I
will not properly adopt since my C++ foo is weak.

Repo is currently available on
https://salsa.debian.org/ametzler/libvigraimpex

cu Andreas

Bug#947717: pbcopper FTBFS on all architectures except x32

[Andreas Tille]

On Sun, Dec 29, 2019 at 07:00:54PM +0100, Michael Crusoe wrote:
> pbcopper's latest release has slipped in a code copy of libssw which uses
> x86 SIMD intrinsics. I've pushed up a fix along the lines I made to libssw
> to enable cross architecture compilation at
> https://salsa.debian.org/med-team/pbcopper/commit/f9678ed29590b57fe30638eed3d6819577b4ace1
> and it awaits sponsorship

Thanks a lot for the fix that is sponsored.  However, for s390[1]
there seems to be a timout problem:

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
cd build && meson test --no-rebuild --print-errorlogs
1/2 pbcopper formatting check   OK   0.01 s 
2/2 pbcopper gtest unittestsTIMEOUT 33.17 s 

Ok:1
Expected Fail: 0
Fail:  0
Unexpected Pass:   0
Skipped:   0
Timeout:   1


The output from the failed tests:

2/2 pbcopper gtest unittestsTIMEOUT 33.17 s 

--- command ---
VERBOSE='1' ARGS='-V' /<>/build/tests/pbcopper_test 
--gtest_output=xml:/<>/build/pbcopper-gtest-unittests.xml
--- stdout ---
Running main() from 
/build/googletest-b6wiRD/googletest-1.9.0.20190831/googletest/src/gtest_main.cc
[==] Running 355 tests from 53 test suites.
[--] Global test environment set-up.
[--] 6 tests from CLI_Runner
[ RUN  ] CLI_Runner.emits_tool_contract_when_requested_from_command_line
[   OK ] CLI_Runner.emits_tool_contract_when_requested_from_command_line (0 
ms)
[ RUN  ] CLI_Runner.runs_application_from_vector_of_args
[   OK ] CLI_Runner.runs_application_from_vector_of_args (0 ms)
[ RUN  ] CLI_Runner.runs_application_from_C_style_args
[   OK ] CLI_Runner.runs_application_from_C_style_args (0 ms)
[ RUN  ] CLI_Runner.can_retrieve_input_commandline
[   OK ] CLI_Runner.can_retrieve_input_commandline (1 ms)
[ RUN  ] CLI_Runner.runs_application_from_resolved_tool_contract
[   OK ] CLI_Runner.runs_application_from_resolved_tool_contract (0 ms)
[ RUN  ] CLI_Runner.throws_on_invalid_choices
[   OK ] CLI_Runner.throws_on_invalid_choices (0 ms)
[--] 6 tests from CLI_Runner (1 ms total)

[--] 5 tests from Align_PairwiseAlignment
[ RUN  ] 
Align_PairwiseAlignment.calculates_metrics_from_input_aligned_sequences
[   OK ] 
Align_PairwiseAlignment.calculates_metrics_from_input_aligned_sequences (0 ms)
[ RUN  ] Align_PairwiseAlignment.can_generate_basic_global_alignments
[   OK ] Align_PairwiseAlignment.can_generate_basic_global_alignments (0 ms)
[ RUN  ] 
Align_PairwiseAlignment.maps_target_to_query_positions_from_transcript
[   OK ] 
Align_PairwiseAlignment.maps_target_to_query_positions_from_transcript (0 ms)
[ RUN  ] Align_PairwiseAlignment.check_justify_internals
[   OK ] Align_PairwiseAlignment.check_justify_internals (0 ms)
[ RUN  ] Align_PairwiseAlignment.can_left_and_right_justify_alignments
[   OK ] Align_PairwiseAlignment.can_left_and_right_justify_alignments (0 
ms)
[--] 5 tests from Align_PairwiseAlignment (0 ms total)

[--] 3 tests from Align_AffineAlignment
[ RUN  ] Align_AffineAlignment.can_generate_basic_affine_alignments
[   OK ] Align_AffineAlignment.can_generate_basic_affine_alignments (0 ms)
[ RUN  ] Align_AffineAlignment.correctly_aligns_large_insertion
[   OK ] Align_AffineAlignment.correctly_aligns_large_insertion (10 ms)
[ RUN  ] Align_AffineAlignment.can_generate_IUPAC_aware_alignments
[   OK ] Align_AffineAlignment.can_generate_IUPAC_aware_alignments (0 ms)
[--] 3 tests from Align_AffineAlignment (10 ms total)

[--] 1 test from Align_LinearAlignment
[ RUN  ] Align_LinearAlignment.can_generate_basic_linear_alignments
[   OK ] Align_LinearAlignment.can_generate_basic_linear_alignments (2 ms)
[--] 1 test from Align_LinearAlignment (2 ms total)

[--] 1 test from Align_LocalAlignment
[ RUN  ] Align_LocalAlignment.can_generate_basic_local_alignments
---

Full log written to /<>/build/meson-logs/testlog.txt
make[1]: *** [debian/rules:15: override_dh_auto_test] Error 1


Kind regards

  Andreas.


[1] 
https://buildd.debian.org/status/fetch.php?pkg=pbcopper&arch=s390x&ver=1.3.0%2Bdfsg-2&stamp=1577654596&raw=0

-- 
http://fam-tille.de

Bug#907123: ceph 14.2.4 in unstable

[Milan Kupcevic]

On 2019-12-27 16:14, Thomas Goirand wrote:
> On 12/26/19 1:49 AM, Bernd Zeimetz wrote:
>> Hi Milan,
>>
>> I gave you access to the salsa team as requested.


Sounds good.


>>
>> Please coordinate what you want to work on with Thomas (zigo@d.o) and me.
>>
>> Right now things like arch-all and various architectures do not build at
>> all.. I think we might even need to drop some as they just don't have
>> enough memory for whatever gcc/g++ is doing there.
>>
>> Bernd
> 
> Hi Bernd,
> 
> Thanks a lot for your work.
> 
> I'd be IMO fine if we drop armel, armhf and mipsel, for the server side
> of things. I don't see how one could reliable setup a cluster with this
> type of CPUs in production anyway.
> 


I've seen BeagleBone Black and Raspberry Pi mini cluster setups used in
classroom environment for educational purposes. We should provide them,
if possible.

As for failing builds on arm architectures it probably does not make
sense to push for ARM NEON on armel as it targets hardware with no float
acceleration. Debian's target on armel is --with-arch=armv5te
--with-float=soft.

On the other hand the armhf arch on Debian is specifically targeting
hardware with float acceleration. Default target is --with-arch=armv7-a
--with-fpu=vfpv3-d16 --with-float=hard. NEON is more likely to be
available on this one.

NEON is safely available on arm64, aarch64-linux-gnu

See https://en.wikipedia.org/wiki/ARM_architecture#Advanced_SIMD_(NEON)
for more info.


Milan



signature.asc
Description: OpenPGP digital signature

Bug#947452: RFS: kworkflow/20191112-1 [ITP] -- Inglorious kernel developer workflow scripts

[Adam Borowski]

On Sun, Dec 29, 2019 at 01:04:51AM -0300, Rodrigo Carvalho wrote:
> Thanks for the tip. I uploaded a new version. I hope now it works fine.

It passes the tests, yeah.

However, there's a problem in debian/copyright.  Alas, even an obvious typo
is unlikely to pass through NEW:

License:   GLP-2+
 This file is used for codestyle checking.

This wasn't spotted by automated checkers because it defines a new license
"GLP-2+" whose full text is "This file is used for codestyle checking.".
Beside the obvious, you'd need to mark that line as "Comment: ".


I haven't yet analyzed the rest in-depth.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#944350: RE: Bug#944350: RE: [External] Bug#944350: systemd: screen remains off after waking up from suspend

[Jiri Kanicky]

Hi Mark.

I updated kernel to 5.4.0-1 and the issue is resolved. Thank you for 
your help. You were right :). Thx



Jiri

Linux superman 5.4.0-1-amd64 #1 SMP Debian 5.4.6-1 (2019-12-27) x86_64 
GNU/Linux



On Fri, 6 Dec 2019 18:47:05 + Mark Pearson  wrote:

> Hi Jiri,
>
> I'm pretty sure it's not in 5.3.0-2. Are you sure? I can look again 
but I recently did put in a merge request to get it pulled into sid: 
https://salsa.debian.org/kernel-team/linux/merge_requests/188

>
> Not sure if/when it will be accepted (it's only my 2nd attempt at 
doing this) but hopefully someone looks at it and thinks it's useful)

>
> Mark
>
> > -Original Message-
> > From: Jiri Kanicky 
> > Sent: Saturday, November 30, 2019 6:56 AM
> > To: 944...@bugs.debian.org
> > Subject: Bug#944350: RE: [External] Bug#944350: systemd: screen 
remains

> > off after waking up from suspend
> >
> > Hi.
> >
> > It seems that Debian 5.3.0-2-amd64 includes the code in the patch
> > already and I still have the issue.
> >
> > Jiri
> >
> > On Mon, 25 Nov 2019 16:45:55 + Mark Pearson
> >  wrote:
> >
> > > Hi,
> > >
> > > I don't know if this is helpful but I recently debugged a similar
> > issue on the Lenovo P1Gen2. There the problem is only with the
> > integrated graphics and an OLED screen - we tracked it down to an 
issue

> > in the i915 driver where it wasn't giving enough time for eDP link
> > training. It turned out this was due to the driver using the wrong
> > clocks after a suspend and resume .
> > >
> > > Intel recently up-streamed a fix (commit 2f216a85 - it went into
> > 5.4-rc8)
> > >
> > > I'm working on doing a patch that I'm hoping to get into Debian to
> > backport - just not done yet :) The patch is pretty small (I've 
attached

> > it) so you might want to give it a go and see if it helps.
> > >
> > > Note - we did also test X1 extreme with OLED panel and didn't see a
> > problem therebut it's a really subtle timing issue so some units
> > might be more susceptible than others. Maybe worth a go?
> > >
> > > If it does make a difference let me know.
> > > Mark
> > >
>

Bug#947254: tightvnc 1.3.9-9+deb10u1 flagged for acceptance

[Adam D. Barratt]

On Mon, 2019-12-30 at 00:06 +0100, Salvatore Bonaccorso wrote:
> Hi Adam,
> 
> On Sun, Dec 29, 2019 at 11:43:48AM +, Adam D Barratt wrote:
> > package release.debian.org
> > tags 947254 = buster pending
> > thanks
> > 
> > Hi,
> > 
> > The upload referenced by this bug report has been flagged for
> > acceptance into the proposed-updates queue for Debian buster.
> > 
> > Thanks for your contribution!
> > 
> > Upload details
> > ==
> > 
> > Package: tightvnc
> > Version: 1.3.9-9+deb10u1
> > 
> > Explanation: security fixes [CVE-2014-6053 CVE-2018-20020 CVE-2018-
> > 20021 CVE-2018-20022 CVE-2018-20748 CVE-2018-7225 CVE-2019-15678
> > CVE-2019-15679 CVE-2019-15680 CVE-2019-15681]
> 
> CVE-2018-20020 should actually be CVE-2019-8287 for tightvnc, might
> be worth fixing for the announcement text.

Fixed the comment files for both buster and stretch; thanks.

Regards,

Adam

Bug#937267: Is there any Python3 version of pebl

[Abhik Shah]

I haven’t made a py3 port and actually haven’t worked on Pebl in years.
There are some forks though (on github) and they may have py3 versions.



On Sun, Dec 29, 2019 at 5:38 AM Andreas Tille  wrote:

> Control: tags -1 upstream
> Control: forwarded -1 abhiks...@gmail.com
>
> Hi,
>
> Python2 is End Or Life at 1.1.2020 and Debian is about to remove
> all Python2 dependencies.  I wonder if there is any Python2 port
> of Pebl.  I just found
>
>https://pypi.org/project/pebl/
>
> which is at version 1.01 while it seems that at googlecode once
> was a version 1.0.2 - at least the Debian package is at this
> version.  Could you please clarify whether there is some Python3
> version of pebl somewhere else?
>
> Kind regards
>
>  Andreas.
>
> --
> http://fam-tille.de
>

Bug#947756: ripit: Unescaped left brace in regex will be fatal in Perl 5.32

[Roman Czyborra]

Package: libmp3-tag-perl
Version: 1.13-1.1
Severity: important

dear ianb,

please upgrade debian's libmp3-tag-perl to version 1.14 for ripit to stay 
functional giving file:/usr/share/perl5/MP3/Tag.pm its needed 3 line changes:

(debian) ripit
Unescaped left brace in regex is deprecated here (and will be fatal in Perl 
5.32), passed through in regex; marked by <-- HERE in m/^\??({ <-- HERE 
([^{}]+)}|.)/ at /usr/share/perl5/MP3/Tag.pm line 2944.
Unescaped left brace in regex is deprecated here (and will be fatal in Perl 
5.32), passed through in regex; marked by <-- HERE in m/^({ <-- HERE 
[^{}]+}|\w)/ at /usr/share/perl5/MP3/Tag.pm line 2956.
Use of uninitialized value $ENV{"LANG"} in string at /usr/bin/ripit line 359.



RipIT version 4.0.0-beta20140508.



Process summary:

Playlist (m3u) file will be written.


Please insert an audio CD!



-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 3.18.0-19838-gc647e70c954a (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages ripit depends on:
ii  cdparanoia  3.10.2+debian-13
ii  ffmpeg  7:4.1.4-1~deb10u1
ii  flac1.3.2-3
ii  lame3.100-2+b1
ii  libcddb-get-perl2.28-2
ii  libdigest-md5-file-perl 0.08-1
ii  libmime-base64-urlsafe-perl 0.01-2
ii  libmp3-tag-perl 1.13-1.1
ii  libmusicbrainz-discid-perl  0.04-1+b1
ii  libtext-unidecode-perl  1.30-1
ii  libunicode-utf8-perl0.62-1
ii  libwebservice-musicbrainz-perl  1.0.4-2
ii  libwww-perl 6.36-2
ii  libxml-simple-perl  2.25-1
ii  normalize-audio 0.7.7-15
ii  perl5.28.1-6
ii  vorbis-tools1.4.0-11

Versions of packages ripit recommends:
ii  exim4  4.92-8+deb10u3
ii  exim4-daemon-light [mail-transport-agent]  4.92-8+deb10u3

Versions of packages ripit suggests:
ii  eject  2.1.5+deb1+cvs20081104-13.2
pn  id3
pn  id3v2  

-- no debconf information

Bug#947755: sbuild: force-orig-source with source-only-changes does not add .orig.tar to source.changes

[Vagrant Cascadian]

Control: retitle 947755 sbuild: force-orig-source with source-only-changes does 
not add .orig.tar to source.changes

On 2019-12-29, Vagrant Cascadian wrote:
> Package: sbuild
> Version: 0.78.1-2
> Severity: normal
>
> When I run:
>
>   sbuild -d UNRELEASED -c sid  --source --force-orig-source 
> --source-only-changes hello_2.10-2.dsc
>
> Results in an hello_2.10-2_amd64.changes that contains references to the
> .orig.tar but hello_2.10-2_source.changes that does not, which is pretty
> counterintuitive to me at least. :)
>
> I believe my /etc/sbuild/sbuild.conf has no changes from the default,
> and I moved aside my ~/.sbuildrc.
>
> Thanks for maintaining sbuild!
>
> live well,
>   vagrant
>
> -- System Information:
> Debian Release: 10.2
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable'), (12, 'unstable'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: armhf, arm64
>
> Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages sbuild depends on:
> ii  adduser 3.118
> ii  libsbuild-perl  0.78.1-2
> ii  perl5.28.1-6
>
> Versions of packages sbuild recommends:
> ii  autopkgtest  5.10
> ii  debootstrap  1.0.114
> ii  schroot  1.6.10-6+b1
>
> Versions of packages sbuild suggests:
> pn  deborphan  
> ii  e2fsprogs  1.44.5-1+deb10u2
> ii  kmod   26-1
> ii  wget   1.20.1-1.1
>
> -- no debconf information


signature.asc
Description: PGP signature

Bug#947716: RFH: terminator -- multiple GNOME terminals in one window

[Lucas Nussbaum]

Hi Markus,

On 29/12/19 at 13:59 +0100, Markus Frosch wrote:
> I request assistance with maintaining the terminator package. [1]
> 
> The upstream seems pretty much dead, though I'd like the keep the
> package available. Popcon [2] is not too bad, and I think usage on
> Ubuntu is also pretty stable (I know a lot of people).

I'm a happy user of terminator, and I'm surprised to learn that it's
dead upstream. What do people use instead?

(I'm unlikely to have time to help, unfortunately)

Lucas

Bug#947356: Kernel install warnings

[積丹尼 Dan Jacobson]

Kernel install warns
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module 
r8169

Bug#947755: sbuild: force-source-changes only adds .orig.tar.* to ARCH.changes, not source.changes

[Vagrant Cascadian]

Package: sbuild
Version: 0.78.1-2
Severity: normal

When I run:

  sbuild -d UNRELEASED -c sid  --source --force-orig-source 
--source-only-changes hello_2.10-2.dsc

Results in an hello_2.10-2_amd64.changes that contains references to the
.orig.tar but hello_2.10-2_source.changes that does not, which is pretty
counterintuitive to me at least. :)

I believe my /etc/sbuild/sbuild.conf has no changes from the default,
and I moved aside my ~/.sbuildrc.

Thanks for maintaining sbuild!

live well,
  vagrant

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (12, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, arm64

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

Versions of packages sbuild depends on:
ii  adduser 3.118
ii  libsbuild-perl  0.78.1-2
ii  perl5.28.1-6

Versions of packages sbuild recommends:
ii  autopkgtest  5.10
ii  debootstrap  1.0.114
ii  schroot  1.6.10-6+b1

Versions of packages sbuild suggests:
pn  deborphan  
ii  e2fsprogs  1.44.5-1+deb10u2
ii  kmod   26-1
ii  wget   1.20.1-1.1

-- no debconf information


signature.asc
Description: PGP signature

Bug#947754: [omv.dynamicpuzzle.ro] gitlab mattermost integration error

[Dragos Jarca]

Package: gitlab
Version: 12.4.6-1
Severity: normal

Dear Maintainer,

I try to integrate mattermost Version: 5.18.0 with gitlab using bundled plugins.
Followed instructions from mattermost and gitlab.

When I try to /gitlab connect and Click here to link your GitLab account I have:
- no errors in mattermost console with debuug activated.
- have 500 Whoops, something went wrong on our end in gitlab windows opened by 
mattermost
and gitlab in log says:

NoMethodError (undefined method `mapping' for Doorkeeper::Rails::Routes:Class):

lib/gitlab/request_profiler/middleware.rb:17:in call'
lib/gitlab/middleware/go.rb:20:incall'
lib/gitlab/etag_caching/middleware.rb:13:in call'
lib/gitlab/middleware/correlation_id.rb:16:inblock in call'
lib/gitlab/middleware/correlation_id.rb:15:in call'
lib/gitlab/middleware/multipart.rb:117:incall'
lib/gitlab/middleware/read_only/controller.rb:48:in call'
lib/gitlab/middleware/read_only.rb:18:incall'
lib/gitlab/middleware/basic_health_check.rb:25:in call'
lib/gitlab/request_context.rb:32:incall'
lib/gitlab/metrics/requests_rack_middleware.rb:49:in call'
lib/gitlab/middleware/release_env.rb:12:incall'

I think that ruby-doorkeeper and/or ruby-doorkeeper-openid-connect can be the 
problem.

Thx

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental'), (500, 
'oldstable')
Architecture: amd64 (x86_64)

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

Versions of packages gitlab depends on:
ii  asciidoctor 2.0.10-2
ii  bc  1.07.1-2+b2
ii  bundler 1.17.3-3
ii  bzip2   1.0.8-2
ii  dbconfig-pgsql  2.0.13
ii  debconf [debconf-2.0]   1.5.73
ii  gitlab-common   12.4.6-1
ii  gitlab-workhorse8.16.0+debian-1
ii  libjs-bootstrap4 [node-bootstrap]   4.4.1+dfsg1-1
ii  libjs-pdf   1.5.188+dfsg-1
ii  libjs-popper.js [node-popper.js]1.16.0+ds2-1
ii  libjs-uglify2.8.29-6
ii  lsb-base11.1.0
ii  nginx   1.16.1-2
ii  nginx-extras [nginx]1.16.1-2
ii  node-autosize   4.0.2~dfsg1-3
ii  node-axios  0.19.0+dfsg-2
ii  node-brace-expansion1.1.8-1
ii  node-cache-loader   2.0.1-2
ii  node-chart.js   2.9.3+dfsg-2
ii  node-core-js2.4.1-2
ii  node-css-loader 1.0.1-1
ii  node-d3 5.12.0-1
ii  node-d3-array   1.2.4-2
ii  node-d3-axis1.0.12-2
ii  node-d3-brush   1.1.5-1
ii  node-d3-ease1.0.5-2
ii  node-d3-scale   2.2.2-1
ii  node-d3-selection   1.4.0-5
ii  node-d3-shape   1.3.5-2
ii  node-d3-time1.0.11-3
ii  node-d3-time-format 2.1.3-2
ii  node-d3-transition  1.2.0-4
ii  node-dateformat 3.0.0-1
ii  node-exports-loader 0.7.0-2
ii  node-file-loader3.0.1-1
ii  node-fuzzaldrin-plus0.5.0+dfsg-3
ii  node-glob   7.1.6-1
ii  node-imports-loader 0.8.0-2
ii  node-jed1.1.1-1
ii  node-jquery 3.4.0+dfsg-1
ii  node-jquery-ujs 1.2.2-2
ii  node-jquery.waitforimages   2.4.0+ds-1
ii  node-js-cookie  2.2.1-1
ii  node-jszip  3.2.2+dfsg-1
ii  node-jszip-utils0.0.2+dfsg-1
ii  node-mou

Bug#947752: RFS: scanbd/1.5.1-5 [QA] [RC] -- Scanner button daemon

[Sudip Mukherjee]

Thanks for reviewing it.

On Mon, Dec 30, 2019 at 01:02:59AM +0100, Adam Borowski wrote:
> On Sun, Dec 29, 2019 at 11:27:18PM +, Sudip Mukherjee wrote:
> >  * Package name: scanbd
> >Version : 1.5.1-5
> 
> > Changes since the last upload:
> > 
> >[ Sudip Mukherjee ]
> >* QA upload.
> >* Fix ftbfs with GCC-9. (Closes: #925822)
> >* Update Standards-Version to 4.4.1
> >* Update compat level to 12
> >* Add Pre-Depends to d/control
> >  .
> >[ Ondřej Nový ]
> >* d/copyright: Change Format URL to correct one
> >* d/watch: Use https protocol
> 
> I'm afraid the patch for strncpy() is invalid.
> 
> While strncpy() is never the right function to use for C strings (it's
> always either insecure or at least inefficient), memcpy() from a
> dynamic-sized user controllable string to a fixed-size buffer isn't right
> either.

I have now uploaded new version and its now back to strncpy but will
always have a null terminated string. Can you please take a look when
you get some time..

--
Regards
Sudip

Bug#929024: [RPKI] Bug#929024: ITP: routinator -- An RPKI Validator

[Marco d'Itri]

On Dec 29, Marco d'Itri via RPKI  wrote:

> Building a real package will still require a few more crates to be 
Right now I am stuck on rpki depending on a very old version of ring.
The verification API has changed since then and I do not know enough 
Rust to update rpki.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#947753: RFS: coinor-cgl/0.60.2+repack1-1 [QA ]-- COIN-OR Cut Generation Library

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "coinor-cgl"

 * Package name: coinor-cgl
   Version : 0.60.2+repack1-1
   Upstream Author : [fill in name and email of upstream]
 * URL : https://projects.coin-or.org/Cgl
 * License : EPL-1
 * Vcs : https://salsa.debian.org/science-team/coinor-cgl
   Section : science

It builds those binary packages:

  coinor-libcgl1 - COIN-OR Cut Generation Library
  coinor-libcgl-dev - COIN-OR Cut Generation Library (developer files)
  coinor-libcgl-doc - COIN-OR Cut Generation Library (documentation)

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


  https://mentors.debian.net/package/coinor-cgl

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/coinor-cgl/coinor-cgl_0.60.2+repack1-1.dsc


Changes since the last upload:

   * QA upload
   [ Debian Janitor ]
   * Drop use of autotools-dev debhelper.
   * Update standards version to 4.4.1, no changes needed.
   * Set upstream metadata fields: Bug-Submit.
   * Use secure URI in debian/watch.
 .
   [ Håvard Flaget Aasen ]
   * New upstream version 0.60.2+repack1
   * Change to debhelper-compat
   * Dependencies in debian control.
 - Change from doxygen-latex to doxygen
 - Remove autotools-dev
 - Update version for build- and runtime-dependencies
   * Update debian/watch
 - Add repack suffix
 - Bump to version 4
   * Create debian/coinor-libcgl-doc.links to link duplicated files
   * Use source created jquery.js in *.doc package
   * Remove debian/tmp/usr/share/coin from coinor-libcgl-dev.install
   * Create autopkgtest.


Tested on amd64, i386, arm64 and s390x

Regards,
Håvard

Bug#941947: RFS: misspell-fixer/0.1-1 [ITP] -- Tool for fixing common misspellings, typos in source code

[Adam Borowski]

On Mon, Dec 30, 2019 at 12:00:31AM +, Lajos Veres wrote:
> I have just uploaded a newer version:
> https://mentors.debian.net/package/misspell-fixer
> https://mentors.debian.net/debian/pool/main/m/misspell-fixer/misspell-fixer_0.2-1.dsc

Hi!
While the only change I disagree with is removal of Vcs-Browser, the
changelog really should contain something other than:
 * Debian packaging tweaks.

That line could cover anything but "New upstream release"...

Could you please mention what actually got changed?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#941783: [Pkg-rust-maintainers] Bug#941783: rustc FTCBFS, problem linking llvm

[Ximin Luo]

Ximin Luo:
> [..]
> 
> Sadly I don't have much time to look into this myself, but if you can find 
> out any clues that are *arm-specific* feel free to add them to this bug 
> report and I can maybe comment further on it.
> 
Although it is weird why it's passing -L/usr/lib/llvm-9/lib.

Can you try deleting the part in src/librustc_llvm/build.rs where it runs 
`llvm-config --ldflags`? Around line 215-236, delete that whole section.

X

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

Bug#947752: RFS: scanbd/1.5.1-5 [QA] [RC] -- Scanner button daemon

[Adam Borowski]

On Sun, Dec 29, 2019 at 11:27:18PM +, Sudip Mukherjee wrote:
>  * Package name: scanbd
>Version : 1.5.1-5

> Changes since the last upload:
> 
>[ Sudip Mukherjee ]
>* QA upload.
>* Fix ftbfs with GCC-9. (Closes: #925822)
>* Update Standards-Version to 4.4.1
>* Update compat level to 12
>* Add Pre-Depends to d/control
>  .
>[ Ondřej Nový ]
>* d/copyright: Change Format URL to correct one
>* d/watch: Use https protocol

I'm afraid the patch for strncpy() is invalid.

While strncpy() is never the right function to use for C strings (it's
always either insecure or at least inefficient), memcpy() from a
dynamic-sized user controllable string to a fixed-size buffer isn't right
either.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#941947: RFS: misspell-fixer/0.1-1 [ITP] -- Tool for fixing common misspellings, typos in source code

[Lajos Veres]

Thanks.
I have just uploaded a newer version:
https://mentors.debian.net/package/misspell-fixer
https://mentors.debian.net/debian/pool/main/m/misspell-fixer/misspell-fixer_0.2-1.dsc

I hope I have not missed anything.

Best regards,
Lajos

On Sun, 29 Dec 2019, Adam Borowski wrote:

> On Sat, Dec 28, 2019 at 10:25:59PM +, Lajos Veres wrote:
> > I have made some small modifications partially to address your
> > recommendation and the excuses listed here: 
> > https://tracker.debian.org/pkg/misspell-fixer
> >
> > - I have removed the mentioned files. 
> > https://github.com/vlajos/misspell-fixer/commit/0aeb0ea73e7ce5b0e3c8500886abc57168c8b78c
> > - Updated the standards-version. 
> > https://github.com/vlajos/misspell-fixer/commit/81d9894d8875913cf0d397c99eb88a04a8d50dca
> > - Added Multi-Arch: foreign. 
> > https://github.com/vlajos/misspell-fixer/commit/4f51acf15f22a2ec58a1c317b4563483f6282aa4
> >
> > But unfortunately most of the remaining excuses are a little unclear for 
> > me...
> > Could you please help me to understand them?
> >
> > > Rejected due to piuparts regression - 
> > > https://piuparts.debian.org/sid/source/m/misspell-fixer.html
> >
> > If I follow the link it says:
> > piuparts-result: failed-testing 0.1-1
> >
> > And when I follow this link as well:
> > https://piuparts.debian.org/sid/state-failed-testing.html#misspell-fixer
>
> It claims, among others, that basically every file on the system has
> disappeared.  That's nonsense.  Looks like that part of the infrastructure
> made a boo-boo.
>
> A package with no preinst/postinst/prerm/postrm can't possibly fail piuparts
> testing -- it carries only static files that are added/removed by dpkg.  You
> have no Replaces that'd allow a file conflict, and your package is a leaf
> one with no bogus symlinks that could possibly redirect something else.
>
> And, it passes piuparts on my box.
>
> > > Migration status for misspell-fixer (- to 0.1-1): BLOCKED: 
> > > Rejected/violates migration policy/introduces a regression
> >
> > Is this one just the end result of the others?
>
> Yeah.
>
> > > Not built on buildd: arch all binaries uploaded by kilobyte, a new 
> > > source-only upload is needed to allow migration
> >
> > This buildd related error message is also not really clear for me. Should
> > I do something differently?
>
> According to new Release Team's rules, only packages built on the official
> infrastructure are allowed to the new release, and the first upload can't
> possibly be.  Until someone implements a better way, every package has to be
> built twice, and arch:all don't currently allow automated rebuilds.
>
> This means, you need to make another upload.
>
> And for this reason I did not wait until nits like the redundant files are
> fixed: that second upload is a good opportunity to fix them.
>
>
> > > > > There are minor issues such as:
> > > > > * unused file debian/misspell-fixer-docs.docs
> > > > > * redundant debian/README.source (Homepage: is a field it two other 
> > > > > files
> > > > >   already)
>
>
> Meow!
>

-- 
Lajos Veres
vla...@gmail.com
07927 460 778

Bug#947752: RFS: scanbd/1.5.1-5 [QA] [RC] -- Scanner button daemon

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: scanbd
   Version : 1.5.1-5
   Upstream Author : Wilhelm Meier 
 * URL : http://scanbd.sf.net/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/scanbd
   Section : misc

It builds those binary packages:

  scanbd - Scanner button daemon

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/scanbd/scanbd_1.5.1-5.dsc

Changes since the last upload:

   [ Sudip Mukherjee ]
   * QA upload.
   * Fix ftbfs with GCC-9. (Closes: #925822)
   * Update Standards-Version to 4.4.1
   * Update compat level to 12
   * Add Pre-Depends to d/control
 .
   [ Ondřej Nový ]
   * d/copyright: Change Format URL to correct one
   * d/watch: Use https protocol


-- 
Regards
Sudip

Bug#947751: gcc/g++: fails to build ceph on armel/armhf/mipsel

[Bernd Zeimetz]

Package: gcc-9
Version: 9.2.1-21
Severity: normal

Hi,

gcc/g++ fails to build ceph on (at least) armel/armhf/mipsel.

virtual memory exhausted: Cannot allocate memory

I've played with various combinations of
--param ggc-min-expand=10 -O1 -g0

but it all did not help.
https://buildd.debian.org/status/fetch.php?pkg=ceph&arch=armel&ver=14.2.4-5&stamp=1577557420&raw=0
for example.

clang(++) seems to do better, but does not support NEON as needed to
build the jerasure code on armel.

But I still think, even with complex code like ceph, a compiler should
behave when it comes to memory usage, at least on those embedded
platforms.


Thanks,

Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#947594: not a bug

[Ximin Luo]

Control: notfound -1 1.39.0+dfsg1-4
Control: close -1

Not a bug, see discussion in #943859.

Please stop creating extra unnecessary paperwork for people (i.e. closing bugs) 
based on blindly running inadequate automated tools.

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

Bug#947593: not a bug

[Ximin Luo]

Control: notfound -1 1.39.0+dfsg1-4
Control: close -1

Not a bug, see discussion in #913572.

Please stop creating extra unnecessary paperwork for people (i.e. closing bugs) 
based on blindly running inadequate automated tools.

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

Bug#862658: Eye of mate not showing images >= 12 megapixel

[Witold Baryluk]

Package: eom
Version: 1.22.2-1
Followup-For: Bug #862658

I can confirm the issue.

I have PNG images 16000x16000 (256 megapixels, input file is about 550MB
on disk with PNG compression) and eom never loads / displays them. I have no
issues opening them in GIMP or Firefox.


Best regards,
Witold


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

Kernel: Linux 5.2.0-3-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages eom depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  eom-common   1.22.2-1
ii  gir1.2-eom-1.0   1.22.2-1
ii  libatk1.0-0  2.34.1-1
ii  libc62.29-3
ii  libcairo21.16.0-4
ii  libexempi8   2.5.1-1
ii  libexif120.6.21-5.1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-1
ii  libgirepository-1.0-11.62.0-2
ii  libgl1   1.1.0-1+b1
ii  libgl1-mesa-glx  19.2.6-1
ii  libglib2.0-0 2.62.3-2
ii  libgtk-3-0   3.24.13-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3+b1
ii  libmate-desktop-2-17 1.22.2-1
ii  libpeas-1.0-01.22.0-4
ii  librsvg2-2   2.46.4-1
ii  librsvg2-common  2.46.4-1
ii  libx11-6 2:1.6.8-1
ii  libxml2  2.9.4+dfsg1-8
ii  mate-desktop-common  1.22.2-1
ii  shared-mime-info 1.10-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

eom recommends no packages.

eom suggests no packages.

-- no debconf information

Bug#923069: eom: please support webp images

[Witold Baryluk]

Package: eom
Version: 1.22.2-1
Followup-For: Bug #923069

Still an issue.

What is interesting, eom does load some webp libraries when opening some
other files:


$ cat /proc/$(pidof eom)/maps | grep -i web
7f6de4e48000-7f6de4e4b000 r--p  07:00 130963 
/usr/lib/x86_64-linux-gnu/libwebp.so.6.0.2
7f6de4e4b000-7f6de4e9c000 r-xp 3000 07:00 130963 
/usr/lib/x86_64-linux-gnu/libwebp.so.6.0.2
7f6de4e9c000-7f6de4eaf000 r--p 00054000 07:00 130963 
/usr/lib/x86_64-linux-gnu/libwebp.so.6.0.2
7f6de4eaf000-7f6de4eb r--p 00066000 07:00 130963 
/usr/lib/x86_64-linux-gnu/libwebp.so.6.0.2
7f6de4eb-7f6de4eb1000 rw-p 00067000 07:00 130963 
/usr/lib/x86_64-linux-gnu/libwebp.so.6.0.2
$

But funnily enough, it doesn't do that when I ask it to open actual webp file.


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

Kernel: Linux 5.2.0-3-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages eom depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  eom-common   1.22.2-1
ii  gir1.2-eom-1.0   1.22.2-1
ii  libatk1.0-0  2.34.1-1
ii  libc62.29-3
ii  libcairo21.16.0-4
ii  libexempi8   2.5.1-1
ii  libexif120.6.21-5.1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-1
ii  libgirepository-1.0-11.62.0-2
ii  libgl1   1.1.0-1+b1
ii  libgl1-mesa-glx  19.2.6-1
ii  libglib2.0-0 2.62.3-2
ii  libgtk-3-0   3.24.13-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3+b1
ii  libmate-desktop-2-17 1.22.2-1
ii  libpeas-1.0-01.22.0-4
ii  librsvg2-2   2.46.4-1
ii  librsvg2-common  2.46.4-1
ii  libx11-6 2:1.6.8-1
ii  libxml2  2.9.4+dfsg1-8
ii  mate-desktop-common  1.22.2-1
ii  shared-mime-info 1.10-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

eom recommends no packages.

eom suggests no packages.

-- no debconf information

Bug#947254: tightvnc 1.3.9-9+deb10u1 flagged for acceptance

[Salvatore Bonaccorso]

Hi Adam,

On Sun, Dec 29, 2019 at 11:43:48AM +, Adam D Barratt wrote:
> package release.debian.org
> tags 947254 = buster pending
> thanks
> 
> Hi,
> 
> The upload referenced by this bug report has been flagged for acceptance into 
> the proposed-updates queue for Debian buster.
> 
> Thanks for your contribution!
> 
> Upload details
> ==
> 
> Package: tightvnc
> Version: 1.3.9-9+deb10u1
> 
> Explanation: security fixes [CVE-2014-6053 CVE-2018-20020 CVE-2018-20021 
> CVE-2018-20022 CVE-2018-20748 CVE-2018-7225 CVE-2019-15678 CVE-2019-15679 
> CVE-2019-15680 CVE-2019-15681]

CVE-2018-20020 should actually be CVE-2019-8287 for tightvnc, might be
worth fixing for the announcement text.

Regards,
Salvatore

Bug#947750: eom: Doesn't render Canon CR2 images

[Witold Baryluk]

Package: eom
Version: 1.22.2-1
Severity: normal

eom does open Canon CR2 files, but they appear blank (transparant).

I made some images with Canon 5D Mk III, and the only thing that eom
shows is Size (5760x3840 pixels), and blank (tranparent) content.

In the view and in Image collection the image content is not displayed.

Clicking Details in the Properties pane doesn't show correct information
either, and shows the last correct image (usually some random JPEG) with
some random metadata from the last correct image, not currently opened file.

There are no errors or warning of any kind on the stdout or stderr during
open.

Interstingly after opening eom, and CR2 file, I see no dcraw or any other
similar raw libraries (libraw) loaded. Only jpeg, png, webp and few
others.

Maybe if the CR2 files are not supported, they should not be displayed in
the Image collection and accepted to be opened?

Best regards,
Witold




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

Kernel: Linux 5.2.0-3-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages eom depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  eom-common   1.22.2-1
ii  gir1.2-eom-1.0   1.22.2-1
ii  libatk1.0-0  2.34.1-1
ii  libc62.29-3
ii  libcairo21.16.0-4
ii  libexempi8   2.5.1-1
ii  libexif120.6.21-5.1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-1
ii  libgirepository-1.0-11.62.0-2
ii  libgl1   1.1.0-1+b1
ii  libgl1-mesa-glx  19.2.6-1
ii  libglib2.0-0 2.62.3-2
ii  libgtk-3-0   3.24.13-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3+b1
ii  libmate-desktop-2-17 1.22.2-1
ii  libpeas-1.0-01.22.0-4
ii  librsvg2-2   2.46.4-1
ii  librsvg2-common  2.46.4-1
ii  libx11-6 2:1.6.8-1
ii  libxml2  2.9.4+dfsg1-8
ii  mate-desktop-common  1.22.2-1
ii  shared-mime-info 1.10-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

eom recommends no packages.

eom suggests no packages.

-- no debconf information

Bug#947749: tipp10 ignores existing setting file, instead resets to its defaults at every start

[Henning Gebhard]

Package: tipp10
Version: 2.1.0-3+b1
Severity: normal

Dear Maintainer,


   * What led up to the situation?

Installing tipp10 with apt, starting tipp10, changing settings and restarting
tipp10.


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

After starting tipp10 for the first time, I have opened its settings dialog and
set the keyboard layout to "Deutschland | NEO Version 2" and the lecture type
to "Deutsch | NEO Version 2". I also disactivated the welcome screen.
I then saved the settings.

   * What was the outcome of this action?

After restarting tipp10, the welcome screen loads up again and all the settings
are back to their defaults.



Some more details:
while testing, I found that tipp10 _does_ in fact honor and remember a custom
path to its db file. All other settings that I tested have been reset after
restarting tipp10. I also noticed that the settings file at "~/.config/Tom
Thielicke IT Solutions/TIPP10.conf" looks weird after saving new settings:
there are two [%General] sections with contradicting values.

FWIW: removing the unwanted General section and/or modifying the settings file
directly does not change anything.


Thank you for your consideration. Please let me know if there is something else
I can check or try.



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

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

Versions of packages tipp10 depends on:
ii  libc62.29-3
ii  libgcc1  1:9.2.1-19
ii  libqt5core5a 5.12.5+dfsg-2
ii  libqt5gui5   5.12.5+dfsg-2
ii  libqt5multimedia55.12.5-1
ii  libqt5printsupport5  5.12.5+dfsg-2
ii  libqt5sql5   5.12.5+dfsg-2
ii  libqt5sql5-sqlite5.12.5+dfsg-2
ii  libqt5widgets5   5.12.5+dfsg-2
ii  libstdc++6   9.2.1-19

tipp10 recommends no packages.

tipp10 suggests no packages.

-- no debconf information

Bug#947748: xorg-server: FTBFS in sid (probably due to newer mesa)

[Samuel Thibault]

Source: xorg-server
Version: 2:1.20.6-1
Severity: serious
Tags: patch
Justification: FTBFS

Hello,

Probably since the upload of the newer mesa, xorg-server now FTBFS,
because it misses dri.pc and x11-xcb.pc. The attached patch fixes this.

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), 
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
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)

-- 
Samuel
"c'est pas nous qui sommes à la rue, c'est la rue qui est à nous"
--- debian/control.original 2019-12-29 23:42:11.163003763 +0100
+++ debian/control  2019-12-29 23:42:28.333138832 +0100
@@ -13,6 +13,7 @@
  xutils-dev (>= 1:7.6+4),
  xfonts-utils (>= 1:7.5+1),
  x11proto-dev (>= 2018.4),
+ libx11-xcb-dev,
  xtrans-dev (>= 1.3.5),
  libxau-dev (>= 1:1.0.5-2),
  libxdmcp-dev (>= 1:0.99.1),
@@ -27,6 +28,7 @@
  libaudit-dev [linux-any],
  libdrm-dev (>= 2.4.89) [!hurd-i386],
  libgl1-mesa-dev (>= 9.2),
+ mesa-common-dev,
  libunwind-dev [amd64 arm64 armel armhf hppa i386 ia64 mips64 mips64el mipsel 
powerpc powerpcspe ppc64 ppc64el sh4],
  libxmuu-dev (>= 1:0.99.1),
  libxext-dev (>= 1:0.99.1),

Bug#941783: rustc FTCBFS, problem linking llvm

[Ximin Luo]

Control: retitle -1 rustc FTCBFS on armel/armhf

Sorry for the early closing, there was a general issue with 1.37 which was 
fixed in 1.38 and that's what I thought your issue was.

Your issue here is arm-specific, cross-compiling is fine for all other arches: 
http://crossqa.debian.net/src/rustc

So I think your diagnosis is incorrect:

> Unfortunately it failed to link llvm, it looks like it was trying to link the 
> amd64 llvm into an armhf binary. 

Generally the stage1 compiler is going to be the build architecture (here, 
amd64 not armhf) because stage1 has to be re-run to build stage2.

Sadly I don't have much time to look into this myself, but if you can find out 
any clues that are *arm-specific* feel free to add them to this bug report and 
I can maybe comment further on it.

X

peter green:
> reopen 941783
> found 941783 1.39.0+dfsg1-4
> thanks
> 
> I have just tested crossbuilding 1.39.0+dfsg1-4 in bullseye, it still fails 
> in the same way.
> 


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

Bug#907123: ceph 14.2.4 in unstable

[Bernd Zeimetz]

On 12/29/19 11:27 PM, Thomas Goirand wrote:
> On 12/28/19 2:23 PM, Bernd Zeimetz wrote:
>> Hi,
>>
>>> I'd be IMO fine if we drop armel, armhf and mipsel, for the server side
>>> of things. I don't see how one could reliable setup a cluster with this
>>> type of CPUs in production anyway.
>>
>> ack.
>>
>>
>>> But IMO, it'd be nice if we could at least keep the client side working.
>>> I'm not sure how to achieve this though, probably this will make the
>>> build a lot more complicated.
>>
>> If you are keen on trying this, go on. I don't have enough spare time to
>> care of it. Might make sense to open an upstream bug report about it,
>> though. Supporting a client-only build should come from them imho, you
>> never know how the build system will change and if it is possible to
>> keep up support for it.
>> Which parts of the client side are you interested in?
>> I could imagine that building cephfs alone is possible.
> 
> I think it'd be nice if we could have at least:
> - cephfs
> - librbd (so that Qemu could be built with it)
> 
> So, more or less, this means all the Package: lib*, no?

I'm building it with clang on those architectures now, seems it does not
need as much memory as gcc. Mightmake sense to file a bug against gcc...



>>> BTW, any idea what dependency is missing in mips64el?
>>
>> https://buildd.debian.org/status/package.php?p=ceph
>> Dependency installability problem for ceph on mips64el:
>> ceph build-depends on missing:
>> - libboost-context-dev:mips64el (>= 1.67.0)
>>
>> (like on various other architectures)
> 
> The buildd status page says it's currently in "building" status for the
> release -6 you've uploaded. So probably this has been solved. Let's see
> then! :)

-5 already built well on mips64el (and showed some more issues on the
-ports arches, I've fixed as many as I could without having to debug
this properly on a porter box.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#907123: ceph 14.2.4 in unstable

[Thomas Goirand]

On 12/28/19 2:23 PM, Bernd Zeimetz wrote:
> Hi,
> 
>> I'd be IMO fine if we drop armel, armhf and mipsel, for the server side
>> of things. I don't see how one could reliable setup a cluster with this
>> type of CPUs in production anyway.
> 
> ack.
> 
> 
>> But IMO, it'd be nice if we could at least keep the client side working.
>> I'm not sure how to achieve this though, probably this will make the
>> build a lot more complicated.
> 
> If you are keen on trying this, go on. I don't have enough spare time to
> care of it. Might make sense to open an upstream bug report about it,
> though. Supporting a client-only build should come from them imho, you
> never know how the build system will change and if it is possible to
> keep up support for it.
> Which parts of the client side are you interested in?
> I could imagine that building cephfs alone is possible.

I think it'd be nice if we could have at least:
- cephfs
- librbd (so that Qemu could be built with it)

So, more or less, this means all the Package: lib*, no?

>> BTW, any idea what dependency is missing in mips64el?
> 
> https://buildd.debian.org/status/package.php?p=ceph
> Dependency installability problem for ceph on mips64el:
> ceph build-depends on missing:
> - libboost-context-dev:mips64el (>= 1.67.0)
> 
> (like on various other architectures)

The buildd status page says it's currently in "building" status for the
release -6 you've uploaded. So probably this has been solved. Let's see
then! :)

Cheers,

Thomas Goirand (zigo)

Bug#945845: buster-pu: package qtwebengine-opensource-src/5.11.3+dfsg-2+deb10u1

[Moritz Mühlenhoff]

On Tue, Dec 03, 2019 at 11:30:44AM +0300, Dmitry Shachnev wrote:
> Dear Release team,
> 
> On Fri, Nov 29, 2019 at 11:10:16PM +0300, Dmitry Shachnev wrote:
> > This update fixes bug #919504 that is also known as #929286, #931860,
> > #933278 and #945147.
> >
> > The debdiff is attached. Please see the header of the added patch for the
> > description of the fix.

FWIW, I ran into a Buster system with the broken print (preview) in Kmail
and can confirm that a build with the proposed patches fixes this issue
for good.

Cheers,
Moritz

Bug#947746: xorg-server: fix build on hurd-any

[Samuel Thibault]

Source: xorg-server
Version: 2:1.20.1-2
Severity: important
Tags: patch

Hello,

Since 2:1.20.1-2 the non-drm builds (on hurd-any) fail, because
the 07_use-modesetting-driver-by-default-on-GeForce.diff patch
unconditionally includes xf86drm.h. I have attached a patch over the
patch, and the resulting updated patch, whichever you prefer to use :)

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), 
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
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)

-- 
Samuel
>   dvips -o $@ $< 
Faut faire gffe de pas te couper avec ton truc, t'as mis des ciseaux ($<)
partout :))
-+- Dom in Guide du linuxien pervers - "J'aime pas les Makefile !" -+-
--- debian/patches/07_use-modesetting-driver-by-default-on-GeForce.diff.orig
2019-12-29 23:14:56.170075293 +0100
+++ debian/patches/07_use-modesetting-driver-by-default-on-GeForce.diff 
2019-12-29 23:15:09.090178045 +0100
@@ -13,11 +13,13 @@
 index 8158c2b62..78d1c947d 100644
 --- a/hw/xfree86/common/xf86pciBus.c
 +++ b/hw/xfree86/common/xf86pciBus.c
-@@ -37,6 +37,7 @@
+@@ -37,6 +37,9 @@
  #include 
  #include 
  #include 
++#if defined(__linux__) || defined(__NetBSD__)
 +#include 
++#endif
  #include "os.h"
  #include "Pci.h"
  #include "xf86.h"
>From aa2f34d80ef3118eae0cce73b610c36cdcb978fe Mon Sep 17 00:00:00 2001
From: Ben Skeggs 
Date: Sat, 22 Apr 2017 02:26:28 +1000
Subject: [PATCH xserver] xfree86: use modesetting driver by default on GeForce
 8 and newer

Signed-off-by: Ben Skeggs 
---
 hw/xfree86/common/xf86pciBus.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/hw/xfree86/common/xf86pciBus.c b/hw/xfree86/common/xf86pciBus.c
index 8158c2b62..78d1c947d 100644
--- a/hw/xfree86/common/xf86pciBus.c
+++ b/hw/xfree86/common/xf86pciBus.c
@@ -37,6 +37,9 @@
 #include 
 #include 
 #include 
+#if defined(__linux__) || defined(__NetBSD__)
+#include 
+#endif
 #include "os.h"
 #include "Pci.h"
 #include "xf86.h"
@@ -1190,6 +1191,25 @@ xf86VideoPtrToDriverList(struct pci_device *dev,
 int idx = 0;
 
 #if defined(__linux__) || defined(__NetBSD__)
+char busid[32];
+int fd;
+
+snprintf(busid, sizeof(busid), "pci:%04x:%02x:%02x.%d",
+ dev->domain, dev->bus, dev->dev, dev->func);
+
+	/* 'modesetting' is preferred for GeForce 8 and newer GPUs */
+fd = drmOpenWithType("nouveau", busid, DRM_NODE_RENDER);
+if (fd >= 0) {
+uint64_t args[] = { 11 /* NOUVEAU_GETPARAM_CHIPSET_ID */, 0 };
+int ret = drmCommandWriteRead(fd, 0 /* DRM_NOUVEAU_GETPARAM */,
+  &args, sizeof(args));
+drmClose(fd);
+if (ret == 0) {
+if (args[1] == 0x050 || args[1] >= 0x80)
+break;
+}
+}
+
 driverList[idx++] = "nouveau";
 #endif
 driverList[idx++] = "nv";
-- 
2.12.2

Bug#947747: stretch-pu: package sssd/1.15.0-3+deb9u1

[Salvatore Bonaccorso]

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

Hi

Attached is the proposed debdiff for an sssd upload for stretch
(originally it was planned to release a DSA for it, but in meanwhile
it has passed enough time that it does not make much sense to release
it via a DSA). It addresses the CVE-2017-12173 (#877885).

The upload was tested not in a production environment tough, but only
by explicitly chekcing the testsuite for the sysdb-tests case (it
needed locally additionall build-depends to actually enable the
tests). The upload done contains as well the testcase (even tough it
will not be tested during build).

Regards,
Salvatore
diff -u sssd-1.15.0/debian/changelog sssd-1.15.0/debian/changelog
--- sssd-1.15.0/debian/changelog
+++ sssd-1.15.0/debian/changelog
@@ -1,3 +1,10 @@
+sssd (1.15.0-3+deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * sysdb: sanitize search filter input (CVE-2017-12173) (Closes: #877885)
+
+ -- Salvatore Bonaccorso   Sun, 29 Dec 2019 14:12:24 +0100
+
 sssd (1.15.0-3) unstable; urgency=medium
 
   * rules, install: Remove responder service and socket files for now, the
diff -u sssd-1.15.0/debian/patches/series sssd-1.15.0/debian/patches/series
--- sssd-1.15.0/debian/patches/series
+++ sssd-1.15.0/debian/patches/series
@@ -1 +1 @@
-#placeholder
+sysdb-sanitize-search-filter-input.patch
only in patch2:
unchanged:
--- sssd-1.15.0.orig/debian/patches/sysdb-sanitize-search-filter-input.patch
+++ sssd-1.15.0/debian/patches/sysdb-sanitize-search-filter-input.patch
@@ -0,0 +1,138 @@
+From: Sumit Bose 
+Date: Thu, 5 Oct 2017 11:07:38 +0200
+Subject: sysdb: sanitize search filter input
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+Origin: https://pagure.io/SSSD/sssd/c/1f2662c8f97c9c0fa250055d4b6750abfc6d0835
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2017-12173
+Bug-Debian: https://bugs.debian.org/877885
+Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1498173
+
+This patch sanitizes the input for sysdb searches by UPN/email, SID and
+UUID.
+
+This security issue was assigned CVE-2017-12173
+
+Reviewed-by: Lukáš Slebodník 
+Reviewed-by: Jakub Hrozek 
+[Salvatore Bonaccorso: Backport to 1.15.0: Adjsust for context changes, adapt
+changes in sysdb_search_object_by_cert as support for multiple results for
+searches by certificates only added in 1.15.2. Changes to search the whole DB
+or only the given domain introduced in 1.15.1 only, adjust testcase]
+---
+ src/db/sysdb_ops.c  | 43 +
+ src/tests/sysdb-tests.c |  7 +++
+ 2 files changed, 42 insertions(+), 8 deletions(-)
+
+--- a/src/db/sysdb_ops.c
 b/src/db/sysdb_ops.c
+@@ -547,6 +547,7 @@ int sysdb_search_user_by_upn_res(TALLOC_
+ int ret;
+ const char *def_attrs[] = { SYSDB_NAME, SYSDB_UPN, SYSDB_CANONICAL_UPN,
+ SYSDB_USER_EMAIL, NULL };
++char *sanitized;
+ 
+ tmp_ctx = talloc_new(NULL);
+ if (tmp_ctx == NULL) {
+@@ -554,6 +555,12 @@ int sysdb_search_user_by_upn_res(TALLOC_
+ goto done;
+ }
+ 
++ret = sss_filter_sanitize(tmp_ctx, upn, &sanitized);
++if (ret != EOK) {
++DEBUG(SSSDBG_OP_FAILURE, "sss_filter_sanitize failed.\n");
++goto done;
++}
++
+ base_dn = sysdb_base_dn(domain->sysdb, tmp_ctx);
+ if (base_dn == NULL) {
+ ret = ENOMEM;
+@@ -562,7 +569,7 @@ int sysdb_search_user_by_upn_res(TALLOC_
+ 
+ ret = ldb_search(domain->sysdb->ldb, tmp_ctx, &res,
+  base_dn, LDB_SCOPE_SUBTREE, attrs ? attrs : def_attrs,
+- SYSDB_PWUPN_FILTER, upn, upn, upn);
++ SYSDB_PWUPN_FILTER, sanitized, sanitized, sanitized);
+ if (ret != EOK) {
+ ret = sysdb_error_to_errno(ret);
+ goto done;
+@@ -4550,16 +4557,30 @@ static errno_t sysdb_search_object_by_st
+const char **attrs,
+struct ldb_result **_res)
+ {
+-char *filter;
++char *filter = NULL;
+ errno_t ret;
++char *sanitized = NULL;
++
++if (str == NULL) {
++return EINVAL;
++}
++
++ret = sss_filter_sanitize(NULL, str, &sanitized);
++if (ret != EOK || sanitized == NULL) {
++DEBUG(SSSDBG_OP_FAILURE, "sss_filter_sanitize failed.\n");
++goto done;
++}
+ 
+-filter = talloc_asprintf(NULL, filter_tmpl, str);
++filter = talloc_asprintf(NULL, filter_tmpl, sanitized);
+ if (filter == NULL) {
+-return ENOMEM;
++ret = ENOMEM;
++goto done;
+ }
+ 
+ ret = sysdb_search_object_attr(mem_ctx, domain, filter, attrs, _res);
+ 
++done:
++talloc_free(sanitized);
+ talloc_free(filter);
+ return ret;
+ }
+@@ -4648,7 +4669,8 @@ errno_t sysdb_search_object_by_cert(TALL
+ struct ldb_result

Bug#930846: partman-auto-lvm: debconf show guided_size during auto install

[Samuel Thibault]

Samuel Thibault, le dim. 29 déc. 2019 22:15:59 +0100, a ecrit:
> Holger Wansing, le dim. 29 déc. 2019 21:59:02 +0100, a ecrit:
> > do you it would be possible for you to do another upload for the 
> > installation-guide some day?
> 
> Ah, sure, I'm on it, then.

Done!

Samuel

Bug#930846: partman-auto-lvm: debconf show guided_size during auto install

[Samuel Thibault]

Holger Wansing, le dim. 29 déc. 2019 21:59:02 +0100, a ecrit:
> do you it would be possible for you to do another upload for the 
> installation-guide some day?

Ah, sure, I'm on it, then.

Samuel

Bug#930846: partman-auto-lvm: debconf show guided_size during auto install

[Holger Wansing]

Hi Samuel,

Holger Wansing  wrote:
> Hi,
> 
> Laura Arjona Reina  wrote:
> > Hi all
> > 
> > El 15/7/19 a las 12:36, Holger Wansing escribió:
> > > Hi,
> > > 
> > > Steve McIntyre  wrote:
> > >> On Sat, Jun 22, 2019 at 01:05:01PM +0200, Baptiste BEAUPLAT wrote:
> > >>> Tags: patch
> > >>>
> > >>> Added patch:
> > >>> https://salsa.debian.org/installer-team/installation-guide/merge_requests/7
> > >>
> > >> Merged, thanks for your contribution!
> > > 
> > > This has been fixed in the installation-guide package, version 20190622
> > > (currently in stable) has the fix.
> > > However, https://www.debian.org/releases/buster/example-preseed.txt
> > > still does not have it.
> > > 
> > > So CC'ing debian-www for assistance
> > > 
> > 
> > I've had a look at the www-master.debian.org
> > I see that the installation guide has been generated on 20190623 but the 
> > example-preseed.txt file has date 20190324.
> > 
> > I guess something went wrong with that file, and since there has not been 
> > changes in the installation guide since then, the build has not been 
> > retried.
> > 
> > In our cron job, I've temporarily removed the part where it checks if we 
> > need to 
> > build or not the guide, to force a rebuild today, and thus have logs to see 
> > what 
> > happens to that file.
> > 
> > I'll have a look later today to the logs and will update the bug.
> 
> Sadly, that did not fix the problem ...


@Samuel,

do you it would be possible for you to do another upload for the 
installation-guide some day?

It's been 6 months since the last upload, there is a big bunch of changings,
and I would like to see, if a new upload triggers to get this bug fixed
(currently, the website still has the old version.)


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#941657: name change: python-lark-parser -> python-lark

[Thomas Andrejak]

Hello

Why changing the name ? it's named lark-parser in pypi.

Moreover, in pypi, there already is a "lark" module which is not lark-parser

Regards

Thomas

Le sam. 28 déc. 2019 à 05:03, Peter Wienemann  a écrit :

> Following the suggestions in
>
> https://bugs.debian.org/945823
>
> I have changed the name from python-lark-parser to python-lark.
>
> The new repository URL is
>
> https://salsa.debian.org/python-team/modules/python-lark
>
> Peter
>
> --
> To unsubscribe, send mail to 941657-unsubscr...@bugs.debian.org.
>

Bug#947745: recent version for stable-(updates|backports)

[Kevin Price]

Package: youtube-dl
Version: 2019.01.17-1.1
Severity: grave

Justification: renders package unusable

Dear maintainer,

the buster version has quit working with yt. The error message is: "YouTube
said: This video is unavailable." 2019.09.28-1 works. Due to the package's
volatility (which causes this grave bug) and given its fairly stable
dependencies, migrating recent versions into stable-updates might well be the
neatest fix to this, imho.

See also #908947.

Cheers
Kevin



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

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

Versions of packages youtube-dl depends on:
ii  python33.7.3-1
ii  python3-pkg-resources  40.8.0-1

Versions of packages youtube-dl recommends:
ii  aria21.34.0-4
ii  ca-certificates  20190110
ii  curl 7.64.0-4
ii  ffmpeg   7:4.1.4-1~deb10u1
ii  mpv  0.29.1-1
ii  phantomjs2.1.1+dfsg-2
ii  python3-pyxattr  0.6.1-1
ii  rtmpdump 2.4+20151223.gitfa8646d.1-2
ii  wget 1.20.1-1.1

youtube-dl suggests no packages.

-- no debconf information

Bug#471537: fixed in lintian 2.42.0

[Emmanuel Bourg]

On 29/12/2019 17:50, Felix Lechner wrote:

> Done with:
> 
> 
> https://salsa.debian.org/lintian/lintian/commit/ca5adad9cb21805b871a9f2e6cdd30b8bdb0246c
> 
> Thanks for helping to make Lintian better.

Thank you for the quick fix!

Emmanuel Bourg

Bug#947242: sphinx-copybutton: incorrect VCS fields in debian/control

[Sandro Tosi]

On Sun, Dec 29, 2019 at 3:09 AM Graham Inggs  wrote:
> Are you planning to upload the new version of sphinx-copybutton soon?

we are waiting for upstream to release a new version: in 0.2.6
upstream no longer shipped the doc/ directory, which the package needs
to create the -doc package. if we remove the commands to build the
documentation, the package will emit a empty-binary-package tag, which
is part of the auto-reject tags
(https://ftp-master.debian.org/static/lintian.tags). the fix is
already merged upstream, we just need them to cut a new release
(proceeding slowly during the holidays period, understandably).

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#947736: ITP: topline -- per-core/NUMA CPU and disk utilization plain-text grapher

[Samuel Thibault]

Adam Borowski, le dim. 29 déc. 2019 22:53:30 +0100, a ecrit:
> On Sun, Dec 29, 2019 at 10:47:15PM +0100, Samuel Thibault wrote:
> > Adam Borowski, le dim. 29 déc. 2019 22:21:01 +0100, a ecrit:
> > > however I have yet
> > > to access any machine with a non-flat NUMA topology:
> > 
> > IIRC you can build whatever you want with qemu with e.g. the sockets
> > parameter of the -smp option
> 
> Well yeah -- my point is, it's not my itch to scratch at the moment,

Ok, I see :)

Samuel

Bug#947736: ITP: topline -- per-core/NUMA CPU and disk utilization plain-text grapher

[Adam Borowski]

On Sun, Dec 29, 2019 at 10:47:15PM +0100, Samuel Thibault wrote:
> Adam Borowski, le dim. 29 déc. 2019 22:21:01 +0100, a ecrit:
> > however I have yet
> > to access any machine with a non-flat NUMA topology:
> 
> IIRC you can build whatever you want with qemu with e.g. the sockets
> parameter of the -smp option

Well yeah -- my point is, it's not my itch to scratch at the moment, thus
I'm waiting to see if anyone else will actually use the tool.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#947736: ITP: topline -- per-core/NUMA CPU and disk utilization plain-text grapher

[Samuel Thibault]

Adam Borowski, le dim. 29 déc. 2019 22:21:01 +0100, a ecrit:
> however I have yet
> to access any machine with a non-flat NUMA topology:

IIRC you can build whatever you want with qemu with e.g. the sockets
parameter of the -smp option

Samuel

Bug#947744: installation-reports: Debian Live Testing LXQt + nonfree - install fails with: "Bad unsquash configuration"

[scott092707]

Package: installation-reports
Severity: grave
Justification: renders package unusable

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Scott Jacobs 
To: Debian Bug Tracking System 
Subject: installation-reports: Debian Live Testing LXQt + nonfree - install 
fails with: "Bad unsquash configuration"
Bcc: Scott Jacobs 
Message-ID: 
<157765450239.2521.4290165524983598064.reportbug@ASUS-PRIME-B350M-A-CSM>
X-Mailer: reportbug 7.5.3
Date: Sun, 29 Dec 2019 16:21:42 -0500
X-Debbugs-Cc: scott092...@aol.com

Dear Maintainer,

Twice, I tried to install the Debian Testing Live LXQt + nonfree .iso, with the
Calamares installer, and twice received the error window with:

"Installation Failed

Bad unsquash configuration
The source filesystem "/run/live/medium/live/filesystem.squashfs" does not
exist"

The .iso s from 12/11/2019 and 12/23/2019 failed exactly the same way.
These came from:
"https://cdimage.debian.org/images/unofficial/non-free/images-including-
firmware/weekly-live-builds/amd64/iso-hybrid/"

My SSD has boot/efi and swap partitions, a /data partition, and 5 20GB
partitions for OS installations.
This is being written from my current Debian Testing LXQt install, which dates
from March of this year, and has been upgraded. (I also sometimes use an old
Lubuntu 17.10 install when I need to scan, as I cannot use my printer/scanner
to scan with Debian, for some reason...)

The install proceeds normally, past the manual install stage (where I mark the
new OS partition for formatting, and keep all others unformatted and labelled
for access from the new install)

Shortly afterwards, the error window appears.

I know the root fs formatting succeeds, at least as far as assigning it a new
UUID - I was unable to boot THIS install until I edited my fstab to comment out
the mount line referring to the old install partition with its old UUID)



-- Package-specific info:

Boot method: USB
Image version: Debian Testing Live LXQt + nonfree .iso  12/11/2019  AND  
12/23/2019
Date: 29, December 2019, ~1pm, ~2pm

Machine: ASUS Prime B350M-A(CSM) + AMD A12e processor and Sapphire Pulse Radeon 
RX560 Graphics Card - 16GB RAM -1TB Crucial MX500 SSD
Partitions: 
scott@ASUS-PRIME-B350M-A-CSM:~$ sudo /sbin/fdisk -l 




   
[sudo] password for scott:  




   
Disk /dev/sda: 931.53 GiB, 1000204886016 bytes, 1953525168 sectors  




   
Disk model: CT1000MX500SSD1 




   
Units: sectors of 1 * 512 = 512 bytes   




   
Sector size (logical/physical): 512 bytes / 4096 bytes  




   
I/O size (minimum/optimal): 4096 bytes / 4096 bytes 

  

Bug#916107: mongodb: MongoDB should not be part of a stable release

[Sandro Tosi]

> I propose to now remove it from unstable, per 
> https://www.mongodb.com/support-policy
> support for 3.4 ends in January 2020.

ive opened #947743 to ask for mongodb removal

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#947742: xorg: Screen corruption on Intel N3050 integrated GPU on x86

[Tomasz Melcer]

Package: xorg
Version: 1:7.7+19
Severity: important

Dear Maintainer,

I have just installed Debian Buster x86 on an Intel NUC5CPYH device
(Intel Celeron N3050 with "Intel HD Graphics for Intel Celeron Processor
N3000 Series", citing ark.intel.com). Installation includes lightdm and
the Mate desktop environment. Under both of them I'm getting screen
corruption: parts of the screen are not refreshed/painted correctly,
often just showing black areas; some parts of the screen are shifted.
Others might display fine. The screen periodically repaints itself with
a different set of corruptions. Rarely, repainting brings the while
image mostly correct, making it possible to see that input is received
correctly.

I've found a question describing a similar problem at [1], suggesting
that this is specific to x86 and doesn't show up on amd64. I'll try that
later.

 [1] http://forums.debian.net/viewtopic.php?f=17&t=143870


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLX_indirect.so.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.2.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.7.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.7.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.0.0 to 
/usr/lib/mesa-diverted/i3

Bug#947743: RM: mongodb -- RoQA; rc-buggy; un-upgreadable due to license issues; not part of stable; preventing some py2rm work

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#945145: O: docbook-dsssl -- modular DocBook DSSSL stylesheets, for print and HTML

[Chris Hofstaedtler]

* Peter Eisentraut  [191229 21:26]:
> I'm not sure if anyone or anything is still using this.

Certainly a few reverse (Build-)Depends:

Checking reverse dependencies...
# Broken Depends:
docbook-utils: docbook-utils
ldp-docbook-stylesheets: ldp-docbook-dsssl
sgmltools-lite: sgmltools-lite

# Broken Build-Depends:
bochs: docbook-dsssl
dictionaries-common: docbook-dsssl
docbook-utils: docbook-dsssl
hugs98: docbook-dsssl
idzebra: docbook-dsssl
installation-guide: docbook-dsssl
kannel: docbook-dsssl
kannel-sqlbox: docbook-dsssl
libdbi: docbook-dsssl
libdbi-drivers: docbook-dsssl
libetpan: docbook-dsssl
libopenusb: docbook-dsssl
libusb: docbook-dsssl
lprng-doc: docbook-dsssl
opensp: docbook-dsssl
pgpool2: docbook-dsssl
privoxy: docbook-dsssl
sgml2x: docbook-dsssl
slony1-2: docbook-dsssl
yaz: docbook-dsssl


While investigating this - knowing nothing about docbook myself -, I
discovered that docbook.org recommends using pandoc instead of the
openjade/xmlto/... zoo. Maybe other maintainers might find this
useful.

Chris

Bug#947736: ITP: topline -- per-core/NUMA CPU and disk utilization plain-text grapher

[Adam Borowski]

On Sun, Dec 29, 2019 at 07:43:54PM +0100, Samuel Thibault wrote:
> Adam Borowski, le dim. 29 déc. 2019 19:06:08 +0100, a ecrit:
> > * URL : https://github.com/kilobyte/topline
> > * License : GPL-2+noA
> >   Programming Lang: C
> >   Description : per-core/NUMA CPU and disk utilization plain-text 
> > grapher
> 
> Nice :)
> 
> You would probably want to use the hwloc library to easily get the
> topology of the machine (numa nodes, sockets, caches, cores) ;)

Sounds interesting.

My tool is simple, and it currently knows about two levels of hierarchy:
NUMA nodes and thread siblings.  It doesn't care about or show memory cache
or tier hierarchy, thus a good part of hwloc data would be irrelevant.
It could be nice to show socket->numa nodes hierarchy, however I have yet
to access any machine with a non-flat NUMA topology:
* servers I know have 2 or 4 sockets, with flat cores->HT on each
* fat AMD desktops (like 2990WX I own) have four chiplets in 1 socket
* HMEM tiering fake nodes have a hierarchy but NVDIMM nodes have no CPUs
* big.LITTLE clusters (like MT6797X 4+4+2) are probably uninteresting

Ie, something for the future, but I'm starting small for now.  I'll see if
there are any users, then see what they want.  And there'll be time to
extend it, for which your pointer to hwloc will be useful.

BTW, I'm not doing this for anything work-related for now, but mostly
because of an idea I came with while messing with zdebootstrap (which I
haven't have tuits to mess with since June :( ).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#947585: FTBFS with scons 3.1.2-1

[Phil Wyett]

Control: tags 947585 + patch

On Sat, 2019-12-28 at 09:32 +0100, Jörg Frings-Fürst wrote:
> Source: xboxdrv
> Version: 0.8.8-1
> Severity: important
> Usertags: scons_ftbfs
> 
> 
> Hello, 
> 
> in the context of the change to Python3 also Scons was revised. With
> the current version 3.1.2-1 from Experimental the changeover is
> finished so far. 
> 
> However, an error occurred while building your package. The build log
> is attached.
> 
> Please check it and fix the error.
> 
> CU
> Jörg
> 

Hi,

Attached is a patch that fixes the build issue.

Regards

Phil

-- 

*** Playing the game for the games sake. ***

Twitter: @kathenasorg

IRC: kathenas

Description: Use python3 print()
Author: Phil Wyett 
Last-Update: 2019-12-29
Bug-Debian: https://bugs.debian.org/947585

--- xboxdrv-0.8.8.orig/SConstruct
+++ xboxdrv-0.8.8/SConstruct
@@ -33,8 +33,8 @@ def build_bin2h(target, source, env):
 def c_escape(str): 
 return str.translate(string.maketrans("/.-", "___"))
 
-print target
-print source
+print (target)
+print (source)
 with open(target[0].get_path(), "w") as fout:
 fout.write("// autogenerated by scons Bin2H builder, do not edit by hand!\n\n")
 
@@ -133,12 +133,12 @@ env.Append(CPPDEFINES = { 'PACKAGE_VERSI
 conf = Configure(env)
 
 if not conf.env['CXX']:
-print "g++ must be installed!"
+print ("g++ must be installed!")
 Exit(1)
 
 # X11 checks
 if not conf.CheckLibWithHeader('X11', 'X11/Xlib.h', 'C++'):
-print 'libx11-dev must be installed!'
+print ('libx11-dev must be installed!')
 Exit(1)
 
 env = conf.Finish()


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

Bug#892548: dhelp_parse still broken

[ael]

I am seeing this bug also: it has been persisting for several months,
but I only just got around to reporting it.

I have librunby2.5, version 2.5.7-1. This is on testing updated most
days.

# /usr/sbin/dhelp_parse -i
index++: error: could not read index from
"/var/lib/dhelp/documents.index": No data available
Dhelp::IndexerError: Couldn't index  using /usr/bin/index++
--config-file /usr/share/dhelp/config/swish++.conf --index-file
/var/lib/dhelp/documents.index --follow-links --incremental -
(/usr/lib/ruby/vendor_ruby/dhelp.rb:616:in `index'
/usr/sbin/dhelp_parse:171:in `do_deferred_indexing'
/usr/sbin/dhelp_parse:205:in `main'
/usr/sbin/dhelp_parse:221:in `')

Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[GCS]

Hi Chris,

On Sun, Dec 29, 2019 at 5:57 PM Chris Lamb  wrote:
> I don't fully understand the ramifications or risks of uploading the
> current Fossil tree I'm afraid so I will have to leave that judgement
> to you. Can you let me know your intention either way so that we don't
> lose this down the cracks and delay Paul's work further? I would not
> want to disable the test and remember to re-enable it again, after all.
 OK, I did some testing and couldn't find any immediate problem. Going
to upload the current Fossil tree soon, then follow what problem may
arise in Debian or in upstream issues.

Regards,
Laszlo/GCS

Bug#947741: systemsettings: changing external display position disables laptop screen

[Gabor Nagy]

Package: systemsettings
Version: 4:5.14.5-1.1
Severity: normal

Dear Maintainer,

I have an HP laptop. I used to have an external monitor connected to my
docking station's DisplayPort. The external monitor is above the laptop
screen, and I have been using it with this setup for more than a year.
That monitor developed a problem and HP has sent me a replacement. Same
model.
When I connected my new external monitor, a number of options got
displayed at the middle of the screen, that allowed me to select one of
the two monitors, unify outputs or to extend the display left or
right. I chose to extend left or right.
When I tried to use systemsettings to adjust the correct position of the
external monitor, the result was that the laptop screen stopped working
reliably. There were a number of different behaviours, for example:
- laptop screen is dark, nothing is displayed
- flashing patterns on laptop screen
- laptop screen appears to be working, but things get extremely slow to
  update and eventually the GUI becomes unresponsive.

I found two ways to overcome this behaviour:
1) switch to console with ctrl-alt-2, log in and kill X or restart (when
GUI is unresponsive)
2) press Fn-F4 on the laptop, which brings up the same quick selector
bar in the middle of the screen. If I select extend display to left or
right, everything is working again.

Note that even if I manually place the external monitor beside the
laptop screen is system settings in a position that seems to be the same
as the default, the same problems will occur. So it appears to me that
it is probably not the actual position that matters but using the manual
positioning is what triggers this behaviour.

At the moment I am using my external screen in a way that it is above my
laptop screen, but I need to move the pointer sideways to travel from
one to the other. I have this situation for 3 months now, and it still
frustrates me.

I would expect that if I chose a position for my screens in
systemsettings, the system will respect that and all my screens remain
functional.

Best regards,
Gabor

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

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

Versions of packages systemsettings depends on:
ii  kio   5.54.1-1
ii  kpackagetool5 5.54.0-1
ii  libc6 2.28-10
ii  libkf5activities5 5.54.0-1
ii  libkf5activitiesstats15.54.0-1
ii  libkf5auth5   5.54.0-2
ii  libkf5completion5 5.54.0-1
ii  libkf5configcore5 5.54.0-1+deb10u1
ii  libkf5configgui5  5.54.0-1+deb10u1
ii  libkf5configwidgets5  5.54.0-1
ii  libkf5coreaddons5 5.54.0-1
ii  libkf5crash5  5.54.0-1
ii  libkf5dbusaddons5 5.54.0-1
ii  libkf5declarative55.54.0-1
ii  libkf5i18n5   5.54.0-1
ii  libkf5iconthemes5 5.54.0-1
ii  libkf5itemviews5  5.54.0-1
ii  libkf5kcmutils5   5.54.0-1
ii  libkf5khtml5  5.54.0-1
ii  libkf5kiowidgets5 5.54.1-1
ii  libkf5package55.54.0-1
ii  libkf5quickaddons55.54.0-1
ii  libkf5service-bin 5.54.0-1
ii  libkf5service55.54.0-1
ii  libkf5widgetsaddons5  5.54.0-1
ii  libkf5windowsystem5   5.54.0-1
ii  libkf5xmlgui5 5.54.0-1
ii  libkworkspace5-5  4:5.14.5.1-1
ii  libqt5core5a  5.11.3+dfsg1-1+deb10u1
ii  libqt5dbus5   5.11.3+dfsg1-1+deb10u1
ii  libqt5gui55.11.3+dfsg1-1+deb10u1
ii  libqt5qml55.11.3-4
ii  libqt5quick5  5.11.3-4
ii  libqt5quickwidgets5   5.11.3-4
ii  libqt5widgets55.11.3+dfsg1-1+deb10u1
ii  libstdc++68.3.0-6
ii  qml-module-org-kde-kcm5.54.0-1
ii  qml-module-org-kde-kirigami2  5.54.0-1
ii  qml-module-qtquick-controls   5.11.3-2
ii  qml-module-qtquick-layouts5.11.3-4
ii  qml-module-qtquick2   5.11.3-4

systemsettings recommends no packages.

systemsettings suggests no packages.

-- no debconf information

Bug#657390: lintian: Non-dh debhelper targets?

[Guillem Jover]

Hi!

On Fri, 2019-12-06 at 16:15:12 -0800, Felix Lechner wrote:
> > Once build-arch and build-indep are supported by dpkg-buildpackage,
> > hopefully in the next week, and/or are required by Policy, please
> > could you apply the attached patch to move build-arch and build-indep
> > from recommended to required?
> 
> With many people now using dh over the older explicit targets [1], is
> this patch still needed?

> [1] According to trends.debian.net, only about 6% of packages use
> debhelper currently.

We discussed this over IRC some weeks ago. I checked the current
numbers derived from the debian-rules-missing-recommended-target tag
and how these get mapped to the different problem types, and here's
the number of sources of what I came up with (which I think is correct
but didn't record a reproducer :/):

  0   building arch-indep + arch-dep binaries (the non-trivial case)
  340 building only arch-dep binaries
  249 building only arch-indep binaries

So we are actually in a way better position than we were some years
ago. As I mentioned there, I don't think those numbers are at a point
where dpkg-source can stop using its fallback code to avoid a FTBFS.
But I guess lintian could make it a non-fatal error already, because
these have been policy violation for a while.

Felix then came up with the great idea of involving Jelmer Vernooij with
Debian Janitor, who was happy to take this on during the coming weeks,
and implemented already initial support for the automatic fix.

Thanks,
Guillem

Bug#947739: RFS: coinor-dylp/1.10.4-2 [QA] [RC] -- Linear programming solver using the dynamic simplex algorithm

[Sudip Mukherjee]

Hi All,
New package uploaded to mentors with updated Vcs.

Vcs : https://salsa.debian.org/debian/coinor-dylp

--
Regards
Sudip

Bug#947587: FTBFS with scons 3.1.2-1

[Phil Wyett]

Control: tags 947587 + patch

On Sat, 2019-12-28 at 09:35 +0100, Jörg Frings-Fürst wrote:
> Source: xsunpinyin
> Version: 2.0.3-5
> Severity: important
> Usertags: scons_ftbfs
> 
> 
> Hello, 
> 
> in the context of the change to Python3 also Scons was revised. With
> the current version 3.1.2-1 from Experimental the changeover is
> finished so far. 
> 
> However, an error occurred while building your package. The build log
> is attached.
> 
> Please check it and fix the error.
> 
> CU
> Jörg
> 

Hi,

Attached is a patch that fixes the build issue.

Regards

Phil

-- 

*** Playing the game for the games sake. ***

Twitter: @kathenasorg

IRC: kathenas

Description: Use python3 print()
Author: Phil Wyett 
Last-Update: 2019-12-29
Bug-Debian: https://bugs.debian.org/947587

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 2019-12-29

Index: xsunpinyin-2.0.3/SConstruct
===
--- xsunpinyin-2.0.3.orig/SConstruct
+++ xsunpinyin-2.0.3/SConstruct
@@ -47,7 +47,7 @@ opts.Add('PREFIX', default='/usr/local')
 def PassVariables(envvar, env):
 for (x, y) in envvar:
 if x in os.environ:
-print 'Warning: you\'ve set %s in the environmental variable!' % x
+print ('Warning: you\'ve set %s in the environmental variable!' % x)
 env.MergeFlags(os.environ[x])
 
 env = Environment(ENV=os.environ,


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

Bug#947587: FTBFS with scons 3.1.2-1

[Phil Wyett]

On Sun, 2019-12-29 at 20:29 +, Phil Wyett wrote:
> Control: tags 947587 + patch
> 
> On Sat, 2019-12-28 at 09:35 +0100, Jörg Frings-Fürst wrote:
> > Source: xsunpinyin
> > Version: 2.0.3-5
> > Severity: important
> > Usertags: scons_ftbfs
> > 
> > 
> > Hello, 
> > 
> > in the context of the change to Python3 also Scons was revised. With
> > the current version 3.1.2-1 from Experimental the changeover is
> > finished so far. 
> > 
> > However, an error occurred while building your package. The build
> > log
> > is attached.
> > 
> > Please check it and fix the error.
> > 
> > CU
> > Jörg
> > 
> 
> Hi,
> 
> Attached is a patch that fixes the build issue.
> 
> Regards
> 
> Phil
> 


Hi,

Edit error.

Attached is updated patch.

Regards

Phil

-- 

*** Playing the game for the games sake. ***

Twitter: @kathenasorg

IRC: kathenas

Description: Use python3 print()
Author: Phil Wyett 
Last-Update: 2019-12-29
Bug-Debian: https://bugs.debian.org/947587

Index: xsunpinyin-2.0.3/SConstruct
===
--- xsunpinyin-2.0.3.orig/SConstruct
+++ xsunpinyin-2.0.3/SConstruct
@@ -47,7 +47,7 @@ opts.Add('PREFIX', default='/usr/local')
 def PassVariables(envvar, env):
 for (x, y) in envvar:
 if x in os.environ:
-print 'Warning: you\'ve set %s in the environmental variable!' % x
+print ('Warning: you\'ve set %s in the environmental variable!' % x)
 env.MergeFlags(os.environ[x])
 
 env = Environment(ENV=os.environ,


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

Bug#947588: FTBFS with scons 3.1.2-1

[Phil Wyett]

Control: tags 947588 + patch

On Sat, 2019-12-28 at 09:37 +0100, Jörg Frings-Fürst wrote:
> Source: zfs-fuse
> Version: 0.7.0-19
> Severity: important
> Usertags: scons_ftbfs
> 
> 
> Hello, 
> 
> in the context of the change to Python3 also Scons was revised. With
> the current version 3.1.2-1 from Experimental the changeover is
> finished so far. 
> 
> However, an error occurred while building your package. The build log
> is attached.
> 
> Please check it and fix the error.
> 
> CU
> Jörg
> 

Hi,

Attached is a patch that fixes the build issue.

Regards

Phil

-- 

*** Playing the game for the games sake. ***

Twitter: @kathenasorg

IRC: kathenas

Description: Use python3 print()
Author: Phil Wyett 
Last-Update: 2019-12-29
Bug-Debian: https://bugs.debian.org/947588

--- zfs-fuse-0.7.0.orig/src/SConstruct
+++ zfs-fuse-0.7.0/src/SConstruct
@@ -56,8 +56,8 @@ else:
 
 if not (('-DDEBUG' in env['CCFLAGS']) or 
 		('-DNDEBUG' in env['CCFLAGS'])):
-	print
-	print "Misconfigured debug level: Neither DEBUG or NDEBUG appears to have been defined: %s" % env['CCFLAGS']
+	print ()
+	print ("Misconfigured debug level: Neither DEBUG or NDEBUG appears to have been defined: %s") % env['CCFLAGS']
 	sys.exit(1)
 
 env['CPPPATH'] = []
@@ -81,8 +81,8 @@ def getarch(arch):
 myarch = getarch(arch)
 
 if not myarch:
-	print
-	print 'Sorry, only the x86, amd64 and sparc64 hardware architectures are supported'
+	print ()
+	print ('Sorry, only the x86, amd64 and sparc64 hardware architectures are supported')
 	sys.exit(1)
 
 if myarch == 'sparc64':
@@ -129,7 +129,7 @@ env.Install(man_dir, '../doc/zstreamdump
 env.Install(man_dir, '../doc/zfs-fuse.8')
 
 if "tags" in sys.argv:
-print "updating tags..."
+print ("updating tags...")
 os.system("ctags --extra=+f `find -name '*.c'` `find -name '*.h'`")
 
 env.Alias('install', [install_dir, man_dir, cfg_dir])


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

Bug#947740: git: Please backport Git 2.24 to Buster

[Paul Anzel]

Package: git
Version: 1:2.20.1-2+deb10u1
Severity: wishlist

Dear Maintainer,

Would you please add the testing version of Git (2.24.1) as a backport to 
Debian Buster? I'd like to have the new Git command functionality from 2.23 
(git switch/restore) and I've seen that some major security vulns were found in 
older version of Git 
(https://github.blog/2019-12-10-multiple-git-vulnerabilities-in-2-24-and-older/).

Thank you!
Paul

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

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

Versions of packages git depends on:
iu  git-man  1:2.24.1-1
ii  libc62.29-3
ii  libcurl3-gnutls  7.64.0-4
iu  liberror-perl0.17028-1
iu  libexpat12.2.9-1
iu  libpcre2-8-0 10.34-7
ii  perl 5.28.1-6
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages git recommends:
ii  ca-certificates  20190110
iu  less 551-1
iu  openssh-client [ssh-client]  1:8.1p1-1
ii  patch2.7.6-3+deb10u1

Versions of packages git suggests:
iu  gettext-base  0.19.8.1-10
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
pn  git-email 
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
pn  gitweb

-- no debconf information

Bug#903740: Many messages in unattended-upgrades.pot are poor

[Bálint Réczey]

Control: tags -1 moreinfo

Hi Maarten.

 ezt írta (időpont: 2018. júl. 13., P, 22:40):
>
> Package: unattended-upgrades
> Version: 1.2
> Severity: minor
> Tags: patch
>
>
> Dear maintainers
>
>
> Recently I made an improved Dutch translation of the messages in
> unattended-upgrades.pot. It was submitted for inclusion in
> unattended-upgrades on 7 July 2018.
>
> During my translation, it appeared to me that many messages in
> unattended-upgrades.pot are poor. This related mostly to poor
> English, but also to other aspects, such as ambiguity and vagueness.
>
> Therefore, I created a 'translation' of all messages in
> proper English. The 'translation' also contains comments that briefly
> point out both the language errors and the shortcomings in the
> messages.
>
> I have attached my 'translation' to this bug report.
>
> Please study the attachment and then make corrections to your source
> code. When you have generated a new pot-file, you may ask the English
> translation team to proofread it.

Thank you for bringing up the issue and also for providing the patch.
I have to agree that the messages are not grammatically correct in many cases.

Regarding the patch I noticed that while the messages became
grammatically correct, in some cases their meaning drifted away from
what the original meaning intended to be.
Could you please provide your fixes as a PR on GitHub to make it
easier to discuss the changes separately?

Thanks,
Balint

>
>
> With kind regards
>
> Maarten
> Member of the Dutch translation team of Debian

Bug#947610: Bug#947611: Debian Bugs #947611, #947610

[Mattia Rizzolo]

On Sun, Dec 29, 2019 at 07:56:18PM +0100, Jörg Frings-Fürst wrote:
> already uploaded.

Note that bartm had already closed this bugs (using the 'close' control@
command, so you received no notifications - nor people on
debian-mentors@ did, as it's forwarded to specific mailing list where
~nobody is…)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#947739: RFS: coinor-dylp/1.10.4-2 [QA] [RC] -- Linear programming solver using the dynamic simplex algorithm

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "coinor-dylp"

 * Package name: coinor-dylp
   Version : 1.10.4-2
   Upstream Author : Lou Hafer 
 * URL : https://projects.coin-or.org/DyLP
 * License : EPL-1.0
 * Vcs : https://salsa.debian.org/debian/dylp
   Section : science

It builds those binary packages:

  coinor-libdylp1 - Linear programming solver using the dynamic simplex 
algorithm
  coinor-libdylp-dev - Linear programming solver using of the dynamic simplex 
algorithm
  coinor-libdylp-doc - Linear programming solver using of the dynamic simplex 
algorithm

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

  https://mentors.debian.net/package/coinor-dylp

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/coinor-dylp/coinor-dylp_1.10.4-2.dsc

Changes since the last upload:

   * QA upload.
   * Remove CoinUtils and Osi from build. (Closes: #947360)
   * Remove CoinUtils and Osi from doc.
   * Add Rules-Requires-Root to d/control.
   * Update Vcs to debian namespace in salsa.
   * Exclude .md5 files from doc package.
   * Use canonical URI in Vcs.

This RC bug was totally my mistake with the previous release.
I should have done a debdiff when updating to the new version. :(

-- 
Regards
Sudip

Bug#783228: clamav-unofficial-sigs: Could not resolve host: clamav.securiteinfo.com bug not resolved on Debian Buster.

[Pieter Hollander]

Package: clamav-unofficial-sigs
Version: 3.7.2-2
Followup-For: Bug #783228

Debian Buster still has this bug. I think the best solution would be to update 
the package from upstream sources. Upstream it has been fixed.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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)
LSM: AppArmor: enabled

Versions of packages clamav-unofficial-sigs depends on:
ii  bind9-host [host]  1:9.11.5.P4+dfsg-5.1
ii  clamav 0.101.4+dfsg-0+deb10u1
ii  curl   7.64.0-4
ii  dnsutils   1:9.11.5.P4+dfsg-5.1
ii  gnupg  2.2.12-1+deb10u1
ii  rsync  3.1.3-6

clamav-unofficial-sigs recommends no packages.

Versions of packages clamav-unofficial-sigs suggests:
ii  clamav-daemon  0.101.4+dfsg-0+deb10u1

-- no debconf information

Bug#947738: inn2 postinst script needs libinn.so.6, but doesn't depend on it

[Florian Zumbiehl]

Package: inn2
Version: 2.6.3-1+deb10u2

During an upgrade from stretch to buster, the inn2 postinst script failed
like this:

| Setting up inn2 (2.6.3-1+deb10u2) ...
| /usr/lib/news/bin/innconfval: error while loading shared libraries: 
libinn.so.6: cannot open shared object file: No such file or directory
| dpkg: error processing package inn2 (--configure):
| installed inn2 package post-installation script subprocess returned error 
exit status 127

The reason being that libinn.so.6 is in the new inn2-inews package, which
was not upgraded yet. Manually upgrading inn2-inews solved the problem.

Bug#888590: /usr/share/man/man8/vigr.8.gz is wrongly in GERMAN

[Bálint Réczey]

Control: fixed -1 1:4.8-1

Michelle Konzack  ezt írta (időpont:
2018. jan. 27., Szo, 15:24):
>
> Package: passwd
> Version: 1:4.4-4.1
> Release: Stretch
>
> Hello Maintainer,
>
> I just checked some packages and discovered, that this package has a
> GERMAN manpage instead of the ENGLISH one in /usr/share/man/man8/.
>
> I assume, it was wrongly copied, while building the package.

This is now fixed in the latest version.

Cheers,
Balint

>
> -- System Information:
> Debian Release: 9.3
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.0-5-amd64 (SMP w/2 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=de_DE:de (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
>
>
> --
> Michelle KonzackMiila ITSystems @ TDnet
> GNU/Linux Developer 00372-54541400
>

Bug#944920: Revise terminology used to specify requirements

[Russ Allbery]

Paul Gevers  writes:
> On 21-11-2019 13:59, Paul Gevers wrote:

>> [Disclaimer: the words below are as a member of the release team, but
>> not necessarily those of the team. We haven't discussed this yet.]

> We have had a discussion, and there were no objections against my vision
> below.

>> I can envision that if Policy carries such a summary list, our policy
>> would mention the version of Policy it was based on, to make sure that
>> Policy doesn't suddenly change what we as the RT agreed on.

> So, yes, we would welcome the Policy to maintain a summary list that we
> could reference. We already acknowledge that there will be items in the
> Policy text that we balance differently for RC-ness, so there will be
> exceptions maintained by us.

Thanks, Paul!  This is now on me to compose this list, and I'll let you
know when that's done.  Once that's complete, we can do a reconciliation.
I'm inclined to downgrade Policy musts that the release team does not
consider likely to be release-critical in the future, for instance.

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

Bug#930679: Please add overridable tag for not using dh sequencer

[Felix Lechner]

Hi Andreas,

On Tue, Dec 24, 2019 at 2:27 AM Andreas Beckmann  wrote:
>
> I produces false positives on packages with non-trivial rules files that
> cannot use the catch-all wildcard

Explicit targets are now allowed via:


https://salsa.debian.org/lintian/lintian/commit/9dafb57bb1766555ea5f9df62b2fbf783972edce

> e.g. nvidia-cuda-toolkit

Thanks for providing the package reference. Unfortunately, it was too
large to download. The test case uses its 'rules' file.

Kind regards
Felix Lechner

Bug#946379: unattended-upgrades: wrong german translation in the help information

[Bálint Réczey]

Control: tags -1 confirmed pending
Control: forwarded -1 https://github.com/mvo5/unattended-upgrades/pull/240

Hi Lorenz,

Lorenz Wenner  ezt írta (időpont: 2019. dec. 8., V, 9:42):
>
> Package: unattended-upgrades
> Version: 1.15
> Severity: minor
> Tags: newcomer
>
> Dear Maintainer,
>
> when i do "unattended-upgrades --help" i get:
>
> -8<-
> Usage: unattended-upgrades [options]
>
> Options:
>   -h, --helpshow this help message and exit
>   -d, --debug   Nachrichten zur Fehlersuche ausgeben
>   --apt-debug   APT/LibAPT detaillierte Nachrichten zur Fehlersuche
> ausgeben lassen
>   -v, --verbose Infomeldungen anzeigen
>   --dry-run Simulation, herunterladen, aber nicht installieren
>   --download-only   Nur herunterladen, aber nicht versuchen zu
> installieren.
>   --minimal-upgrade-steps
> Upgrade in minimal steps (and allow interrupting with
> SIGTERM) (default)
>   --no-minimal-upgrade-steps
> Aktualisierung in kleinen Schritten (und Unterbrechung
> mit SIGTERM erlauben)
> ->8-
>
> i think something went wrong in the german translation of the sections
> concerning --(no-minimal-upgrade-steps). the german text for --no-minimal-
> upgrade-steps would be correct for --minimal-upgrade-steps but is -- as i
> strongly assume -- wrong for --no-minimal-upgrade-steps.

This is indeed wrong, but the translation is correct. The original
English text was wrong which will be fixed in the next upload.

Cheers,
Balint

>
> kind regards & hope this helps
> Lorenz Wenner
>
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages unattended-upgrades depends on:
> ii  debconf [debconf-2.0]  1.5.73
> ii  lsb-base   11.1.0
> ii  lsb-release11.1.0
> ii  python33.7.5-1
> ii  python3-apt1.8.4+b1
> ii  python3-dbus   1.2.14-1
> ii  python3-distro-info0.22
> ii  ucf3.0038+nmu1
> ii  xz-utils   5.2.4-1+b1
>
> Versions of packages unattended-upgrades recommends:
> ii  anacron 2.3-29
> ii  cron [cron-daemon]  3.0pl1-135
> ii  systemd-sysv244-3
>
> Versions of packages unattended-upgrades suggests:
> pn  bsd-mailx   
> pn  default-mta | mail-transport-agent  
> pn  needrestart 
> ii  powermgmt-base  1.36
> ii  python3-gi  3.34.0-3
>
> -- debconf information excluded
>

Bug#947737: buster: please document the rpcbind NEWS on enabling remote calls in the Release Notes

[Nis Martensen]

Package: release-notes
Severity: normal

After the upgrade from stretch to buster on a NIS server it was no
longer possible to log into NIS client machines. While the buster
release notes warn that this can be caused by a change in ypbind, it
turned out that rpcinfo can also cause this. However, this is only
mentioned in rpcbind's NEWS and not in the release notes.

It would be nice if the buster release notes mentioned this as well. I
have prepared a proposed change in a merge request on salsa:
https://salsa.debian.org/ddp-team/release-notes/merge_requests/58

Questions:

 - Is it still possible to add such changes to the release notes for
   point releases, or should this information go somewhere else?

 - The new '-r' option is only available since the second point release
   (10.2). Should this be mentioned?

 - The proposed release notes change mentions that this option is
   debian-specific. Is this something that should be mentioned or
   dropped?

Bug#947610: Debian Bugs #947611, #947610

[Jörg Frings-Fürst]

Hello,

already uploaded.


CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#947736: ITP: topline -- per-core/NUMA CPU and disk utilization plain-text grapher

[Samuel Thibault]

Hello,

Adam Borowski, le dim. 29 déc. 2019 19:06:08 +0100, a ecrit:
> * URL : https://github.com/kilobyte/topline
> * License : GPL-2+noA
>   Programming Lang: C
>   Description : per-core/NUMA CPU and disk utilization plain-text grapher

Nice :)

You would probably want to use the hwloc library to easily get the
topology of the machine (numa nodes, sockets, caches, cores) ;)

Samuel

Bug#947237: gnome-software: Crashes on click over any software icon

[Laurent Bigonville]

On Mon, 23 Dec 2019 11:45:45 +0100 definetti  wrote:

> Dear Maintainer,

Hello,

> upon updating to 3.34.2, the application crashes when I click over any
software
> icon, before the relative page is loaded.
> Valgrind reports a segmentation fault with the error
>
> ==186020== Thread 5 pool-gnome-soft:
> ==186020== Invalid read of size 1
> ==186020== at 0x49AAE20: g_str_hash (in /usr/lib/x86_64-linux-
> gnu/libglib-2.0.so.0.6200.3)
> ==186020== by 0x49A9EFE: g_hash_table_lookup (in /usr/lib/x86_64-linux-
> gnu/libglib-2.0.so.0.6200.3)
> ==186020== by 0xE030388: ??? (in /usr/lib/x86_64-linux-gnu/gs-
> plugins-13/libgs_plugin_snap.so)
> ==186020== by 0xE030D2C: gs_plugin_add_alternates (in
/usr/lib/x86_64-linux-
> gnu/gs-plugins-13/libgs_plugin_snap.so)

The issue seems to be in the snap plugin, are you using snap? Could you
please install the debug packages (gnome-software-plugin-snap-dbgsym and
gnome-software-dbgsym) and try to reproduce the issue so we have a
better trace?

If you are not using snap, could you try to uninstall the
gnome-software-plugin-snap package and see if you can still reproduce it?

Thanks,

Laurent Bigonville

Bug#946775: any news about this itp?

[Jonas Meurer]

Hey Angel,
Angel Abad:
> Hi, any news about this itp?
> 
> Are you working on it?

the wofi package is almost ready for upload, will do so shortly ;)

You find the packaging repo at https://salsa.debian.org/swaywm-team/wofi

Cheers
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#947736: ITP: topline -- per-core/NUMA CPU and disk utilization plain-text grapher

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: topline
  Version : 0.1
  Upstream Author : yours truly
* URL : https://github.com/kilobyte/topline
* License : GPL-2+noA
  Programming Lang: C
  Description : per-core/NUMA CPU and disk utilization plain-text grapher
 This is a top-of-the-line logger of CPU usage patterns, designed for
 machines with ca. 50-300 total hardware threads (fewer results in a
 narrow graph, more requires a very wide terminal).  Every per-tick
 sample is shown abusing Unicode characters to fit within a single line.
 .
 Disk usage is also shown in a similarly terse per-device way, as %
 utilization for reads and writes.


Other similar tools:
* htop: full-screen interactive
* dstat: can't do more than a few CPUs
* VTUNE: can't be used in CI/etc, proprietary, non-portable
This is a simple tool, with nowhere as many features as the above, but
it has its niche.

Bug#947374: cacti: CVE-2019-17357: does not seem to affect stretch

[Chris Lamb]

Hi Hugo,

> rationale: template_id is sanitized at line 1048:
> input_validate_input_number(get_request_var_request("template_id"));
[…]
> Chris: you worked on cacti in jessie and triaged it not-affected. Jessie
> has a similar version, does this match your findings?

Ah yes; well-spotted. :)


Regards,

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

Bug#947374: cacti: CVE-2019-17357: does not seem to affect stretch

[Hugo Lefeuvre]

Hi,

after taking a look at the source code, this vulnerability does not seem to
affect cacti 0.8.8h+ds1-10 (stretch).

rationale: template_id is sanitized at line 1048:
input_validate_input_number(get_request_var_request("template_id"));

This check was replaced over time and gradually disappeared, which explains
the security issue in recent versions.

Chris: you worked on cacti in jessie and triaged it not-affected. Jessie
has a similar version, does this match your findings?

Just to make sure, I contacted upstream to get reproduction instructions
before I triage this not-affected in stretch in the tracker.

cheers,
Hugo

-- 
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C


signature.asc
Description: PGP signature

Bug#947717: pbcopper FTBFS on all architectures except x32

[Michael Crusoe]

pbcopper's latest release has slipped in a code copy of libssw which uses
x86 SIMD intrinsics. I've pushed up a fix along the lines I made to libssw
to enable cross architecture compilation at
https://salsa.debian.org/med-team/pbcopper/commit/f9678ed29590b57fe30638eed3d6819577b4ace1
and it awaits sponsorship

Thanks,

On Sun, Dec 29, 2019 at 5:45 PM Andreas Tille  wrote:

> Control: tags -1 help
>
> Hi,
>
> it might be that the new upstream version is targeting only at amd64
> (and by chance builds on x32).  If there is a hint from porters how to
> fix the build the only idea I have is to restrict it to amd64 (and x32).
>
> Kind regards
>
>Andreas.
>
> On Sun, Dec 29, 2019 at 02:15:58PM +0100, Paul Gevers wrote:
> > Source: pbcopper
> > Version: 1.3.0+dfsg-1
> > Severity: serious
> > Justification: ftbfs
> > Tags: ftbfs sid bullseye
> >
> > Dear maintainer,
> >
> > Your package fails to build from source on all buildds except x32. Your
> > package is involved in the pbbam and htslib transitions and blocking
> > progress. Please have a look.
> >
> > Paul
> >
> > https://buildd.debian.org/status/package.php?p=pbcopper
> >
> > Tail of log for pbcopper on arm64:
> >
> > cc -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude -I../include
> > -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> > -D_FILE_OFFSET_BITS=64 -std=c11 -g -O2
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread
> > -MD -MQ 'src/25a6634@@pbcopper@sha/align_cssw_ssw.c.o' -MF
> > 'src/25a6634@@pbcopper@sha/align_cssw_ssw.c.o.d' -o
> > 'src/25a6634@@pbcopper@sha/align_cssw_ssw.c.o' -c
> ../src/align/cssw/ssw.c
> > ../src/align/cssw/ssw.c:38:10: fatal error: emmintrin.h: No such file or
> > directory
> >38 | #include 
> >   |  ^
> > compilation terminated.
> > [9/114] c++ -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude
> > -I../include -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> > -D_FILE_OFFSET_BITS=64 -std=c++14 -g -O2
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
> > -pthread -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wrestrict
> > -Wuseless-cast -Wdouble-promotion -Wshadow -Wformat=1 -MD -MQ
> > 'src/25a6634@@pbcopper@sha/align_LinearAlignment.cpp.o' -MF
> > 'src/25a6634@@pbcopper@sha/align_LinearAlignment.cpp.o.d' -o
> > 'src/25a6634@@pbcopper@sha/align_LinearAlignment.cpp.o' -c
> > ../src/align/LinearAlignment.cpp
> > [10/114] c++ -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude
> > -I../include -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> > -D_FILE_OFFSET_BITS=64 -std=c++14 -g -O2
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
> > -pthread -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wrestrict
> > -Wuseless-cast -Wdouble-promotion -Wshadow -Wformat=1 -MD -MQ
> > 'src/25a6634@@pbcopper@sha/align_BandedChainAlignment.cpp.o' -MF
> > 'src/25a6634@@pbcopper@sha/align_BandedChainAlignment.cpp.o.d' -o
> > 'src/25a6634@@pbcopper@sha/align_BandedChainAlignment.cpp.o' -c
> > ../src/align/BandedChainAlignment.cpp
> > [11/114] c++ -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude
> > -I../include -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> > -D_FILE_OFFSET_BITS=64 -std=c++14 -g -O2
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
> > -pthread -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wrestrict
> > -Wuseless-cast -Wdouble-promotion -Wshadow -Wformat=1 -MD -MQ
> > 'src/25a6634@@pbcopper@sha/align_AffineAlignment.cpp.o' -MF
> > 'src/25a6634@@pbcopper@sha/align_AffineAlignment.cpp.o.d' -o
> > 'src/25a6634@@pbcopper@sha/align_AffineAlignment.cpp.o' -c
> > ../src/align/AffineAlignment.cpp
> > [12/114] c++ -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude
> > -I../include -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> > -D_FILE_OFFSET_BITS=64 -std=c++14 -g -O2
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
> > -pthread -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wrestrict
> > -Wuseless-cast -Wdouble-promotion -Wshadow -Wformat=1 -MD -MQ
> > 'src/25a6634@@pbcopper@sha/align_SparseAlignment.cpp.o' -MF
> > 'src/25a6634@@pbcopper@sha/align_SparseAlignment.cpp.o.d' -o
> > 'src/25a6634@@pbcopper@sha/align_SparseAlignment.cpp.o' -c
> > ../src/align/SparseAlignment.cpp
> > [13/114] c++ -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude
> > -I../include -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> > -D_FILE_OFFSET_BITS=64 -std=c++14 -g -O2
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC

Bug#947612: Re : Bug#947612: libreoffice-writer: Can’t see the characters’ colour.

[David Kalnischkies]

Hi,

On Sun, Dec 29, 2019 at 05:21:09PM +0100, Rene Engelhard wrote:
> On Sun, Dec 29, 2019 at 11:01:19AM +0100, nicolas.patr...@gmail.com wrote:
> > Architecture: i386 (i686)
> 
> in your report. My bad, maybe it's 32bit only? 32bit builds are not done
> upstream anymore and so they might miss stuff...

I could not reproduce this problem on a i686 laptop belonging to my
family with 6.3.3 nor with 6.4.0~rc1-3. XFCE as desktop environment,
"2x Genuine Intel T2050" as cpu and graphics identifying as "Intel Mobile
945GM/GMS, 943/940GML Express Integrated Graphics Controller" run by fully
upgraded 'unstable' environment.

I am happy to recheck with a test document if need be (please CC me in
that case). Coloring text (although in Calc) is something my family
does quite frequently, so if that wouldn't work I would never hear the
end of it and are hence certain it isn't a general i386 problem… 😉


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#947429: Manual note

[Felix Lechner]

Hi Valentin,
Hi Adam,

This bug was fixed via:


https://salsa.debian.org/lintian/lintian/commit/6e861559f6899216d1c74bb2b35893f1921e7a83

For some reason Salsa stopped sending pending notifications.

Kind regards
Felix Lechner

Bug#947488: closed by r...@rene-engelhard.de (Re: Bug#947488: libreoffice-common: Error in /usr/share/doc-base/access2base', line 7: all `Format' sections are invalid.)

[Rene Engelhard]

Hi,

On Sun, Dec 29, 2019 at 04:56:00PM +, Thorsten Glaser wrote:
> found 947488 1:6.4.0~rc1-2
   
> >If this explanation is unsatisfactory and you have not received a
> >better one in a separate message then please contact r...@rene-engelhard.de 
> >by
> >replying to this email.
> 
> It’s not fixed, trivially:

Of course not when the fix (as I wrote) is in -3.

Regards,

Rene

Bug#947671: lintian: please warn if orphaned package is maintained in a private space

[Felix Lechner]

Hi Mattia,

On Sat, Dec 28, 2019 at 1:48 PM Mattia Rizzolo  wrote:
>
> I'd like if you can also check for package
> maintained in private spaces, i.e. anything that is not
> https://salsa.debian.org/debian/
> https://git.dgit.debian.org/

Done via:


https://salsa.debian.org/lintian/lintian/commit/9fd686c545e53d8e50a520c30f62b5297b4c62f3

Kind regards
Felix Lechner

Bug#947469: marked as done (Error in `/usr/share/doc-base/access2base', line 7: all `Format' sections are invalid.)

[Rene Engelhard]

reopen 947469
close 947469 1:6.4.0~rc1-3
thanks

Hi,

On Sun, Dec 29, 2019 at 05:03:04PM +, Debian Bug Tracking System wrote:
> Date: Sun, 29 Dec 2019 16:58:22 + (UTC)
> From: Thorsten Glaser 
> To: 947488-d...@bugs.debian.org
> cc: r...@rene-engelhard.de
> Subject: Bug#947488: marked as done (libreoffice-common: Error in
>  /usr/share/doc-base/access2base', line 7: all `Format' sections are
>  invalid.) (fwd)
> 
> Version: 1:6.4.0~rc1-3
> 
> Ah, well…

What on earth? You really believe I didn't fix it up myself after I
noticed the error and wrote about it?

Actually I directly forcedmerged with Michael Biebls bug.

Trying to fix the "Done:" up. What a waste of time.

Regards,

Rene

Bug#947719: [Python-apps-team] Bug#947719: Is gstreamer1.0-libav really a hard dependency of lollypop?

[Andreas Ronnquist]

On Sun, 29 Dec 2019 13:28:42 +,
Amr Ibrahim wrote:

>Package: lollypop
>Version: 1.2.19-1
>
>I see that gstreamer1.0-libav is set as a hard dependency of lollypop
>in Debian. However, upstream does not list gstreamer1.0-libav as a
>dependency [1]. If lollypop runs without gstreamer1.0-libav, then it
>should not be a run-time dependency. If the idea is to support more
>music formats in lollypop, then gstreamer1.0-libav should be a
>suggested package (or a recommended package if it provides very
>popular music formats).
>
>[1] https://gitlab.gnome.org/World/lollypop#depends-on

Thanks for your report - I'll update the package with a suggests on
gstreamer1.0-libav instead of a dependency.

-- Andreas Rönnquist
mailingli...@gusnan.se
gus...@debian.org

Bug#947653: csv2latex FTCBFS: strips with the wrong strip

[Benoît Rouits]

Hello again Helmut,

Unfortunately, i cannot sign the new source package due to your
changelog entry. What is the best way to integrate your patch then ?
May i change the debian changelog entry with my own message or is there
a better way to integrate your patch (maybe you should sign the source
package) ?

Thank you for your reply.
 Benoît

Le 29/12/2019 à 17:45, Benoît Rouits a écrit :
> Thank you Helmut for your patch.
> I am applying it. Then i will ask my deb mentor to upload the new source
> package i will build with your patch included.
>  Benoît
> 
> Le 28/12/2019 à 21:52, Helmut Grohne a écrit :
>> Source: csv2latex
>> Version: 0.21-1
>> Tags: patch
>> User: debian-cr...@lists.debian.org
>> Usertags: ftcbfs
>>
>> csv2latex fails to cross build from source, because it strips with the
>> wrong strip at make install time. Beyond breaking cross compilation,
>> this breaks DEB_BUILD_OPTION=nostrip as well as generation of -dbgsym
>> packages. It is best to defer all stripping to dh_strip. The attached
>> patch implements that. Please consider applying it.
>>
>> Helmut
>>

Bug#947488: closed by r...@rene-engelhard.de (Re: Bug#947488: libreoffice-common: Error in /usr/share/doc-base/access2base', line 7: all `Format' sections are invalid.)

[Thorsten Glaser]

reopen 947488
found 947488 1:6.4.0~rc1-2
thanks

Debian Bug Tracking System dixit:

>This is an automatic notification regarding your Bug report
>which was filed against the libreoffice-common package:
>
>#947488: libreoffice-common: Error in /usr/share/doc-base/access2base', line 
>7: all `Format' sections are invalid.
>
>It has been closed by r...@rene-engelhard.de.
>
>Their explanation is attached below along with your original report.

>>Fixed in above version...

>If this explanation is unsatisfactory and you have not received a
>better one in a separate message then please contact r...@rene-engelhard.de by
>replying to this email.

It’s not fixed, trivially:

tglase@tglase-nb:~ $ sudo cleanenv / install-docs --verbose --check 
/usr/share/doc-base/access2base
Warning in `/usr/share/doc-base/access2base', line 7: `Files' value not 
specified for format `html'.
Error in `/usr/share/doc-base/access2base', line 7: all `Format' sections are 
invalid.
/usr/share/doc-base/access2base: Fatal error found, the file won't be 
registered.
tglase@tglase-nb:~ $ dpkg -S /usr/share/doc-base/access2base
libreoffice-common: /usr/share/doc-base/access2base
tglase@tglase-nb:~ $ dpkg-query -W libreoffice-common
libreoffice-common  1:6.4.0~rc1-2

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4

[Chris Lamb]

Hi László,

> scheduled to 31st of December, this year but it was delayed with a
> whole month later

I don't fully understand the ramifications or risks of uploading the
current Fossil tree I'm afraid so I will have to leave that judgement
to you. Can you let me know your intention either way so that we don't
lose this down the cracks and delay Paul's work further? I would not
want to disable the test and remember to re-enable it again, after all.


Regards,

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

Bug#471537: fixed in lintian 2.42.0

[Felix Lechner]

Hi Emmanuel,

On Sat, Dec 28, 2019 at 9:33 AM Emmanuel Bourg  wrote:
>
> I suggest changing the severity to info or pedantic, and adjust the
> description to explain the suffix is optional.

Done with:


https://salsa.debian.org/lintian/lintian/commit/ca5adad9cb21805b871a9f2e6cdd30b8bdb0246c

Thanks for helping to make Lintian better.

Kind regards

Felix Lechner

Bug#947653: csv2latex FTCBFS: strips with the wrong strip

[Benoît Rouits]

Thank you Helmut for your patch.
I am applying it. Then i will ask my deb mentor to upload the new source
package i will build with your patch included.
 Benoît

Le 28/12/2019 à 21:52, Helmut Grohne a écrit :
> Source: csv2latex
> Version: 0.21-1
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> csv2latex fails to cross build from source, because it strips with the
> wrong strip at make install time. Beyond breaking cross compilation,
> this breaks DEB_BUILD_OPTION=nostrip as well as generation of -dbgsym
> packages. It is best to defer all stripping to dh_strip. The attached
> patch implements that. Please consider applying it.
> 
> Helmut
> 

Bug#947717: pbcopper FTBFS on all architectures except x32

[Andreas Tille]

Control: tags -1 help

Hi,

it might be that the new upstream version is targeting only at amd64
(and by chance builds on x32).  If there is a hint from porters how to
fix the build the only idea I have is to restrict it to amd64 (and x32).

Kind regards

   Andreas.

On Sun, Dec 29, 2019 at 02:15:58PM +0100, Paul Gevers wrote:
> Source: pbcopper
> Version: 1.3.0+dfsg-1
> Severity: serious
> Justification: ftbfs
> Tags: ftbfs sid bullseye
> 
> Dear maintainer,
> 
> Your package fails to build from source on all buildds except x32. Your
> package is involved in the pbbam and htslib transitions and blocking
> progress. Please have a look.
> 
> Paul
> 
> https://buildd.debian.org/status/package.php?p=pbcopper
> 
> Tail of log for pbcopper on arm64:
> 
> cc -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude -I../include
> -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> -D_FILE_OFFSET_BITS=64 -std=c11 -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread
> -MD -MQ 'src/25a6634@@pbcopper@sha/align_cssw_ssw.c.o' -MF
> 'src/25a6634@@pbcopper@sha/align_cssw_ssw.c.o.d' -o
> 'src/25a6634@@pbcopper@sha/align_cssw_ssw.c.o' -c ../src/align/cssw/ssw.c
> ../src/align/cssw/ssw.c:38:10: fatal error: emmintrin.h: No such file or
> directory
>38 | #include 
>   |  ^
> compilation terminated.
> [9/114] c++ -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude
> -I../include -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> -D_FILE_OFFSET_BITS=64 -std=c++14 -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
> -pthread -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wrestrict
> -Wuseless-cast -Wdouble-promotion -Wshadow -Wformat=1 -MD -MQ
> 'src/25a6634@@pbcopper@sha/align_LinearAlignment.cpp.o' -MF
> 'src/25a6634@@pbcopper@sha/align_LinearAlignment.cpp.o.d' -o
> 'src/25a6634@@pbcopper@sha/align_LinearAlignment.cpp.o' -c
> ../src/align/LinearAlignment.cpp
> [10/114] c++ -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude
> -I../include -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> -D_FILE_OFFSET_BITS=64 -std=c++14 -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
> -pthread -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wrestrict
> -Wuseless-cast -Wdouble-promotion -Wshadow -Wformat=1 -MD -MQ
> 'src/25a6634@@pbcopper@sha/align_BandedChainAlignment.cpp.o' -MF
> 'src/25a6634@@pbcopper@sha/align_BandedChainAlignment.cpp.o.d' -o
> 'src/25a6634@@pbcopper@sha/align_BandedChainAlignment.cpp.o' -c
> ../src/align/BandedChainAlignment.cpp
> [11/114] c++ -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude
> -I../include -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> -D_FILE_OFFSET_BITS=64 -std=c++14 -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
> -pthread -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wrestrict
> -Wuseless-cast -Wdouble-promotion -Wshadow -Wformat=1 -MD -MQ
> 'src/25a6634@@pbcopper@sha/align_AffineAlignment.cpp.o' -MF
> 'src/25a6634@@pbcopper@sha/align_AffineAlignment.cpp.o.d' -o
> 'src/25a6634@@pbcopper@sha/align_AffineAlignment.cpp.o' -c
> ../src/align/AffineAlignment.cpp
> [12/114] c++ -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude
> -I../include -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> -D_FILE_OFFSET_BITS=64 -std=c++14 -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
> -pthread -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wrestrict
> -Wuseless-cast -Wdouble-promotion -Wshadow -Wformat=1 -MD -MQ
> 'src/25a6634@@pbcopper@sha/align_SparseAlignment.cpp.o' -MF
> 'src/25a6634@@pbcopper@sha/align_SparseAlignment.cpp.o.d' -o
> 'src/25a6634@@pbcopper@sha/align_SparseAlignment.cpp.o' -c
> ../src/align/SparseAlignment.cpp
> [13/114] c++ -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude
> -I../include -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> -D_FILE_OFFSET_BITS=64 -std=c++14 -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
> -pthread -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wrestrict
> -Wuseless-cast -Wdouble-promotion -Wshadow -Wformat=1 -MD -MQ
> 'src/25a6634@@pbcopper@sha/align_PairwiseAlignment.cpp.o' -MF
> 'src/25a6634@@pbcopper@sha/align_PairwiseAlignment.cpp.o.d' -o
> 'src/25a6634@@pbcopper@sha/align_PairwiseAlignment.cpp.o' -c
> ../src/align/PairwiseAlignment.cpp
> [14/114] c++ -Isrc/25a6634@@pbcopper@sha -Isrc -I../src -Iinclude
> -I../include -Isrc/utility -fdiagnostics-color=always -DNDEBUG -pipe
> -D_FILE_OFFSET_BITS=64 -std=c++14 -g -O2
>

Bug#926922: metoo

[Harald Dunkel]

I would be highly interested, too. deb-multimedia.org is not an option.

Thanx in advance
Harri

Bug#947735: qtlocation-opensource-src: Fix build on hurd-i386

[Samuel Thibault]

Source: qtlocation-opensource-src
Version: 5.12.5+dfsg-2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

qtlocation-opensource-src currently can't build on hurd-i386 because it
does not enable the geoclue modules. The attach patch fixes this.

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), 
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
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)

-- 
Samuel
c> [ ] morning [ ] afternoon [ ] evening [ ] night , everyone (choose as 
applicable)
Index: qtlocation-opensource-src-5.12.5+dfsg/src/plugins/position/position.pro
===
--- qtlocation-opensource-src-5.12.5+dfsg.orig/src/plugins/position/position.pro
+++ qtlocation-opensource-src-5.12.5+dfsg/src/plugins/position/position.pro
@@ -2,8 +2,8 @@ TEMPLATE = subdirs
 
 QT_FOR_CONFIG += positioning-private
 
-linux|freebsd|openbsd|netbsd:qtHaveModule(dbus):SUBDIRS += geoclue
-linux|freebsd|openbsd|netbsd:qtHaveModule(dbus):SUBDIRS += geoclue2
+linux|freebsd|openbsd|netbsd|hurd:qtHaveModule(dbus):SUBDIRS += geoclue
+linux|freebsd|openbsd|netbsd|hurd:qtHaveModule(dbus):SUBDIRS += geoclue2
 qtConfig(gypsy):SUBDIRS += gypsy
 qtConfig(winrt_geolocation):SUBDIRS += winrt
 qtHaveModule(simulator):SUBDIRS += simulator

Bug#947734: tf5 and GNUtls interaction, breaks in TLS1.3 connections seemingly!

[Simon Iremonger]

Package: tf5
Version: 5.0beta8-7
Severity: important
Tags: upstream

Dear Maintainer,


As per brief discussion with Russ Allberry, I posting this bug report.

tf5 in testing/sid and also debian buster, along with GNUtls versions thereby
provided, has some undeseriable interaction/bug.
Specifically, attempting a connection to a TLS1.3 enabled stunnel4 host fails.
When using  tf5  and then  /connect -x [host] [TLS port]  ... the result
is :-

% Connected to (unnamed1) using cipher ECDHE_RSA_AES_256_GCM_SHA384.
% Connection to (unnamed1) closed by foreign host.

On the server-side, is possible to disable TLS1.3, and then things work fine
with TLS1.2 connectivity.  Have not tested specifically different cipher suites
and so-on, however.

Older versions of tf5+gnutls (e.g. all current Ubuntu-LTS, and Debian before
buster) do not seem to have the issue, presumably because of lacking TLS1.3
support!.


My suggestion is that may make best sense for tf5 to (if possible) disable
TLS1.3 usage until this is sorted out in gnutls-land, or indeed, openssl 2.0
reaches debian and can just be used with tf5 instead!

May also be appropriate to post a bug into GNUTLS once some further
investigation
done?


With thanks,

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

Kernel: Linux 4.15.0-72-generic (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages tf5 depends on:
ii  libc62.29-6
ii  libgnutls-openssl27  3.6.11.1-2
ii  libpcre3 2:8.39-12+b1
ii  libtinfo66.1+20191019-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

tf5 recommends no packages.

Versions of packages tf5 suggests:
pn  spell  

-- no debconf information