Bug#944086: adminer install does not have apache.conf file in /etc/adminer/

[Alexandre Rossi]

Hi,

> when I install the package, the file apache.conf is not in place in
> /etc/adminer/.

Why would you expect that? I could not find any documentation pointing
to this location.
A basic apache configuration for adminer is available at the following location.
/etc/apache2/conf-available/adminer.conf

Alex

Bug#944092: linux-image-5.3.0-1-amd64: i915 gpu hang, system freezes for seconds every few minutes

[Philipp Marek]

Package: src:linux
Version: 5.3.7-1
Severity: normal
Tags: patch upstream

Whole machine hangs, but recovers after a few seconds; no visible 
association to CPU or memory load.

Please include the patch from 

https://patchwork.freedesktop.org/patch/300891/

it claims to fix a bug that is reported since about a year in many different 
bug reports and -trackers.

-- Package-specific info:
** Version:
Linux version 5.3.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 
20191008 (Debian 9.2.1-9)) #1 SMP Debian 5.3.7-1 (2019-10-19)

** PCI devices:
00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core 
Processor Integrated Graphics Controller [8086:0416] (rev 06) (prog-if 00 [VGA 
controller])
Subsystem: Lenovo 4th Gen Core Processor Integrated Graphics Controller 
[17aa:2210]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

Bug#941412: CVE-2019-14866

[Ola Lundqvist]

Hi again

The new patch can be found here:
http://apt.inguza.net/wheezy-security/cpio/CVE-2019-14866.patch

It is not perfectly properly documented since it refers to a commit that do
not contain it all. But I think you get the point anyway.

// Ola

On Mon, 4 Nov 2019 at 08:10, Ola Lundqvist  wrote:

> Hi Sergey, Thomas and cpio Debian maintainers
>
> I have been preparing fixes for CVE-2019-14866 for Debian oldstable and
> oldoldstable. While doing that I realized that the patch mentioned here (1)
> do work for amd64 but do not work for i386.
> I was able to build on both amd64 and i386 but the fix obviously did not
> work on i386 since I could reproduce the problem.
>
> I think the reason for this is that a long is 32 bit on i386 while it is
> 64 bits on amd64.
>
> (1) https://lists.gnu.org/archive/html/bug-cpio/2019-08/msg3.html
>
> The fix is very simple. Change the "long" to a "long long" in
> to_out_or_error.
>
> With that correction it works when I build and test on i386.
> Please let me know what you think. I'm going to upload a fixed package to
> debian old and oldold stable tomorrow.
>
> Best regards
>
> // Ola
>
> --
>  --- Inguza Technology AB --- MSc in Information Technology 
> |  o...@inguza.como...@debian.org|
> |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
>  ---
>
>

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#944091: deprecation warnings with 3.8 in the autopkg tests

[Matthias Klose]

Package: src:python-apt
Version: 1.9.0
Severity: important
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.8

you can work around them with the allow-stderr restriction, however these should 
be fixed.


autopkgtest [06:10:11]: test run-tests: ---]
run-testsFAIL stderr: 
/usr/lib/python3/dist-packages/apt/package.py:484: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats
autopkgtest [06:10:11]: test run-tests:  - - - - - - - - - - results - - - - - - 
- - - -
autopkgtest [06:10:11]: test run-tests:  - - - - - - - - - - stderr - - - - - - 
- - - -
/usr/lib/python3/dist-packages/apt/package.py:484: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats

  return apt_pkg.version_compare(self._cand.ver_str, other.version)
/usr/lib/python3/dist-packages/apt/package.py:401: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats

  self._rec = apt_pkg.TagSection(record_str)
/usr/lib/python3/dist-packages/apt/debfile.py:89: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats

  self._sections = apt_pkg.TagSection(control)
/usr/lib/python3/dist-packages/apt/debfile.py:325: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats

  return apt_pkg.parse_depends(self._sections[key], False)
/usr/lib/python3/dist-packages/apt/debfile.py:338: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats

  apt_pkg.parse_depends(self._sections[key], False))
/usr/lib/python3/dist-packages/apt/debfile.py:349: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats

  return apt_pkg.parse_depends(self._sections[key], False)
/usr/lib/python3/dist-packages/apt/debfile.py:359: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats

  return apt_pkg.parse_depends(self._sections[key], False)
/usr/lib/python3/dist-packages/apt/debfile.py:799: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats

  self._depends.extend(apt_pkg.parse_src_depends(sec[tag]))
/tmp/autopkgtest.QOsY27/build.R1N/src/tests/test_deps.py:75: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats

  deps = apt_pkg.parse_depends("p1a (<< 1a) | p1b (>> 1b)")
/tmp/autopkgtest.QOsY27/build.R1N/src/tests/test_deps.py:90: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats

  self.assertEqual("<", apt_pkg.parse_depends("p1 (<< 1)")[0][0][2])
/tmp/autopkgtest.QOsY27/build.R1N/src/tests/test_deps.py:91: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats

  self.assertEqual("<=", apt_pkg.parse_depends("p1 (< 1)")[0][0][2])
/tmp/autopkgtest.QOsY27/build.R1N/src/tests/test_deps.py:92: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats

  self.assertEqual("<=", apt_pkg.parse_depends("p1 (<= 1)")[0][0][2])
/tmp/autopkgtest.QOsY27/build.R1N/src/tests/test_deps.py:93: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats

  self.assertEqual("=", apt_pkg.parse_depends("p1 (= 1)")[0][0][2])
/tmp/autopkgtest.QOsY27/build.R1N/src/tests/test_deps.py:94: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats

  self.assertEqual(">=", apt_pkg.parse_depends("p1 (>= 1)")[0][0][2])
/tmp/autopkgtest.QOsY27/build.R1N/src/tests/test_deps.py:95: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats

  self.assertEqual(">=", apt_pkg.parse_depends("p1 (> 1)")[0][0][2])
/tmp/autopkgtest.QOsY27/build.R1N/src/tests/test_deps.py:96: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats

  self.assertEqual(">", apt_pkg.parse_depends("p1 (>> 1)")[0][0][2])
/tmp/autopkgtest.QOsY27/build.R1N/src/tests/test_deps.py:67: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats

  deps = apt_pkg.parse_depends("po4a:native", True)
/tmp/autopkgtest.QOsY27/build.R1N/src/tests/test_deps.py:70: DeprecationWarning: 
PY_SSIZE_T_CLEAN will be required for '#' formats

  deps = apt_pkg.parse_depends("po4a:native", False)
/tmp/autopkgtest.QOsY27/build.R1N/src/tests/test_deps.py:106: 
DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats

  depends_this = apt_pkg.parse_src_depends("p [%s]" % architecture)
/tmp/autopkgtest.QOsY27/build.R1N/src/tests/test_deps.py:107: 
DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats

  depends_this_too = apt_pkg.parse_src_depends("p [!not-existing-arch]")
/tmp/autopkgtest.QOsY27/build.R1N/src/tests/test_deps.py:108: 
DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats

  depends_other = apt_pkg.parse_src_depends("p [!%s]" % architecture)
/tmp/autopkgtest.QOsY27/build.R1N/src/tests/test_deps.py:109: 
DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats

  depends_other_too = apt_pkg.parse_src_depends("p [not-existing-arch]")
/tmp/autopkgtest.QOsY27/build.R1N/src/tests/test_tagfile.py:172: 
DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' 

Bug#941412: CVE-2019-14866

[Ola Lundqvist]

Hi Sergey, Thomas and cpio Debian maintainers

I have been preparing fixes for CVE-2019-14866 for Debian oldstable and
oldoldstable. While doing that I realized that the patch mentioned here (1)
do work for amd64 but do not work for i386.
I was able to build on both amd64 and i386 but the fix obviously did not
work on i386 since I could reproduce the problem.

I think the reason for this is that a long is 32 bit on i386 while it is 64
bits on amd64.

(1) https://lists.gnu.org/archive/html/bug-cpio/2019-08/msg3.html

The fix is very simple. Change the "long" to a "long long" in
to_out_or_error.

With that correction it works when I build and test on i386.
Please let me know what you think. I'm going to upload a fixed package to
debian old and oldold stable tomorrow.

Best regards

// Ola

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#944090: CMake: please package newer version - 3.15

[Roman Lebedev]

Package: cmake
Version: 3.13.4-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer.
The CMake v3.15 series is avaliable, while currently, sid is at 3.13.
LLVM is considering requiring said 3.15 in the near future:
https://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html

It would be great to have said CMake version in sid before that happens,
should said unfortunate decision be made by them, to avoid having to
workaround the systems CMake version.

Roman.

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

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

Versions of packages cmake depends on:
ii  cmake-data3.13.4-1
ii  libarchive13  3.4.0-1+b1
ii  libc6 2.29-3
ii  libcurl4  7.66.0-1+b1
ii  libexpat1 2.2.9-1
ii  libgcc1   1:9.2.1-16
ii  libjsoncpp1   1.7.4-3+b1
ii  librhash0 1.3.8-1
ii  libstdc++69.2.1-16
ii  libuv11.33.1-2
ii  procps2:3.3.15-2+b1
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages cmake recommends:
ii  gcc   4:9.2.1-3.1
ii  make  4.2.1-1.2

Versions of packages cmake suggests:
pn  cmake-doc
ii  ninja-build  1.9.0-3

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEjkF6151RK40WXe2HCDw+u0oWieAFAl2/zv8ACgkQCDw+u0oW
ieDU7RAAlO83s80+JNmbeHEYc6OVn2anLYpS6Y+Idwhwtz0noObWV6G/lfvlwJcS
VZGGlQoXpRuUihhAsMgkKoSLhB8VLnkvTxU6iFl1FRJUdmhxaxactGXnbHKrkWb1
jQsZMN4raAL/U8JR1mMhAcMb+z9MLGihkmgrruq5pui28dqeL7G7TE/fLKQL/3oc
fOCMQIZISKwNxzNSIU0yiONKCCO1twuiWeBdx3Eh0/oQknMusZbkN0pp4v2Wdpb6
ZegaUbcJ7DZkipQ0cvquCuGdf+UYbgqIpe9kQhX4Fr6oFdBlWxBcW5nApsFOMbVQ
5e/Gh2sro92fy5v3dw7aqceHr0RoJ1Bxxadf2/ZtdG4h7DaQvvCfI3WDS9215yGp
XpQUh+2OkpG/a60UF85p20zIEgw2ex6z6qCSIb6BtlPHSMUJxFhmr1nLKm16L7jZ
0STPuRsVhQeMcIy1+/QD6zUO/qor6ypg/KGCP7qLfp6ICGoFR85tZNiwbewOXMKQ
lmmEu/8bJC5hkEXNIio5sBIwZUsDodnCPRFkU+cecXs5BnVZ2uYUoLOsc+QBxeh+
M5+liG5c/Rrw0a7QE2vpnIzeSxqbLTILRuPzviI7pXhvkemZX+qZktuy9H35mr30
A8EvmRKzRGMX1/kWUkHSWdaC9YVjL7S4xl6UOnHxlw+e7FMXngE=
=9NqW
-END PGP SIGNATURE-

Bug#944084: ntpsec: "Module/Binary version mismatch" message running ntpmon

[Richard Laager]

On 11/3/19 4:56 PM, tony mancill wrote:
> Perhaps @NTPSEC_VERSION_EXTENDED@ is not getting set properly in all of
> the modules at build time?  (It's probably something simple; I haven't
> looked yet.)

Thanks for the bug report. I found and fixed this. It'll be in the next
upload, which should be in a couple of days.

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Bug#944089: tool for ISA usage statistics within ELF binaries?

[Shengjing Zhu]

Package: lintian
Severity: wishlist
Control: retitle -1 lintian: check ISA used in binaries

On Mon, Nov 4, 2019 at 5:18 AM Adam Borowski  wrote:
>
> On Sun, Nov 03, 2019 at 04:27:12PM +, Mo Zhou wrote:
> > Hi mentors,
> >
> > do you know if there is a static ELF analysing tool, that makes
> > statistics on the usage of different ISAs? maybe something on top
> > of a disassembler?
> >
> > actually, I'd like to know if an ELF binary has got more, say
> > AVX instructions after recompiling with -march=native,
> > -ftree-vectorization, -O3, etc.
>
> No check for AVX yet, but a quick hack that may be useful to you is attached
> to: https://lists.debian.org/debian-devel/2017/08/msg00200.html
>

I think this could be added to lintian.

lintian could give a warning if the generated binaries break ISA baseline.

-- 
Shengjing Zhu

Bug#944088: x2goserver FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: x2goserver
Version: 4.1.0.3-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

x2goserver fails to cross build from source, because it uses the build
architecture compiler. During dh_auto_configure, the Makefile.PL is run,
but it doesn't seem to record cross tools for the build step. Thus, one
should use the makefile buildsystem for dh_auto_build to pass cross
tools there. Later during dh_auto_install, the software is rebuilt with
the build architecture compiler due to bad Makefile dependencies. The
attached patch fixes all of this. Please consider applying it.

Helmut
diff --minimal -Nru x2goserver-4.1.0.3/debian/changelog 
x2goserver-4.1.0.3/debian/changelog
--- x2goserver-4.1.0.3/debian/changelog 2019-03-17 23:02:58.0 +0100
+++ x2goserver-4.1.0.3/debian/changelog 2019-11-04 05:35:59.0 +0100
@@ -1,3 +1,13 @@
+x2goserver (4.1.0.3-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Force a makefile build system as the configure step doesn't record
+  cross compilers.
++ cross.patch: Don't rebuild libx2go-server-db-perl during make install.
+
+ -- Helmut Grohne   Mon, 04 Nov 2019 05:35:59 +0100
+
 x2goserver (4.1.0.3-4) unstable; urgency=medium
 
   * debian/po:
diff --minimal -Nru x2goserver-4.1.0.3/debian/patches/cross.patch 
x2goserver-4.1.0.3/debian/patches/cross.patch
--- x2goserver-4.1.0.3/debian/patches/cross.patch   1970-01-01 
01:00:00.0 +0100
+++ x2goserver-4.1.0.3/debian/patches/cross.patch   2019-11-04 
05:35:59.0 +0100
@@ -0,0 +1,14 @@
+--- x2goserver-4.1.0.3.orig/libx2go-server-db-perl/Makefile
 x2goserver-4.1.0.3/libx2go-server-db-perl/Makefile
+@@ -38,8 +38,9 @@
+ 
+ build: build-arch build-indep
+ 
+-build-arch:
+-  $(CC) $(CFLAGS) $(LDFLAGS) 
-DTRUSTED_BINARY=\"$(LIBDIR)/libx2go-server-db-sqlite3-wrapper.pl\" -o 
lib/libx2go-server-db-sqlite3-wrapper src/libx2go-server-db-sqlite3-wrapper.c
++build-arch:lib/libx2go-server-db-sqlite3-wrapper
++lib/libx2go-server-db-sqlite3-wrapper:src/libx2go-server-db-sqlite3-wrapper.c
++  $(CC) $(CFLAGS) $(LDFLAGS) 
-DTRUSTED_BINARY=\"$(LIBDIR)/libx2go-server-db-sqlite3-wrapper.pl\" -o $@ $^
+ 
+ build-indep:
+ 
diff --minimal -Nru x2goserver-4.1.0.3/debian/patches/series 
x2goserver-4.1.0.3/debian/patches/series
--- x2goserver-4.1.0.3/debian/patches/series2018-12-01 11:44:40.0 
+0100
+++ x2goserver-4.1.0.3/debian/patches/series2019-11-04 05:35:59.0 
+0100
@@ -1,2 +1,3 @@
 1001_fix-desktopsharing-version.patch
 0001-x2goversion-Fix-situations-where-compfile-contains-a.patch
+cross.patch
diff --minimal -Nru x2goserver-4.1.0.3/debian/rules 
x2goserver-4.1.0.3/debian/rules
--- x2goserver-4.1.0.3/debian/rules 2018-11-29 11:04:06.0 +0100
+++ x2goserver-4.1.0.3/debian/rules 2019-11-04 05:35:59.0 +0100
@@ -10,7 +10,7 @@
PREFIX=/usr NXLIBDIR=$(NXLIBDIR) dh ${@}
 
 override_dh_auto_build:
-   PREFIX=/usr NXLIBDIR=$(NXLIBDIR) PERL_INSTALLDIRS=vendor dh_auto_build
+   PREFIX=/usr NXLIBDIR=$(NXLIBDIR) PERL_INSTALLDIRS=vendor dh_auto_build 
--buildsystem=makefile
 
 override_dh_auto_install:
$(MAKE) -f Makefile build-arch

Bug#939767: fuse3: Installing fuse3 breaks fuse2 applications using -o nonempty

[Dmitry Smirnov]

> ...the one who mounts the filesystem need to be sure
> s/he doesn't shadow real files / directories with the mount.

No, this is a very unsafe default because benign `mount -av` will create more 
layered mounts on every invocation.

Mount should be idempotent by default.


> This is the same with any other mounts as I know.

Not really. FYI attempt to mount ext4 for the second time comes back with 
"already mounted" error and exit code 32.

IMHO mounting over non-empty folder should be only allowed with explicit 
"force" option such as "-o nonempty".


> Why this is a behavior change, the only callers just need to remove
> the '-o nonempty' option, right? From the user point of view
> everything will work exactly the same as I see.

Too many problems with that. First of all some software must be re-compiled 
to remove "nonempty" option. Secondly, that makes file systems unsafe in 
regards to `mount -av`.

I wonder what FUSE3 developers were thinking when they did such unsafe 
breaking change?  :( :(

-- 
All the best,
 Dmitry Smirnov

---

Truth never damages a cause that is just.
-- Mahatma Gandhi


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

Bug#944033: /usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_all_cron: mail from weekly cronjob

[Theodore Y. Ts'o]

On Sun, Nov 03, 2019 at 11:09:00AM -0800, Darrick J. Wong wrote:
> 
> Because if you don't do that, the e2scrub process gets started with fd 0
> mapped to stdout of ls_targets on account of the "ls_targets | while
> read tgt" loop.  Yay bash.  I guess the problem here is that
> e2scrub_all's stdin is itself a pipe, so /dev/stdin maps to
> /proc/self/fd/0, is a symlink to "pipe:[]" which doesn't help us
> any.
> 
> We could amend the e2scrub_all script to do:
> 
>   stdin="$(realpath /dev/stdin)"
>   test -w "${stdin}" || stdin=/dev/null

Shouldn't that be 'test -r "${stdin}"'?

Or we could just always redirect the input to /dev/null, perhaps?

Cheers,

- Ted

Bug#943948: ITP: erofs-utils -- Utilities for EROFS File System

[Gao Xiang]

Hi Emfox,

On Mon, Nov 04, 2019 at 09:13:33AM +0800, Emfox Zhou wrote:
> Hello, have you put your packaging work online anywhere, so that people
> interested can help checking it?

Thanks for your kind reply.

I just worked out a manual page for mkfs.erofs since I noticed it's a
requirement for a debian package. I think I can upload the whole package to
a github repo or mentors.debian.net website then in a few day.

Could you help take time checking it as well? :-)

> And if the issues is critical, I am afraid we should not upload erofs-utils
> until lz4 is fixed.

I think it's not critical (it only crashes with some given binary
sequences), so I can limit srcsize as a workaround if LZ4 compressor
isn't fixed.

By the way, LZ4HC compressor is not affected at all and it's also
recommended to use LZ4HC rather than LZ4.

However, I'd like to know if some priority to resolve debian LZ4
compressor though. It seems much better than do some workaround on
my side.

Thanks,
Gao Xiang

> 
> On Fri, Nov 1, 2019 at 9:33 PM Gao Xiang  wrote:
> 
> > Package: wnpp
> > Severity: wishlist
> > Owner: Gao Xiang 
> >
> > * Package name: erofs-utils
> >   Version : 1.0
> >   Upstream Author : Li Guifu , Miao Xie <
> > miao...@huawei.com>, Gao Xiang 
> > * URL :
> > https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git
> > * License : GPL-2+
> >   Programming Lang: C
> >   Description : Utilities for EROFS File System
> >
> > EROFS [1] [2] is a new enhanced lightweight linux upstreamed in-kernel
> > read-only filesystem with modern designs (eg. no buffer head, reduced
> > metadata, inline xattrs/data, etc.) for scenarios which need
> > high-performance
> > read-only requirements, e.g. Android OS for smartphones and LIVECDs.
> >
> > It also provides fixed-sized output compression support, which improves
> > storage density, keeps relatively higher compression ratios, which is more
> > useful to achieve high performance for embedded devices with limited memory
> > since it has unnoticable memory overhead and page cache thrashing.
> >
> > erofs-utils 1.0 [3] was released weeks ago, I'm trying to request for
> > debian inclusion (also consider security issues [4] for lz4 package).
> >
> > I made a usable debian package just now although I have limited knowledge
> > about the whole debian packaging stuff. I'd like and will take time to be
> > the package maintainer if no one have interest or enough time on this.
> >
> > Please kindly consider my request.
> >
> > Thanks,
> > Gao Xiang
> >
> > [1]
> > https://kccncosschn19eng.sched.com/event/Nru2/erofs-an-introduction-and-our-smartphone-practice-xiang-gao-huawei
> > [2] https://www.usenix.org/conference/atc19/presentation/gao
> > [3]
> > https://lore.kernel.org/r/20191024033259.GA2513@hsiangkao-HP-ZHAN-66-Pro-G1
> > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943751
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943680
> >
> 
> 
> -- 
> Emfox Zhou
> 
> GnuPG Public Key: 0x1DEB

Bug#944087: RFP: crun -- lightweight OCI runtime for running containers

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org d...@fragfest.com.au
Owner: Dmitry Smirnov 

   Package name: crun
Version: 0.10.4
Upstream Author: Giuseppe Scrivano 
License: (L)GPL-3+
URL: https://github.com/containers/crun
Vcs-Browser: https://salsa.debian.org/debian/crun
Description: lightweight OCI runtime for running containers
 Fast and low-memory footprint OCI Container Runtime fully written in C.


Finally, an app container runtime not written in Golang. :)


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

Bug#942235: [Python-modules-team] Bug#942235: python-xarray needed new dask as well?

[Emmanuel Arias]

Oops!!! Sorry, I reverted the change

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El dom., 3 de nov. de 2019 a la(s) 19:49, Drew Parsons
(dpars...@debian.org) escribió:
>
> On 2019-11-04 01:15, Emmanuel Arias wrote:
> > Hi,
> >
> > I've just prepare the new upstream release (for some reason
> > the upstream branch was not merge to master). [1]
> >
>
> Emmanuel, the work-in-progress is in the experimental branch.  Push to
> experimental first before pulling into master.
>
> Drew

Bug#942114: ganeti-instance-debootstrap: diff for NMU version 0.16-6.1

[Antoine Beaupré]

On 2019-11-02 07:01:43, Mike Gabriel wrote:
> Hi Antoine,
>
> On  Sa 02 Nov 2019 00:10:38 CET, anarcat wrote:
>
>> Control: tags 942114 + pending
>>
>> Dear maintainer,
>>
>> I've prepared an NMU for ganeti-instance-debootstrap (versioned as  
>> 0.16-6.1) and
>> uploaded it to DELAYED/02. Please feel free to tell me if I
>> should delay it longer.
>>
>> Regards.
>
> Would it in fact be an option, to join the Ganeti team and do a team upload?
>
> Otherwise, I'd say the NMU is ok for now, I will update the packaging  
> Git the coming week with that NMU.
>
> Thanks for helping out on Ganeti in Debian!

I'd be happy to join the team as I'll be using Ganeti quite a bit in the
coming months/years/who knows, but I suspect it might already be too
late for a team upload...

a.

-- 
Anarchy is not perfection, it is not the absolute ideal which like the
horizon recedes as fast as we approach it; but it is the way open to
all progress and all improvements for the benefit of everybody.
- Errico Malatesta

Bug#943948: ITP: erofs-utils -- Utilities for EROFS File System

[Emfox Zhou]

Hello, have you put your packaging work online anywhere, so that people
interested can help checking it?
And if the issues is critical, I am afraid we should not upload erofs-utils
until lz4 is fixed.

On Fri, Nov 1, 2019 at 9:33 PM Gao Xiang  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Gao Xiang 
>
> * Package name: erofs-utils
>   Version : 1.0
>   Upstream Author : Li Guifu , Miao Xie <
> miao...@huawei.com>, Gao Xiang 
> * URL :
> https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git
> * License : GPL-2+
>   Programming Lang: C
>   Description : Utilities for EROFS File System
>
> EROFS [1] [2] is a new enhanced lightweight linux upstreamed in-kernel
> read-only filesystem with modern designs (eg. no buffer head, reduced
> metadata, inline xattrs/data, etc.) for scenarios which need
> high-performance
> read-only requirements, e.g. Android OS for smartphones and LIVECDs.
>
> It also provides fixed-sized output compression support, which improves
> storage density, keeps relatively higher compression ratios, which is more
> useful to achieve high performance for embedded devices with limited memory
> since it has unnoticable memory overhead and page cache thrashing.
>
> erofs-utils 1.0 [3] was released weeks ago, I'm trying to request for
> debian inclusion (also consider security issues [4] for lz4 package).
>
> I made a usable debian package just now although I have limited knowledge
> about the whole debian packaging stuff. I'd like and will take time to be
> the package maintainer if no one have interest or enough time on this.
>
> Please kindly consider my request.
>
> Thanks,
> Gao Xiang
>
> [1]
> https://kccncosschn19eng.sched.com/event/Nru2/erofs-an-introduction-and-our-smartphone-practice-xiang-gao-huawei
> [2] https://www.usenix.org/conference/atc19/presentation/gao
> [3]
> https://lore.kernel.org/r/20191024033259.GA2513@hsiangkao-HP-ZHAN-66-Pro-G1
> [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943751
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943680
>


-- 
Emfox Zhou

GnuPG Public Key: 0x1DEB

Bug#943891: [pkg-go] Bug#943891: umoci: autopkgtest regression: can't load package: package .: no Go files

[Dmitry Smirnov]

On Monday, 4 November 2019 8:03:14 AM AEDT Paul Gevers wrote:
> Do you mean autodep8 here? I don't see how autopkgtest could be to
> blame, but please enlighten me.

I don't know either but I suspect whatever is being tested for Golang 
packages per "autopkgtest-pkg-go" may have a bug responsible for this 
(presumably) false positive.


> It's hard to believe otherwise. The test has now been performed on a
> daily basis since 2019-10-13 and has been failing systematically for the
> new version, while it systematically passes for the old version (in
> testing, of which the latest one was today). In unstable, the switch
> from passing to failing was with the upload of the new version.

Lot of things may get broken in unstable due to changes in other packages 
around the same time.

In this particular package the only thing changed is introduction of "-dev" 
package. However "go build" (or "go generate") is failing in the most unusual 
unreproducible way unrelated to the change in recent upload.

I suspect that one of the patches is not applied for a test but that's only a 
guess...

-- 
Regards,
 Dmitry Smirnov.

---

Truth — Something somehow discreditable to someone.
-- H. L. Mencken, 1949


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

Bug#944039: ITP: docker-systemctl-replacement -- daemonless "systemctl" command to manage services without systemd

[Dmitry Smirnov]

On Monday, 4 November 2019 5:12:57 AM AEDT Andrei POPESCU wrote:
> s/SystemD/systemd :)

Yes, yes, thank you. Lintian slapped me for this already. :)

Already fixed in 

  https://salsa.debian.org/debian/docker-systemctl-replacement/commit/3f7b7bd9

-- 
Cheers,
 Dmitry Smirnov.

---

We are all equal before the law, but not before those appointed to apply it.
-- Stanisław Jerzy Lec



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

Bug#944085: ITP: ocaml-uchar -- Compatibility library for OCaml's Uchar module

[Andy Li]

Package: wnpp
Severity: wishlist
Owner: Andy Li 

* Package name: ocaml-uchar
  Version : 0.0.2
  Upstream Author : Daniel Bünzli 
* URL : https://github.com/ocaml/uchar
* License : LGPL with OCaml-linking exception
  Programming Lang: OCaml
  Description : Compatibility library for OCaml's Uchar module

The uchar package provides a compatibility library for the Uchar module
introduced in OCaml 4.03.

It is effectively an empty package with only metadata for ocamlfind to resolve 
"uchar", which is used by sedlex 2.1.

Bug#943998: O_TMPFILE not available on macOS

[Dmitry Bogatov]

[2019-11-02 20:03] Clint Adams 
> > FTBFS on macOS systems, because of undefined O_TMPFILE,
> > which was introduced in 4.9 release.
> > 
> > Attempt to build was made here: 
> > https://github.com/Homebrew/homebrew-core/pull/46107
>
> Dmitry, any thoughts?  Maybe disabling --stdin on systems without O_TMPFILE?

Maybe it would better to provide emulation? This patch illustrates my
idea, but is /not/ tested:

+#ifdef O_TMPFILE
+static int open_tmpfile_rw(void)
+{
+   const char *tmpdir;
+
+   tmpdir = getenv("TMPDIR");
+   if (!tmpdir) {
+   tmpdir = "/tmp";
+   }
+
+   return open(tmpdir, O_TMPFILE|O_RDWR|O_EXCL, S_IRUSR | S_IWUSR);
+}
+#else
+static char tmpfile_path[] = "/tmp/run-parts.stdin.XX";
+static int cleanup_tmpfile(void)
+{
+   unlink(tmpfile_path);
+}
+
+static int open_tmpfile_rw(void)
+{
+   int fd;
+
+   fd = mkstemp(tmpfile_path);
+   if (fd != -1) {
+   atexit(_tmpfile);
+   }
+   return fd;
+}
+#endif
+
+
 /*
  * Copy stdin into temporary read-write file, and return file descriptor to it.
  */
@@ -396,15 +429,7 @@ static int copy_stdin(void)
   char buffer[4096];
   ssize_t bytes;
 
-  tmpdir = getenv("TMPDIR");
-  if (!tmpdir) {
-tmpdir = "/tmp";
-  };
-
-  fd = open(tmpdir, O_TMPFILE|O_RDWR|O_EXCL, S_IRUSR | S_IWUSR);
-  if (fd < 0) {
-return -1;
-  };
+  fd = open_tmpfile_rw();
 
   do {
 ssize_t rest;
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#944078: [Pkg-utopia-maintainers] Bug#944078: firewall-applet: applet does not appear

[Michael Biebl]

Am 03.11.19 um 23:51 schrieb Toni Mueller:
> 
> Hi Michael,
> 
> On Sun, Nov 03, 2019 at 11:45:07PM +0100, Michael Biebl wrote:
>> Am 03.11.19 um 23:28 schrieb Toni Mueller:
>>> I have tried two versions that don't work. Switching window managers is
>>> not an option for me, and generally, it should work everywhere (imho).
>>>
>>> What would be the way forward?
>>
>> If I had to guess I'd say it's either an issue of Qt5 or the tray
>> application you are using in awesome. Might also be related to compositing.
>> Maybe those hints help you further investigation this issue.
> 
> well, I have no clue about Qt, and I am using the standard awesome with
> no special addons that I am aware of - just as it comes with buster,
> plus a memory/cpu/battery widget. Every other program, like eg.
> pavucontrol, screengrab, nm-applet, vlc, radiotray, redshift-gtk etc.,
> has no problems adding itself to the tray. The systray is, to the best
> of my very limited knowledge, a builtin feature of awesome. You have it
> if you just install awesome.
> 
> Now what...

I'd talk to the awesome maintainer and/or Qt5 maintainers.

I'm not really familiar with either of them.


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



signature.asc
Description: OpenPGP digital signature

Bug#944078: [Pkg-utopia-maintainers] Bug#944078: firewall-applet: applet does not appear

[Michael Biebl]

Am 04.11.19 um 00:11 schrieb Michael Biebl:
> Am 03.11.19 um 23:51 schrieb Toni Mueller:

>> Now what...
> 
> I'd talk to the awesome maintainer and/or Qt5 maintainers.
> 
> I'm not really familiar with either of them.

That's the same buster VM, btw.

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


signature.asc
Description: OpenPGP digital signature

Bug#939798: floppy support in d-i

[Holger Wansing]

Control: severity -1 wishlist


John Paul Adrian Glaubitz  wrote:
> On 11/3/19 11:19 PM, Holger Wansing wrote:
> >> Since no new arguments (pro or contra floppy support in d-i) were given, I 
> >> suppose it looks like we will keep the status quo and therefore close the
> >> related bugs.
> > 
> > To get this to an end, I will:
> > 
> > - simplify related templates, to remove the mention of "floppy support" from
> >   dialogs, as mentioned in the proposed patches in
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880122#5
> >   and
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939799#5;
> > - but keep the code unchanged, so that floppy support is still available for
> >   those, who still need/use it.
> > 
> > This should minimize the chance, that people get irritated/frustrated by 
> > reading of "floppy support in 2020", but keep the possibility to use floppy 
> > capabilities if needed.
> > 
> > I think this is a good compromise, which should satisfy all.
> I disagree. It's a really weak argument. Are you really saying that people
> are getting frustrated because they are reading the word "floppy"? That
> doesn't make any sense at all.
> 
> I would understand the argument that the code would create additional 
> maintenance
> burden but that's not the case, so it seems we are fabricating arguments here
> just to justify some sort of change.
> 
> Please do not remove documentation if a feature is still there just for the
> sake of making a change. And if some people are offended by the word "floppy",
> so be it.
> 
> Debian is supposed to be a universal system and that includes universal
> hardware support.

Dropping to wishlist




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

Bug#944078: [Pkg-utopia-maintainers] Bug#944078: firewall-applet: applet does not appear

[Toni Mueller]

Hi Michael,

On Sun, Nov 03, 2019 at 11:45:07PM +0100, Michael Biebl wrote:
> Am 03.11.19 um 23:28 schrieb Toni Mueller:
> > I have tried two versions that don't work. Switching window managers is
> > not an option for me, and generally, it should work everywhere (imho).
> > 
> > What would be the way forward?
> 
> If I had to guess I'd say it's either an issue of Qt5 or the tray
> application you are using in awesome. Might also be related to compositing.
> Maybe those hints help you further investigation this issue.

well, I have no clue about Qt, and I am using the standard awesome with
no special addons that I am aware of - just as it comes with buster,
plus a memory/cpu/battery widget. Every other program, like eg.
pavucontrol, screengrab, nm-applet, vlc, radiotray, redshift-gtk etc.,
has no problems adding itself to the tray. The systray is, to the best
of my very limited knowledge, a builtin feature of awesome. You have it
if you just install awesome.

Now what...


Cheers,
Toni

Bug#944084: ntpsec: "Module/Binary version mismatch" message running ntpmon

[tony mancill]

Package: ntpsec
Version: 1.1.7+dfsg1-1
Severity: minor

Hi,

I notice that when ntpmon exits, it logs the following to the console:

$ ntpmon
Module/Binary version mismatch
Binary: ntpsec-@NTPSEC_VERSION_EXTENDED@
Module: ntpsec-1.1.7 2019-09-30T03:27:38Z

Perhaps @NTPSEC_VERSION_EXTENDED@ is not getting set properly in all of
the modules at build time?  (It's probably something simple; I haven't
looked yet.)

Thanks,
tony


signature.asc
Description: PGP signature

Bug#944078: [Pkg-utopia-maintainers] Bug#944078: firewall-applet: applet does not appear

[Michael Biebl]

Am 03.11.19 um 23:45 schrieb Michael Biebl:

> If I had to guess I'd say it's either an issue of Qt5 or the tray
> application you are using in awesome. Might also be related to compositing.
> Maybe those hints help you further investigation this issue.

Googling a bit shows issues like this one
https://github.com/awesomeWM/awesome/issues/1720

Maybe try with a compositing manager like compton (if you don't do already).


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



signature.asc
Description: OpenPGP digital signature

Bug#942235: [Python-modules-team] Bug#942235: python-xarray needed new dask as well?

[Drew Parsons]

On 2019-11-04 01:15, Emmanuel Arias wrote:

Hi,

I've just prepare the new upstream release (for some reason
the upstream branch was not merge to master). [1]



Emmanuel, the work-in-progress is in the experimental branch.  Push to 
experimental first before pulling into master.


Drew

Bug#944078: [Pkg-utopia-maintainers] Bug#944078: firewall-applet: applet does not appear

[Michael Biebl]

Am 03.11.19 um 23:28 schrieb Toni Mueller:
> 
> 
> Hi Michael,
> 
> nice that it works for you.
> 
> On Sun, Nov 03, 2019 at 11:14:06PM +0100, Michael Biebl wrote:
>> Am 03.11.19 um 21:54 schrieb Toni Mueller:
>>> Package: firewall-applet
>>> Version: 0.7.2-1
>>> Severity: important
>>>
>>> Dear Maintainer,
>>>
>>> I am trying to run the firewall-applet on my buster machine, and neither
>>> the buster version nor the version in testing actually create the tray
>>> applet. Instead, the program just hangs with no output. For the buster
>>
>> Seems to work fine here (in a buster, XFCE VM).
> 
> I have tried two versions that don't work. Switching window managers is
> not an option for me, and generally, it should work everywhere (imho).
> 
> What would be the way forward?

If I had to guess I'd say it's either an issue of Qt5 or the tray
application you are using in awesome. Might also be related to compositing.
Maybe those hints help you further investigation this issue.

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



signature.asc
Description: OpenPGP digital signature

Bug#944083: libbsd-dev: Lacks user_from_uid() & uid_from_user() functions

[Robert Luberda]

Package: libbsd-dev
Version: 0.10.0-1
Severity: wishlist

Hi,

I'm trying to prepare new version of bsd-mailx package from the OpenBSD
repository, but it unfortunatelly fails to compile because they switched
to using to user_from_uid() and uid_from_user(), see the links below.
 Would it be possible to provide the functions in the libbsd package?



https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mail/v7.local.c?rev=1.18=text/x-cvsweb-markup=date
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mail/v7.local.c.diff?r1=1.17=1.18=date=h
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mail/temp.c.diff?r1=1.17=1.18=date=h

Regards,
robert



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (990, 'unstable-debug'), (990, 'stable-updates'), (990, 
'unstable'), (990, 'testing'), (990, 'stable')

Versions of packages libbsd-dev depends on:
ii  libbsd0  0.10.0-1

libbsd-dev recommends no packages.

libbsd-dev suggests no packages.

-- no debconf information

Bug#880122: Bug#939798: floppy support in d-i

[Holger Wansing]

Hi,

Holger Wansing  wrote:
> John Paul Adrian Glaubitz  wrote:
> > On 9/8/19 11:43 PM, Holger Wansing wrote:
> > > I assume, this bugreport was motivated by bug #880122 by Chris Lamb from 
> > > 2017,
> > > which proposed to remove floppy support from hw-detect package, since
> > > floppies appear to no longer be widely used for ages:
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880122
> > > 
> > > 
> > > The same bugreport made me working on preparations for removing floppy 
> > > support
> > > from debian-installer templates recently:
> > > https://lists.debian.org/debian-boot/2019/09/msg00057.html
> > 
> > (...)
> > 
> > > With this "Debian Ports" argumentation, we need a discussion on this topic
> > > first, as it seems.
> > 
> > The standard floppy driver in the kernel just recently got a new maintainer 
> > [1]
> > and Linus underlined that the floppy driver is still useful for 
> > virtualization
> > environments (I can't find the LKML post at the moment).
> > 
> > It's super easy to create a floppy image with just the dd tool and use it in
> > qemu or on servers.
> > 
> > Please do not assume that all users are just on x86 laptops with no optical
> > drives or floppy drives. I know that a lot of people don't use optical or
> > floppy media anymore, but that doesn't mean there is still a use case for 
> > it.
> > 
> > Like with serial connections, floppy drives are simple enough that they work
> > in basically every environment, so having them as a simple fallback is
> > incredibly useful and unless there is a very good reason for removing floppy
> > support - i.e. code that is broken or blocks other new code - I'm objecting
> > to removing floppy support and would be willing to take care of it.
> 
> Since no new arguments (pro or contra floppy support in d-i) were given, I 
> suppose it looks like we will keep the status quo and therefore close the
> related bugs.

To get this to an end, I will:

- simplify related templates, to remove the mention of "floppy support" from
  dialogs, as mentioned in the proposed patches in
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880122#5
  and
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939799#5;
- but keep the code unchanged, so that floppy support is still available for
  those, who still need/use it.

This should minimize the chance, that people get irritated/frustrated by 
reading of "floppy support in 2020", but keep the possibility to use floppy 
capabilities if needed.

I think this is a good compromise, which should satisfy all.



Holger



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

Bug#880122: Bug#939798: floppy support in d-i

[John Paul Adrian Glaubitz]

On 11/3/19 11:24 PM, John Paul Adrian Glaubitz wrote:
> I disagree. It's a really weak argument. Are you really saying that people
> are getting frustrated because they are reading the word "floppy"? That
> doesn't make any sense at all.

And I just saw the "argument". The argument was "It's 2018". That's not
an argument.

Adrian

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

Bug#880122: Bug#939798: floppy support in d-i

[John Paul Adrian Glaubitz]

On 11/3/19 11:19 PM, Holger Wansing wrote:
>> Since no new arguments (pro or contra floppy support in d-i) were given, I 
>> suppose it looks like we will keep the status quo and therefore close the
>> related bugs.
> 
> To get this to an end, I will:
> 
> - simplify related templates, to remove the mention of "floppy support" from
>   dialogs, as mentioned in the proposed patches in
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880122#5
>   and
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939799#5;
> - but keep the code unchanged, so that floppy support is still available for
>   those, who still need/use it.
> 
> This should minimize the chance, that people get irritated/frustrated by 
> reading of "floppy support in 2020", but keep the possibility to use floppy 
> capabilities if needed.
> 
> I think this is a good compromise, which should satisfy all.
I disagree. It's a really weak argument. Are you really saying that people
are getting frustrated because they are reading the word "floppy"? That
doesn't make any sense at all.

I would understand the argument that the code would create additional 
maintenance
burden but that's not the case, so it seems we are fabricating arguments here
just to justify some sort of change.

Please do not remove documentation if a feature is still there just for the
sake of making a change. And if some people are offended by the word "floppy",
so be it.

Debian is supposed to be a universal system and that includes universal
hardware support.

Thanks,
Adrian

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

Bug#942417: Please update to 5.0.7 so KMyMoney can be built with AqBanking 6

[Micha Lenk]

Control: severity -1 serious

Hi KDE maintainers,

I've just uploaded libgwenhywfar/4.99.24rc8-1 and libaqbanking/5.99.43beta-1 to
unstable, which now makes package kmymoney/5.0.6-1 fail to build from source.
Hence I've raised this bug's severity to serious.

Please update to the current upstream version 5.0.7, which contains already a
fix for this issue. At the same time I would appreciate the build dependency
versions to be bumped so that builds will be forced to pick up the new library
versions (see attached patch).

Best regards,
Micha Lenk
diff --git a/debian/control b/debian/control
index 362e2d6..11254c2 100644
--- a/debian/control
+++ b/debian/control
@@ -33,8 +33,8 @@ Build-Depends: debhelper (>= 11), cmake, pkg-kde-tools (>= 0.15.16),
  libkf5wallet-dev,
  libkf5webkit-dev,
  libkf5xmlgui-dev,
- libaqbanking-dev (>= 5.8.0~),
- libgwenhywfar-core-dev (>= 4.20.0~), libgwengui-qt5-dev (>= 4.20.0~),
+ libaqbanking-dev (>= 5.99.43),
+ libgwenhywfar-core-dev (>= 4.99.24), libgwengui-qt5-dev (>= 4.99.24),
  libgpgmepp-dev, libgpg-error-dev, libgpgme-dev,
  libalkimia5-dev (>= 7.0),
  libical-dev, libofx-dev, libgmp-dev,

Bug#944082: RM: sqlkit -- RoQA; Dead upstream, unmaintained, depends on legacy libs

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove sqlkit. It's dead upstream, unmaintained (last upload in 2015)
and depends on pygtk/Python 2.

Cheers,
Moritz

Bug#937085: mozilla-devscripts: Python2 removal in sid/bullseye

[Benjamin Drung]

block 937085 by 780741
thanks

Hi,

I ported amo-changelog and xpi-repack to Python 3 in version 0.54, but I
wasn't able to port all scripts, because there is no Python 3 version of
redland-bindings (see Debian bug #780741).

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#944080: RM: activity-log-manager -- RoQA; unmaintained, depends on legacy libs

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove activity-log-manager. It's unmaintained (last maintainer upload
in 2011) and depends on legacy codebases (pygtk, Python 2).

Cheers,
Moritz

Bug#944081: libmoo-perl: Please recommend libnamespace-clean-perl

[Felix Lechner]

Package: libmoo-perl
Severity: wishlist

Hi,

Developing with Moo has many advantages, but also one pitfall:
Namespaces may require cleanup. The issue is documented here:

https://metacpan.org/pod/Moo#CLEANING-UP-IMPORTS

Perhaps libnamespace-clean-perl should be a recommended package.

Kind regards,
Felix Lechner

Bug#944079: RM: driconf -- RoQA; dead upstream, unmaintained, depends on legacy libs

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove driconf. It's dead upstream (last release in 2006), unmaintained
(no upload since 2014) and depends on pygtk and Python 2.

Cheers,
Moritz

Bug#944053: nvidia-legacy-390xx-kernel-dkms: Unable to build the driver

[Andreas Beckmann]

Control: tag -1 moreinfo

On 03/11/2019 14.14, Nicolas Patrois wrote:
> The package can’t build the driver because it does not find the snd-page-alloc
> kernel driver in the 4.17.0 kernel (nor in 4.18).

The nvidia driver is not related to any sound driver kernel module.
The error messages you posted do not mention nvidia at all.

The nvidia kernel module is loaded:

> -- Package-specific info:
> uname -a:
> Linux nicolas.home 4.17.0-3-686-pae #1 SMP Debian 4.17.17-1 (2018-08-18) i686 
> GNU/Linux
> 
> /proc/version:
> Linux version 4.17.0-3-686-pae (debian-ker...@lists.debian.org) (gcc version 
> 7.3.0 (Debian 7.3.0-28)) #1 SMP Debian 4.17.17-1 (2018-08-18)
> 
> /proc/driver/nvidia/version:
> NVRM version: NVIDIA UNIX x86 Kernel Module  390.129  Mon Jul 22 19:40:01 PDT 
> 2019
> GCC version:  gcc version 7.4.0 (Debian 7.4.0-10) 

and was successfully built for 4.17 and 4.18:

> Kernel modules: nvidia.ko
> /lib/modules/4.17.0-3-686-pae/updates/dkms/nvidia-legacy-390xx.ko
> /lib/modules/4.17.0-3-686-pae/updates/dkms/nvidia-legacy-390xx-drm.ko
> /lib/modules/4.17.0-3-686-pae/updates/dkms/nvidia-legacy-390xx-modeset.ko
> /lib/modules/4.18.0-1-686-pae/updates/dkms/nvidia-legacy-390xx.ko
> /lib/modules/4.18.0-1-686-pae/updates/dkms/nvidia-legacy-390xx-drm.ko
> /lib/modules/4.18.0-1-686-pae/updates/dkms/nvidia-legacy-390xx-modeset.ko

Andreas

Bug#944076: python-coverage: autopkgtest regression: Can't load /usr/share/doc/python-coverage/html/index.html

[Ben Finney]

On 03-Nov-2019, Paul Gevers wrote:

> With a recent upload of python-coverage the autopkgtest of
> python-coverage fails in testing when that autopkgtest is run with the
> binary packages of python-coverage from unstable. It passes when run
> with only packages from testing.

Thank you for investigating this difference between environments.

> I copied some of the output at the bottom of this report.

I see that the build log does not show any output at all for
attempting to build the documentation; for some reason that step is
being silently omitted. I will investigate why.

> In tabular form:
>passfail
> python-coveragefrom testing4.5.2+dfsg.1-2
> all others from testingfrom testing

Is there anywhere I can see the output from a successful build of this
package release?

Or, do you mean that the success is for a *different* (previous?)
release of ‘python-coverage’?

Also, what does “all others” represent here; what packages?

-- 
 \“I don't accept the currently fashionable assertion that any |
  `\   view is automatically as worthy of respect as any equal and |
_o__)   opposite view.” —Douglas Adams |
Ben Finney 


signature.asc
Description: PGP signature

Bug#941198: initscripts: packages should ship systemd units

[Russ Allbery]

Ansgar  writes:
> Sean Whitton writes:

>>> +Packages that include system services should include ``systemd`` units
>>> +to start or stop services.
>>> +
>>>  Packages that include daemons for system services should place scripts
>>>  in ``/etc/init.d`` to start or stop services at boot time or during a
>>>  change of runlevel. These scripts should be named

>> The text now has both "Packages that include system services ..." and
>> "Packages that include daemons for system services".  Do you take these
>> to refer to different things?  Surely we can combine the language somehow.

> No.  I just wanted to have a simple initial proposal to start with.
> Arguably one can ship systemd services for more things (such as
> dbus-activated or timer-activated services), but I don't think that
> difference matters here.

> I omitted the "daemons for" as both service files and initscripts don't
> always start a persistent background process (daemon), but can also run
> one-time actions.

> To combine the language, maybe the second paragraph should be changed to
> something like

> [To support alternative init systems] packages should additionally
> place initscripts in ``/etc/init.d``. These scripts should be named
> ...

> (with or without the text in brackets).

Combining this idea, I end up with this proposed change:

--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -388,11 +388,14 @@ argument ``stop``.
 Writing the scripts
 ~~~
 
-Packages that include daemons for system services should place scripts
-in ``/etc/init.d`` to start or stop services at boot time or during a
-change of runlevel. These scripts should be named
-``/etc/init.d/package``, and they should accept one argument, saying
-what to do:
+Packages that include system services should include ``systemd`` service
+units to start or stop those services.  See :manpage:`systemd.service(5)`.
+
+To support other init systems, packages that include daemons for system
+services should place scripts in ``/etc/init.d`` to start or stop those
+services at boot time or during a change of runlevel. These scripts should
+be named ``/etc/init.d/package``, and they should accept one argument,
+saying what to do:
 
 ``start``
 start the service,

Ansgar, does that look good to you?  If so, it also needs one more second.

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

Bug#944071: RFS: trace-cmd/2.8.3-1 -- Utility for retrieving and analyzing function tracing in the kernel

[Adam Borowski]

On Sun, Nov 03, 2019 at 07:22:38PM +, Sudip Mukherjee wrote:
>  * Package name: trace-cmd
>Version : 2.8.3-1

> Changes since the last upload:
> 
>* Update to upstream v2.8.3 and change maintainer (Closes: #943551)

Fails to build for me:

NO_PYTHON forced: swig not installed, not compiling python plugins

/bin/sh: 1: /usr/bin/cmake: not found

which is quite obvious...

Full log: http://ix.io/20JX


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#943891: umoci: autopkgtest regression: can't load package: package .: no Go files

[Paul Gevers]

Hi Dmitry

On 02-11-2019 08:31, Dmitry Smirnov wrote:
> On Saturday, 2 November 2019 5:38:33 PM AEDT Dmitry Smirnov wrote:
>> I have noticed the problem but I can neither reproduce not understand what
>> is causing it. I suspect a bug in autopkgtest as I don't see why would
>> that particular command fail.

Do you mean autodep8 here? I don't see how autopkgtest could be to
blame, but please enlighten me.

> What is almost certain is that the problem is not in "umoci". Test started to 
> fail after introduction of "-dev" package but not because of this unrelated 
> change...

It's hard to believe otherwise. The test has now been performed on a
daily basis since 2019-10-13 and has been failing systematically for the
new version, while it systematically passes for the old version (in
testing, of which the latest one was today). In unstable, the switch
from passing to failing was with the upload of the new version.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#944078: firewall-applet: applet does not appear

[Toni Mueller]

Package: firewall-applet
Version: 0.7.2-1
Severity: important

Dear Maintainer,

I am trying to run the firewall-applet on my buster machine, and neither
the buster version nor the version in testing actually create the tray
applet. Instead, the program just hangs with no output. For the buster
version, I have stepped through the program to figure out where it
hangs:

$ python3 -m pdb /usr/bin/firewall-applet 
> /usr/bin/firewall-applet(23)()
-> import sys
(Pdb) n
> /usr/bin/firewall-applet(24)()
-> from PyQt5 import QtGui, QtCore, QtWidgets
(Pdb) 
> /usr/bin/firewall-applet(26)()
-> import gi
(Pdb) 
> /usr/bin/firewall-applet(27)()
-> gi.require_version('Notify', '0.7')
(Pdb) 
> /usr/bin/firewall-applet(28)()
-> from gi.repository import Notify
(Pdb) 
> /usr/bin/firewall-applet(30)()
-> import os
(Pdb) 
> /usr/bin/firewall-applet(31)()
-> from dbus.mainloop.pyqt5 import DBusQtMainLoop
(Pdb) 
> /usr/bin/firewall-applet(32)()
-> import functools
(Pdb) 
> /usr/bin/firewall-applet(34)()
-> from firewall import config
(Pdb) 
> /usr/bin/firewall-applet(35)()
-> from firewall.core.fw_nm import nm_is_imported, nm_get_zone_of_connection, \
(Pdb) 
> /usr/bin/firewall-applet(39)()
-> from firewall.core.watcher import Watcher
(Pdb) 
> /usr/bin/firewall-applet(40)()
-> from firewall.client import FirewallClient
(Pdb) 
> /usr/bin/firewall-applet(41)()
-> import slip.dbus
(Pdb) 
> /usr/bin/firewall-applet(42)()
-> import dbus
(Pdb) 
> /usr/bin/firewall-applet(43)()
-> import signal
(Pdb) 
> /usr/bin/firewall-applet(45)()
-> import gettext
(Pdb) 
> /usr/bin/firewall-applet(46)()
-> gettext.textdomain(config.DOMAIN)
(Pdb) 
> /usr/bin/firewall-applet(47)()
-> _ = gettext.gettext
(Pdb) 
> /usr/bin/firewall-applet(49)()
-> PATH = [ ]
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(54)()
-> def search_app(app):
(Pdb) 
> /usr/bin/firewall-applet(61)()
-> NM_CONNECTION_EDITOR = ""
(Pdb) 
> /usr/bin/firewall-applet(62)()
-> for binary in [ "/usr/bin/nm-connection-editor",
(Pdb) 
> /usr/bin/firewall-applet(68)()
-> if os.path.exists(binary):
(Pdb) 
> /usr/bin/firewall-applet(69)()
-> NM_CONNECTION_EDITOR = binary
(Pdb) 
> /usr/bin/firewall-applet(70)()
-> break
(Pdb) 
> /usr/bin/firewall-applet(72)()
-> PY2 = sys.version < '3'
(Pdb) 
> /usr/bin/firewall-applet(74)()
-> def escape(text):
(Pdb) 
> /usr/bin/firewall-applet(80)()
-> def fromUTF8(text):
(Pdb) 
> /usr/bin/firewall-applet(87)()
-> class ZoneInterfaceEditor(QtWidgets.QDialog):
(Pdb) 
> /usr/bin/firewall-applet(160)()
-> class ZoneConnectionEditor(ZoneInterfaceEditor):
(Pdb) 
> /usr/bin/firewall-applet(185)()
-> class ZoneSourceEditor(ZoneInterfaceEditor):
(Pdb) 
> /usr/bin/firewall-applet(201)()
-> class 

Bug#943833: [src:x11vnc] Drop bundled libvncserver/libvncclient

[Mike Gabriel]

Control: close -1
Control: fixed -1 0.9.16-1

Am Sonntag, 3. November 2019 schrieb Antoni Villalonga:
> On Wed, Oct 30, 2019 at 02:59:32PM +, Mike Gabriel wrote:
> > Package: src:x11vnc
> > Version: 0.9.13-6
> > Severity: wishlist
> > 
> > While this is not a functionality improvement, it helps with security
> > audits. Please consider removing the libvncclient/ and libvncserver/ folders
> > from the x11vnc orig tarball. Thanks!
> 
> Hi Mike,
> 
> I've uploaded x11vnc 0.9.16-1 to experimental.
> Can we consider this bug fixed on that version?
> 
> Thanks for your time!

Yes, perfect.

Mike

-- 
Gesendet von meinem Fairphone2 (powered by Sailfish OS).

Bug#944070: libtest-corpus-audio-mpd-perl: Won't migrate to testing due to non-source-only upload

[gregor herrmann]

On Sun, 03 Nov 2019 14:18:37 -0500, Boyuan Yang wrote:

> Dear libtest-corpus-audio-mpd-perl maintainers,
> 
> I noticed that libtest-corpus-audio-mpd-perl cannot migrate to testing since
> the latest upload (back in 2015) was not a source-only upload. This issue is
> blocking package mpdtoys from migrating to testing.

Thanks for caring about libtest-corpus-audio-mpd-perl.
Feel free to reschedule the NUM to 0-day.

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#938661: theano: remove python2

[Thomas Goirand]

Hi Rebecca,

I've just uploaded the Python 2 removal from deepnano (ie: I switched it
to Python 3). It looks like working... ;)

So, now there's no blockger for theano. Please upload what I saw you
commited in the Git repo for Theano! Since you're a DM, I'm guessing you
already have a ACL for this package. If you still need sponsoring, let
me know, and I'll sponsor the upload for you.

Thanks for your work,
Cheers,

Thomas Goirand (zigo)

Bug#943974: [debian-mysql] Bug#943974: mariadb-server-10.3: as "service mysql stop" fails, system refuse to shut down

[Otto Kekäläinen]

Did you investigate anything suggested in
https://forum.manjaro.org/t/computer-does-not-shut-down-because-of-mariadb/81565
?
Did you figure it out?

Bug#944038: gpsd missing sysvinit script and breaks functionality on upgrade

[Bernd Zeimetz]

On 11/3/19 8:51 PM, Joerg Dorchain wrote:
> I would expect more
> explicit hints for such drastic changes from my favourite
> distribution.

- Your favorite distribution uses systemd as default, expect init script
to be broken and/or not maintained at all. I'm not maintaining something
I'm not going to use, not going to test, and that most people do not
care about.

- Your favorite distribution will soon have a GR about which init
system(s) will be supported in the future. If it forces me to maintain
init script, you can happily adopt the gpsd package. If not, you'll get
a very prominent hint. So I'm not going to change anything on the gpsd
package now. Sorry.

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

Bug#895917: Libav-tools relegated to Suggests

[Bálint Réczey]

Hi Ross,

IMO the practice of referencing packages which do not exist in the
current release from debian-multimedia just to keep an autogenerated
listing of packages include them for the benefit of the users of
previous releases is backwards.
The page should just show the union of the the dependencies of the
debian-multimedia's binary packages for all interesting releases.

Cheers,
Balint

Bug#941907: transition: ocaml

[Paul Gevers]

Control: tags -1 confirmed

Hi Stéphane,

On 07-10-2019 15:50, Stéphane Glondu wrote:
> I think it's time to upgrade OCaml to 4.08.1.
> 
> It has been uploaded to experimental, and builds fine on all release
> architectures. [1]
> 
> Most of reverse-dependencies recompile fine with no changes (on
> amd64). [2]
> 
> Bug reports have been (or will be) reported for the few packages that
> need action. [3]
> 
> [1] https://buildd.debian.org/status/package.php?p=ocaml=experimental
> [2] https://ocaml.debian.net/transitions/ocaml-4.08.0/

This link never works for me.

> [3] 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ocaml-4.08-transition;users=debian-ocaml-ma...@lists.debian.org
> 
> I will take care of the necessary binNMUs.

Please go ahead.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#940595: transition: hypre

[Paul Gevers]

Control: tags -1 confirmed

Hi Drew,

On 30-10-2019 08:26, Drew Parsons wrote:
> So yes, the unversioned libhypre package name is certainly the option
> that will preserve the greatest sanity (I'll proceed directly with
> 2.18.2 once you give the thumbs up).

Thumbs up.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#944038: gpsd missing sysvinit script and breaks functionality on upgrade

[Joerg Dorchain]

On Sun, Nov 03, 2019 at 04:39:59PM +0100, Bernd Zeimetz wrote:
> > Justification: Breaks silently functionality on upgrade
> 
> not if you'd use the default init system.

Policy says all init system are equally supported.

> 
> > In my setup, gpsd is required to start at system boot with a sysv
> > init.
> 
> That is not supported by the gpsd upstream anymore, all the
> hotplugging/udev rules require systemd (which makes a lot of sense!),
> and to avoid a mess in debugging this, I'm not going to change this.

Hm. Upstream has an init script...

If you do not accept bug reports about sysvinit, make this clear
in a README.Debian, but please still ship the script, even if it
is under documenation. Other packages, e.g. sendmail, have an
explicit config setting where the admin has all freedom with own
config at the price of explicitly getting no maintainer support.
> 
> 
> > The upgrading process stops the running gpsd, and without the
> > init script, it is not restarted, resulting in a system without
> > gps information.
> > 
> > Please bring the init script back.
> no. please use systemd.

systemd is not an option.

If you have reasons not supporting sysvinit (if it is lack of
time, I could help), then at least do not siliently have a
disrupting break in functionality.

The package system has ways to tell the admin that he needs to do
something, like e.g. an acknowledgement on upgrade, or at least
a NEWS.Debian file.

Just without a decent warning stopping gpsd and not telling about
it is IMHO at the very least impolite. I would expect more
explicit hints for such drastic changes from my favourite
distribution.

Thanks for considering.

Bye,

Joerg



signature.asc
Description: PGP signature

Bug#942707: transition: aqbanking6

[Paul Gevers]

Control: tags -1 confirmed

Hi Micha,

On 20-10-2019 13:47, Micha Lenk wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi release team,
> 
> AqBanking and Gwenhywfar, a Germany focused pair of libraries for online
> banking data exchange, recently ceased to work because bank server behavior
> changes that were caused by legal changes. The upstream author of these
> libraries is working on nnew releases, which I would like to upload to 
> unstable
> soon, so that affected users will find better usable library versions in the
> archive.
> 
> Due to soname bumps this upload will result in a multi package transition. The
> impacted source packages are:
> - libgwenhywfar: Already uploaded to experimental
> - libaqbanking: Already uploaded to experimental
> - kmymoney: Will need to be updated to newer upstream version 5.0.7 for 
> passing
>   builds (see also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942417).
> - gnucash: Will need only a binNMU
> 
> Please ACK the transition when you consider it ready for upload.

Please go ahead.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#944077: libclass-methodmaker-perl FTCBFS: Missing Build-Depends: perl-xs-dev

[Helmut Grohne]

Source: libclass-methodmaker-perl
Version: 2.24-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Thanks to Niko's work, debhelper now knows how to cross and we have a
temporary provides for perl-xs-dev. As it happens, this is enough to
make libclass-methodmaker-perl cross buildable if one adds the build
dependency on perl-xs-dev. Some other perl extensions already have
become cross buildable.

Helmut
diff --minimal -Nru libclass-methodmaker-perl-2.24/debian/changelog 
libclass-methodmaker-perl-2.24/debian/changelog
--- libclass-methodmaker-perl-2.24/debian/changelog 2015-05-02 
22:22:07.0 +0200
+++ libclass-methodmaker-perl-2.24/debian/changelog 2019-11-03 
19:53:00.0 +0100
@@ -1,3 +1,10 @@
+libclass-methodmaker-perl (2.24-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Missing Build-Depends: perl-xs-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 03 Nov 2019 19:53:00 +0100
+
 libclass-methodmaker-perl (2.24-1) unstable; urgency=medium
 
   [ Salvatore Bonaccorso ]
diff --minimal -Nru libclass-methodmaker-perl-2.24/debian/control 
libclass-methodmaker-perl-2.24/debian/control
--- libclass-methodmaker-perl-2.24/debian/control   2015-05-02 
22:22:07.0 +0200
+++ libclass-methodmaker-perl-2.24/debian/control   2019-11-03 
19:52:58.0 +0100
@@ -8,7 +8,8 @@
 Testsuite: autopkgtest-pkg-perl
 Priority: optional
 Build-Depends: debhelper (>= 9.20120312~),
-   libipc-run-perl
+   libipc-run-perl,
+   perl-xs-dev,
 Standards-Version: 3.9.6
 Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-perl/packages/libclass-methodmaker-perl.git
 Vcs-Git: 
git://anonscm.debian.org/pkg-perl/packages/libclass-methodmaker-perl.git

Bug#944033: /usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_all_cron: mail from weekly cronjob

[Darrick J. Wong]

On Sun, Nov 03, 2019 at 08:17:30AM -0500, Theodore Y. Ts'o wrote:
> On Sun, Nov 03, 2019 at 05:07:22AM +0100, gregor herrmann wrote:
> > 
> > Cron sends me the following mail once per week:
> > 
> > /sbin/e2scrub_all: line 173: /proc/8234/fd/pipe:[90083173]: No such file or 
> > directory
> 
> Gregor, thanks for the bug report!  This is coming from:
> 
> stdin="$(realpath /dev/stdin)"
>...
> ${DBG} "@root_sbindir@/e2scrub" ${scrub_args} "${tgt}" < "${stdin}"
> 
> I'm not sure why this hack is there at all.  Darrick, can you shed any
> light?  What was the original intent of redirecting stdin to the
> realpath of /dev/stdin?

Because if you don't do that, the e2scrub process gets started with fd 0
mapped to stdout of ls_targets on account of the "ls_targets | while
read tgt" loop.  Yay bash.  I guess the problem here is that
e2scrub_all's stdin is itself a pipe, so /dev/stdin maps to
/proc/self/fd/0, is a symlink to "pipe:[]" which doesn't help us
any.

We could amend the e2scrub_all script to do:

stdin="$(realpath /dev/stdin)"
test -w "${stdin}" || stdin=/dev/null

So at least you won't get that complaint from the cron job... I don't
know of a good way to work around the "ls_targets | while loop" idiom.

for i in $(ls_targets); do ... done

doesn't escape spaces at all, and if there are a lot of LVs on the
system we can potentially exhaust bash's command line length maximum.

I guess one could restructure the script so that "ls_targets" has the
side effect of generating a bash array containing all eligible targets
and then change the loop to "for tgt in "${targets[@]}"; do ... done".
Pretty gross of a coding strategy but ... it's bash.

--D

> Thanks,
> 
>- Ted

Bug#938735: txt2tags: Python2 removal in sid/bullseye

[Ricardo Mones]

Source: txt2tags
Followup-For: Bug #938735

Hi,

Seems somebody has ported this to Python 3:
https://github.com/jendrikseipp/txt2tags

This could be a better alternative to removal of the package in case
current upstream doesn't provide an updated version.

HTH,

-- System Information:
Debian Release: 10.1
  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=es_ES.UTF-8, LC_CTYPE=es_ES.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#944076: python-coverage: autopkgtest regression: Can't load /usr/share/doc/python-coverage/html/index.html

[Paul Gevers]

Source: python-coverage
Version: 4.5.2+dfsg.1-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of python-coverage the autopkgtest of
python-coverage fails in testing when that autopkgtest is run with the
binary packages of python-coverage from unstable. It passes when run
with only packages from testing. In tabular form:
   passfail
python-coveragefrom testing4.5.2+dfsg.1-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python-coverage

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-coverage/3323210/log.gz

autopkgtest [05:10:13]: test command1:   w3m -dump
/usr/share/doc/python-coverage/html/index.html > /dev/null
autopkgtest [05:10:13]: test command1: [---
w3m: Can't load /usr/share/doc/python-coverage/html/index.html.
autopkgtest [05:10:13]: test command1: ---]


autopkgtest [05:10:50]: test command2:   file --brief
/usr/share/doc/python-coverage/html/index.html| grep -q 'HTML document'
autopkgtest [05:10:50]: test command2: [---
autopkgtest [05:10:51]: test command2: ---]
autopkgtest [05:10:51]: test command2:  - - - - - - - - - - results - -
- - - - - - - -
command2 FAIL non-zero exit status 1




signature.asc
Description: OpenPGP digital signature

Bug#943609: breezy ftbfs with python 3.8

[Jelmer Vernooij]

On Sun, Oct 27, 2019 at 11:27:00AM +0100, Matthias Klose wrote:
> Package: src:breezy
> Version: 3.0.1-6
> Severity: important
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: python3.8
> 
> breezy fails when trying to build for python 3.8:
> 
> 
> breezy/_simple_set_pyx.c:318:11: error: too many arguments to function 
> ‘PyCode_New’
>   318 |   PyCode_New(a, 0, k, l, s, f, code, c, n, v, fv, cell, fn,
> name, fline, lnos)
>   |   ^~
> breezy/_simple_set_pyx.c:8604:15: note: in expansion of macro 
> ‘__Pyx_PyCode_New’
>  8604 | py_code = __Pyx_PyCode_New(
>   |   ^~~~
> In file included from /usr/include/python3.8/compile.h:5,
>  from /usr/include/python3.8/Python.h:138,
>  from breezy/_simple_set_pyx.c:4:
> /usr/include/python3.8/code.h:122:28: note: declared here
>   122 | PyAPI_FUNC(PyCodeObject *) PyCode_New(
>   |^~

This is fixed upstream. Unfortunately my key expired, so I need to
wait for the next upload of debian-keyring before I can fix this.

Jelmer


signature.asc
Description: PGP signature

Bug#944074: tryton-proteus breaks tryton-modules-account-fr autopkgtest: Doctest: scenario_fec.rst ... FAIL

[Paul Gevers]

Source: tryton-proteus, tryton-modules-account-fr
Control: found -1 tryton-proteus/5.0.4-1
Control: found -1 tryton-modules-account-fr/5.0.1-2
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of tryton-proteus the autopkgtest of
tryton-modules-account-fr fails in testing when that autopkgtest is run
with the binary packages of tryton-proteus from unstable. It passes when
run with only packages from testing. In tabular form:
  passfail
tryton-proteusfrom testing5.0.4-1
tryton-modules-account-fr from testing5.0.1-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of tryton-proteus to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=tryton-proteus

https://ci.debian.net/data/autopkgtest/testing/amd64/t/tryton-modules-account-fr/3324532/log.gz

/usr/lib/python3/dist-packages/trytond/modules/account_fr/tests/scenario_fec.rst
Doctest: scenario_fec.rst ... FAIL

==
FAIL:
/usr/lib/python3/dist-packages/trytond/modules/account_fr/tests/scenario_fec.rst
Doctest: scenario_fec.rst
--
Traceback (most recent call last):
  File "/usr/lib/python3.7/doctest.py", line 2196, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for scenario_fec.rst
  File
"/usr/lib/python3/dist-packages/trytond/modules/account_fr/tests/scenario_fec.rst",
line 0

--
File
"/usr/lib/python3/dist-packages/trytond/modules/account_fr/tests/scenario_fec.rst",
line 148, in scenario_fec.rst
Failed example:
with io.open(file, mode='rb') as fp:
FEC.form.file.decode('utf-8') == fp.read().decode('utf-8')
Expected:
True
Got:
False




signature.asc
Description: OpenPGP digital signature

Bug#944073: tryton-proteus breaks tryton-modules-purchase-request autopkgtest: trytond.exceptions.UserError: ('UserError', ('Purchase requests are only created by the system.', ''))

[Paul Gevers]

Source: tryton-proteus, tryton-modules-purchase-request
Control: found -1 tryton-proteus/5.0.4-1
Control: found -1 tryton-modules-purchase-request/5.0.2-2
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of tryton-proteus the autopkgtest of
tryton-modules-purchase-request fails in testing when that autopkgtest
is run with the binary packages of tryton-proteus from unstable. It
passes when run with only packages from testing. In tabular form:
passfail
tryton-proteus  from testing5.0.4-1
tryton-modules-purchase-request from testing5.0.2-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of tryton-proteus to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=tryton-proteus

https://ci.debian.net/data/autopkgtest/testing/amd64/t/tryton-modules-purchase-request/3324533/log.gz

/usr/lib/python3/dist-packages/trytond/modules/purchase_request/tests/scenario_purchase_request.rst
Doctest: scenario_purchase_request.rst ... FAIL

==
FAIL:
/usr/lib/python3/dist-packages/trytond/modules/purchase_request/tests/scenario_purchase_request.rst
Doctest: scenario_purchase_request.rst
--
Traceback (most recent call last):
  File "/usr/lib/python3.7/doctest.py", line 2196, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for scenario_purchase_request.rst
  File
"/usr/lib/python3/dist-packages/trytond/modules/purchase_request/tests/scenario_purchase_request.rst",
line 0

--
File
"/usr/lib/python3/dist-packages/trytond/modules/purchase_request/tests/scenario_purchase_request.rst",
line 228, in scenario_purchase_request.rst
Failed example:
pr.save()
Exception raised:
Traceback (most recent call last):
  File "/usr/lib/python3.7/doctest.py", line 1329, in __run
compileflags, 1), test.globs)
  File "", line 1, in

pr.save()
  File "/usr/lib/python3/dist-packages/proteus/__init__.py", line
93, in newfunc
return self.func(owner, [instance], *args, **kwargs)
  File "/usr/lib/python3/dist-packages/proteus/__init__.py", line
816, in save
ids = proxy.create(values, context)
  File "/usr/lib/python3/dist-packages/proteus/config.py", line 195,
in __call__
result = rpc.result(meth(*args, **kwargs))
  File
"/usr/lib/python3/dist-packages/trytond/modules/purchase_request/purchase_request.py",
line 264, in create
cls.raise_user_error('create_request')
  File "/usr/lib/python3/dist-packages/trytond/error.py", line 74,
in raise_user_error
raise UserError(error)
trytond.exceptions.UserError: ('UserError', ('Purchase requests are
only created by the system.', ''))



signature.asc
Description: OpenPGP digital signature

Bug#944075: RM: thunderbird [armel armhf] -- ROM; decreased supported build architectures for ESR series 68.x

[Carsten Schoenert]

Package: ftp.debian.org
Severity: normal

Dear FTP-Masters,

Thunderbird is partielly following the needed removel request for
firefox-esr.

Like for Firefox also Thunderbird wont ever get able to build on armel
due the lack of node-js as a build dependency.

And armhf is failing to build due memory exhausting issues while linking
libxul.so since the early beginning of uploading Thunderbird 68.x to
experimental. So far nobody has provided any fix for this issue until
now and I'm unable to solve this problem in the near future.

So I hereby request the removal of Thunderbird binary packages on armel
and armhf within unstable so the current version of Thunderbird can
migrate to testing.

Regards
Carsten

Bug#918430: find /tmp/ -path /tm

[Gabriel F. T. Gomes]

Forwarded upstream as https://github.com/scop/bash-completion/pull/359

Bug#944072: tlsh: autopkgtest regression: No such file or directory: 'debian/tests/use-python-tlsh'

[Paul Gevers]

Source: tlsh
Version: 3.4.4+20151206-1.2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, mo...@debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of tlsh the autopkgtest of tlsh fails in testing
when that autopkgtest is run with the binary packages of tlsh from
unstable. It passes when run with only packages from testing. In tabular
form:
   passfail
tlsh   from testing3.4.4+20151206-1.2
all others from testingfrom testing

I copied some of the output at the bottom of this report. @Sandro, it
seems you removed one file too many in your last NMU. The python3 test
uses the python2 code.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=tlsh

https://ci.debian.net/data/autopkgtest/testing/amd64/t/tlsh/3323213/log.gz

autopkgtest [05:10:43]: test use-python3-tlsh: [---
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.cwk94dux/downtmp/build.nV3/src/debian/tests/use-python3-tlsh",
line 6, in 
globals = runpy.run_path('debian/tests/use-python-tlsh')
  File "/usr/lib/python3.7/runpy.py", line 261, in run_path
code, fname = _get_code_from_file(run_name, path_name)
  File "/usr/lib/python3.7/runpy.py", line 231, in _get_code_from_file
with open(fname, "rb") as f:
FileNotFoundError: [Errno 2] No such file or directory:
'debian/tests/use-python-tlsh'
autopkgtest [05:10:43]: test use-python3-tlsh: ---]



signature.asc
Description: OpenPGP digital signature

Bug#944071: RFS: trace-cmd/2.8.3-1 -- Utility for retrieving and analyzing function tracing in the kernel

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "trace-cmd"

 * Package name: trace-cmd
   Version : 2.8.3-1
   Upstream Author : Steven Rostedt rost...@goodmis.org
 * URL : http://kernelshark.org/
 * License : GPL-2
 * Vcs : https://github.com/sudipm-mukherjee/trace-cmd.git
   Section : devel

It builds those binary packages:

  trace-cmd - Utility for retrieving and analyzing function tracing in the 
kernel
  kernelshark - Utilities for graphically analyzing function tracing in the 
kernel.

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

  https://mentors.debian.net/package/trace-cmd

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/trace-cmd/trace-cmd_2.8.3-1.dsc

Changes since the last upload:

   * Update to upstream v2.8.3 and change maintainer (Closes: #943551)



-- 
Regards
Sudip

Bug#944070: libtest-corpus-audio-mpd-perl: Won't migrate to testing due to non-source-only upload

[Boyuan Yang]

Package: libtest-corpus-audio-mpd-perl
Version: 1.120990-2
Control: tags -1 + pending patch
X-Debbugs-CC: gre...@debian.org fschl...@zedat.fu-berlin.de

Dear libtest-corpus-audio-mpd-perl maintainers,

I noticed that libtest-corpus-audio-mpd-perl cannot migrate to testing since
the latest upload (back in 2015) was not a source-only upload. This issue is
blocking package mpdtoys from migrating to testing.

In order to solve this, I just made a non-maintainer source-only upload of
DELAYED/3 with minimal changes on top of package's git packaging repo at 
https://salsa.debian.org/perl-team/modules/packages/libtest-corpus-audio-mpd-perl
. Please let me know if I should delay it longer.

The full diff is provided as follows.

-- 
Best,
Boyuan Yang


commit 0f118f3f7cadb1679a9304338e38cdae57afa090
Author: Boyuan Yang 
Date:   Sun Nov 3 12:19:31 2019 -0500

debian/changelog: Use new source-only NMU

diff --git a/debian/changelog b/debian/changelog
index 037c8d2..627bd08 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,10 @@
-libtest-corpus-audio-mpd-perl (1.120990-3) UNRELEASED; urgency=medium
+libtest-corpus-audio-mpd-perl (1.120990-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Boyuan Yang ]
+  * Source-only upload to allow testing migration. Source package
+prepared from master branch of the git repository.
 
   [ Salvatore Bonaccorso ]
   * debian/control: Use HTTPS transport protocol for Vcs-Git URI
@@ -13,7 +19,7 @@ libtest-corpus-audio-mpd-perl (1.120990-3) UNRELEASED;
urgency=medium
   [ Salvatore Bonaccorso ]
   * Update Vcs-* headers for switch to salsa.debian.org
 
- -- Salvatore Bonaccorso   Sat, 30 Jan 2016 20:06:49 +0100
+ -- Boyuan Yang   Sun, 03 Nov 2019 12:18:18 -0500
 
 libtest-corpus-audio-mpd-perl (1.120990-2) unstable; urgency=low


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

Bug#944069: block iwd 1.0 testing migration

[Andreas Henriksson]

Package: iwd
Version: 1.0-1
Severity: serious

This bug report was opened to temporarily prevent iwd 1.0 from migrating
to testing to give NetworkManager some time to catch up.

Regards,
Andreas Henriksson

Bug#944068: git-daemon-run: Pending update in runit will make git-daemon-run buggy

[Lorenzo Puliti]

Package: git-daemon-run
Version: 1:2.24.0~rc2-1dotlink1
Severity: normal
Tags: patch

Dear Git Maintainer,
(runit maintainer in CC)

Since runit 2.1.2-36, update-service will be used also to record the local admin
settings about the wanted status of a service (enabled/disabled).
See #942323 to understand why this was done.
This change will make git-daemon-run buggy in that using update-service
in maintscripts will overwrite local admin preference.

I've attached a patch that tries to emulate the logic of dh-runit, can you
have a look? Ideally this should be uploaded before runit.

Thanks,
Lorenzo 

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

Kernel: Linux 4.20.3-van (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages git-daemon-run depends on:
ii  adduser  3.118
ii  git  1:2.24.0~rc2-1
ii  runit2.1.2-35

git-daemon-run recommends no packages.

git-daemon-run suggests no packages.

-- no debconf information
>From 789e8e894973f529f3ee507143a44ffc1dea1bcc Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti 
Date: Sun, 3 Nov 2019 19:20:45 +0100
Subject: [PATCH] Git-daemon-run: preserve local admin settings

Preserve local admin decision to keep git-daemon disabled:
this will prevent from enabling the service when a
'.git-daemon' symlink exists at postinstall stage; also
this means that the '.git-daemon' symlink should be preserved
at prerm stage, but only if it was a local admin decision.
---
 debian/git-daemon-run.postinst | 10 ++
 debian/git-daemon-run.postrm   |  1 +
 debian/git-daemon-run.prerm| 10 ++
 3 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/debian/git-daemon-run.postinst b/debian/git-daemon-run.postinst
index 00a4d38459..9ec0435f7d 100644
--- a/debian/git-daemon-run.postinst
+++ b/debian/git-daemon-run.postinst
@@ -17,7 +17,9 @@ test -z "$2" || dpkg --compare-versions "$2" gt '1:1.5.4.2-1' 
|| {
 }
 
 # enable git-daemon service
-update-service --add /etc/sv/git-daemon
-
-# restart git-daemon service if it was running
-test -z "$2" || sv -v term git-daemon || :
+# no-op if the admin set it as 'disabled'
+if [ ! -h /etc/service/.git-daemon ]; then
+  update-service --add /etc/sv/git-daemon
+  # restart git-daemon service if it was running
+  test -z "$2" || sv -v term git-daemon || :
+fi
diff --git a/debian/git-daemon-run.postrm b/debian/git-daemon-run.postrm
index f6aa282d05..f73b1d6bf1 100644
--- a/debian/git-daemon-run.postrm
+++ b/debian/git-daemon-run.postrm
@@ -16,6 +16,7 @@ for i in '@*' current config lock state; do
   rm -f /var/log/git-daemon/$i
 done
 rmdir /var/log/git-daemon || :
+rm -f /etc/service/.git-daemon
 
 getent passwd gitlog >/dev/null || exit 0
 ! deluser --version >/dev/null 2>&1 || exec deluser -f gitlog
diff --git a/debian/git-daemon-run.prerm b/debian/git-daemon-run.prerm
index 0685520903..ad8734a06d 100644
--- a/debian/git-daemon-run.prerm
+++ b/debian/git-daemon-run.prerm
@@ -6,4 +6,14 @@ set -e
 test "$1" = 'remove' || test "$1" = 'deconfigure' || \
   test "$1" = 'failed-upgrade' || exit 0
 
+disabled=0
+
+if [ -h /etc/service/.git-daemon ]; then
+  disabled=1
+fi
+
 update-service --remove /etc/sv/git-daemon || :
+
+if [ "$disabled" = 0 ]; then
+  rm -f /etc/service/.git-daemon
+fi
-- 
2.24.0.rc2

Bug#944067: linux-image-5.3.0-1-amd64: Kernel >5.0 breaks modules signed via MOK key

[Arman Hajishafieha]

Package: src:linux
Version: 5.3.7-1
Severity: important
Tags: upstream

Dear Maintainer,

Apparently as of kernel 5.0, all keys picked up from uefi are put in the
.platform keyring, which are not trusted by kernel to be used for module
signing. This makes it impossible to insmod third party modules when secure
boot is enabled using the method described in
(https://wiki.debian.org/SecureBoot).

This problem was discussed in
(https://bugzilla.redhat.com/show_bug.cgi?id=1701096) and a patch was submitted
to trust .platform keyring for module signing.

Perhaps debian could take the same approach.



-- Package-specific info:
** Version:
Linux version 5.3.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 
20191008 (Debian 9.2.1-9)) #1 SMP Debian 5.3.7-1 (2019-10-19)

** Command line:
BOOT_IMAGE=/vmlinuz-5.3.0-1-amd64 
root=UUID=c84374eb-fdb3-44d4-9307-c7a0d2babaee ro quiet net.ifnames=0

** Not tainted

** Kernel log:
[7.941164] MCE: In-kernel MCE decoding enabled.
[7.943012] EDAC amd64: Node 0: DRAM ECC disabled.
[7.943014] EDAC amd64: ECC disabled in the BIOS or no ECC capability, 
module will not load.
Either enable ECC checking or force module loading by setting 
'ecc_enable_override'.
(Note that use of the override may cause unknown side effects.)
[7.944815] snd_hda_codec_generic hdaudioC0D0: ignore pin 0x7, too many 
assigned pins
[7.944829] snd_hda_codec_generic hdaudioC0D0: ignore pin 0x9, too many 
assigned pins
[7.944843] snd_hda_codec_generic hdaudioC0D0: ignore pin 0xb, too many 
assigned pins
[7.944845] snd_hda_codec_generic hdaudioC0D0: autoconfig for Generic: 
line_outs=0 (0x0/0x0/0x0/0x0/0x0) type:line
[7.944846] snd_hda_codec_generic hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[7.944848] snd_hda_codec_generic hdaudioC0D0:hp_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[7.944849] snd_hda_codec_generic hdaudioC0D0:mono: mono_out=0x0
[7.944850] snd_hda_codec_generic hdaudioC0D0:dig-out=0x3/0x5
[7.944851] snd_hda_codec_generic hdaudioC0D0:inputs:
[7.947458] input: HDA ATI HDMI HDMI as 
/devices/pci:00/:00:03.1/:07:00.1/sound/card0/input11
[7.947500] input: HDA ATI HDMI HDMI as 
/devices/pci:00/:00:03.1/:07:00.1/sound/card0/input12
[7.950359] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC887-VD: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line
[7.950361] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[7.950362] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 
(0x1b/0x0/0x0/0x0/0x0)
[7.950363] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0
[7.950363] snd_hda_codec_realtek hdaudioC1D0:dig-out=0x11/0x0
[7.950364] snd_hda_codec_realtek hdaudioC1D0:inputs:
[7.950365] snd_hda_codec_realtek hdaudioC1D0:  Front Mic=0x19
[7.950366] snd_hda_codec_realtek hdaudioC1D0:  Rear Mic=0x18
[7.950367] snd_hda_codec_realtek hdaudioC1D0:  Line=0x1a
[7.998246] systemd-journald[558]: Received request to flush runtime journal 
from PID 1
[7.998998] input: HD-Audio Generic Rear Mic as 
/devices/pci:00/:00:08.1/:09:00.3/sound/card1/input13
[7.999112] input: HD-Audio Generic Line as 
/devices/pci:00/:00:08.1/:09:00.3/sound/card1/input14
[7.999180] input: HD-Audio Generic Line Out as 
/devices/pci:00/:00:08.1/:09:00.3/sound/card1/input15
[8.022089] EDAC amd64: Node 0: DRAM ECC disabled.
[8.022090] EDAC amd64: ECC disabled in the BIOS or no ECC capability, 
module will not load.
Either enable ECC checking or force module loading by setting 
'ecc_enable_override'.
(Note that use of the override may cause unknown side effects.)
[8.027667] EXT4-fs (sda2): mounting ext2 file system using the ext4 
subsystem
[8.030522] EXT4-fs (sda2): mounted filesystem without journal. Opts: (null)
[8.081491] Adding 1952764k swap on /dev/mapper/swap_crypt.  Priority:-2 
extents:1 across:1952764k SSFS
[8.118492] EDAC amd64: Node 0: DRAM ECC disabled.
[8.118494] EDAC amd64: ECC disabled in the BIOS or no ECC capability, 
module will not load.
Either enable ECC checking or force module loading by setting 
'ecc_enable_override'.
(Note that use of the override may cause unknown side effects.)
[8.190467] EDAC amd64: Node 0: DRAM ECC disabled.
[8.190470] EDAC amd64: ECC disabled in the BIOS or no ECC capability, 
module will not load.
Either enable ECC checking or force module loading by setting 
'ecc_enable_override'.
(Note that use of the override may cause unknown side effects.)
[8.212369] usblp 3-1:1.0: usblp1: USB Bidirectional printer dev 2 if 0 alt 
0 proto 2 vid 0x03F0 pid 0x952A
[8.212392] usbcore: registered new interface driver usblp
[8.270440] EDAC amd64: Node 0: DRAM ECC disabled.
[8.270444] EDAC amd64: ECC disabled 

Bug#944066: golang-github-nrdcg-goinwx: Please update/expand "Andrew" copyright holder

[Chris Lamb]

Source: golang-github-nrdcg-goinwx
Version: 0.6.1-1
Severity: wishlist
X-Debbugs-CC: Thorsten Alteholz , 
ftpmas...@debian.org

Hi,

I just ACCEPTed golang-github-nrdcg-goinwx from NEW but was wondering 
if you could find a nicer copyright holder name than just "Andrew."

Whatever the legality of this (the discussion I will leave to others
to dissect ad nauseum…) it just doesn't feel Pquite right to me.


Best wishes,

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

Bug#942206: Unable to install libreoffice-{avmedia-backend-vlc, core, kde, ogltrans, pdfimport} packages in buster-backports

[s3v]

Dear Maintainer,

libreoffice (versioned as 1:6.3.3-2~bpo10+1) migrated in bpo but the problem is
still there.

Kind regards.

Bug#944065: checkstyle: Wrapper script run fails due to unresolved picocli dependency

[Timo Kalliomäki]

Package: checkstyle
Version: 8.15-1
Severity: normal

Dear Maintainer,

checkstyle can not be run with the wrapper script (/usr/bin/checkstyle).
The following happens:

$ checkstyle -c checkstyle.xml src/
[warning] /usr/bin/checkstyle: JVM flavor 'sunmin5' not understood
[warning] /usr/bin/checkstyle: Unable to locate commons-cli in 
/usr/share/java
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on 
-Dswing.aatext=true

Error: Unable to initialize main class com.puppycrawl.tools.checkstyle.Main
Caused by: java.lang.NoClassDefFoundError: 
picocli/CommandLine$ParameterException


Adding picocli to the find_jars command arguments in the wrapper script
makes the script work.

Br,
Timo

-- System Information:
Debian Release: 10.1
  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=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), 
LANGUAGE= (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages checkstyle depends on:
ii  antlr 2.7.7+dfsg-9.2
ii  default-jre-headless [java7-runtime-headless] 2:1.11-71
ii  java-wrappers 0.3
ii  libantlr4-runtime-java4.7.2-1
ii  libcommons-beanutils-java 1.9.3-1
ii  libcommons-lang3-java 3.8-2
ii  libcommons-logging-java   1.2-2
ii  libguava-java 19.0-1
ii  libpicocli-java   3.9.2-1
ii  openjdk-11-jre-headless [java7-runtime-headless]  11.0.5+10-1~deb10u1

checkstyle recommends no packages.

Versions of packages checkstyle suggests:
ii  ant-optional  1.10.5-2
pn  junit4

-- no debconf information

Bug#944064: buster-pu: package libxslt/1.1.32-2.2~deb10u1

[Salvatore Bonaccorso]

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

Hi SRM'ers

libxslt is affected by CVE-2019-18197 and the issue was fixed in
unstable via the NMU 1.1.32-2.2 cherry picking the upstream commit. As
per previous upload here the simplest seem to be to do a rebuild of
1.1.32-2.2 for buster, versioned as 1.1.32-2.2~deb10u1.

Attached the full resulting debdiff against the current
1.1.32-2.1~deb10u1 in buster.

Regards,
Salvatore
diff -Nru libxslt-1.1.32/debian/changelog libxslt-1.1.32/debian/changelog
--- libxslt-1.1.32/debian/changelog 2019-08-09 21:49:31.0 +0200
+++ libxslt-1.1.32/debian/changelog 2019-11-03 17:11:47.0 +0100
@@ -1,8 +1,15 @@
-libxslt (1.1.32-2.1~deb10u1) buster; urgency=medium
+libxslt (1.1.32-2.2~deb10u1) buster; urgency=medium
 
   * Rebuild for buster 
 
- -- Salvatore Bonaccorso   Fri, 09 Aug 2019 21:49:31 +0200
+ -- Salvatore Bonaccorso   Sun, 03 Nov 2019 17:11:47 +0100
+
+libxslt (1.1.32-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix dangling pointer in xsltCopyText (CVE-2019-18197) (Closes: #942646)
+
+ -- Salvatore Bonaccorso   Sat, 19 Oct 2019 21:21:23 +0200
 
 libxslt (1.1.32-2.1) unstable; urgency=medium
 
diff -Nru 
libxslt-1.1.32/debian/patches/0009-Fix-dangling-pointer-in-xsltCopyText.patch 
libxslt-1.1.32/debian/patches/0009-Fix-dangling-pointer-in-xsltCopyText.patch
--- 
libxslt-1.1.32/debian/patches/0009-Fix-dangling-pointer-in-xsltCopyText.patch   
1970-01-01 01:00:00.0 +0100
+++ 
libxslt-1.1.32/debian/patches/0009-Fix-dangling-pointer-in-xsltCopyText.patch   
2019-10-19 21:21:23.0 +0200
@@ -0,0 +1,35 @@
+From: Nick Wellnhofer 
+Date: Sat, 17 Aug 2019 16:51:53 +0200
+Subject: Fix dangling pointer in xsltCopyText
+Origin: 
https://gitlab.gnome.org/GNOME/libxslt/commit/2232473733b7313d67de8836ea3b29eec6e8e285
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-18197
+Bug-Debian: https://bugs.debian.org/942646
+Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15746
+Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15768
+Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15914
+
+xsltCopyText didn't reset ctxt->lasttext in some cases which could
+lead to various memory errors in relation with CDATA sections in input
+documents.
+
+Found by OSS-Fuzz.
+---
+ libxslt/transform.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/libxslt/transform.c b/libxslt/transform.c
+index 95ebd0732f95..d7ab0b6677cc 100644
+--- a/libxslt/transform.c
 b/libxslt/transform.c
+@@ -1094,6 +1094,8 @@ xsltCopyText(xsltTransformContextPtr ctxt, xmlNodePtr 
target,
+   if ((copy->content = xmlStrdup(cur->content)) == NULL)
+   return NULL;
+   }
++
++  ctxt->lasttext = NULL;
+ } else {
+ /*
+* normal processing. keep counters to extend the text node
+-- 
+2.20.1
+
diff -Nru libxslt-1.1.32/debian/patches/series 
libxslt-1.1.32/debian/patches/series
--- libxslt-1.1.32/debian/patches/series2019-08-04 08:14:05.0 
+0200
+++ libxslt-1.1.32/debian/patches/series2019-10-19 21:21:23.0 
+0200
@@ -6,3 +6,4 @@
 0006-Fix-security-framework-bypass.patch
 0007-Fix-uninitialized-read-of-xsl-number-token.patch
 0008-Fix-uninitialized-read-with-UTF-8-grouping-chars.patch
+0009-Fix-dangling-pointer-in-xsltCopyText.patch

Bug#944063: gparted-common: Move AppStream metadata to main gparted package

[Jeremy Bicha]

Source: gparted
Version: 1.0.0-0.1~exp
Severity: important
X-Debbugs-CC: ni...@debian.org

The latest experimental NMU of gparted created a gparted-common
package and put the AppStream metadata in that package.

According to the guidelines
/usr/share/metainfo/gparted.appdata.xml
should be installed by the gparted package and not by a separate package.

Comments

I don't see  much benefit in splitting help and translations out to a
separate Debian package. It seems a surprising change to make in an
NMU, especially where I don't see a record of where this change was
requested or proposed with sufficient time for the maintainer to
reply.

References

https://wiki.debian.org/AppStream/Guidelines#General
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#nmu
https://salsa.debian.org/debian/gparted/commits/debian/experimental

Thanks,
Jeremy Bicha

Bug#944039: ITP: docker-systemctl-replacement -- daemonless "systemctl" command to manage services without SystemD

[Andrei POPESCU]

On Du, 03 nov 19, 19:33:59, Dmitry Smirnov wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-de...@lists.debian.org
> Owner: Dmitry Smirnov 
> 
>Package name: docker-systemctl-replacement
> Version: 1.4.3424
> Upstream Author: Guido U. Draheim
> License: EUPL-1.2
> URL: https://github.com/gdraheim/docker-systemctl-replacement
> Vcs-Browser: https://salsa.debian.org/debian/docker-systemctl-replacement
> Description: daemonless "systemctl" command to manage services without 
> SystemD
>  "systemctl" is a replacement command to control system daemons without
>  SystemD. "systemctl" is useful in application containers where SystemD is
>  not available to start/stop services.
>  .
>  This script can also be run as init of an application container (i.e. the
>  main "CMD" on PID 1) where it will automatically bring up all enabled
>  services in the "multi-user.target" and where it will reap all zombies
>  from background processes in the container. When stopping such a container
>  it will also bring down all configured services correctly before exit.

s/SystemD/systemd :)

See https://www.freedesktop.org/wiki/Software/systemd (currently down 
for me).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug#944062: yapsy: autopkgtest regression: python: command not found

[Paul Gevers]

Source: yapsy
Version: 1.12.0-1.1
X-Debbugs-CC: debian...@lists.debian.org, mo...@debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of yapsy the autopkgtest of yapsy fails in testing
when that autopkgtest is run with the binary packages of yapsy from
unstable. It passes when run with only packages from testing. In tabular
form:
   passfail
yapsy  from testing1.12.0-1.1
all others from testingfrom testing

I copied some of the output at the bottom of this report. @Sandro, you
forgot to fix the autopkgtest for your NMU.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=yapsy

https://ci.debian.net/data/autopkgtest/testing/amd64/y/yapsy/3323462/log.gz

autopkgtest [06:13:28]: test unittests: [---
.
--
Ran 97 tests in 0.168s

OK
/tmp/autopkgtest-lxc.z9w02dca/downtmp/build.Sw9/src/debian/tests/unittests:
line 2: python: command not found
autopkgtest [06:13:29]: test unittests: ---]



signature.asc
Description: OpenPGP digital signature

Bug#944061: octave: cannot upgrade to 5.1.0-4

[Patrice DUROUX]

Package: octave
Version: 5.1.0-4
Severity: normal

Dear Maintainer,

Last upgrade to octave 5.1.0-4 did not success here:

Setting up octave (5.1.0-4) ...
/usr/bin/octave-cli: error while loading shared libraries: liblapack.so.3: 
cannot open shared object file: No such file or directory
dpkg: error processing package octave (--configure):
 installed octave package post-installation script subprocess returned error 
exit status 127
Errors were encountered while processing:
 octave

But I am not sure if it is due to octave or liblapack.

$ dpkg -l | grep liblapack
ii  liblapack-dev:amd64  3.8.0-8
   amd64Library of linear algebra routines 3 - static version
ii  liblapack3:amd64 3.8.0-8
   amd64Library of linear algebra routines 3 - shared version
ii  liblapacke:amd64 3.8.0-8
   amd64Library of linear algebra routines 3 - C lib shared 
version

Regards,
Patrice

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

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

Versions of packages octave depends on:
ii  libamd21:5.4.0+dfsg-1
ii  libbz2-1.0 1.0.8-2
ii  libc6  2.29-3
ii  libccolamd21:5.4.0+dfsg-1
ii  libcholmod31:5.4.0+dfsg-1
ii  libcolamd2 1:5.4.0+dfsg-1
ii  libcxsparse3   1:5.4.0+dfsg-1
ii  libfftw3-double3   3.3.8-2
ii  libfftw3-single3   3.3.8-2
ii  libfltk-gl1.3  1.3.4-10
ii  libfltk1.3 1.3.4-10
ii  libgcc11:9.2.1-16
ii  libgl1 1.1.0-1+b1
ii  libglpk40  4.65-2
ii  liboctave7 5.1.0-4
ii  libportaudio2  19.6.0-1
ii  libqhull7  2015.2-4
ii  libqscintilla2-qt5-13  2.10.4+dfsg-2.1
ii  libqt5core5a   5.12.5+dfsg-2
ii  libqt5gui5 5.12.5+dfsg-2
ii  libqt5help55.12.5-2
ii  libqt5network5 5.12.5+dfsg-2
ii  libqt5printsupport55.12.5+dfsg-2
ii  libqt5widgets5 5.12.5+dfsg-2
ii  libqt5xml5 5.12.5+dfsg-2
ii  libsndfile11.0.28-6
ii  libstdc++6 9.2.1-16
ii  libsuitesparseconfig5  1:5.4.0+dfsg-1
ii  libx11-6   2:1.6.8-1
ii  octave-common  5.1.0-4
ii  texinfo6.7.0.dfsg.2-5
ii  zlib1g 1:1.2.11.dfsg-1+b1

Versions of packages octave recommends:
ii  default-jre-headless  2:1.11-72
ii  epstool   3.09-2
ii  gnuplot-qt [gnuplot-x11]  5.2.7+dfsg1-6
ii  libatlas3-base3.10.3-8
ii  libopenblas-base  0.3.7+ds-3
ii  octave-doc5.1.0-4
ii  pstoedit  3.74-1+b1

Versions of packages octave suggests:
pn  liboctave-dev  

-- no debconf information

Bug#934573: workaround for bug #934573

[Pallinger Péter]

I've found a way to disable this message: in PCManFM in the Edit
menu, choose Preferences, and select "Don't ask options on launch
executable file". 

Whether this should be the default or not is up for debate, but
personally I found the current default annoying, and the setting is not
very easy to find (alas, I found this bug report while searching for
it).

Bug#944060: exim4-daemon-light: FTBFS (testsuite error) on mipsel

[Andreas Metzler]

Package: exim4-daemon-light
Version: 4.93~RC0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

4.93~RC0-1 and later (including 4.93~RC1-2) FTBFS on mipsel, the binary
is built but broken.

/path/to/exim -C /dev/null -be '${if bool{0}{yes}{no}}'
fails with
2019-11-03 17:50:00 failed to malloc 2008002776 bytes of memory: called from 
line 3359 in readconf_main

cu Andreas

PS:
I wish I had seen the  build errors /before/ uploading to unstable but
whenever I checked mipse was at needs-build.

Bug#919170: [Piuparts-devel] Bug#919170: Please update dependency to python3-debianbts

[Bastian Venthur]

Hi Sando and Holger,

according to Holger, I can upload the new version of python-debianbts
that removes Python2 support to unstable, since piuparts is broken in
sid and bullseye anyways.

Just to verify once more before breaking stuff for real: is this OK for
everyone?


Cheers,

Basti


Am 24.08.19 um 12:23 schrieb Holger Levsen:
> On Fri, Aug 23, 2019 at 09:36:12PM -0400, Sandro Tosi wrote:
>> Hey Holger,
>>
>> On Sun, 13 Jan 2019 14:02:53 + Holger Levsen  
>> wrote:
>>> piuparts has a python2 codebase. Help porting it to python3 would be
>>> much appreciated.
>>
>> i see there's been some activities in the repo about porting piuparts
>> to py3k, f.e. 
>> https://salsa.debian.org/debian/piuparts/commit/336d7650927f883db6abe2a6783bd88ed953acc9
>> -- any idea if there's an upload expected soon? that would help
>> dropping python-debianbts (piuparts is its only rdep) which would then
>> free python-pysimplesoap.
> 
> someone needs to test the master branch and confirm it still works on
> buster *and* sid. once that has happened, I'll upload to sid.
> 
> the master branch should be ready for python3 thanks to zigo's work.
> 
> i'll try to get this done ASAP, which likely will translate to september.
> as usual, help is very welcome.
> 
> 

-- 
Dr. Bastian Venthur https://venthur.de
Debian Developer venthur at debian org




signature.asc
Description: OpenPGP digital signature

Bug#942554: transition: soapysdr

[Paul Gevers]

Control: reopen-1

Ehmm

On 03-11-2019 18:42, Paul Gevers wrote:
> This seems to be finished, closing.

I must have been blind...

Paul



signature.asc
Description: OpenPGP digital signature

Bug#883812: Bug #883812: gparted: Please don't use --enable-xhost-root

[Curtis Gedak]

Hi Nicolas,

If you wish GParted to run under Wayland, then it needs to be built with
the --enable-xhost-root configure option.  Notice that this is the way
Fedora configures their RPM packages [1].

[1] https://koji.fedoraproject.org/koji/packageinfo?packageID=1950

If you click on "gparted-1.0.0-3.fc31" then under "Logs" for "x86_64"
and click on "build.log" [2] you can search and find "--enable-xhost-root".

[2]
https://kojipkgs.fedoraproject.org//packages/gparted/1.0.0/3.fc31/data/logs/x86_64/build.log

'Hope that helps.

Regards,
Curtis

Bug#944054: statsmodels: ignored test failures on at least ppc64el

[Rebecca N. Palmer]

The test failures are:

armhf: 86, probably all #924036

i386: 1, TestDFM_Approx.test_smoothed_measurement_disturbance out of 
tolerance: suspect rounding error (x87 extra precision).


arm64, ppc64el, s390x: the same 3, 
base.tests.test_penalized.TestPenalizedPoissonOraclePenalized2*: looks 
like a "find which input variables do something" test is finding 3 when 
there are 4.  This is the kind of task where too-weak real signals can 
legitimately be missed in the noise, but the test input doesn't seem 
that close to this edge: on amd64 it works for mod.pen_weight *= 
approximately 3 to 11 (the test uses 10).  There are also convergence 
warnings.


This may need discussion with upstream.

Bug#941018: ibus 1.5.21-1 does not work with qt5 applications

[Salvatore Bonaccorso]

Hi Simon, and all others,

First: thanks for all your work and energy putted in into resolving
this issue.

On Wed, Oct 30, 2019 at 03:04:26PM +, Simon McVittie wrote:
> On Wed, 30 Oct 2019 at 15:45:19 +0100, Gunnar Hjalmarsson wrote:
> > Seeing that you included quite a few patches in this update, I have a
> > question as regards the stable releases. Are the commits included in
> >  a standalone set
> > of commits which would be sufficient for patching the stable releases in
> > order to fix the IBus/Qt issue? I'm asking with my Ubuntu glasses on at
> > first hand (in Ubuntu 16.04 we have glib2.0 2.48...), but the question does
> > reasonably apply to Debian too.
> 
> I was hoping to let glib2.0 get some testing in unstable before
> backporting anything. A build of GLib with amd64, i386, build-time tests,
> autopkgtest and piuparts takes about an hour, and I have to do my actual
> job as well, so I can't iterate on this particularly rapidly.
> 
> How do the security team want to handle this - as a stable update, or
> as a DSA? It isn't a security fix in its own right, but it fixes what
> is effectively a regression triggered by fixing CVE-2019-14822 in ibus
> (#940267, DSA-4525-1).
[...]

I would lean towards fixing it via a point release, still even if the
issue was uncovered/triggered by fixing CVE-2019-14822. This allows to
a have a slighter more exposure as well before the point release.

Would you agree? And have you the resources to prepare fixes?

Regards,
Salvatore

Bug#944047: lintian: warn against Build-Depends-Package: #PACKAGE# in symbol files

[Sebastian Ramacher]

Hi Felix

On 2019-11-03 05:49:59, Felix Lechner wrote:
> On Sun, Nov 3, 2019 at 2:24 AM Sebastian Ramacher  
> wrote:
> >
> > In libdvdread 6.0.1-1, the following line was added to "fix" the
> > lintian info on the missing Build-Depends-Package:
> >
> > | * Build-Depends-Package: #PACKAGE#
> >
> > This causes the package name of the shared library to be substituted,
> > and not the -dev package. So please warn against Build-Depends-Package
> > lines of this form.
> 
> That's funny. I often thought about doing the same. It seems some
> program in the middle should be smart enough to fill it in.

Nobody wrote that program yet.

> Isn't that
> what happens to #MINVAR?

#MINVER# is not replaced at build time. Installed symbol files still
contain #MINVER#, wheras #PACKAGE# gets replaced during package build.

As for your new Lintian tag, we like to start
> them on the lower end of their severity. Would 'I' (informational) be
> okay for now?
> 
> Also, do you have any suggestions on how to fix the tag description
> for symbols-file-missing-build-depends-package-field? We should
> perhaps clarify that #PACKAGE# is not the right value to use.

No, I don't. But I am also not a fan of that tag.

> I looked briefly at the relevant portions of dpkg-shlibdeps (1),
> policy [2], deb-symbols (5) and the Debian Maintainer's Guide [3]
> (dpkg-gensymbols does not mention the field) but I could not find
> much. Is there a variable that would work?

No, not as far as I am aware.

Cheers

> 
> Kind regards,
> Felix Lechner
> 
> [1] 
> https://lintian.debian.org/tags/symbols-file-missing-build-depends-package-field.html
> [2] 
> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-symbols
> [3] 
> https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#librarysymbols

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#942235: [Python-modules-team] Bug#942235: python-xarray needed new dask as well?

[Emmanuel Arias]

Hi,

I've just prepare the new upstream release (for some reason
the upstream branch was not merge to master). [1]

But is necessary some work with patches, are failing.

I can work on it tomorrow.

[1] https://salsa.debian.org/python-team/modules/dask

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El dom., 3 de nov. de 2019 a la(s) 11:24, Matthias Klose
(d...@debian.org) escribió:

>
> it looks to me that python-xarray 0.14 needs a newer dask version as well.
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

Bug#944059: zfs-auto-snapshot: Package for stretch is very old and buggy

[keithatskool]

Package: zfs-auto-snapshot
Version: 1.2.1-1+deb9u1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
Trying to use the package on debian stretch
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Using commands structured as per "zfs-auto-snapshot --help", unintented 
or incorrect results occured.
see https://github.com/zfsonlinux/zfs-auto-snapshot/issues/111 for an 
example. The script also generates recursive snapshots of intermediate datasets 
(e.g. snapshotting s/s0 will also snapshot s/s0/root and s/s0/pfsense) without 
-r specified
   * What was the outcome of this action?
unexpected snapshots on unexpected datasets. Many of these bugs appear 
to have been fixed in newer versions of zfs-auto-snapshot
but the stretch version is old
   * What outcome did you expect instead?
the package should have a newer version of the script for stretch, or 
be pulled as it currently does not function as intended or as documented

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


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

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

Versions of packages zfs-auto-snapshot depends on:
ii  cron3.0pl1-128+deb9u1
ii  zfsutils-linux  0.6.5.9-5

zfs-auto-snapshot recommends no packages.

zfs-auto-snapshot suggests no packages.

-- no debconf information

Bug#944038: gpsd missing sysvinit script and breaks functionality on upgrade

[Bernd Zeimetz]

Hi,

> Justification: Breaks silently functionality on upgrade

not if you'd use the default init system.

> In my setup, gpsd is required to start at system boot with a sysv
> init.

That is not supported by the gpsd upstream anymore, all the
hotplugging/udev rules require systemd (which makes a lot of sense!),
and to avoid a mess in debugging this, I'm not going to change this.


> The upgrading process stops the running gpsd, and without the
> init script, it is not restarted, resulting in a system without
> gps information.
> 
> Please bring the init script back.
no. please use systemd.


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#943833: [src:x11vnc] Drop bundled libvncserver/libvncclient

[Antoni Villalonga]

On Wed, Oct 30, 2019 at 02:59:32PM +, Mike Gabriel wrote:
> Package: src:x11vnc
> Version: 0.9.13-6
> Severity: wishlist
> 
> While this is not a functionality improvement, it helps with security
> audits. Please consider removing the libvncclient/ and libvncserver/ folders
> from the x11vnc orig tarball. Thanks!

Hi Mike,

I've uploaded x11vnc 0.9.16-1 to experimental.
Can we consider this bug fixed on that version?

Thanks for your time!

-- 
Antoni Villalonga
http://friki.cat/

Bug#944058: ITP: libcolor-rgb-util-perl -- set of utilities related to RGB colors

[gregor herrmann]

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

* Package name: libcolor-rgb-util-perl
  Version : 0.599
  Upstream Author : perlancar 
* URL : https://metacpan.org/release/Color-RGB-Util
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : set of utilities related to RGB colors

Color::RGB::Util provides routines for dealing with RGB colors.

Among others, functions are available to convert between strings and RGB
values, or integers and RGB values, to convert from RGB to other color
schemes, or to calculate color differences and distances.

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

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#942235: python-xarray needed new dask as well?

[Matthias Klose]

it looks to me that python-xarray 0.14 needs a newer dask version as well.

Bug#944057: ITP: libtest-randomresult-perl -- module to test that results of a running code look random

[gregor herrmann]

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

* Package name: libtest-randomresult-perl
  Version : 0.001
  Upstream Author : perlancar 
* URL : https://metacpan.org/release/Test-RandomResult
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to test that results of a running code look random

Test::RandomResult is a test module that checks that the results of some code
look random.

Currently it does not check the distribution of the random results.

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

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#944055: linbox ftbfs on armhf, bus errors in the test suite

[Torrance, Douglas]

Control: forwarded -1 https://github.com/linbox-team/linbox/issues/238

On Sun, Nov 3, 2019 at 8:57 AM Matthias Klose 
mailto:d...@debian.org>> wrote:
linbox ftbfs on armhf, bus errors in the test suite, like

../build-aux/test-driver: line 107: 21585 Bus error   "$@" >
$log_file 2>&1
FAIL: test-smith-form-valence

the builders are now machines with 64bit kernels, and that looks like an
alignment error.

full build log at
https://buildd.debian.org/status/fetch.php?pkg=linbox=armhf=1.6.3-1=1568385253=0

the package also fails on mipsel, didn't look for the reasons.

Thanks for the report!  Forwarded upstream.

Bug#248496: missing font 8x16

[Andras Korn]

Hi,

I just encountered the same problem.

I'm fairly certain the root cause is that the game assumes some specific
named font is available, and fails when it isn't (i.e. missing dependency).

I looked at it using xtruss
(https://www.chiark.greenend.org.uk/~sgtatham/xtruss/) and it seems to try
to use a font called "8x16":

OpenFont(fid=f#0463, name="8x16")
ChangeGC(gc=g#0462, foreground=0x, background=0x, 
font=f#0463)
ChangeWindowAttributes(window=w#0461, event-mask=Exposure)
ConfigureWindow(window=w#0461, stack-mode=Above)
MapWindow(window=w#0461)
 ... OpenFont(fid=f#0463, name="8x16") = BadName
 ... ChangeGC(gc=g#0462, foreground=0x, background=0x, 
font=f#0463) = BadFont(font=f#)
--- Expose(window=w#0461, x=0, y=0, width=1, height=1, count=0)
X Error of failed request:  BadName (named color or font does not exist)
  Major opcode of failed request:  45 (X_OpenFont)
  Serial number of failed request:  27
  Current serial number in output stream:  31

I have no idea how to provide the game with the required font; the
xfonts-base package, which contains /usr/share/fonts/X11/misc/8x16.pcf.gz,
is installed, fwiw.

HTH.

Andras

-- 
  The trouble with political humor is that so many jokes are elected.

Bug#944056: i3-wm: i3 ignores system keyboard layouts

[Vlastimil Zima]

Package: i3-wm
Version: 4.17.1-1
Severity: normal
Tags: l10n

Dear Maintainer,

I'm trying to setup a i3, but I encountered a problem with keyboard
layout setup. Multiple layouts set up in /etc/default/keyboard are
ignored by i3 and only 'us' layout is available. On the other hand,
keyboard options are respected.

I have in /etc/default/keyboard

XKBLAYOUT="us,cz"
XKBVARIANT=",qwerty"
BACKSPACE="guess"
XKBMODEL="pc105"
XKBOPTIONS="grp:alt_shift_toggle,grp_led:scroll,caps:none"

but after i3 is started, 'setxkbmap -query' returns

rules:  evdev
model:  pc105
layout: us
options:grp:alt_shift_toggle,grp_led:scroll,caps:none

I'd expect the layouts from the keyborad setup would be used as well. I
wasn't able to find another location which would override the keyboard
layout.

Regards,
Vlastimil Zíma


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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.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 i3-wm depends on:
ii  libc6 2.29-2
ii  libcairo2 1.16.0-4
ii  libev41:4.27-1
ii  libglib2.0-0  2.62.2-1
ii  libpango-1.0-01.42.4-7
ii  libpangocairo-1.0-0   1.42.4-7
ii  libpcre3  2:8.39-12+b1
ii  libstartup-notification0  0.12-6
ii  libxcb-cursor00.1.1-4
ii  libxcb-icccm4 0.4.1-1.1
ii  libxcb-keysyms1   0.4.0-1+b2
ii  libxcb-randr0 1.13.1-2
ii  libxcb-shape0 1.13.1-2
ii  libxcb-util0  0.3.8-3+b2
ii  libxcb-xinerama0  1.13.1-2
ii  libxcb-xkb1   1.13.1-2
ii  libxcb-xrm0   1.0-3
ii  libxcb1   1.13.1-2
ii  libxkbcommon-x11-00.8.4-1
ii  libxkbcommon0 0.8.4-1
ii  libyajl2  2.1.0-3
ii  perl  5.30.0-9

Versions of packages i3-wm recommends:
ii  fonts-dejavu-core 2.37-1
ii  gnome-terminal [x-terminal-emulator]  3.34.2-1
ii  libanyevent-i3-perl   0.17-1
ii  libjson-xs-perl   4.020-1+b1
ii  xfonts-base   1:1.0.5
ii  xterm [x-terminal-emulator]   349-1

i3-wm suggests no packages.

-- no debconf information

Bug#944055: linbox ftbfs on armhf, bus errors in the test suite

[Matthias Klose]

Package: src:linbox
Version: 1.6.3-1
Severity: serious
Tags: sid bullseye

linbox ftbfs on armhf, bus errors in the test suite, like

../build-aux/test-driver: line 107: 21585 Bus error   "$@" > 
$log_file 2>&1

FAIL: test-smith-form-valence

the builders are now machines with 64bit kernels, and that looks like an 
alignment error.


full build log at
https://buildd.debian.org/status/fetch.php?pkg=linbox=armhf=1.6.3-1=1568385253=0

the package also fails on mipsel, didn't look for the reasons.

Bug#944047: lintian: warn against Build-Depends-Package: #PACKAGE# in symbol files

[Felix Lechner]

Hi Sebastian,

On Sun, Nov 3, 2019 at 2:24 AM Sebastian Ramacher  wrote:
>
> In libdvdread 6.0.1-1, the following line was added to "fix" the
> lintian info on the missing Build-Depends-Package:
>
> | * Build-Depends-Package: #PACKAGE#
>
> This causes the package name of the shared library to be substituted,
> and not the -dev package. So please warn against Build-Depends-Package
> lines of this form.

That's funny. I often thought about doing the same. It seems some
program in the middle should be smart enough to fill it in. Isn't that
what happens to #MINVAR? As for your new Lintian tag, we like to start
them on the lower end of their severity. Would 'I' (informational) be
okay for now?

Also, do you have any suggestions on how to fix the tag description
for symbols-file-missing-build-depends-package-field? We should
perhaps clarify that #PACKAGE# is not the right value to use.

I looked briefly at the relevant portions of dpkg-shlibdeps (1),
policy [2], deb-symbols (5) and the Debian Maintainer's Guide [3]
(dpkg-gensymbols does not mention the field) but I could not find
much. Is there a variable that would work?

Kind regards,
Felix Lechner

[1] 
https://lintian.debian.org/tags/symbols-file-missing-build-depends-package-field.html
[2] 
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-symbols
[3] 
https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#librarysymbols

Bug#932990: freeciv: railroad and transformation in adjacent tiles

[Jacob Nevins]

David Christensen writes:
> Please see attached game save file freeciv-T0202-Y01510-manual.sav.bz2:

(This save game was created with Freeciv 2.5.6, using the 'classic'
ruleset.)

> 1.  Swamp near Kobenhavn with roads being upgraded to railroads.

I assume this is the tile highlighted if you paste
[l tgt="tile" x=37 y=12 /]
into the chatline.

> 2.  Adjacent swamp tile being transformed to swamp.

I assume this is [l tgt="tile" x=36 y=11 /], where *Ocean* is being
transformed to Swamp.

> When "Turn Done" is pressed:
> 
> 1.  Swamp is converted to ocean (bug).
> 
> 2.  Ocean is converted to swamp (correct).
> 
> 3.  Grassland adjacent to both of the above is converted to ocean (bug).

The unwanted terrain transformations are by design. Due to pollution,
catastrophic climate change has led to terrain changes. See Cities /
Pollution in the built-in help.

On the Messages tab after pressing Turn Done, I have among others these
messages:
| Global warming has occurred!
| Coastlines have been flooded and vast ranges of grassland have become deserts.

On the previous turn, the user interface shows:
| Shows the progress of global warming:
| Pollution rate: 5%
| Chance of catastrophic warming each turn: 14%

(In the Gtk client, this is shown as a tooltip for the 'sun' icon.)

(If you don't like this rule, you can turn it off in the server
settings for future games:
Game / Options / Remote server / Geological / Global warming
or '/set globalwarming disabled' from the server command line.
However, once a game has started, this option can't be changed.)

Bug#943666: python3: Update Python Policy for removal of the Python 2 stack

[Neil Williams]

On Sun, 3 Nov 2019 13:45:37 +0100 Matthias Klose 
wrote:
> On 03.11.19 13:10, Neil Williams wrote:
> > On Wed, 30 Oct 2019 16:44:24 +0100 Matthias Klose 
> > wrote:
> >> On 27.10.19 17:59, Neil Williams wrote:
> >>> Package: python3
> >>> Version: 3.7.5-1
> >>> Severity: normal
> >>>
> >>> As discussed on IRC and alongside the post to
> >>> debian-devel-announce, please review and include this amendment
> >>> to the Debian Python Policy to cover the removal of the Python 2
> >>> stack as outlined at https://wiki.debian.org/Python/2Removal
> >>
> >> thanks for doing that.  I think we should make it more clear that
> >> there will no python binary package, and no python command in
> >> bullseye.  You adjusted the names, but are still talking about
> >> "should" in some place.  If we end up with some remaining python 2
> >> packages, then these must depend on python2, python2-dbg, and must
> >> use the python2 command.
> >>
> > 
> > OK, I've updated MR 1 with changes along those lines.
> > 
> > https://salsa.debian.org/cpython-team/python3-defaults/merge_requests/1
> 
> ok, commenting here in the bug report:
> 
> +   Debian has previously supported two Python stacks, one for
> Python 3> + and one for Python 2.  The goal for Debian is to
> reduce this
> +   to one stack, dropping the Python 2 stack and intepreter
> for
> +   the Bullseye release.
>   
>   
> https://www.python.org/dev/peps/pep-0404/;
> 
> 
> TYPO "intepreter"

Fixed. Thanks.


> @@ -91,32 +95,33 @@
> >PEP 466.
>   
>   
> -   Packages in Debian should use Python 3 if Python 3 is
> -   supported.  New packages should use Python 3 from the
> initial
> -   upload, new upstream versions for existing packages should
> -   use Python 3 if the new upstream version supports it.
> +   Packages in Debian must use Python 3. New packages must
> +   use Python 3 from the initial upload, new upstream versions
> +   for existing packages should must use Python 3.
>   
> 
> TYPO "should must"
> Wouldn't we disallow any Python2 package with this change?


Yes, I've changed that.

  Packages in Debian should use Python 3. New packages must
  use Python 3 from the initial upload, new upstream versions
  for existing packages must use Python 3. If Python 2 is still
  supported in Bullseye, selected packages may continue using
  Python 2 until Python 3 support is available. Please discuss
  all use of Python 2 on the debian-python mailing list before
  uploading.

> -   Programs should use Python 3, and should not be
> packaged
> -   for Python 2 as well.  Python 3 should be used for the
> -   packaging if the packaging scripts use Python.
> +   Applications must use Python 3, and should not be
> packaged
> +   for Python 2 as well.  If an application supports only
> +   Python 2, the application will need to be removed from
> +   Debian so that it does not block removal of other
> Python 2
> +   packages.
> 
> I think this is a bit premature. I don't agree with the py2keep tag
> filed for mercurial, but maybe there will be another application
> which will not exist for Python 2 for the time of the bullseye
> release.

OK, replaced the paragraph.

> - 
> -   The version of the python package must
> be
> -   greater than or equal to 2.Y
> and lower than
> -   2.Y+1.
> - 
> - 
> -   The python binary package must also
> ensure
> -   that /usr/bin/python is provided, as
> a symlink to the
> -   current
> python2.Y executable.
> See
> -   https://www.python.org/dev/peps/pep-0394/;
> ->PEP 394 for details.
> - 
> 
> While I would like that change, just removing it would allow pointing
> the python package to python3.  This isn't seen so by everybody, so
> please keep this paragraph, and maybe address this later.

Done.

> @@ -475,8 +483,10 @@
>   
> The binary package python3-doc will
> always provide the documentation for the default Debian Python 3
> version.
> -   The binary package python-doc will
> always
> -   provide the documentation for the default Debian Python 2
> version.
> +   The binary package python-doc may
> +   provide the documentation for the default Debian Python 2,
> or
> +   the default Debian Python 3 version if no Python 2 binary
> +   is built.
> 
> hmm, up to now I thought to remove python-doc together with python
> and python-dbg.  So build python-doc now from python3-defaults and
> let it depend on python3-doc?


Actually, that's a good catch. I was mixing up the defaults package
with the general advice on python3 migration to not remove
python-foo-doc just to rename it to python3-foo-doc.

Removing the defaults package python-doc seems right to me. I've
updated that paragraph.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpqpyMlAUwOa.pgp

Bug#944054: statsmodels: ignored test failures on at least ppc64el

[Rebecca N. Palmer]

Package: python3-statsmodels
Version: 0.10.1-1
Control: fixed -1 0.9.0-6
Severity: serious

While making statsmodels clean up after its tests, I accidentally also 
made it ignore failed tests.


Some tests did fail on at least ppc64el and s390x; I don't yet know if 
these are actually a serious problem.