Bug#940990: rtl-sdr: FTBFS on hurd-i386

[Pino Toscano]

Source: rtl-sdr
Version: 0.6-3
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hi,

rtl-sdr currently fails to build on hurd-i386 [1].

This happens because the required libusb library is the new libusb-1.0,
which is not installed on hurd-i386 (the old libusb-dev is pulled).
Furthermore, the old hurd-usb patch is basically unused, as the cmake
file changed by that patch is removed with another patch
(modernize-cmake).

Hence, the fixes needed are the following:
- drop patch hurd-usb, no more needed
- refresh patch modernize-cmake according to the removal of the patch
  hurd-usb; refreshed version attached
- switch the build dependencies to use libusb-1.0 also on Hurd; patch
  debian.diff attached (it reflects the dependencies of librtlsdr-dev,
  which are correct already)

[1] 
https://buildd.debian.org/status/fetch.php?pkg=rtl-sdr=hurd-i386=0.6-3=1569211482=0

Thanks,
-- 
Pino
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,4 +1,4 @@
-# Copyright 2012 OSMOCOM Project
+# Copyright 2012,2018 OSMOCOM Project
 #
 # This file is part of rtl-sdr
 #
@@ -21,7 +21,7 @@
 
 # Project setup
 
-cmake_minimum_required(VERSION 2.6)
+cmake_minimum_required(VERSION 3.7.2)
 project(rtlsdr C)
 
 #select the release build type by default to get optimization flags
@@ -29,13 +29,12 @@
set(CMAKE_BUILD_TYPE "Release")
message(STATUS "Build type not specified: defaulting to release.")
 endif(NOT CMAKE_BUILD_TYPE)
-set(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING "")
 
 list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/Modules)
 
-if(NOT LIB_INSTALL_DIR)
-   set(LIB_INSTALL_DIR lib)
-endif()
+include(GNUInstallDirs)
+include(GenerateExportHeader)
+include(CMakePackageConfigHelpers)
 
 # Set the version information here
 set(VERSION_INFO_MAJOR_VERSION 0) # increment major on api compatibility 
changes
@@ -63,12 +62,12 @@
 
 # Find build dependencies
 
-find_package(PkgConfig)
-find_package(LibUSB)
 if(WIN32 AND NOT MINGW)
 set(THREADS_USE_PTHREADS_WIN32 true)
 endif()
 find_package(Threads)
+find_package(PkgConfig)
+pkg_check_modules(LIBUSB libusb-1.0 IMPORTED_TARGET)
 
 if(NOT LIBUSB_FOUND)
 message(FATAL_ERROR "LibUSB 1.0 required to compile rtl-sdr")
@@ -76,21 +75,6 @@
 if(NOT THREADS_FOUND)
 message(FATAL_ERROR "pthreads(-win32) required to compile rtl-sdr")
 endif()
-
-# Setup the include and linker paths
-
-include_directories(
-${CMAKE_SOURCE_DIR}/include
-${LIBUSB_INCLUDE_DIR}
-${THREADS_PTHREADS_INCLUDE_DIR}
-)
-
-#link_directories(
-#...
-#)
-
-# Set component parameters
-#set(INCLUDE_DIRS ${CMAKE_CURRENT_SOURCE_DIR}/include CACHE INTERNAL "" FORCE)
 
 
 # Create uninstall target
@@ -135,9 +119,17 @@
 endif (ENABLE_ZEROCOPY)
 
 
+# Install public header files
+
+install(FILES
+include/rtl-sdr.h
+include/rtl-sdr_export.h
+DESTINATION include
+)
+
+
 # Add subdirectories
 
-add_subdirectory(include)
 add_subdirectory(src)
 
 
@@ -162,9 +154,9 @@
 ENDIF(CMAKE_CROSSCOMPILING)
 
 set(prefix ${CMAKE_INSTALL_PREFIX})
-set(exec_prefix \${prefix})
-set(libdir \${exec_prefix}/${LIB_INSTALL_DIR})
-set(includedir \${prefix}/include)
+set(exec_prefix \${prefix}/${CMAKE_INSTALL_LIBEXECDIR})
+set(libdir \${prefix}/${CMAKE_INSTALL_LIBDIR})
+set(includedir \${prefix}/${CMAKE_INSTALL_INCLUDEDIR})
 
 CONFIGURE_FILE(
 ${CMAKE_CURRENT_SOURCE_DIR}/librtlsdr.pc.in
@@ -173,10 +165,38 @@
 
 INSTALL(
 FILES ${CMAKE_CURRENT_BINARY_DIR}/librtlsdr.pc
-DESTINATION ${LIB_INSTALL_DIR}/pkgconfig
+DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig
 )
 
 
+# Create CMake Config File
+
+write_basic_package_version_file(
+  "${CMAKE_CURRENT_BINARY_DIR}/rtlsdr/rtlsdrConfigVersion.cmake"
+  VERSION ${VERSION}
+  COMPATIBILITY AnyNewerVersion
+  )
+
+configure_file(cmake/rtlsdrConfig.cmake
+  "${CMAKE_CURRENT_BINARY_DIR}/rtlsdr/rtlsdrConfig.cmake"
+  COPYONLY
+  )
+
+set(ConfigPackageLocation lib/cmake/rtlsdr)
+install(EXPORT RTLSDR-export
+  FILE rtlsdrTargets.cmake
+ 

Bug#935438: chaussette: diff for NMU version 1.3.0+git20170419+82ac44a-0.2

[Sandro Tosi]

Control: tags 935438 + patch
Control: tags 935438 + pending


Dear maintainer,

I've prepared an NMU for chaussette (versioned as 
1.3.0+git20170419+82ac44a-0.2) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru chaussette-1.3.0+git20170419+82ac44a/debian/changelog chaussette-1.3.0+git20170419+82ac44a/debian/changelog
--- chaussette-1.3.0+git20170419+82ac44a/debian/changelog	2019-09-12 11:24:59.0 -0400
+++ chaussette-1.3.0+git20170419+82ac44a/debian/changelog	2019-09-23 00:39:37.0 -0400
@@ -1,3 +1,11 @@
+chaussette (1.3.0+git20170419+82ac44a-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch from python2 to python3 (remove some deps, they are skipped when
+running py3k); Closes: #935438
+
+ -- Sandro Tosi   Mon, 23 Sep 2019 00:39:37 -0400
+
 chaussette (1.3.0+git20170419+82ac44a-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru chaussette-1.3.0+git20170419+82ac44a/debian/control chaussette-1.3.0+git20170419+82ac44a/debian/control
--- chaussette-1.3.0+git20170419+82ac44a/debian/control	2019-09-12 11:24:59.0 -0400
+++ chaussette-1.3.0+git20170419+82ac44a/debian/control	2019-09-23 00:27:25.0 -0400
@@ -6,23 +6,21 @@
 Vcs-Git: git://github.com/circus-tent/chaussette.git -b debian
 Vcs-Browser: https://github.com/circus-tent/chaussette
 Build-Depends: 
-  python-setuptools (>= 0.6b3), 
-  python-all (>= 2.6.6-3), 
-  python-six (>= 1.3),
-  python-paste,
-  python-pastedeploy,
-  python-nose,
-  python-socketio,
-  python-ws4py,
-  python-waitress,
-  python-tornado,
-  python-requests,
-  python-minimock,
-  python-greenlet,
-  python-eventlet,
-  python-gevent-websocket,
-  python-unittest2,
-  python-sphinx,
+  python3-setuptools (>= 0.6b3), 
+  python3-all (>= 2.6.6-3), 
+  python3-six (>= 1.3),
+  python3-paste,
+  python3-pastedeploy,
+  python3-nose,
+  python3-ws4py,
+  python3-waitress,
+  python3-tornado,
+  python3-requests,
+  python3-minimock,
+  python3-greenlet,
+  python3-eventlet,
+  python3-unittest2,
+  python3-sphinx,
   dh-python,
   debhelper (>= 9),
 Standards-Version: 3.9.6
@@ -31,23 +29,21 @@
 Package: chaussette
 Architecture: all
 Depends: 
-  python-six (>= 1.3),
-  python-paste,
-  python-pastedeploy,
+  python3-six (>= 1.3),
+  python3-paste,
+  python3-pastedeploy,
   ${misc:Depends}, 
-  ${python:Depends},
+  ${python3:Depends},
 Suggests:
-  python-nose,
-  python-socketio,
-  python-ws4py,
-  python-waitress,
-  python-tornado,
-  python-requests,
-  python-minimock,
-  python-greenlet,
-  python-eventlet,
-  python-gevent-websocket,
-  python-werkzeug,
+  python3-nose,
+  python3-ws4py,
+  python3-waitress,
+  python3-tornado,
+  python3-requests,
+  python3-minimock,
+  python3-greenlet,
+  python3-eventlet,
+  python3-werkzeug,
 Description: WSGI Server for Circus
  Chaussette is a WSGI server you can use to run your Python WSGI applications.
  .
diff -Nru chaussette-1.3.0+git20170419+82ac44a/debian/.gitignore chaussette-1.3.0+git20170419+82ac44a/debian/.gitignore
--- chaussette-1.3.0+git20170419+82ac44a/debian/.gitignore	2019-09-12 11:24:59.0 -0400
+++ chaussette-1.3.0+git20170419+82ac44a/debian/.gitignore	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-.pc
diff -Nru chaussette-1.3.0+git20170419+82ac44a/debian/rules chaussette-1.3.0+git20170419+82ac44a/debian/rules
--- chaussette-1.3.0+git20170419+82ac44a/debian/rules	2019-09-12 11:24:59.0 -0400
+++ chaussette-1.3.0+git20170419+82ac44a/debian/rules	2019-09-22 23:44:37.0 -0400
@@ -4,7 +4,7 @@
 export PYBUILD_AFTER_INSTALL=rm -rf '{destdir}/{install_dir}/examples'
 
 %:
-	dh $@ --with python2 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 # pybuild sets the http_proxy environment variable to prevent 'python setup.py'
 # from downloading stuff from pypi, but this breaks the tests that perform 

Bug#940932: zfs-dkms: Reads from ZFS volumes cause system instability when SIMD acceleration is enabled.

[Alexander]

A quick update:

I have booted up the Debian live USB on another machine and was able to 
reproduce this bug with it.


The machine had the Ryzen 5 2600 CPU (the one I swapped with the machine 
I have originally found the problem on).


The Mainboard is: ASUS PRIME B350-PLUS
BIOS Version: 5216

Output of uname -a:
Linux debian 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2 (2019-08-28) x86_64 
GNU/Linux


Output of zfs --version:
zfs-0.8.1-4~bpo10+1
zfs-kmod-0.8.1-4~bpo10+1

Also here are the steps I'm taking to reproduce the problem:

- Start mprime for linux 64 bit
- Select Torture Test
- Choose 12 torture test threads in case of ryzen 5 (default setting)
- Select Test (2) Small FFT
- All other settings are set to default settings
- Run the test
- Read data from zfs by either reading a large file or starting a scrub. 
(raidz scrubs are escpecially effective)


Within a few seconds you should see mprime reporting errors.

Bug#940974: oslo-sphinx: autopkgtest regression: autodep8 tests the wrong Python 3 package since Python 2 package was dropped

[Amina Shamil]

Remove me from mail list

On Mon, Sep 23, 2019 at 2:00 AM Paul Gevers  wrote:

> Source: oslo-sphinx
> Version: 4.18.0-3
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: regression
>
> Dear maintainers,
>
> With a recent upload of oslo-sphinx the autopkgtest of oslo-sphinx fails
> in testing when that autopkgtest is run with the binary packages of
> oslo-sphinx from unstable. It passes when run with only packages from
> testing. In tabular form:
>passfail
> oslo-sphinxfrom testing4.18.0-3
> all others from testingfrom testing
>
> I copied some of the output at the bottom of this report. The issue is
> that the logic in autodep8 to determine which package to use isn't that
> smart. In the past, the package was correctly determined based on your
> Python 2 package name, but since you dropped that, it picks the wrong
> package (for Python 3 testing). My proposal to fix the current situation
> is one of:
> 1) help fix autodep8 to find the right package (and maybe do smarter
> testing on common Python workflows)
> 2) revert the order of the two packages in d/control, such that the
> first one is the one that autodep8 should pick
> 3) don't use autodep8 to provide autopkgtests (maybe just hard code the
> autodep8 template for now)
>
> Currently this regression is blocking the migration to testing [1]. Can
> you please fix the current situation?
>
> 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=oslo-sphinx
>
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/o/oslo-sphinx/3005383/log.gz
>
> autopkgtest [17:53:51]: test autodep8-python2: set -e ; for py in
> $(pyversions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing
> with $py:" ; $py -c "import oslosphinx_common; print oslosphinx_common"
> ; done
> autopkgtest [17:53:51]: test autodep8-python2: [---
> Testing with python2.7:
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: No module named oslosphinx_common
> autopkgtest [17:53:52]: test autodep8-python2: ---]
>
> --
Kind regards,
Amina

Bug#940989: ksh: KEYBD trap with undefined associative-array elements kills shell

[Bill Brelsford]

Package: ksh
Version: 2020.0.0~beta1-1
Severity: normal

Dear Maintainer,

My .env file contains

typeset -A SH_ktbl; SH_ktbl['   ']=".sh.edchar=$'\026\t'"
trap 'eval "${SH_ktbl[${.sh.edchar}]}"' KEYBD

(Replaces tab with ^V-tab; suggested by David Korn to disable
command-name and filename completion so tabs can be entered normally.)

But, in an apparent memory race condition, perhaps due to undefined
array elements, the new 2020 version soon gives "double free or
corruption (fasttop)" and kills the shell.

(For my situation,

trap "[[ \${.sh.edchar} == $'\t' ]] && .sh.edchar=$'\026\t'" KEYBD

is a less-efficient workaround.)

Bill


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

Kernel: Linux 5.2.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1), LANGUAGE=en_US 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages ksh depends on:
ii  binfmt-support  2.2.0-2
ii  libc6   2.29-2

ksh recommends no packages.

ksh suggests no packages.

-- no debconf information

Bug#940988: linux-image-5.2.0-2-amd64: USB breaks after a while

[Alexander Clausen]

Package: src:linux
Version: 5.2.9-2
Severity: important

Dear Maintainer,

I have the following setup: 

USB3 Hub connected to USB3 port of the mainboard, controller:

07:00.0 USB controller: VIA Technologies, Inc. VL805 USB 3.0 Host Controller 
(rev 01)

Plugged in are just two HID devices, keyboard and mouse. Keyboard
contains a USB2 Hub:

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 4: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 4: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 4, If 0, Class=Hub, Driver=hub/3p, 12M
|__ Port 1: Dev 6, If 0, Class=Human Interface Device, 
Driver=usbhid, 12M
|__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 7, If 0, Class=Human Interface Device, 
Driver=usbhid, 12M
|__ Port 4: Dev 7, If 1, Class=Human Interface Device, 
Driver=usbhid, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
|__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=ums-realtek, 480M


After some time of using the computer, minutes, sometimes also
seconds, the USB devices stop working. This appears to be the whole controller
becoming unstable, as removing and inserting the USB Hub has no effect.

The USB devices still show up in lsusb at this point, but don't work and are no
longer powered. The following is logged when this occurs:

[10157.861002] DMAR: DRHD: handling fault status reg 302
[10157.861004] xhci_hcd :07:00.0: WARNING: Host System Error
[10157.861013] DMAR: [DMA Read] Request device [07:00.0] fault addr ff766000 
[fault reason 06] PTE Read access is not set

This can be "fixed" by either rebooting or executing the following via
SSH:

$ cd /sys/bus/pci/drivers/xhci_hcd
$ echo :07:00.0 | sudo tee unbind && echo :07:00.0 | sudo tee bind

With some luck, this keeps the USB devices working for a while, after
which they crash again.

There are actually two more ways to trigger this bug:

1) Executing lsusb -vvv. Crahes most of the time. This leads to the following 
output in the
   kernel log:

[ 9961.755079] DMAR: DRHD: handling fault status reg 202
[ 9961.755090] DMAR: [DMA Read] Request device [07:00.0] fault addr
ffe5c000 [fault reason 06] PTE Read access is not set
[ 9961.755118] DMAR: DRHD: handling fault status reg 302
[ 9961.755126] DMAR: [DMA Read] Request device [07:00.0] fault addr
ffe5c000 [fault reason 06] PTE Read access is not set
[ 9961.755234] DMAR: DRHD: handling fault status reg 402
[ 9961.755239] DMAR: [DMA Read] Request device [07:00.0] fault addr
ffe5c000 [fault reason 06] PTE Read access is not set
[ 9961.755244] xhci_hcd :07:00.0: WARNING: Host System Error
[ 9962.757254] usb 3-4: Failed to suspend device, error -22
[ 9962.760476] usb 2-1.4.4.4: usbfs: usb_submit_urb returned -22
[ 9962.760493] usb 2-1.4.4.4: usbfs: usb_submit_urb returned -22
[ 9962.762059] usb 2-1.4.4.4: usbfs: usb_submit_urb returned -22
[ 9962.762100] usb 2-1.4.4.4: usbfs: usb_submit_urb returned -22
[ 9962.762959] usb 2-1.4.4: usbfs: usb_submit_urb returned -22
[ 9962.762975] usb 2-1.4.4: usbfs: usb_submit_urb returned -22
[ 9962.764339] usb 2-1.4.4: usbfs: usb_submit_urb returned -22
[ 9962.764374] usb 2-1.4.4: usbfs: usb_submit_urb returned -22
[ 9962.764387] usb 2-1.4.4: usbfs: usb_submit_urb returned -22
[ 9962.764411] usb 2-1.4.4: usbfs: usb_submit_urb returned -22
[ 9962.765308] usb 2-1.4.1.1: usbfs: usb_submit_urb returned -22
[ 9962.765324] usb 2-1.4.1.1: usbfs: usb_submit_urb returned -22
[ 9962.765446] usb 2-1.4.1.1: usbfs: usb_submit_urb returned -22
[ 9962.766239] usb 2-1.4.1.1: usbfs: usb_submit_urb returned -22
[ 9962.766265] usb 2-1.4.1.1: usbfs: usb_submit_urb returned -22
[ 9962.767168] usb 2-1.4.1: usbfs: usb_submit_urb returned -22
[ 9962.767184] usb 2-1.4.1: usbfs: usb_submit_urb returned -22
[ 9962.767987] usb 2-1.4.1: usbfs: usb_submit_urb returned -22
[ 9962.768015] usb 2-1.4.1: usbfs: usb_submit_urb returned -22
[ 9962.768041] usb 2-1.4.1: usbfs: usb_submit_urb returned -22
[ 9962.768872] usb 2-1.4: usbfs: usb_submit_urb returned -22
[ 9962.768887] usb 2-1.4: usbfs: usb_submit_urb returned -22
[ 9962.769615] usb 2-1.4: usbfs: usb_submit_urb returned -22
[ 9962.769624] usb 2-1.4: usbfs: usb_submit_urb returned -22
[ 9962.769629] usb 2-1.4: usbfs: usb_submit_urb returned -22
[ 9962.769637] usb 2-1.4: usbfs: usb_submit_urb returned -22
[ 9962.769927] usb 2-1: usbfs: usb_submit_urb returned -22
[ 9962.770201] usb 2-1: usbfs: usb_submit_urb returned -22
[ 9962.770210] usb 2-1: usbfs: usb_submit_urb returned 

Bug#940930: devscripts: add new script for self-service give-backs

[Paul Wise]

On Sun, 2019-09-22 at 14:17 +0200, Mattia Rizzolo wrote:

> assure me that client certificates will stay

I guess that depends entirely on when browsers delete their support for 
client certificates. They've been breaking them more and more over time.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#863118: devscripts configuration

[Paul Wise]

On Sun, 2019-09-22 at 19:08 +0200, Nicolas Boulenguez wrote:

> Note that Config.pm uses '/bin/bash'.

I hadn't noticed, thanks for pointing that out.

> Out of curiousity: I was once taught that not relying on $PATH,
> aliases and so on was safer. Do you have a reference (the question
> seems to vague for a web search)?

Relying on the current location of the binary isn't a great idea since
it could change or could be different on different operating systems.
For example with the /usr merge stuff it will be in /usr/bin/bash and
/bin/bash will only be a compatibility symlink. On Solaris or BSD it
could be somewhere in /opt/gnu or similar.

> Confvar only unsets the variables matching the list (or regex)
> expected by the devscript tool.
> devscripts.conf(5) requires this behaviour.
> Confvar does not modify HOME, or any unrelated setting.

Hmm, I could have sworn environment was inherited before, perhaps I
have broken it with my changes.

> I agree that these are changes in behaviour introduced by Confvar.
> They have been approved by a devscripts maintainer in messages 10 to
> 27 in the same bug log.

I see thanks.

> As far as I understand:
> qq{} allows ' instead of \' inside literal strings.
> q{} allows " instead of \" inside interpolated strings.
> None happens in Confvar for now.
> This would only raise the barrier for people less fluent in perl like
> me.

Personally I think these increase readability even when the escapes
aren't present because it is easy to see where the string ends instead
of having to parse it in your head.

Another handy one is using s{foo}{bar}g instead of s/foo/bar/g

> I could argue that, in order to see that your implementation is safer,
> one has to be fluent with perl constructs like
>   map {qq{"\$$_"}} @key_names
> and understand why " \0 \n are passed correctly via
>   printf '%s\0' "$a"

I consider those to be fairly simple constructs, but a clarifying
comment could help people not very familiar with Perl or shell.

The map call simply applies the first argument as a function to each
element of the array, with $_ being the argument to the function.

The printf builtin using %s as the first argument is the only safe way
to output a string without any mangling by the shell. The printf
builtin applies the first argument to each of the other arguments and
prints them to stdout in turn. The NUL character (\0) is the best
option for separating each variable to avoid doing escaping/etc.

> After many attempts at comparable solutions, I have encountered
> scripts accepting a non-static range of variable identifiers defined
> by a pattern, or even worst by the content of another user variable. I
> have found no way to do this without parsing the output of the 'set'
> built-in.  The escaping used by 'set' is described in the comments at
> the end of Confvar.pm.

It looks like `compgen -A variable` or `compgen -v` can output the
names of all bash variables, if you then loop through all the variables
printing both the name and value (NUL separated) then you can just pass
out all variable names and values and then match them on the Perl side.
This could even mean that the bash script can be converted to a static
script file instead of a generated script embedded in Perl. Personally
I quite dislike code where one language is embedded in another.

> As far as I understand, Dpkg::IPC::spawn separates stdout from stderr.

Good to hear.

> > any output the devscripts config generates also isn't parsed by the
> > Perl code. Probably the way to do this is to print a few NUL characters
> > in a row to indicate the start of the exported variables and discard
> > any output before those NUL characters. Of course the devscripts config
> > could print the NULs too and thus break the parsing, but outputting
> > NULs from one's devscripts config seems unlikely to exist today.

Woops, I missed the very obvious solution of using a separate file
descriptor to pass out the variables instead of using stdout.

> In the messages quoted above, the maintainers are in favor of
> requiring only simple affectations in configuration files, and even
> removing shell support in the future if ever possible.

Personally I use the shell support to avoid hard-coding things in
~/.devscripts that are primarily defined elsewhere or vary depending on
aspects of my shell environment. I think other folks do the same.

> It would be way safer to report any unexpected output, and only go on
> proceeding with an explicit override (for example if
> lib/Devscripts/Output.pm::die_on_error is false).

I think it would be better to just define a safe protocol than try and
handle exceptions. Sure if you want to force people to make their
configs not print anything, that is fine but that is orthogonal to safe
communication between the config script and devscripts, the best way to
do that is to make what the config script does output irrelevant by
ignoring it. Using a separate file descriptor would be the best option
here, 

Bug#933192: lintian-brush: complains repository is dirty, but git status lists no files

[Felipe Sateler]

On Sun, Sep 22, 2019 at 8:52 PM Jelmer Vernooij  wrote:

> On Sun, Sep 22, 2019 at 08:02:56PM -0300, Felipe Sateler wrote:
> > On Sat, Aug 31, 2019 at 7:45 AM Jelmer Vernooij 
> wrote:
> > > On Sun, Jul 28, 2019 at 11:01:29PM -0400, Felipe Sateler wrote:
> > > > On Sun, Jul 28, 2019, 18:36 Jelmer Vernooij 
> wrote:
> > > > > On Sat, Jul 27, 2019 at 08:54:17AM -0400, Felipe Sateler wrote:
> > > > > > lintian-brush complains repository is dirty, but repo is clean:
> > > > > >
> > > > > > felipe@felipedell:csound% lintian-brush
> > > > > > /home/felipe/src/deb/pkg-multimedia/csound: Please commit pending
> > > > > changes first.
> > > > > > % git status
> > > > > > On branch master
> > > > > > Your branch is ahead of 'origin/master' by 3 commits.
> > > > > >   (use "git push" to publish your local commits)
> > > > > >
> > > > > > nothing to commit, working tree clean
> > > > > >
> > > > > >
> > > > > > Turns out there are gitignored files:
> > > > > >
> > > > > > % git clean -fdX
> > > > > > Removing .pc/
> > > > > > Removing .vscode/
> > > > > > Removing test.wav
> > > > > >
> > > > > > After this lintian-brush can work.
> > > > > >
> > > > > > I think lintian-brush should also ignore gitignored files
> > > > >
> > > > > lintian-brush attempts to ignore gitignored files, but it seems
> that
> > > > > this doesn't always work.
> > > > >
> > > > > In this particular case, it appears that it does properly ignore
> > > > > test.wav because "*.wav" exists in .gitignore.
> > > > >
> > > > > I don't see any matches for .pc/ or .vscode/ in .gitignore though.
> Do
> > > > > you perhaps have them in ~/.git/ignore ?
> > > > Yes, I have .vscode in the global gitignore.
> > > >
> > > > Were there any files under
> > > > > .pc/ or .vscode/ that you can remember?
> > > > >
> > > > I don't know if .pc had anything in it, but .vscode probably did.
> > > Can you try again with dulwich currently in unstable? Several
> > > gitignore fixes have gone in that may have addressed this.
> > It's still failing. I think global gitignore is not processed by
> > lintian-brush.
> It does attempt to read global ignore files, and also did at
> the time your reported this bug - but it's of course possible that there
> is a bug in the way this is done.
>
> The next version of lintian-brush will spit out what files it
> considers still having pending changes when --verbose is specified, so
> that should hopefully make it easier to understand what's happening
> here.
>
> How many files does 'git ignore' list as being in use by this repo?
>

It lists a directory. Perhaps that is the problem?

Ignored files:
  (use "git add -f ..." to include in what will be committed)
.vscode/



> > > > I wonder why not just rely on git status (or the plumbing equivalent)
> > > > instead of detecting changes manually?
> > > Mostly to avoid shelling out - lintian-brush runs the equivalent of
> > > git status times before and after running each fixer - that can be
> > > quite slow on large repositories, where each run takes ~.5 seconds.
> >
> >
> > > Rather than statting, it uses inotify to watch what files have
> > > changed by each fixer, and then checks if those are ignored files or
> > > not.
> > But why is it necessary to run after each fixer? Perhaps a single one at
> > the start is necessary.
> Yes - it does this to check if the fixer actually made any changes.
>

OK.


-- 

Saludos,
Felipe Sateler

Bug#940987: rdetails fails: TypeError: sequence item 0: expected str instance, bytes found

[Felipe Sateler]

Package: apt-xapian-index
Version: 0.50
Severity: important

Hi,

Trying to issue axi-cache rdetails fails:

% axi-cache rdetails apt-xapian-index
Traceback (most recent call last):
  File "/usr/bin/axi-cache", line 861, in 
sys.exit(ui.perform())
  File "/usr/bin/axi-cache", line 852, in perform
return f(self.args)
  File "/usr/bin/axi-cache", line 718, in do_rdetails
print(name, tag, " ".join(deps))
TypeError: sequence item 0: expected str instance, bytes found


It seems the query is returning bytes instead of strings. Converting
with utf-8 makes it work (but I have no idea if this fix is correct):

deps = map(lambda x: x.decode('utf-8'), db.get_rdeps(name, pfx))

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

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

Versions of packages apt-xapian-index depends on:
ii  python3 3.7.3-1
ii  python3-apt 1.8.4
ii  python3-debian  0.1.36
ii  python3-xapian  1.4.12-2

apt-xapian-index recommends no packages.

Versions of packages apt-xapian-index suggests:
ii  python3-xdg  0.25-5

-- no debconf information

Bug#933192: lintian-brush: complains repository is dirty, but git status lists no files

[Jelmer Vernooij]

On Sun, Sep 22, 2019 at 08:02:56PM -0300, Felipe Sateler wrote:
> On Sat, Aug 31, 2019 at 7:45 AM Jelmer Vernooij  wrote:
> > On Sun, Jul 28, 2019 at 11:01:29PM -0400, Felipe Sateler wrote:
> > > On Sun, Jul 28, 2019, 18:36 Jelmer Vernooij  wrote:
> > > > On Sat, Jul 27, 2019 at 08:54:17AM -0400, Felipe Sateler wrote:
> > > > > lintian-brush complains repository is dirty, but repo is clean:
> > > > >
> > > > > felipe@felipedell:csound% lintian-brush
> > > > > /home/felipe/src/deb/pkg-multimedia/csound: Please commit pending
> > > > changes first.
> > > > > % git status
> > > > > On branch master
> > > > > Your branch is ahead of 'origin/master' by 3 commits.
> > > > >   (use "git push" to publish your local commits)
> > > > >
> > > > > nothing to commit, working tree clean
> > > > >
> > > > >
> > > > > Turns out there are gitignored files:
> > > > >
> > > > > % git clean -fdX
> > > > > Removing .pc/
> > > > > Removing .vscode/
> > > > > Removing test.wav
> > > > >
> > > > > After this lintian-brush can work.
> > > > >
> > > > > I think lintian-brush should also ignore gitignored files
> > > >
> > > > lintian-brush attempts to ignore gitignored files, but it seems that
> > > > this doesn't always work.
> > > >
> > > > In this particular case, it appears that it does properly ignore
> > > > test.wav because "*.wav" exists in .gitignore.
> > > >
> > > > I don't see any matches for .pc/ or .vscode/ in .gitignore though. Do
> > > > you perhaps have them in ~/.git/ignore ?
> > > Yes, I have .vscode in the global gitignore.
> > >
> > > Were there any files under
> > > > .pc/ or .vscode/ that you can remember?
> > > >
> > > I don't know if .pc had anything in it, but .vscode probably did.
> > Can you try again with dulwich currently in unstable? Several
> > gitignore fixes have gone in that may have addressed this.
> It's still failing. I think global gitignore is not processed by
> lintian-brush.
It does attempt to read global ignore files, and also did at
the time your reported this bug - but it's of course possible that there
is a bug in the way this is done.

The next version of lintian-brush will spit out what files it
considers still having pending changes when --verbose is specified, so
that should hopefully make it easier to understand what's happening
here.

How many files does 'git ignore' list as being in use by this repo?

> > > I wonder why not just rely on git status (or the plumbing equivalent)
> > > instead of detecting changes manually?
> > Mostly to avoid shelling out - lintian-brush runs the equivalent of
> > git status times before and after running each fixer - that can be
> > quite slow on large repositories, where each run takes ~.5 seconds.
> 
> 
> > Rather than statting, it uses inotify to watch what files have
> > changed by each fixer, and then checks if those are ignored files or
> > not.
> But why is it necessary to run after each fixer? Perhaps a single one at
> the start is necessary.
Yes - it does this to check if the fixer actually made any changes.

Jelmer

Bug#933192: lintian-brush: complains repository is dirty, but git status lists no files

[Felipe Sateler]

Hi,

On Sat, Aug 31, 2019 at 7:45 AM Jelmer Vernooij  wrote:

> On Sun, Jul 28, 2019 at 11:01:29PM -0400, Felipe Sateler wrote:
> > On Sun, Jul 28, 2019, 18:36 Jelmer Vernooij  wrote:
> > > On Sat, Jul 27, 2019 at 08:54:17AM -0400, Felipe Sateler wrote:
> > > > lintian-brush complains repository is dirty, but repo is clean:
> > > >
> > > > felipe@felipedell:csound% lintian-brush
> > > > /home/felipe/src/deb/pkg-multimedia/csound: Please commit pending
> > > changes first.
> > > > % git status
> > > > On branch master
> > > > Your branch is ahead of 'origin/master' by 3 commits.
> > > >   (use "git push" to publish your local commits)
> > > >
> > > > nothing to commit, working tree clean
> > > >
> > > >
> > > > Turns out there are gitignored files:
> > > >
> > > > % git clean -fdX
> > > > Removing .pc/
> > > > Removing .vscode/
> > > > Removing test.wav
> > > >
> > > > After this lintian-brush can work.
> > > >
> > > > I think lintian-brush should also ignore gitignored files
> > >
> > > lintian-brush attempts to ignore gitignored files, but it seems that
> > > this doesn't always work.
> > >
> > > In this particular case, it appears that it does properly ignore
> > > test.wav because "*.wav" exists in .gitignore.
> > >
> > > I don't see any matches for .pc/ or .vscode/ in .gitignore though. Do
> > > you perhaps have them in ~/.git/ignore ?
> > Yes, I have .vscode in the global gitignore.
> >
> > Were there any files under
> > > .pc/ or .vscode/ that you can remember?
> > >
> > I don't know if .pc had anything in it, but .vscode probably did.
> Can you try again with dulwich currently in unstable? Several
> gitignore fixes have gone in that may have addressed this.
>

It's still failing. I think global gitignore is not processed by
lintian-brush.


>
> > I wonder why not just rely on git status (or the plumbing equivalent)
> > instead of detecting changes manually?
> Mostly to avoid shelling out - lintian-brush runs the equivalent of
> git status times before and after running each fixer - that can be
> quite slow on large repositories, where each run takes ~.5 seconds.


> Rather than statting, it uses inotify to watch what files have
> changed by each fixer, and then checks if those are ignored files or
> not.
>

But why is it necessary to run after each fixer? Perhaps a single one at
the start is necessary.

-- 

Saludos,
Felipe Sateler

Bug#940902: doesn't read the data

[Ana Guerrero Lopez]

Hi Andreas,

On Sat, Sep 21, 2019 at 06:39:51PM +0200, Andreas Tille wrote:
> Control: tags -1 help
> 
> Dear Ana,
> 
> On Sat, Sep 21, 2019 at 05:41:27PM +0200, Ana Guerrero Lopez wrote:
> > This new version of cycle, ported to python3, doesn't read the data file
> > ( under .cycle) and prompts to create a new user.
> > 
> > Not creating a new user and downgrading to the version in buster (-14), 
> > allows
> > to continue using the application with the previous data.
> 
> thanks a lot for thorough testing the package!
> 
> The situation is as follows:  Upstream is dead so we probably become
> upstream in Debian.  I has done my best to port it to Python3 with the
> help of Debian Python team.  I personally can not do more.  I can just
> hope that someone who is using the program will try to fix it.  If you
> feel able to do this it would be great.  If you know somebody who could
> do it great as well.  I'd be really happy if we could keep the package
> inside Debian and if someone could fix it.

I used to maintain this package, so I'm well aware of the problems, check
the changelog ;)

The package should be removed from the archive, the base code is very poor to
start with, and the patching for python3 isn't going to fix this, just add
more problems...
Your current python3 porting is not helping here since many people will start
the application, will be prompted for a new user, will create it and erase
all their data. So please, revert your changes and if that means the package
will be removed from the archive, let it be. At least people will be able to
continue using it while they move to something else (or not), but won't lose
their data as it'll happen now.

Thanks for caring.

cheers,
Ana

Bug#940985: dnsmasq WFTBFS: Accesses ECC curves directly

[Magnus Holmgren]

Package: dnsmasq
Version: 2.80-1
Tags: upstream
Severity: serious

dnsmasq_ecdsa_verify() (in crypto.c) uses the addresses of nettle_secp_256r1 
and nettle_secp_384r1 directly. As the comment in ecc-curve.h explains, "Due 
to ABI subtleties, applications should not refer to these directly, but use 
the below accessor functions." (nettle_get_secp_256r1() and 
nettle_get_secp_384r1().) Indeed, dnsmasq will fail to build with nettle 
3.5.1.

-- 
Magnus Holmgrenholmg...@debian.org
Debian Developer 

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

Bug#940986: duplicity: sh_pexpect_backend.py fails to byte-compile during installation

[Tomasz Buchert]

Package: duplicity
Version: 0.8.04-1
Severity: normal

Dear Maintainer,
the version 0.8.04-1 of duplicity fails to pypy3compile ssh_pexpect_backend.py
during installation with the following message:

Setting up duplicity (0.8.04-1) ...
-V is ignored in pypy3compile
Failed to byte-compile /usr/lib/python3/dist-
packages/duplicity/backends/ssh_pexpect_backend.py:   File "/usr/lib/pyth
on3/dist-packages/duplicity/backends/ssh_pexpect_backend.py", line 52
global pexpect
^
SyntaxError: name 'pexpect' is assigned to before global declaration

==

AFAICT, this does not break duplicity in general, but I'd expect that the
pexpect backend may be broken.



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

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

Versions of packages duplicity depends on:
ii  gnupg  2.2.17-3
ii  libc6  2.29-1
ii  librsync2  2.0.2-1
ii  python33.7.3-1
ii  python3-fasteners  0.12.0-5
ii  python3-future 0.16.0-1
ii  python3-lockfile   1:0.12.2-2

Versions of packages duplicity recommends:
ii  python3-oauthlib  2.1.0-1
ii  python3-paramiko  2.6.0-1
ii  python3-pexpect   4.6.0-1
ii  python3-urllib3   1.24.1-1
ii  rsync 3.1.3-6+b1

Versions of packages duplicity suggests:
pn  lftp 
pn  ncftp
pn  par2 
ii  python3-boto 2.49.0-2
ii  python3-pip  18.1-5
pn  python3-swiftclient  
pn  tahoe-lafs   

-- no debconf information

Bug#940984: python-biggles: should this package be removed?

[Sandro Tosi]

Source: python-biggles
Severity: serious

Hello,
as part of https://wiki.debian.org/Python/2Removal i noticed python-biggles and
i believe we should remove it from Debian:

- maybe it was sophisiticated when it was created, but there are better
  alternatives now (but i may be bias as i maintainer some of them :) )
- python2 only (in debian)
- upstream moved to https://github.com/biggles-plot/biggles with a version
  that's py3k compatible, but someone should step up and package it
- no rdeps
- low popcon
- last upload from Deepak on this package was in 2010

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

Regards,
Sandro

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

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

Bug#940983: rust-sha-1: rebuilding results in broken dependencies.

[peter green]

Package: rust-sha-1
Version: 0.8.1-2
Severity: serious

If rust-sha-1 is re-built, the version mentioned in virtual package names in the provides changes from 
"0.4" to "0.8", but the version mentioned in the virtual package names in the depends 
stays at "0.4", thus breaking dependencies between the binary packages.

Bug#940982: planet-venus: should this package be removed?

[Sandro Tosi]

Package: planet-venus
Severity: serious

Hello,
as part of https://wiki.debian.org/Python/2Removal i noticed planet-venus, and i
believe we should remove it from Debian:

- RC buggy
- pretty low pop-con
- python2-only, also upstream
- https://github.com/rubys/venus/issues/37 showed some possible work to port it
  to py3k, but that effort never materialized
- last maintainer upload in 2014

if i dont hear a good reason to keep this package in Debian within a week, i
will file for its removal.

Regards,
Sandro

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

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

Versions of packages planet-venus depends on:
ii  python  2.7.16-1
ii  python-chardet  3.0.4-3
ii  python-feedparser   5.2.1-1
ii  python-html5lib 1.0.1-1
pn  python-htmltmpl 
ii  python-httplib2 0.11.3-2
pn  python-librdf   
ii  python-libxml2  2.9.4+dfsg1-7+b3
pn  python-portalocker  
ii  python-utidylib 0.5-2

Versions of packages planet-venus recommends:
pn  python-libxslt1  

Versions of packages planet-venus suggests:
pn  python-django  
pn  python-genshi  
ii  python-lxml4.4.1-1

Bug#940981: doconce: should this package be removed?

[Sandro Tosi]

Package: doconce
Severity: serious

Hello,
as part of https://wiki.debian.org/Python/2Removal i noticed doconce, and i
believe we should remove it from Debian:

- last upload to debian 7 years go
- low popcon
- Uploader seems to have lost interest in Debian
- python2 only (in debian)
- upstream has a new home https://github.com/hplgit/doconce that supports p3k,
  but someone has to step up and upload it

if i dont hear back with a good reason to keep this package in Debian within a
week, i will ask for its removal.

Regards,
Sandro

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

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

Versions of packages doconce depends on:
ii  python 2.7.16-1
ii  python2.7  2.7.16-2

Versions of packages doconce recommends:
pn  preprocess   
ii  python-mako  1.0.7+ds1-1

Versions of packages doconce suggests:
ii  imagemagick  8:6.9.10.23+dfsg-2.1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
ii  pandoc   2.2.1-3+b2
pn  ptex2tex 
ii  python-docutils  0.14+dfsg-4
ii  python-sphinx1.8.4-1
ii  texlive-base 2018.20190227-2
pn  texlive-base-recommended 
ii  texlive-latex-base   2018.20190227-2

Bug#940980: clang-7: ICE while building pocl on mips*el

[Andreas Beckmann]

Package: clang-7
Version: 1:7.0.1-9
Severity: normal

https://buildd.debian.org/status/fetch.php?pkg=pocl=mipsel=1.3-6=1568920151=0
https://buildd.debian.org/status/fetch.php?pkg=pocl=mips64el=1.3-6=1568939487=0

mipsel:

Stack dump:
0.  Program arguments: /usr/lib/llvm-7/bin/clang -cc1 -triple 
mipsel-unknown-linux-gnu -emit-llvm-bc -emit-llvm-uselists -disable-free 
-disable-llvm-verifier -discard-value-names -main-file-name convert_type.cl 
-mrelocation-model pic -pic-level 1 -mthread-model posix -mdisable-fp-elim 
-fmath-errno -ffp-contract=off -masm-verbose -mconstructor-aliases 
-fuse-init-array -target-cpu mips32r2 -target-feature -noabicalls 
-target-feature +fpxx -target-feature +nooddspreg -target-abi o32 -mfloat-abi 
hard -dwarf-column-info -debugger-tuning=gdb -coverage-notes-file 
/<>/obj-mipsel-linux-gnu/lib/kernel/host/GENERIC/convert_type.cl.gcno
 -resource-dir /usr/lib/llvm-7/lib/clang/7.0.1 -include 
/<>/include/_kernel.h -include 
/<>/include/_enable_all_exts.h -D _CL_DISABLE_HALF -D 
__OPENCL_C_VERSION__=120 -D __OPENCL_VERSION__=120 -D 
POCL_DEVICE_ADDRESS_BITS=32 -D cl_khr_int64 -D cl_khr_global_int32_base_atomics 
-D cl_khr_local_int32_base_atomics -D cl_khr_3d_image
 _writes -D cl_khr_fp64 -internal-isystem /usr/local/include -internal-isystem 
/usr/lib/llvm-7/lib/clang/7.0.1/include -internal-externc-isystem 
/usr/include/mipsel-linux-gnu -internal-externc-isystem /include 
-internal-externc-isystem /usr/include -Wall -Wno-unused-local-typedef 
-fdebug-compilation-dir /<>/obj-mipsel-linux-gnu/lib/kernel/host 
-ferror-limit 19 -fmessage-length 0 -fobjc-runtime=gcc 
-fdiagnostics-show-option -cl-std=CL1.2 
-cl-ext=-all,+cl_khr_global_int32_base_atomics,+cl_khr_local_int32_base_atomics,+cl_khr_3d_image_writes,+cl_khr_fp64,
 -o 
/<>/obj-mipsel-linux-gnu/lib/kernel/host/GENERIC/convert_type.cl.bc
 -x cl /<>/lib/kernel/convert_type.cl -faddrsig 
1.  /<>/lib/kernel/convert_type.cl:34418:1 
>/include/_kernel.h:89:28>: current parser token 
'__attribute__'
2.  /<>/lib/kernel/convert_type.cl:34410:9: LLVM IR generation 
of declaration 'convert_ushort2_sat_rte'
3.  /<>/lib/kernel/convert_type.cl:34410:9: Generating code 
for declaration 'convert_ushort2_sat_rte'
clang: error: unable to execute command: Bus error
clang: error: clang frontend command failed due to signal (use -v to see 
invocation)
clang version 7.0.1-9+b1 (tags/RELEASE_701/final)
Target: mipsel-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-7/bin
clang: note: diagnostic msg: PLEASE submit a bug report to 
https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, 
and associated run script.
[ 65%] Building C to LLVM bitcode 
/<>/obj-mipsel-linux-gnu/lib/kernel/host/GENERIC/get_global_size.c.bc
cd /<>/obj-mipsel-linux-gnu/lib/kernel/host && 
/usr/lib/llvm-7/bin/clang-7 --target=mipsel-unknown-linux-gnu 
-D_CL_DISABLE_HALF -emit-llvm -ffp-contract=off -D__OPENCL_VERSION__=120 
-DPOCL_DEVICE_ADDRESS_BITS=32 -Dcl_khr_int64 -Dcl_khr_global_int32_base_atomics 
-Dcl_khr_local_int32_base_atomics -Dcl_khr_3d_image_writes -Dcl_khr_fp64 
-Xclang 
-cl-ext=-all,+cl_khr_global_int32_base_atomics,+cl_khr_local_int32_base_atomics,+cl_khr_3d_image_writes,+cl_khr_fp64,
 -O1 -xc -std=c11 -D__CBUILD__ -fno-math-errno -fno-stack-protector -fPIC -o 
/<>/obj-mipsel-linux-gnu/lib/kernel/host/GENERIC/get_global_size.c.bc
 -c /<>/lib/kernel/get_global_size.c -I/<>/include 
-include /<>/include/_kernel_c.h
clang: note: diagnostic msg: 


PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/convert_type-46f685.cl
clang: note: diagnostic msg: /tmp/convert_type-46f685.sh
clang: note: diagnostic msg: 


make[3]: *** 
[lib/kernel/host/CMakeFiles/kernel_host_GENERIC.dir/build.make:362: 
lib/kernel/host/GENERIC/convert_type.cl.bc] Error 254
make[3]: *** Waiting for unfinished jobs

mips64el:

Stack dump:
0.  Program arguments: /usr/lib/llvm-7/bin/clang -cc1 -triple 
mips64el-unknown-linux-gnu -emit-llvm-bc -emit-llvm-uselists -disable-free 
-disable-llvm-verifier -discard-value-names -main-file-name convert_type.cl 
-mrelocation-model pic -pic-level 1 -mthread-model posix -mdisable-fp-elim 
-fmath-errno -ffp-contract=off -no-integrated-as -mconstructor-aliases 
-fuse-init-array -target-cpu mips64r2 -target-feature -noabicalls -target-abi 
n64 -mfloat-abi hard -dwarf-column-info -debugger-tuning=gdb 
-coverage-notes-file 
/<>/obj-mips64el-linux-gnuabi64/lib/kernel/host/GENERIC/convert_type.cl.gcno
 -resource-dir /usr/lib/llvm-7/lib/clang/7.0.1 -include 
/<>/include/_kernel.h -include 
/<>/include/_enable_all_exts.h -D _CL_DISABLE_HALF -D 
__OPENCL_C_VERSION__=120 -D __OPENCL_VERSION__=120 -D 
POCL_DEVICE_ADDRESS_BITS=64 -D cl_khr_int64 -D cl_khr_global_int32_base_atomics 
-D cl_khr_local_int32_base_atomics -D cl_khr_3d_image_writes -D cl_khr_fp64 

Bug#939586: gwenview should provide a /usr/lib/mime/packages/gwenview file

[Nicholas D Steeves]

On Fri, Sep 06, 2019 at 05:57:27PM +0200, Erwan David wrote:
> Package: gwenview
> Version: 4:18.04.0-1.1+b1
> Severity: minor
> 
> since there is no /usr/lib/mime/packages/gwenview, we cannot use gwenview as
> default image viewer for non KDE applications. Such a file would be useful.
> 

+1 !  I was just about to file a bug on this topic, because I've
finally gotten fed up about this.  Steps to reproduce:

1. Install Debian with KDE Desktop
2. "see foo.png" opens with gwenview
3. Install calibre (installs ImageMagick as a dependency)
4. "see foo.png" now opens in Imagemagick :-(

The only workaround I'm aware of is /etc/mailcap.order.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#808999: init.d/bootlogd: Last two lines are missing from the log

[Bjarni Ingi Gislason]

On Sat, Aug 24, 2019 at 01:20:00AM +, Bjarni Ingi Gislason wrote:
> On Thu, Aug 22, 2019 at 12:05:27PM +, Dmitry Bogatov wrote:
> > 
> > control: tags -1 +moreinfo
> > 

  The bug is actually in "stop-bootlogd".

  See Debian bug report #920117.

  So this report (#808999) should be closed.

-- 
Bjarni I. Gislason

Bug#938006: python-pattern: Python2 removal in sid/bullseye

[Sandro Tosi]

On Fri, 30 Aug 2019 07:43:51 + Matthias Klose  wrote:
> Package: src:python-pattern
> Version: 2.6+git20150109-3
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
>
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

Looks like upstream released 3.6 which supports python3 -- Miriam, do
you have an plan to package this version?

https://pypi.org/project/Pattern/
https://github.com/clips/pattern

Bug#920117: stop-bootlogd: It starts too early

[Bjarni Ingi Gislason]

On Wed, Jan 23, 2019 at 07:28:45PM +, Dmitry Bogatov wrote:
> 
> control: tags -1 +confirmed
> 
> [2019-01-21 23:01] Bjarni Ingi Gislason 
> > Package: bootlogd
> > Version: 2.93-3
> > Severity: wishlist
> >
> > Dear Maintainer,
> >
> >   the "bootlogd" should stop as late as possible to catch all output from
> > the booting process.
> >
> >   Currently it is in the time slot "02" but the last boot script is
> > "rc.local" in "04".
> >
> >   The "Required-Start" in "/etc/init.d/stop-bootlogd" should be changed
> > from "$local_fs" to "$all" (same as for "rc.local") to start it as the
> > last script.
> 
> Yes, I see; but it is correct to have two scripts that depends on $all?
> Maybe it would be better to depend on rc.local?
> 
> Dear co-maintainers, any ideas, what uninteded side-effects it may have?

  I tested the use of "rc.local" but "insserv --showall stop-bootlogd"
rejected that.

  Using "$all" is correct, see "insserv(8)" (search for "$all").

  After issuing "update-rc.d stop-bootlogd" the content for "rc.local"
and "stop-bootlogd" in the file "/etc/init.d/.depend.start") is the
same.

  The output on the terminal (use "--noclear", 

1:2345:respawn:/sbin/getty --noclear 38400 tty1

in the "/etc/inittab" file)

shows the same last lines as in the "/var/log/boot" file.

(The last line should come from "stop-bootlogd" which is
"/etc/init.d/bootlogd stop")

-- 
Bjarni I. Gislason

Bug#940979: orc: OrcTargetPowerPCFlags enum typedef FTBFS

[GCS]

Source: orc
Version: 0.4.30-1
Severity: important
Tags: patch upstream

I would like to update VIPS, but it FTBFS due to orc. Its upstream
forgot the 'typedef' for one enum. It is fixed now[1] and will be part
of the next release. But please apply it before as your time permits.

Thanks,
Laszlo/GCS
[1] 
https://gitlab.freedesktop.org/gstreamer/orc/merge_requests/32/diffs?commit_id=0b1a288835d6a3b6d52f77e0c2e86d685de6526e

Bug#940972: litl: flacky autopkgtest: FAIL: test_litl_write_multiple_threads(|_flush)

[Samuel Thibault]

Control: clone -1 -2
Control: severity -2 normal
Control: forwarded -2 litl-de...@fusionforge.int-evry.fr
Control: tag -1 + pending
Control: tag -2 - pending

Hello,

Paul Gevers, le dim. 22 sept. 2019 21:32:39 +0200, a ecrit:
> it fails once in a while with one or the other multiple_threads test.

Indeed.  I wonder how we could make sure that package maintainers get
notified of such random failures.  I have forwarded the issue to
upstream.  In the meanwhile, I have disabled these two tests.

Samuel

Bug#940977: libfte: should this package be removed?

[Sandro Tosi]

Source: libfte
Severity: serious

Hello,
as part of https://wiki.debian.org/Python/2Removal i noticed libfte, and i
believe we should remove this package from Debian:

- single maintainer upload, immediately followed by a NMU
- python2 only, even upstream
- last upstream release 5 years ago, according to
  https://github.com/kpdyer/fteproxy/releases

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

Regards,
Sandro

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

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

Bug#940976: python-avc: should this package be removed?

[Sandro Tosi]

Package: python-avc
Severity: serious

Hello,
As part of https://wiki.debian.org/Python/2Removal i stumbled across this
package, and i believe we should remove it:

- popcon very low
- no maintainer upload to debian in 8 years
- last upload, NMU, 5 years ago
- last upstream release 3.5years ago

if I dont hear back with a good reason to keep this package in Debian withing a
week, i'll ask for python-avc removal.

Regards,
Sandro

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

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

Versions of packages python-avc depends on:
ii  python  2.7.16-1

python-avc recommends no packages.

Versions of packages python-avc suggests:
pn  jython   
ii  python-gtk2  2.24.0-6
pn  python-qt3   
ii  python-qt4   4.12.1+dfsg-2+b1
ii  python-tk2.7.16-2
ii  python-wxgtk3.0  3.0.2.0+dfsg-8

Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

[David Steele]

On Tue, Jul 23, 2019 at 2:10 PM Sean Whitton  wrote:
>
> The Policy Editors have decided that dropping the requirement to ship
> init scripts is not something that can be decided by means of the Policy
> Changes Process, at least for the time being.
>
> In proposing and reviewing wording to resolve this bug, then, we should
> be careful not to weaken the requirement to ship init scripts.
> Otherwise, in resolving this bug we would be changing the requirements
> to ship init scripts by means of the Policy Changes Process.
>
> I'm suggesting this be kept in mind.  It need not result in a wordier
> change, and I certainly agree with you that we should assume good faith
> on the part of package maintainers.
>

Candidate language attached. It adds "Also excepted are packages which require a
feature of an alternate init system which is not available in SysV-Style
init systems.". Thoughts?

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE
From 5b99099d370b6304cadaedc99d5f8d8cd3063c71 Mon Sep 17 00:00:00 2001
From: David Steele 
Date: Sun, 22 Sep 2019 15:53:12 -0400
Subject: [PATCH] Clarify exception to sysv init script requirement

---
 policy/ch-opersys.rst | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 3e685cf..41f06fa 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -1006,7 +1006,9 @@ supported by all init implementations. An exception to this rule is
 scripts or jobs provided by the init implementation itself; such jobs
 may be required for an implementation-specific equivalent of the
 ``/etc/rcS.d/`` scripts and may not have a one-to-one correspondence
-with the init scripts.
+with the init scripts. Also excepted are packages which require a
+feature of an alternate init system which is not available in SysV-Style
+init systems.
 
 .. _s-upstart:
 
-- 
2.23.0

Bug#940975: jQuery may not need two different packages

[David Prévot]

Package: libjs-jquery, node-jquery
Control: found -1 libjs-jquery/3.3.1~dfsg-3
Control: found -1 node-jquery/3.4.0+dfsg-1

Hi,

I only notice now that both libjs-jquery and node-jquery provide the
jquery.{,min.}js files, seem both build from the same source and use
almost the same version and long description.

I was not able to find a reason why we need two source packages, so
maybe we don’t.

Regards

David


signature.asc
Description: PGP signature

Bug#939446: emacs 26.1+1-3.2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 939446 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: emacs
Version: 26.1+1-3.2+deb10u1

Explanation: update the EPLA packaging key

Bug#940971: init script takes 90 seconds

[Mark Hindley]

Simon,

On Sun, Sep 22, 2019 at 09:05:32PM +0200, Simon Richter wrote:
> Package: dbus
> Version: 1.12.16-1
> Severity: important
> 
> Hi,
> 
> /etc/init.d/dbus is hanging pretty much exactly 90 seconds on either boot
> or manual start:

[snip]

> Init: sysvinit (via /sbin/init)

[snip]

> ii  libsystemd0   242-7

I have observed similar behaviour on sysvinit systems which still have systemd
installed.

I think it is related to libnss-systemd: removing it gets rid of the hang for
me.

Mark

Bug#936302: cigi-ccl: Python2 removal in sid/bullseye

[Sandro Tosi]

On Fri, 30 Aug 2019 07:13:21 + Matthias Klose  wrote:
> Package: src:cigi-ccl
> Version: 3.3.3a+svn818-10
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
>
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

I spent a bit of time on cigi-ccl, and i believe we should remove this
package: its popcon is extremely low (but it may also be a niche
package), it had RC bugs for almost a year and a half now, with no
activity.

If i dont hear back from you withing 5 days, i'll retitle this to RM

Regards,
Sandro

Bug#935173: audacity graphical windows fail to update properly

[Klaumi Klingsporn]

Am / On Sun, 22 Sep 2019 21:50:04 +0200
schrieb / wrote Yuri D'Elia :

> Ok -- wow, I think I've found the issue.
> I ran under a different system, and it seems that setting:
>
> export GTK_IM_MODULE=xim
>
> is causing the issue (!).
> If I unset this, then audacity works.
>
> Could you confirm this?

Not exactly! If I start audacity with

export GTK_IM_MODULE=xim & /usr/bin/audacity

nothing changed. But I've not installed scim, so maybe
setting this variable with scim installed at least triggers
the problem.

Klaumi

---
Klaus-Michael Klingsporn
mail: klaumi...@gmx.de
web: www.klaumikli.de

Bug#940973: libarchive-zip-perl breaks strip-nondeterminism autopkgtest: error: becoming Archive::Zip::DirectoryMember

[Chris Lamb]

Hi Paul,

> ok 20 - t/fixtures/zip/bug_803503.zip.in
> Reading ZIP archive failed: IO error: reading local extra field :
> 
> error: becoming Archive::Zip::DirectoryMember
> # Looks like your test exited with 29 just after 20.
> Tests failed

These is likely related:

  https://bugs.debian.org/858431
  https://salsa.debian.org/reproducible-builds/strip-nondeterminism/issues/4
  https://bugs.debian.org/931730

Will investigate soon.


Regards,

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

Bug#940974: oslo-sphinx: autopkgtest regression: autodep8 tests the wrong Python 3 package since Python 2 package was dropped

[Paul Gevers]

Source: oslo-sphinx
Version: 4.18.0-3
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of oslo-sphinx the autopkgtest of oslo-sphinx fails
in testing when that autopkgtest is run with the binary packages of
oslo-sphinx from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
oslo-sphinxfrom testing4.18.0-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. The issue is
that the logic in autodep8 to determine which package to use isn't that
smart. In the past, the package was correctly determined based on your
Python 2 package name, but since you dropped that, it picks the wrong
package (for Python 3 testing). My proposal to fix the current situation
is one of:
1) help fix autodep8 to find the right package (and maybe do smarter
testing on common Python workflows)
2) revert the order of the two packages in d/control, such that the
first one is the one that autodep8 should pick
3) don't use autodep8 to provide autopkgtests (maybe just hard code the
autodep8 template for now)

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

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=oslo-sphinx

https://ci.debian.net/data/autopkgtest/testing/amd64/o/oslo-sphinx/3005383/log.gz

autopkgtest [17:53:51]: test autodep8-python2: set -e ; for py in
$(pyversions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing
with $py:" ; $py -c "import oslosphinx_common; print oslosphinx_common"
; done
autopkgtest [17:53:51]: test autodep8-python2: [---
Testing with python2.7:
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named oslosphinx_common
autopkgtest [17:53:52]: test autodep8-python2: ---]



signature.asc
Description: OpenPGP digital signature

Bug#935173: audacity graphical windows fail to update properly

[Yuri D'Elia]

On Sun, Sep 22 2019, Klaumi Klingsporn wrote:
> This bug-message I get on the console too, so it may be
> related to the problems but doesn't seem to cause them.

Ok -- wow, I think I've found the issue.
I ran under a different system, and it seems that setting:

export GTK_IM_MODULE=xim

is causing the issue (!).
If I unset this, then audacity works.

Could you confirm this?

Bug#940973: libarchive-zip-perl breaks strip-nondeterminism autopkgtest: error: becoming Archive::Zip::DirectoryMember

[Paul Gevers]

Source: libarchive-zip-perl, strip-nondeterminism
Control: found -1 libarchive-zip-perl/1.66-1
Control: found -1 strip-nondeterminism/1.6.0-1
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 libarchive-zip-perl the autopkgtest of
strip-nondeterminism fails in testing when that autopkgtest is run with
the binary packages of libarchive-zip-perl from unstable. It passes when
run with only packages from testing. In tabular form:
   passfail
libarchive-zip-perlfrom testing1.66-1
strip-nondeterminism   from testing1.6.0-1
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
libarchive-zip-perl 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? If needed,
please change the bug's severity.

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=libarchive-zip-perl

https://ci.debian.net/data/autopkgtest/testing/amd64/s/strip-nondeterminism/3013957/log.gz

ok 20 - t/fixtures/zip/bug_803503.zip.in
Reading ZIP archive failed: IO error: reading local extra field :

error: becoming Archive::Zip::DirectoryMember
# Looks like your test exited with 29 just after 20.
Tests failed



signature.asc
Description: OpenPGP digital signature

Bug#935173: audacity graphical windows fail to update properly

[Klaumi Klingsporn]

Am / On Sun, 22 Sep 2019 21:02:11 +0200
schrieb / wrote Yuri D'Elia :

> Some widgets do not repaint properly, but the main issue
> is that audio tracks only seem to redraw when resizing
> the main window. I rebuilt audacity from git earlier
> today, but it still doesn't repaint the tracks (for
> instance, while playing, zooming, etc).

Mysterious! Works all fine here. The only irritation I have
got is in the devices-toolbar, where the names sometimes
don't fit in the boxes and the mouseklicks don't apply to
the right box (after window-resizing). But I've put this
toolbar down on the bottom of the audacity window and rarely
use it.

> The only thing I see is errors on the console:
>
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug
>
> but I'm not sure if they're related or not.

This bug-message I get on the console too, so it may be
related to the problems but doesn't seem to cause them.

Klaumi


---
Klaus-Michael Klingsporn
mail: klaumi...@gmx.de
web: www.klaumikli.de

Bug#940969: libdc1394-22: Please package new upstream release (2.2.6)

[Guus Sliepen]

tags 940969 + pending
thanks

> Source: libdc1394-22
> Version: 2.2.5-2.1
> Severity: normal
> X-Debbugs-CC: g...@debian.org p...@debian.org
> 
> Dear libdc1394-22 maintainers,
> 
> The upstream of libdc1394-22 has made a new release on 2019-04-28 (2.2.6, 
> https://sourceforge.net/projects/libdc1394/files/libdc1394-2/2.2.6/ ). Please
> consider packaging it in Debian.

Upstream changed the soname of the library, this means new package names
are necessary. Packages for 2.2.6 are currently waiting in the NEW
queue:

https://ftp-master.debian.org/new/libdc1394_2.2.6-1.html

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#940972: litl: flacky autopkgtest: FAIL: test_litl_write_multiple_threads(|_flush)

[Paul Gevers]

Source: litl
Version: 0.1.9-6
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear Samuel,

With a recent upload of glibc the autopkgtest of litl failed in testing
when that autopkgtest was run with the binary packages of glibc from
unstable. However, when the test was retried, the test passed. I looked
into the history of your autopkgtest (you recently added the
autopkgtest: great!!) and it fails once in a while with one or the other
multiple_threads test.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests. Please either fix the test to be more robust, or use the "flaky"
restriction for the offending test until a solution has been found.

I copied some of the output at the bottom of this report. (It's very
tense, can it be made more verbose as well?)

I'll have the migration software ignore the results of your autopkgtest
until this bug is fixed.

Paul

https://ci.debian.net/data/autopkgtest/unstable/amd64/l/litl/2855760/log.gz

PASS: test_litl_write
PASS: test_litl_read
PASS: test_litl_write_concurent
FAIL: test_litl_write_multiple_threads
PASS: test_litl_write_multiple_applications
PASS: test_litl_pause
PASS: test_litl_write_flush
PASS: test_litl_read_flush
PASS: test_litl_write_concurent_flush
FAIL: test_litl_write_multiple_threads_flush
PASS: test_litl_write_multiple_applications_flush
PASS: test_litl_pause_flush
PASS: test_litl_buffer
PASS: test_litl_trace_size
PASS: test_litl_mapping_to_fxt



signature.asc
Description: OpenPGP digital signature

Bug#916776: ITS: python-pyocr

[Chris Lamb]

tags 916776 + pending
thanks

Hi Thomas,

> A new version fixing the bugs of the package was just uploaded to
> mentors.d.n

Uploaded. :)


Regards,

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

Bug#916776: ITS: python-pyocr

[Thomas Perret]

Le 13/07/2019 à 03:59, Chris Lamb a écrit :
> Hi Thomas,
Hi Chris

>> According to the ITS process, I will wait for any objections during 21
>> days before uploading a new package into the DELAYED queue.
> 
> I think you've reached this 21 days. Fancy fixing #886306 on your
> first upload? :)

Indeed ;-)
Sorry I didn't had time to work on that the past few months.
A new version fixing the bugs of the package was just uploaded to
mentors.d.n

Bug#940939: Bug

[Matthieu Gallien]

Hello,

Sorry for the confusion, the fix proposal is in https://phabricator.kde.org/
D24147 .

Best regards

Bug#932540: epiphany-browser: Gmail doesn't work correctly in Epiphany in buster

[Gerardo Ballabio]

Sorry for not replying earlier. I did not find time immediately to
check the console and then I got distracted by other issues and in the
end I simply forgot.

But recently epiphany-browser was updated in stable (current version
is now 3.32.1.2-3~deb10u1) and after I installed the update the issue
seems to have been fixed. I'm sending this from Epiphany. I've used it
for some days since the update and I haven't had any problems.

I guess this bug can be closed for now. I'll reopen it if the problem
surfaces again.

Thanks
Gerardo

Il giorno mer 14 ago 2019 alle ore 11:36 Alberto Garcia
 ha scritto:
>
> On Tue, Aug 13, 2019 at 08:33:41PM +0200, Gerardo Ballabio wrote:
> > I ticked off everything: Try to block advertisements, Try to block
> > web trackers, and even Try to block dangerous websites. Didn't work
> > (sending this from Firefox).
>
> If it still works with the MiniBrowser but not with Epiphany perhaps
> you could try to open the web inspector console in both cases (right
> click -> Inspect Element -> Console (on the right)) and compare the
> messages that appear when you open and try to use GMail.
>
> If both browsers behave differently then that could give us a clue.
>
> Berto

Bug#940970: autopostgresqlbackup: should depend on mailx instead of heirloom-mailx

[Roland Hieber]

Package: autopostgresqlbackup
Version: 1.1-1
Severity: normal

Dear Maintainer,

autopostgresqlbackup uses 'mail -s' to send logs by mail. The package
currently depends on heirloom-mailx, but heirloom-mailx does no longer
provide a /usr/bin/mail alternative since the move to s-nail. See [1]
and [2] for more information.

I suggest that the "Depends: heirloom-mailx | biabam | mutt" be changed
to "Depends: mailx | biabam | mutt", which makes use of the virtual
package mailx, currently provided by bsd-mailx and mailutils.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858080
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847049

Cheers,

 - Roland

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

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

Versions of packages autopostgresqlbackup depends on:
ii  mailutils [mailx] 1:3.5-3
pn  postgresql-client-common  

Versions of packages autopostgresqlbackup recommends:
pn  heirloom-mailx | biabam | mutt  
ii  openssl 1.1.1c-1

Versions of packages autopostgresqlbackup suggests:
ii  bzip2 1.0.6-9.2
ii  xz-utils  5.2.4-1

Bug#935173: audacity graphical windows fail to update properly

[Klaumi Klingsporn]

Am / On Sun, 22 Sep 2019 14:23:33 +0200
schrieb / wrote Yuri D'Elia :

> Version: 2.3.2-2
> Followup-For: Bug #935173
>
> "Very difficult" is an understatement.
> audacity 2.3.2 is basically unusable as it is :(

Interesting. I've NO problems here with audacity 2.3.2-2
from testing using libwxbase3.0-0v5 and libwxgtk3.0-gtk3-0v5
version 3.0.4+dfsg-12 (both testing as well).

But I remember that I had similar problems with a
self-compiled earlier 2.3-version of audacity. I had to
move the configuration-directory (~/.audacity-data) out of
the way and to choose the classic-theme to make it work.

Maybe this helps?

Klaumi

---
Klaumi Klingsporn
mail: klaumi...@gmx.de
web: www.klaumikli.de

Bug#940971: init script takes 90 seconds

[Simon Richter]

Package: dbus
Version: 1.12.16-1
Severity: important

Hi,

/etc/init.d/dbus is hanging pretty much exactly 90 seconds on either boot
or manual start:

# time service dbus start
Starting system message bus: dbus.

real1m30.111s
user0m0.010s
sys 0m0.010s

The service seems to be running afterwards.

   Simon

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: ppc64el (ppc64le)

Kernel: Linux 5.2.0-2-powerpc64le (SMP w/64 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages dbus depends on:
ii  adduser   3.118
ii  libapparmor1  2.13.3-5
ii  libaudit1 1:2.8.5-2
ii  libc6 2.29-1
ii  libcap-ng00.7.9-2+b1
ii  libdbus-1-3   1.12.16-1
ii  libexpat1 2.2.7-2
ii  libselinux1   2.9-2+b2
ii  libsystemd0   242-7

dbus recommends no packages.

Versions of packages dbus suggests:
ii  dbus-x11 [dbus-session-bus]  1.12.16-1

Versions of packages dbus is related to:
ii  dbus-x11  1.12.16-1
ii  systemd   242-7
pn  systemd-sysv  

-- no debconf information

Bug#935173: audacity graphical windows fail to update properly

[Yuri D'Elia]

On Sun, Sep 22 2019, Klaumi Klingsporn wrote:
> But I remember that I had similar problems with a
> self-compiled earlier 2.3-version of audacity. I had to
> move the configuration-directory (~/.audacity-data) out of
> the way and to choose the classic-theme to make it work.
>
> Maybe this helps?

I tried zapping ~/.audacity-data, but I have the same issue.

Some widgets do not repaint properly, but the main issue is that audio
tracks only seem to redraw when resizing the main window. I rebuilt
audacity from git earlier today, but it still doesn't repaint the tracks
(for instance, while playing, zooming, etc).

The only thing I see is errors on the console:

*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

but I'm not sure if they're related or not.

Bug#940969: libdc1394-22: Please package new upstream release (2.2.6)

[Boyuan Yang]

Source: libdc1394-22
Version: 2.2.5-2.1
Severity: normal
X-Debbugs-CC: g...@debian.org p...@debian.org

Dear libdc1394-22 maintainers,

The upstream of libdc1394-22 has made a new release on 2019-04-28 (2.2.6, 
https://sourceforge.net/projects/libdc1394/files/libdc1394-2/2.2.6/ ). Please
consider packaging it in Debian.

Thanks,
Boyuan Yang


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

Bug#918572: check FTBFS on ppc*: test failure

[Boyuan Yang]

I submitted a self-service giveback request and had this package rebuilt on
ppc64el. It is still failing with GCC 9. Looks like further investigation is
needed.

https://buildd.debian.org/status/package.php?p=check

Thanks,
Boyuan Yang


On Fri, 20 Sep 2019 09:57:02 +0200 "Thierry fa...@linux.ibm.com" <
thie...@linux.ibm.com> wrote:
> On Mon, 07 Jan 2019 15:54:46 +0200 Adrian Bunk  wrote:
> > Source: check
> > Version: 0.12.0-0.1
> > Severity: serious
> > Tags: ftbfs
> > 
> > https://buildd.debian.org/status/package.php?p=check
> > 
> > ...
> > FAIL: check_check_export
> > FAIL: check_check
> > PASS: test_output.sh
> > PASS: test_check_nofork.sh
> > PASS: test_check_nofork_teardown.sh
> > PASS: test_xml_output.sh
> > PASS: test_log_output.sh
> > PASS: test_set_max_msg_size.sh
> > PASS: test_tap_output.sh
> > 
> >Check 0.12.0: tests/test-suite.log
> > 
> > 
> > # TOTAL: 9
> > # PASS:  7
> > # SKIP:  0
> > # XFAIL: 0
> > # FAIL:  2
> > # XPASS: 0
> > # ERROR: 0
> > 
> > 
> > 
> > (powerpcspe builds with nocheck)
> > 
> > 
> Could you recheck compilation as my last test with gcc-9 on SID passes. Thx
> -- 
> Thierry Fauck @ fr.ibm.com
> 
> 


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

Bug#940967: libsecp256k1-0: ECDH support not built

[Janus Troelsen]

Package: libsecp256k1-0
Severity: wishlist
Tags: newcomer

Dear Maintainer,

libsecp256k1 can be built with "experimental" ECDH support. This adds an
additional symbol to the shared object. I have used this ECDH support for years
(built myself), and have had no issues with it. It is only experimental because
the API might change. Consumers of the library should know this. Note that
libsecp256k1 has never had a stable release, so even functions not marked
"experimental" are vulnerable to the same kind of API breakage.

I request building with ECDH support.



-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic-proposed'), (500, 'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libsecp256k1-0 depends on:
ii  libc6 2.27-3ubuntu1
ii  libgmp10  2:6.1.2+dfsg-2

libsecp256k1-0 recommends no packages.

libsecp256k1-0 suggests no packages.

Bug#940968: /usr/bin/boincmgr: tray icon does not show in kde systray

[Achim Schaefer]

Package: boinc-manager
Version: 7.16.1+dfsg-2
Severity: normal
File: /usr/bin/boincmgr

Dear Maintainer,

ince the removal of qt4 stuff, the tray icon does not show up any more in 
systray.



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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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

Versions of packages boinc-manager depends on:
ii  boinc-client  7.16.1+dfsg-2
ii  libboinc7 7.16.1+dfsg-2
ii  libc6 2.29-2
ii  libgcc1   1:9.2.1-8
ii  libglib2.0-0  2.61.1-2
ii  libgtk-3-03.24.11-1
ii  libnotify40.7.8-1
ii  libsqlite3-0  3.29.0-2
ii  libstdc++69.2.1-8
ii  libwxbase3.0-0v5  3.0.4+dfsg-12
ii  libwxgtk-webview3.0-gtk3-0v5  3.0.4+dfsg-12
ii  libwxgtk3.0-gtk3-0v5  3.0.4+dfsg-12

boinc-manager recommends no packages.

Versions of packages boinc-manager suggests:
ii  libgl1-mesa-glx  19.1.6-1
ii  libxt6   1:1.1.5-1+b3

-- no debconf information

Bug#940966: qml-module-org-kde-kirigami2 uses an invalid version of QtQuick.Controls

[Peter Karbaliotis]

Package: qml-module-org-kde-kirigami2
Version: 5.62.0-1
Severity: important

Dear Maintainer,

  * What led up to the situation?

After upgrading to the latest version of kirgiami2 (5.62.0-1) attempting to
set a wallpaper led to the following error messages:

Error: Could not load: file:///usr/share/plasma/wallpapers/org.kde/image/content
s/ui/config.qml:276 Type Wallpaper Delegate unavailable
file:///usr/share/plasma/wallpapers/org.kde/image/contents/ui/WalpaperDelegate.q
ml:52 Type Kirigami.Action unavailable
file:///usr/lilb/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/Action.qml:21 modul
e "QtQuick.Controls" version 2.5 is not installed

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

According to https://doc.qt.io/qt-5/qtquickcontrols-index.html the correct versi
on to use is 2.4. Making this change to Action.qml restored the functionality of
the wallpaper dialog.

These are all of the files I found with invalid versions:

./org/kde/kirigami.2/Action.qml:import QtQuick.Controls 2.5 as Controls
./org/kde/kirigami.2/ActionToolBar.qml:import QtQuick.Controls 2.5 as Controls
./org/kde/kirigami.2/ListSectionHeader.qml:import QtQuick.Controls 2.5 as QQC2
./org/kde/kirigami.2/ListSectionHeader.qml: * import QtQuick.Controls 2.5 as QQC
2
./org/kde/kirigami.2/templates/SwipeListItem.qml:import QtQuick.Controls 2.7 as


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

Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:e
n (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qml-module-org-kde-kirigami2 depends on:
ii  libc6  2.29-2
ii  libkf5kirigami2-5  5.62.0-1
ii  libqt5core5a   5.11.3+dfsg1-4
ii  libqt5gui5 5.11.3+dfsg1-4
ii  libqt5network5 5.11.3+dfsg1-4
ii  libqt5qml5 5.11.3-4
ii  libqt5quick5   5.11.3-4
ii  libqt5quickcontrols2-5 5.11.3+dfsg-2
ii  libstdc++6 9.2.1-8
ii  qml-module-qtgraphicaleffects  5.11.3-2
ii  qml-module-qtqml-models2   5.11.3-4
ii  qml-module-qtquick-controls2   5.11.3+dfsg-2
ii  qml-module-qtquick-templates2  5.11.3+dfsg-2
ii  qml-module-qtquick25.11.3-4

qml-module-org-kde-kirigami2 recommends no packages.

qml-module-org-kde-kirigami2 suggests no packages.

-- no debconf information

-- 
World War III will be a guerilla information war with no division
between military and civilian participation.
  Marshall McLuhan

Bug#940698: [SPAM] Bug#940698: [debian-edu-config] Add wget as a dependency

[mike . gabriel]

Hi Wolfgang,

Am Sonntag, 22. September 2019 schrieb Wolfgang Schweer:
> On Thu, Sep 19, 2019 at 11:38:15AM +, Holger Levsen wrote:
> > On Thu, Sep 19, 2019 at 10:56:41AM +0200, Petter Reinholdtsen wrote:
> > > > And then the cf-agent call fails. We might have to consider adding  
> > > > wget to Depends: of d-e-c.
> > > Is perhaps 'curl'  installed by default?  What about rewriting the
> > > cfengine rules to us curl instead?
> > 
> > sure, go ahead! :)
> > 
> > In the meantime I have added a depends on wget in git, we already have
> > more than 30 direct depends, so I doubt adding wget hurts in anyway.
> 
> I'm just wondering if this isn't rather a FAI ruleset issue. The 
> debootstrap package depends upon wget (as only Depends, actually). 
> 
> Wolfgang

debootstrap uses wget outside the chroot, it does not require it inside the 
chroot, afair.

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

Bug#918843: ITS: matlab-support

[Boyuan Yang]

Sorry but there hasn't been much progress yet -- recent MATLAB releases have
several changes that requires much tweak on matlab-support package and I
haven't have enough time into it.

Given the lack of original maintainers' response in the previous months, I
believe it should be reasonable to "salvage" this package and have it team-
maintained under either Debian Science Team or the Debian Octave Group. If you
are going to upload any new version of matlab-support, please also consider
adding me into the uploaders list.

Thanks,
BOyuan Yang

在 2019-09-22日的 10:39 +0200，Sébastien Villemot写道：
> Dear Boyuan,
> 
> On Tue, 23 Apr 2019 11:05:01 -0400 Boyuan Yang  wrote:
> > Since no response was received under this ITS bug, I will proceed to
> > upload
> > new version of matlab-support. The initial version will be in Debian
> > Experimental first since we are in deep freeze. The new packaging
> > repository
> > will be under Salsa Debian group.
> 
> Is there any news on this?
> 
> I’m also interested in improving matlab-support.
> 
> In particular, I think it would be better if the package was team-
> maintained, in order to facilitate collaborative work. Two
> possible candidates are the Debian Science Team, and the Debian Octave
> Group (I’m a member of both).
> 
> Best,
> 
> 
> > --
> > Thanks,
> > Boyuan Yang
> > 
> > 在 2019-01-09三的 16:41 -0500，Boyuan Yang写道：
> > > Source: matlab-support
> > > Version: 0.0.21
> > > Severity: important
> > > X-Debbugs-CC: 
> y...@debian.org
>  
> m...@debian.org
>  
> t...@neuro.debian.net
> 
> > > I see that package matlab-support hasn't receive any updates since 2015
> > > and
> > > I'm wondering about its future. As a MATLAB user, I'd like to open an
> > > ITS to
> > > help to improve matlab-support, especially to make an upload before
> > > Buster
> > > freeze to clean up various problems.
> > > 
> > > I also noticed the creation of
> > > 
> https://salsa.debian.org/neurodebian-team/matlab-support
>  .
> > > Michael, will there be an upload in near future?
> > > 
> > > --
> > > Regards,
> > > Boyuan Yang
> 
> 


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

Bug#940965: apt: Fails to find a solution for libgtk-3-0 and sysvinit-core

[Simon Richter]

Package: apt
Version: 1.8.2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

apt's resolver does not find a working solution for installing both
libgtk-3-0 and sysvinit-core, or for installing libgtk-3-0 when
systemd-sysv has a negative score in preferences. Aptitude resolves both of
these by favouring dbus-x11 over dbus-user-session.

When presented manually with this solution, apt accepts it as valid.

   Simon

- -- Package-specific info:

- -- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-source-4\.19\.0-5-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-modules";
APT::VersionedKernelPackages:: "linux-modules-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "linux-image-unsigned";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::VersionedKernelPackages:: "linux-cloud-tools";
APT::VersionedKernelPackages:: "linux-buildinfo";
APT::VersionedKernelPackages:: "linux-source";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke "";
APT::Update::Post-Invoke:: "[ ! -x /usr/bin/debtags ] || debtags update || 
true";
APT::Default-Release "buster";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Architectures:: "armhf";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "false";
APT::Compressor::zstd::Cost "60";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";

Bug#940939: Upstream

[Martin Steigerwald]

Hi Matthieu.

Matthieu Gallien - 22.09.19, 18:52:07 CEST:
> I have open https://phabricator.kde.org/D22974 to propose a solution.

Thanks.

Okay. As far as I understand this is about Qt 5.11 compatibility. Qt 
5.12.5 will likely land in Debian soon as far as I am aware.

Best,
-- 
Martin

Bug#872381: dpkg-dev: optimize Makefile snippets for debian/rules

[Nicolas Boulenguez]

Please replace 0003.patch with the attached version (changes are
cosmetic but should use review and merge).
>From a93a87581dbe90bd15822f11f374ae6d76263ca4 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Mon, 29 Jul 2019 19:03:16 +0200
Subject: [PATCH 3 (v2)/3] scripts/mk: improve subprocesses

architecture.mk and buildflags.mk spawn less subshells, improving the
overall speed (the tests run twice faster according to bash time
builtin).

pkg-info.mk uses the same trick than buildflags.mk in order to spawn
at most one subshell. The performance gain is visible, but minor
because there are way less variables.

In buildtools.mk, remove the test 'ifdef $(1)', since $(1) is affected
by previous stanza.

diff --git a/scripts/mk/architecture.mk b/scripts/mk/architecture.mk
index 0af96019d..86ef28a41 100644
--- a/scripts/mk/architecture.mk
+++ b/scripts/mk/architecture.mk
@@ -2,10 +2,9 @@
 # that dpkg-architecture can return. Existing values of those variables
 # are preserved as per policy.
 
-dpkg_lazy_eval ?= $$(or $$(value DPKG_CACHE_$(1)),$$(eval DPKG_CACHE_$(1) := $$(shell $(2)))$$(value DPKG_CACHE_$(1)))
-
-dpkg_architecture_setvar = export $(1) ?= $(call dpkg_lazy_eval,$(1),dpkg-architecture -q$(1))
-
-$(foreach machine,BUILD HOST TARGET,\
-  $(foreach var,ARCH ARCH_ABI ARCH_LIBC ARCH_OS ARCH_CPU ARCH_BITS ARCH_ENDIAN GNU_CPU GNU_SYSTEM GNU_TYPE MULTIARCH,\
-$(eval $(call dpkg_architecture_setvar,DEB_$(machine)_$(var)
+# According to dpkg-architecture(1), the variables must always be
+# exported, so we need at least an external subprocess.
+# Attempt to set all variables with this subprocesses.
+# This also avoids maintaining a copy of the variable list here.
+# Each = is replaced with ?= in order to export existing overridden values.
+$(eval $(shell dpkg-architecture | sed 's/\([^=]*\)\(.*\)/$$(eval export \1?\2)/'))
diff --git a/scripts/mk/buildflags.mk b/scripts/mk/buildflags.mk
index bb496e108..e7276a1d8 100644
--- a/scripts/mk/buildflags.mk
+++ b/scripts/mk/buildflags.mk
@@ -16,11 +16,13 @@
 # This list is kept in sync with the default set of flags returned
 # by dpkg-buildflags.
 
-dpkg_lazy_eval ?= $$(or $$(value DPKG_CACHE_$(1)),$$(eval DPKG_CACHE_$(1) := $$(shell $(2)))$$(value DPKG_CACHE_$(1)))
-
 DPKG_BUILDFLAGS_LIST = CFLAGS CPPFLAGS CXXFLAGS OBJCFLAGS OBJCXXFLAGS \
GCJFLAGS FFLAGS FCFLAGS LDFLAGS
 
+# Accumulate the parameters for dpkg-buildflags, in case it is ever
+# called.
+
+DPKG_BUILDFLAGS_EXPORT_ENVVAR :=
 define dpkg_buildflags_export_envvar
 ifdef $(1)
 DPKG_BUILDFLAGS_EXPORT_ENVVAR += $(1)="$$(value $(1))"
@@ -33,11 +35,20 @@ $(foreach flag,$(DPKG_BUILDFLAGS_LIST),\
   $(foreach operation,SET STRIP APPEND PREPEND,\
 $(eval $(call dpkg_buildflags_export_envvar,DEB_$(flag)_MAINT_$(operation)
 
-dpkg_buildflags_setvar = $(1) = $(call dpkg_lazy_eval,$(1),$(DPKG_BUILDFLAGS_EXPORT_ENVVAR) dpkg-buildflags --get $(1))
-
-$(foreach flag,$(DPKG_BUILDFLAGS_LIST),\
-  $(eval $(call dpkg_buildflags_setvar,$(flag
+# This variable is only expanded on demand, and we ensure that it
+# happens at most once..
+dpkg-buildflags_run = $(eval $(shell \
+  $(DPKG_BUILDFLAGS_EXPORT_ENVVAR) dpkg-buildflags \
+  | sed 's/^\([^=]*\)\(.*\)/$$(eval \1:\2)/'))
 
 ifdef DPKG_EXPORT_BUILDFLAGS
+  # We must compute all values right now.
+  $(dpkg-buildflags_run)
   export $(DPKG_BUILDFLAGS_LIST)
+else
+  # Only run a subprocess when a variable is actually used,
+  # but then replace each recursive definition with a non-recursive one
+  # (and of course return the asked value).
+  $(foreach var,$(DPKG_BUILDFLAGS_LIST),\
+$(eval $(var)=$$(dpkg-buildflags_run)$$($(var
 endif
diff --git a/scripts/mk/buildtools.mk b/scripts/mk/buildtools.mk
index c3b44bb8a..a95b0a69c 100644
--- a/scripts/mk/buildtools.mk
+++ b/scripts/mk/buildtools.mk
@@ -23,27 +23,30 @@
 #
 # The variables are not exported by default. This can be changed by
 # defining DPKG_EXPORT_BUILDTOOLS.
+#
+# If TOOL is undefined or contains the Make built-in value,
+# it is assigned the Debian default prefixed with the host triplet.
+#
+# If TOOL_FOR_BUILD is undefined,
+# it is assigned the value of TOOL for native builds,
+# or the Debian default prefixed with the build triplet for cross builds.
+
 
 dpkg_datadir = $(srcdir)/mk
 include $(dpkg_datadir)/architecture.mk
 
-# We set the TOOL_FOR_BUILD variables to the specified value, and the TOOL
-# variables (for the host) to the their triplet-prefixed form iff they are
-# not defined or contain the make built-in defaults. On native builds if
-# TOOL is defined and TOOL_FOR_BUILD is not, we fallback to use TOOL.
 define dpkg_buildtool_setvar
 ifeq ($(origin $(1)),default)
 $(1) = $(DEB_HOST_GNU_TYPE)-$(2)
-endif
+else
 $(1) ?= $(DEB_HOST_GNU_TYPE)-$(2)
+endif
 
-# On native build fallback to use TOOL if that's defined.
 ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
-ifdef $(1)
 $(1)_FOR_BUILD ?= $$($(1))
-endif
-endif
+else
 $(1)_FOR_BUILD ?= 

Bug#884857: developers-reference: clarify process on retirement/improve wording

[Judit Foglszinger]

Updated both descriptions.
From 72725a668cf8e8783f21503368b56df697a6a4c0 Mon Sep 17 00:00:00 2001
From: Judit Foglszinger 
Date: Mon, 23 Sep 2019 00:29:33 +0700
Subject: [PATCH 1/2] fix description for retiring

---
 source/developer-duties.rst | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/source/developer-duties.rst b/source/developer-duties.rst
index 0502029..a163ffb 100644
--- a/source/developer-duties.rst
+++ b/source/developer-duties.rst
@@ -240,12 +240,21 @@ the following steps:
 -  Orphan all your packages, as described in :ref:`orphaning`.
Remove yourself from uploaders for co-maintained packages.
 
+-  If you received mails via a @debian.org e-mail alias (e.g.
+   pr...@debian.org) and would like to get removed, open a RT ticket for
+   the Debian System Administrators. Just send an e-mail to
+   ``ad...@rt.debian.org`` with "Debian RT" somewhere in the subject
+   stating from which aliases you'd like to get removed.
+
 -  Use the link https://nm.debian.org/process/emeritus to log in to
-   nm.debian.org [2]_, request emeritus status and write a goodby
+   nm.debian.org, request emeritus status and write a goodbye
message that will be automatically posted on debian-private.
 
-   This also automatically notifies the MIA team, so that they can
-   check if some of your packages still need orphaning.
+   Authentification to the NM site requires an SSO browser certificate.
+   You can generate them on https://sso.debian.org.
+
+   In the case you run into problems opening the retirement process
+   yourself, contact NM front desk using ``n...@debian.org``
 
 It is important that the above process is followed, because finding
 inactive developers and orphaning their packages takes significant time
-- 
2.23.0

From bdb946330d97c26bca42fa8032dd45b9e5f4b3cc Mon Sep 17 00:00:00 2001
From: Judit Foglszinger 
Date: Mon, 23 Sep 2019 00:38:53 +0700
Subject: [PATCH 2/2] fix description for returning from retirement

---
 source/developer-duties.rst | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/source/developer-duties.rst b/source/developer-duties.rst
index a163ffb..ff544b8 100644
--- a/source/developer-duties.rst
+++ b/source/developer-duties.rst
@@ -270,8 +270,12 @@ in :ref:`s3.7` is followed, and "removed" otherwise. Retired
 developers with an "emeritus" account can get their account re-activated
 as follows:
 
--  Use the link https://nm.debian.org/wizard/process/return to log in to
-   nm.debian.org [2]_ and request to return from emeritus status.
+-  Get access to an alioth account (either by remembering the
+   credentials for your old guest account or by requesting a new one as
+   decribed at `SSO Debian wiki page
+   `__.
+
+-  Mail ``n...@debian.org`` for further instructions.
 
 -  Go through a shortened NM process (to ensure that the returning
developer still knows important parts of P and T).
@@ -282,9 +286,3 @@ again.
 .. [1]
This is so that the message can be easily filtered by people who
don't want to read vacation notices.
-
-.. [2]
-   Login on nm.debian.org requires an SSO browser certificate.
-   (you can generate them on https://sso.debian.org)
-   If you cannot access SSO, the recommended way of action is to
-   mail NM frontdesk using ``n...@debian.org``.
-- 
2.23.0



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

Bug#934646: git-all: Installing git-all on Debian XFCE base install removes core system packages

[Sven Joachim]

On 2019-08-12 16:10 -0600, Robert Petry wrote:

> Package: git-all
> Version: 1:2.20.1-2
> Severity: important
>
> Dear Maintainer,
>
> I did a fresh install of Debian Stable using the
> firmware-10.0.0-amd64-netinst.iso image and installed the following
> tasks: Debian desktop environment, XFCE, print server and standard
> system utilities.  After this I ran a script which installed my usual
> packages.  For reference these were:
> -
> PACKAGELIST="emacs texlive texlive-latex-extra texlive-fonts-extra
> texlive-science texlive-games perl-tk latexmk auto-multiple-choice
> auto-multiple-choice-doc auctex psutils pstoedit pdftk pdfchain
> asymptote mkdocs mkdocs-doc elpa-markdown-mode xfig xfig-doc
> gsfonts-x11 fig2ps imagemagick inkscape krita blender build-essential
> glibc-doc git-all jupyter-core jupyter-notebook
> python3-widgetsnbextension jupyter-nbconvert python-notebook-doc
> python3-seaborn texlive-xetex python3-plotly python3-numpy
> python-numpy-doc python3-scipy python-scipy-doc idle3
> python3-matplotlib python3-matplotlib-venn python-matplotlib-doc
> python3-mpmath python-mpmath-doc python3-gmpy2 python3-sympy
> python3-sympy-doc ipython3 python-ipython-doc wxmaxima evince sshfs
> sudo audacious gnome-sound-recorder simple-scan youtube-dl
> gnome-system-tools unattended-upgrades xournal deja-dup thunderbird
> locate xinput galculator obs-studio gigolo"
> 
> After this was complete my networking and the lightdm window manager
> were no longer present.  Looking at the apt log showed that my apt -y
> autoinstall of git-all had caused the removal of the task-xfce-desktop
> package, the network-manager the lightdm display manager as well as
> other core packages. This was obviously unexpected.
>
> Next I reinstalled Debian as above without the git-all package and
> tried to install the various dependencies of git-all to see what was
> going on.  Looking at the dependencies of git-all shows that it
> recommends git-daemon-run or git-daemon-sysvinit.  It turns out that
> the git-daemon-run package is the one which appears to require the
> removal of the core packages above if you try to install it after a
> fresh install.

It does not strictly _require_ that, but on my system apt would remove
dbus-user-session and quite a few of its reverse dependencies, which is
bad.  With aptitude the results are better, as it installs runit-systemd
by default and would not remove any packages.

> The upshot is that because the default Debian install method is to
> install recommends and because git-all recommends git-daemon-run which
> in turn does not play nicely with the basic XFCE installation
> described above the system becomes broken. My suggestion would be to
> do one of the following:
>
> 1) Fix the git-daemon-run package or its dependency which is causing
> this.  This appears to be new behaviour in Debian 10 as it worked
> before in 9.
> 2) Make the default recommend git-daemon-sysvinit which at least does not 
> cause this problem.
> 3) Make these recommended packages suggested only.

I think 2) would make most sense, but either of these options looks
preferable to the status quo.

Cheers,
   Sven

Bug#940914: Issue was caused by AppArmor

[Michel Le Bihan]

After disabling AppArmor on my system by appending `apparmor=0` to the
kernel I was able to launch LibreOffice and create a new writer
document.

Michel Le Bihan

Bug#940963: samba doesn't start anymore

[Elimar Riesebieter]

Control: severity -1 grave
Control: reassign -1 samba-common-bin

* Elimar Riesebieter  [2019-09-22 13:00 +0200]:

> Package: samba
> Version: 2:4.10.8+dfsg-1
> Severity: normal
> 
> 
> This server runs sysvinit!
> 
> [2019/09/22 12:44:28.672896,  0] ../../source3/smbd/server.c:1850(main)
>   server role = 'active directory domain controller' not compatible with 
> running smbd standalone. 
>   You should start 'samba' instead, and it will control starting smbd if 
> required
> [2019/09/22 12:44:30.809747,  0] ../../source3/nmbd/nmbd.c:921(main)
>   server role = 'active directory domain controller' not compatible with 
> running nmbd standalone. 
>   You should start 'samba' instead, and it will control starting the internal 
> nbt server

/etc/init.d/samba-ad-dc calls 
'samba-tool testparm --parameter-name="server role"' which fails
with:

Traceback (most recent call last):
  File "/bin/samba-tool", line 33, in 
from samba.netcmd.main import cmd_sambatool
  File "/usr/lib/python3/dist-packages/samba/__init__.py", line 29, in 
import samba.param
ImportError: 
/lib/x86_64-linux-gnu/libpytalloc-util.cpython-37m-x86-64-linux-gnu.so.2: 
version `PYTALLOC_UTIL.PY3_2.1.6' not found (required by 
/usr/lib/python3/dist-packages/samba/param.cpython-37m-x86_64-linux-gnu.so)

Elimar
-- 
  Do you smell something burning or is it me?

Bug#939598: marked as done (libubootenv-tool: trying to overwrite '/usr/bin/fw_printenv', which is also in package u-boot-tools 2019.01+dfsg-7)

[Stefano Babic]

Hi Vagrant,

On 21/09/19 23:49, Vagrant Cascadian wrote:
>> Preparing to unpack .../15-libubootenv-tool_0.1-1_amd64.deb ...
>> Unpacking libubootenv-tool (0.1-1) ...
>> dpkg: error processing archive 
>> /tmp/apt-dpkg-install-S5V5yb/15-libubootenv-tool_0.1-1_amd64.deb (--unpack
>> ):
>>  trying to overwrite '/usr/bin/fw_printenv', which is also in package 
>> u-boot-tools 2019.01+dfsg-7
>>
>> Since the packages are both u-boot related, the new program might have
>> the same functionality as the existing one and hence using
>> update-alternatives for the two variants maybe an option.
> ...
>>  libubootenv (0.1-2) unstable; urgency=medium
>>  .
>>* Add u-boot-tools Conflicts of libubootenv-tool (Closes: #939598)
> 
> This seems like a rather sub-optimal solution to the problem; now it's
> impossible to install u-boot-tools at the same time, which has other
> functionality as well. There are also packages that depend or recommend
> on u-boot-tools that won't be able to be installed or may have reduced
> functionality when libubootenv-tool is installed.
> 
> Many of these packages would seem quite reasonable to have installed
> with both libubootenv-tool and u-boot-tools installed at the same
> time, such as u-boot-sunxi...

Right, but it looks like that u-boot-tools contains tools with different
meaning that could be addressed with different packages. For example,
tools like "netconsole" is missing. The package in libubootenv exposes
the "envtools" from U-Boot, that is just the tool to modify the environment.

> 
> Is there anything in the libubootenv's fw_printenv and fw_setenv
> implementations that's significantly different from u-boot-tools?

>From the user point of view, they are thought to be fully compatible.
The syntax for the tool is the same as the original tools to avoid
breakages in already implemented script. Anyway, the most important
difference (at least for Debian) is the tools are hardware unaware.

In fact, the original u-boot-tools must be compiled with the same
machine (_defconfig) of the bootloader because the environment is
statically linked to the binary. This is a severe issue if a board boots
with the "default" environment, that is the environment linked together
with the bootloader. The original fw_setenv tool is built just one
machine: fw_setenv can brick the target because it cannot know the
environment because it was not written to the flash and it is only
present in the U-Boot binary. There is no way to instruct the original
tool for this. With libubootenv, the environment is read from a file and
the same binary can be used on different targets without exceptions.

The original discussion about this topic was in this old thread on
U-Boot's ML:
http://u-boot.10912.n7.nabble.com/SWUpdate-U-Boot-environment-library-dependency-td340530.html

Apart of this, libubootenv just addresses "envtools" from U-Boot, while
u-boot-tools contains tools for different purposes: image generation
(mkimage and friends), environment.

My logical way to do is to split u-boot-tools in several sub-packages
that won't conflict. This is the solution in OE, too, where a
u-boot-mkimage package contains the image generation tool and
u-boot-fw-utils contains the envtools. In OE libubootenv is set as
replacement for u-boot-fw-utils (with PROVIDES) and there is no conflict.

> 
> Couldn't libubootenv-tool depend on u-boot-tools instead of conflicting
> with it?

Depend ? No.

>  Or would it make sense for u-boot-tools to depend on
> libubootenv-tool instead?

Mmhh.. I do not know. u-boot-tools should not install fw_setenv /
fw_printenv is libubootenv is already installed.

> Is this likely to be merged in upstream u-boot
> at some point?

No. libubootenv is also thought to remove some limitations due to the
U-Boot build environment. U-Boot cannot use standard library as they
are, so code from libraries (libz, openssl, and so on..) is copied from
the original library into U-Boot. If this is required for the bootloader
that is an independent binary not linked with anything, it is a
sub-optimal solution for a User Space tool: libubootenv is simply linked
against the required libraries.

> 
> Alternately, the original suggestion of using the alternatives system
> would at least allow both packages to coexist at the same time, at the
> cost of some additional complication in both packages maintainer
> scripts.

Best regards,
Stefano
-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

Bug#800115: debsecan: support python3 backend

[Marc Haber]

Hi Michael,

thanks for the bug report. Without being the debsecan maintainer, I'd
like to know whether this is really such a straightforward thing without
having to mess around with on-disk structure of local files. Would that
patch, assuming that it still applies, be suitable for a package in
Debian?

Florian, are there reasons for not applying this nearly four year old
patch other than lack of time? Would you want me to go ahead with this?
Do you want me to do an NMU, add myself to Uploaders or would you prefer
a PR on gitlab? Or, Michael, would you be willing to do this if Florian
agrees? You have much more python skills than I have.

Greetings
Marc


On Sat, Sep 26, 2015 at 08:41:53PM -0400, Michael Gilbert wrote:
> package: debsecan
> severity: wishlist
> tags: patch
> 
> I'm trying to migrate my systems to python3 only, so I've worked on a
> python3 backend patch for debsecan.
> 
> The 2to3 script got most of the way automatically, although there was
> some trickiness with the removal of __cmp__ and compressed data
> strings, but otherwise it was rather straightforward.
> 
> I also made sure to maintain backwards compatibility with python2 via
> try/except in a few places.
> 
> I've done some modest testing, getting the same output with either
> python2 or python3 as backend.
> 
> Please see attached.
> 
> Best wishes,
> Mike

Bug#863118: devscripts configuration

[Nicolas Boulenguez]

> > My point was that your sentence suggests
> > - that several scripts use Config. Actually, only one does.
> I count three scripts that use Config (salsa, uscan, mk-origtargz).
Sorry.  A year ago, grepping scripts was enough, but uscan is not
alone in lib/ anymore.
3 is still less than 25.

> Don't use an absolute path to bash.

Done.
Note that Config.pm uses '/bin/bash'.
Out of curiousity: I was once taught that not relying on $PATH,
aliases and so on was safer. Do you have a reference (the question
seems to vague for a web search)?

> Unsetting the environment represents a change in the interface between
> devscripts and people's config files. An example of what could break:
> if someone sets HOME in their running zsh to a subdirectory, and in
> that directory has a devscripts config that uses ~/ then unsetting HOME
> could mean that the devscripts config would use their main home
> directory instead of the subdirectory they wanted to use.

Confvar only unsets the variables matching the list (or regex)
expected by the devscript tool.
devscripts.conf(5) requires this behaviour.
Confvar does not modify HOME, or any unrelated setting.

> Checking the syntax of the config files represents a change in the
> interface between devscripts and people's config files; config files
> that contain valid variables at the start and syntax errors at the end
> would stop setting the valid variables from the start.
> Telling bash to exit on errors by passing the -e option to bash
> represents a change in the interface between devscripts and people's
> config files. It could cause later parts of the config files to
> silently stop working if they have a command near the start that does
> not succeed.

I agree that these are changes in behaviour introduced by Confvar.
They have been approved by a devscripts maintainer in messages 10 to
27 in the same bug log.

> In the perl code use q{}/qq{} instead of ''/"" for readability; this is
> so that you can use quoting characters in the shell code without
> escaping them with backslash characters, which reduce the readability.

As far as I understand:
qq{} allows ' instead of \' inside literal strings.
q{} allows " instead of \" inside interpolated strings.
None happens in Confvar for now.
This would only raise the barrier for people less fluent in perl like
me.

> Use the spawn function from Dpkg::IPC instead of backticks because they
> introduce an extra unnecessary shell process while spawn does not use
> the shell so there can be no quoting issues no matter what is passed.

Done. Thanks.

> Pass the config filenames as arguments to the generated bash script and
> load the files from those arguments instead of from quoted strings.
> This avoids any possible mismatch between bash/Perl quoting code.

Done. Thanks.

> Use NUL characters (\0) to split the output up, this allows all
> characters to be represented instead of relying on Perl code to parse
> the output of the bash set command.

I could argue that, in order to see that your implementation is safer,
one has to be fluent with perl constructs like
  map {qq{"\$$_"}} @key_names
and understand why " \0 \n are passed correctly via
  printf '%s\0' "$a"

After many attempts at comparable solutions, I have encountered
scripts accepting a non-static range of variable identifiers defined
by a pattern, or even worst by the content of another user variable. I
have found no way to do this without parsing the output of the 'set'
built-in.  The escaping used by 'set' is described in the comments at
the end of Confvar.pm.

For now, only the a=$'...' syntax is ignored (and bash array
variables, but this does not matter here). Bash uses it when the
variable contains control characters like \r \n.  It would be possible
to also decode such values (by calling printf or similar), but
investing work in this direction does not seem in line with the
orientation selected by the maintainers in first messages of this bug
log.

> One enhancement I should have added to the Config module but didn't
> think of until now is to ensure that the stderr isn't parsed and that

As far as I understand, Dpkg::IPC::spawn separates stdout from stderr.

> any output the devscripts config generates also isn't parsed by the
> Perl code. Probably the way to do this is to print a few NUL characters
> in a row to indicate the start of the exported variables and discard
> any output before those NUL characters. Of course the devscripts config
> could print the NULs too and thus break the parsing, but outputting
> NULs from one's devscripts config seems unlikely to exist today.

In the messages quoted above, the maintainers are in favor of
requiring only simple affectations in configuration files, and even
removing shell support in the future if ever possible.

It would be way safer to report any unexpected output, and only go on
proceeding with an explicit override (for example if
lib/Devscripts/Output.pm::die_on_error is false).

> > It seemed right to answer a bug 

Bug#935173: audacity graphical windows fail to update properly

[Yuri D'Elia]

Package: audacity
Version: 2.3.2-2
Followup-For: Bug #935173

"Very difficult" is an understatement.
audacity 2.3.2 is basically unusable as it is :(

Bug#940930: devscripts: add new script for self-service give-backs

[Mattia Rizzolo]

user devscri...@packages.debian.org
usertags 940930 new
tags 940930 moreinfo
thanks

On Sun, Sep 22, 2019 at 12:14:28PM +0800, Paul Wise wrote:
> Please add a new script for contributors to do self-service give-backs
> from the command-line, perhaps something like this:
> 
>wanna-build-sso gb --packages foo bar baz --architectures amd64 i386 
> --suites unstable experimental

For the log, there is already one tool that uses SSO to authenticate,
namely `nmcli`, used by FD, DAM, etc to query stuff on nm.d.o.
Also, I wrote a thing (incompleted) to be able to schedule builds on
tests.reproducible-builds.org, also using SSO client certificates.

But, the future of SSO is currently uncertain, I prefer if the Debian
SSO would first finish their thing, and assure me that client
certificates will stay, as it's currenly not at all clear.
I don't want to include a tool in devscripts, that may already start
failing in 1 or 2 years.  Till then, I consider this request stalled
with "moreinfo".

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#803789: RFP: RasterView -- a simple GUI image viewer for CUPS and PWG Raster files

[Didier 'OdyX' Raboud]

Control: owner -1 !
Control: retitle -1 ITP: RasterView - A CUPS/PWG/Apple raster file viewer

Le dimanche, 28 octobre 2018, 15.20:13 h CEST Brian Potkin a écrit :
> On Mon 02 Nov 2015 at 20:47:24 +0100, Kurt Pfeifle wrote:
> > RasterView is a simple GUI image viewer which specializes in displaying
> > CUPS raster and PWG Raster files.
> > 
> > The CUPS and PWG Raster formats are used by CUPS in some printing
> > workflows. Both can handle multi-page image files, and can embed job
> > specific settings in page headers (such as page size or duplex settings).
> > 
> > PWG Raster was specified by the Printer Working Group working on the
> > upcoming "IPP Everywhere" standard which aims at ubiquituos "driverless
> > printing" for all major OS platforms. It is one of the three core formats
> > (besides JPEG and PDF) to be supported by print devices for compliance
> > with
> > the IPP Everywhere standard.
> > 
> > A viewer for the generated raster files in such a printing workflow is
> > important not just for debugging print problems...
> > 
> > RasterView has a dependency on FLTK. It was written by Mike Sweet (CUPS
> > developer). Its license is GPL v2. Its latest release is v1.4.1 (Aug 27,
> > 2015).
> 
> The latest release (28 Oct 2018) is 1.7.1
> 
> > I was able to compile it on Debian Jessie "out of the box".
> 
> It also compiles on buster.
> 
> > License: GPL v2
> 
> 1.7.1 is under the Apache License Version 2.0.
> 
> > Source Tarball:
> > https://www.msweet.org/files/project7/rasterview-1.4.1.tar.gz
> > URL: https://www.msweet.org/projects.php?Z7
> 
> A new URL:
> https://github.com/michaelrsweet/rasterview/releases

I'll upload 1.7.1 later today to NEW. Thanks for bringing it to my attention!

Cheers,

OdyX

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

Bug#940964: ITP: honggfuzz -- security oriented fuzzer with powerful analysis options

[Alessandro Ghedini]

Package: wnpp
Severity: wishlist
Owner: Alessandro Ghedini 

* Package name: honggfuzz
  Version : 1.9
  Upstream Author : Robert Swiecki 
* URL : https://github.com/google/honggfuzz
* License : Apache 2.0
  Programming Lang: C
  Description : security oriented fuzzer with powerful analysis options

honggfuzz is a security oriented, feedback-driven, evolutionary, easy-to-use
fuzzer with interesting analysis options.


signature.asc
Description: PGP signature

Bug#940939: Upstream

[Matthieu Gallien]

Hello,

I have open https://phabricator.kde.org/D22974 to propose a solution.

Best regards

Bug#925344: polkit-qt-1: Please support new logind virtual packages

[Cristian Ionescu-Idbohrn]

Maintainers,

On Sat, 23 Mar 2019, Mark Hindley wrote:
> 
> Package: polkit-qt-1
> Version: 0.112.0-6
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> Please change polkit-qt-1 to use the new default-logind and logind 
> virtual packages.  This will enable binaries built from polkit-qt-1 
> (libpolkit-qt-1-1 and libpolkit-qt5-1-1) to also be used on systems 
> using elogind and non-systemd inits.
> 
> The logind and default-logind virtual packages have been seconded 
> for inclusion in Debian Policy (see #917431) and libpam-elogind and 
> libpam-systemd providing these have been uploaded.
> 
> Patch below.
> 
> Thanks
> 
> Mark
> 
> commit 7a3084d2ba52f8aa0a01114de45d257e1feb4fe2
> Author: Mark Hindley 
> Date:   Sat Mar 23 12:35:26 2019 +
> 
> Use new logind virtual packages instead of libpam-systemd.
> 
> diff --git a/debian/control b/debian/control
> index 9b1c85f..3cfb08a 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -38,7 +38,7 @@ Package: libpolkit-qt-1-1
>  Architecture: any
>  Multi-Arch: same
>  Pre-Depends: ${misc:Pre-Depends}
> -Depends: libpam-systemd [linux-any],
> +Depends: default-logind [linux-any] | logind [linux-any],
>   ${misc:Depends},
>   ${shlibs:Depends}
>  Description: PolicyKit-qt-1 library
> @@ -77,7 +77,7 @@ Package: libpolkit-qt5-1-1
>  Architecture: any
>  Multi-Arch: same
>  Pre-Depends: ${misc:Pre-Depends}
> -Depends: libpam-systemd [linux-any], ${misc:Depends}, ${shlibs:Depends}
> +Depends: default-logind [linux-any] | logind [linux-any], ${misc:Depends}, 
> ${shlibs:Depends}
>  Description: PolicyKit-qt5-1 library
>   PolicyKit is an application-level toolkit for defining and handling the 
> policy
>   that allows unprivileged processes to speak to privileged processes.

Would you please resolve this in a speedy manner?  Got some 90 
packages that would be removed if I move to elogind now :(

  akonadi-server breeze drkonqi ffmpegthumbs frameworkintegration k3b
  kactivitymanagerd kaffeine kamera kamoso kcachegrind kde-cli-tools
  kde-config-cddb kde-config-screenlocker kde-runtime kde-style-breeze
  kdeconnect kdelibs5-plugins kdesudo kinit kio kmahjongg kmenuedit kommander
  kpat krusader kwin-common kwin-style-breeze libcolorcorrect5 libk3b7
  libkf5akonadicore5abi2 libkf5akonadiwidgets5abi1 libkf5auth5 libkf5authcore5
  libkf5bookmarks5 libkf5cddb5 libkf5configwidgets5 libkf5declarative5
  libkf5iconthemes5 libkf5kcmutils5 libkf5kdegames7 libkf5kdelibs4support5
  libkf5kdelibs4support5-bin libkf5kiocore5 libkf5kiofilewidgets5
  libkf5kiogui5 libkf5kiowidgets5 libkf5kmahjongglib5 libkf5newstuff5
  libkf5newstuffcore5 libkf5notifyconfig5 libkf5parts5 libkf5plasma5
  libkf5plasmaquick5 libkf5purpose-bin libkf5purpose5 libkf5quickaddons5
  libkf5runner5 libkf5sane5 libkf5style5 libkf5texteditor-bin
  libkf5texteditor5 libkf5textwidgets5 libkf5wallet-bin libkf5xmlgui5
  libkf5xmlrpcclient5 libkscreenlocker5 libkwin4-effect-builtins1
  libokular5core8 libpam-systemd libpolkit-backend-1-0 libpolkit-qt-1-1
  libpolkit-qt5-1-1 libprocessui7 libsystemd0 libtaskmanager6 libweather-ion7
  milou okular plasma-desktop plasma-framework plasma-integration
  plasma-workspace polkit-kde-agent-1 qml-module-org-kde-draganddrop
  qml-module-org-kde-kconfig qml-module-org-kde-kcoreaddons
  qml-module-org-kde-kquickcontrols qml-module-org-kde-kquickcontrolsaddons
  qml-module-org-kde-kwindowsystem qml-module-org-kde-purpose
  qml-module-org-kde-qqc2desktopstyle rasdaemon skanlite skrooge systemd
  udisks2



Cheers,

-- 
Cristian

Bug#940963: samba doesn't start anymore

[Elimar Riesebieter]

Package: samba
Version: 2:4.10.8+dfsg-1
Severity: normal


This server runs sysvinit!

[2019/09/22 12:44:28.672896,  0] ../../source3/smbd/server.c:1850(main)
  server role = 'active directory domain controller' not compatible with 
running smbd standalone. 
  You should start 'samba' instead, and it will control starting smbd if 
required
[2019/09/22 12:44:30.809747,  0] ../../source3/nmbd/nmbd.c:921(main)
  server role = 'active directory domain controller' not compatible with 
running nmbd standalone. 
  You should start 'samba' instead, and it will control starting the internal 
nbt server

smb.conf isn't modified since last successful start:

# Global parameters
[global]
workgroup = LXTEC
realm = HOME.LXTEC.NET
netbios name = TOY
server role = active directory domain controller
server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, 
winbind, ntp_signd, kcc, dnsupdate
idmap_ldb:use rfc2307 = yes
interfaces = ???.???.???.???

..

-- Package-specific info:
* /var/lib/samba/dhcp.conf not present

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

Kernel: Linux 4.19.75-toy-lxtec-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages samba depends on:
ii  adduser  3.118
ii  dpkg 1.19.7
ii  init-system-helpers  1.57
ii  libbsd0  0.10.0-1
ii  libc62.29-2
ii  libldb1  2:1.5.5-2
ii  libpam-modules   1.3.1-5
ii  libpam-runtime   1.3.1-5
ii  libpopt0 1.16-12
ii  libpython3.7 3.7.4-4
ii  libtalloc2   2.3.0-2
ii  libtdb1  1.4.2-2
ii  libtevent0   0.10.1-3
ii  libwbclient0 2:4.10.8+dfsg-1
ii  lsb-base 11.1.0
ii  procps   2:3.3.15-2+b1
ii  python3  3.7.3-1
ii  python3-dnspython1.16.0-1
ii  python3-samba2:4.10.8+dfsg-1
ii  samba-common 2:4.10.8+dfsg-1
ii  samba-common-bin 2:4.10.8+dfsg-1
ii  samba-libs   2:4.10.8+dfsg-1
ii  tdb-tools1.4.2-2

Versions of packages samba recommends:
ii  attr1:2.4.48-4
ii  logrotate   3.15.1-1
ii  samba-dsdb-modules  2:4.10.8+dfsg-1
ii  samba-vfs-modules   2:4.10.8+dfsg-1

Versions of packages samba suggests:
ii  bind9  1:9.11.5.P4+dfsg-5.1+b1
ii  bind9utils 1:9.11.5.P4+dfsg-5.1+b1
pn  ctdb   
ii  ldb-tools  2:1.5.5-2
ii  ntp1:4.2.8p13+dfsg-2
ii  smbldap-tools  0.9.9-1
pn  ufw
pn  winbind

-- no debconf information

Bug#884857: developers-reference: clarify process on retirement/improve wording

[Judit Foglszinger]

Hi,

> Can I recommend we keep the alternative available (with a somewhat lower
> precedence, as retirment through nm.d.o are a tad easier to process for
> everybody involved).

Wouldn't it be more advisable to write something like
"in case you fail to authenticate to the NM site or have other issues
to open the retirement/return process yourself, contact front desk"
instead of keeping the former more cumbersome way of retirement alife?

That also would adress "not advertise NM as the SSO support team".

> This is still true.  Nobody is actually checking the aliases to see if
> any need updating in the retirement/removal process, so really if
> somebody is receiving mails from an alias it needs to be updated
> manually.

Ok.

Also, what about the gpg  key?
Are people asked to prove they still control their key?
If so, in which way?



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

Bug#939446: buster-pu: package emacs/1:26.1+1-3.2

[Rob Browning]

"Adam D. Barratt"  writes:

> Apologies for not getting back to you on this sooner - the request was
> filed just before the 10.1 point release, and things have been a little
> busy since.

No worries -- just uploaded with urgency "high".  Please let me know if
I got something wrong.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#940939: More info

[Matthieu Gallien]

Hello,

This is a Kirigami2 issue. I am trying to find a solution upstream.

Please move it to this package.

It may be a good idea to change the severity given that all applications using 
Kirigam2 are broken.

Best regards

Bug#940962: ITP: libinsane -- A cross-platform, cross-programming languages, cross scanner library that takes care of all the quirks of scanners.

[Thomas Perret]

Package: wnpp
Severity: wishlist
Owner: Thomas Perret 

* Package name: libinsane
  Version : 1.0.1
  Upstream Author : Jerome Flesch 
* URL : https://gitlab.gnome.org/World/OpenPaperwork/libinsane
* License : LGPL-3.0+
  Programming Lang: C
  Description : A cross-platform, cross-programming languages, cross 
scanner library that takes care of all the quirks of scanners.

Libinsane is *the* library to access scanners on both Linux and Windows. It's
cross-platform, cross-programming languages, cross-scanners :-). It takes care
of all the quirks of all the platforms and scanners

It has however some limitations:
- It is only designed to work with *scanners*, not webcams, not USB keys, etc
  (think paper-eaters only)
- TWAIN API may display some dialogs. Libinsane cannot prevent them.
- Full bed page scan only: Presence of the option to set the scan area cannot
  be guaranteed. You may have to crop the image later in your own application
  (see [Paperwork](https://openpaper.work) for example).
- 24 bits color scans only (may be fixed later)

It is the successor of Pyinsane2[0] but shares no code with it.

This is a dependency of paperwork[1] package which I'm in the process of
packaging.

This package will be maintained in salsa.d.o in the group
openpaperwork-team with other paperwork dependencies.

As I'm not a DD, I'll need a sponsor for this package.

[0]: https://tracker.debian.org/pkg/pyinsane
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721287

Bug#940932: new upstream bug report

[Antonio Russo]

I couldn't find a bug report on the zfsonlinux bug tracker, so I opened one for 
this issue [1].

Thanks for looking into this,
Antonio

[1] https://github.com/zfsonlinux/zfs/issues/9346

Bug#940961: aptitude: upgrade of apt is not smooth

[Oswald Buddenhagen]

Package: aptitude
Version: 0.8.12-1
Severity: normal

while upgrading apt from within aptitude, i got this error:

[...]
Setting up libapt-pkg5.0:amd64 (1.8.4) ...
(Reading database ... 316101 files and directories currently installed.)
Preparing to unpack .../libapt-inst2.0_1.8.4_amd64.deb ...
Unpacking libapt-inst2.0:amd64 (1.8.4) over (1.8.3) ...
Preparing to unpack .../archives/apt_1.8.4_amd64.deb ...
Unpacking apt (1.8.4) over (1.8.3) ...
dpkg: error: dpkg frontend lock is locked by another process
/etc/cron.daily/apt-compat.dpkg-new
/etc/kernel/postinst.d/apt-auto-removal.dpkg-new
/etc/apt/apt.conf.d/01autoremove.dpkg-new
/etc/logrotate.d/apt.dpkg-new
/etc/ld.so.conf.d/zz_i386-biarch-compat.conf.dpkg-new
E: Sub-process /usr/bin/dpkg returned an error code (2)
dpkg: error: dpkg frontend lock is locked by another process
Press Return to continue, 'q' followed by Return to quit.

however, immediately trying again (apparently) resolved the issue:

Preconfiguring packages ...
Setting up apt (1.8.4) ...
(Reading database ... 316101 files and directories currently installed.)
Preparing to unpack .../apt-utils_1.8.4_amd64.deb ...
[...]

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

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

Current library versions:
  NCurses version: ncurses 6.1.20190803
  cwidget version: 0.5.18
  Apt version: 5.0.2

aptitude linkage:
linux-vdso.so.1 (0x7ffd1b0d5000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7fa6bf1bf000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7fa6bf184000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7fa6bf154000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fa6bf14b000)
libcwidget.so.4 => /usr/lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7fa6bf045000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fa6bef21000)
libboost_iostreams.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x7fa6bef01000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7fa6bece8000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fa6becc7000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fa6beaee000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fa6be9a9000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fa6be98f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fa6be7cd000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7fa6be7b5000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fa6be798000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fa6be785000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fa6be75c000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7fa6be73d000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 
(0x7fa6be693000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7fa6be668000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7fa6be5c1000)
/lib64/ld-linux-x86-64.so.2 (0x7fa6bf81b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fa6be5bc000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fa6be5b1000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fa6be5a6000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7fa6be489000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7fa6be466000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.12-1
ii  libapt-pkg5.0 1.8.4
ii  libboost-iostreams1.67.0  1.67.0-13
ii  libc6 2.29-2
ii  libcwidget4   0.5.18-5
ii  libgcc1   1:9.2.1-8
ii  libncursesw6  6.1+20190803-1
ii  libsigc++-2.0-0v5 2.10.1-2
ii  libsqlite3-0  3.29.0-2
ii  libstdc++69.2.1-8
ii  libtinfo6 6.1+20190803-1
ii  libxapian30   1.4.12-1

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  

Bug#884857: developers-reference: clarify process on retirement/improve wording

[Mattia Rizzolo]

Hello, I have some comments on the already applied patch:

> -2. Send an gpg-signed email announcing your retirement to
> -   ``debian-priv...@lists.debian.org``.
> +-  Use the link https://nm.debian.org/process/emeritus to log in to
> +   nm.debian.org [2]_, request emeritus status and write a goodby
typo: goodbye
> +   message that will be automatically posted on debian-private.

While the above it's true, sending a signed retirement email to
debian-private@ is still very much supported, and a very good way to
proceed for all the myriad reasons there could be for SSO to fail (or to
be a pain to set up for inactive people that just want to get out of the
way).
Can I recommend we keep the alternative available (with a somewhat lower
precedence, as retirment through nm.d.o are a tad easier to process for
everybody involved).


> -4. If you received mails via a @debian.org e-mail alias (e.g.
> -   pr...@debian.org) and would like to get removed, open a RT ticket for
> -   the Debian System Administrators. Just send an e-mail to
> -   ``ad...@rt.debian.org`` with "Debian RT" somewhere in the subject
> -   stating from which aliases you'd like to get removed.

This is still true.  Nobody is actually checking the aliases to see if
any need updating in the retirement/removal process, so really if
somebody is receiving mails from an alias it needs to be updated
manually.

> +   This also automatically notifies the MIA team, so that they can
> +   check if some of your packages still need orphaning.

Why mentioning the MIA team here?

> --  Contact ``da-mana...@debian.org``.
> +-  Use the link https://nm.debian.org/wizard/process/return to log in to
> +   nm.debian.org [2]_ and request to return from emeritus status.

Here I would also mention that doing so requires being able to actually
authenticate.  That's usually hard for retired DDs because they can't
get a @d.o certificate, and they most likely long lost access to their
@user.alioth.d.o account.  Maybe just mention in passing that for auth
(or, most likely, all kind of) issues they can write to nm@d.o?
And if they are registering a new SSO account (don't ask me why, it
happens…), it probably needs to be linked to their previous nm.d.o
account, which requires manual intervention from the people behind
nm@d.o, so please do write that address as the contact point.

> +.. [2]
> +   Login on nm.debian.org requires an SSO browser certificate.
> +   (you can generate them on https://sso.debian.org)
> +   If you cannot access SSO, the recommended way of action is to
> +   mail NM frontdesk using ``n...@debian.org``.

Mh, not really.  For SSO issues, the point of contact is the SSO team.
The NM team grew a some know-how due to providing support in the past,
but I really don't want it to be advertised as the SSO support team.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#940840: systemctl --no-ask-password restart apt-daily-upgrade.timer hangs indefinetely

[Michael Biebl]

Am 22.09.19 um 14:08 schrieb Marc Haber:
> On Sat, Sep 21, 2019 at 05:05:10PM +0200, Michael Biebl wrote:
>>>   58 systemd-time-wait-sync.service   start running
>>
>> Hm, this service is not enabled by default and I'm guessing it prevents
>> time-sync.target to be reached, blocking all subsequent services.
>>
>> Have you enabled this service manually?
> 
> Not that I am aware of. The link dates back to August 8, the machine
> has been updated and rebooted multiple times since then without
> problems, there were no significant changes to the machine. The system
> logs don't show the service being enabled manually (auth.log should have
> a sudo entry if I did that manally, I never work in a root shell but
> prefix every root command with its own sudo call for exactly this
> reason).


All I can say for sure is that the Debian systemd package never
explicitly enabled this service. Looking at codesearch.debian.net I
don't find any other package referencing that service either.

Since you are adamant that you haven't enabled the service manually (at
least not explicitly), I wonder if you used something like "systemctl
preset" in the past and it was enabled because of that (afaics
systemd-time-wait-sync.service is not explicitly disabled).



>> What happens if you disable this service?
> 
> Then, everything is fine.

Ok, good. So we have isolated the root cause then.

>> If you read man 8 systemd-time-wait-sync.service
>>
>>> systemd-time-wait-sync is a system service that delays the start of 
>>> units that depend on time-sync.target
>>> until the system time has been synchronized with an accurate time 
>>> source by systemd-timesyncd.service.
>>>
>>> systemd-timesyncd.service notifies on successful synchronization.  
>>> systemd-time-wait-sync also tries to
>>> detect when the kernel marks the time as synchronized, but this 
>>> detection is not reliable and is intended
>>> only as a fallback for other servies that can be used to 
>>> synchronize time (e.g., ntpd, chronyd).
>>>
>>
>>
>> Maybe you should only use systemd-time-wait-sync.service in combination
>> with systemd-timesyncd. The man page explicitly warns that using it
>> combination with other NTP clients can be unreliable.
> 
> Yes, but I interpret this part of the man page as an information that I
> might end up with a system that doesn't think that it's synchronized and
> otherwise runs fine. It is is really meant to warn that the system might
> be inhibited from finishing booting with unrelated systemctl calls
> blocking indefinetely and upgrades stalling, this warning should be WAY
> more explicit.

For me the man page is pretty clear, fwiw.
If you have ideas for how to improve the man page, please consider
filing an upsteam bug report.

> Or, preferably, the code should be made more robust so that using a
> non-systemd time server doesn't endanger the system.

Unfortunately, I have no idea how to "make it more robust".
This needs someone more clever then me to come up with ideas how the
heuristics for non-systemd-timesyncd case can be improved.

It could be debated whether it makes sense to use
TimeoutStartSec=infinity or if the service should have a reasonably
chosen timeout.
This would need discussion with upstream though.

> I do have only two decades of Unix experience and I am not familiar with
> the concept of time synchronization of the kernel. When does a regular
> ntp server consider itself synced, and why did we live for so long
> without the init systemd being informed about that state?

I guess the rationale for systemd-time-wait-sync.service is the same as
for NetworkManager-wait-online.service or
systemd-networkd-wait-online.service.
The simple fact that those daemons have started does not mean that you
have network access (or your system clock is synchronized).

You can probably find out more about it at the initial PR
https://github.com/systemd/systemd/pull/8494


> A new title for this bug report could probably be "using
> systemd-time-wait-sync with non-systemd time sync services such as ntp
> might lead to weird behavior and incomplete boots".

does
"systemd-time-wait-sync blocks indefinitely with alternative NTP
implementations, stalling boot and units depending on time-sync.target"
sound ok?

In any case, if you want the documentation improved or the behaviour of
the service changed, you should best file this upstream. This doesn't
look like a downstream, Debian specific issue.

Regards,
Michael

-- 
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#940938: telegram-desktop: Could not start Telegram Desktop!

[Коля Гурьев]

Severity: minor
Tags: moreinfo

Hi!

22.09.2019 12:41, Utkarsh Gupta пишет:
> [2019.09.22 15:07:08] FATAL: Could not move logging to 
> '/home/utkarsh2102/.local/share/TelegramDesktop/log.txt'!

Please check that Telegram can write to this file, especially that it
isn't immutable. See lsattr(1), flag 'i'.

Telegram Desktop needs its working directory to be fully accessible
under your EUID. I'd recommend you to remove the ~/.local/share/TelegramDesktop
directory (this will drop your current Telegram session) and then start
telegram-desktop as unprivileged user, without sudo.

Bug#940679: pandas: random test crashes

[Rebecca N. Palmer]

Control: tags -1 patch

Running the test suite (of -7) under gdb a few times produced a crash in 
pandas/tests/indexes/interval/test_astype.py::TestDatetimelikeSubtype::test_astype_category[index4] 
(4 not 3).


The trace points to Cython-generated C from _Timedelta._has_ns, which 
(among other things) tries to dereference 
((PyDictObject*)((_PyObject_GetDictPtr(((PyObject *)__pyx_v_self).


(gdb) p (__pyx_v_self)
$18 = (struct __pyx_obj_6pandas_5_libs_6tslibs_10timedeltas__Timedelta 
*) 0x7fff8ee09f70
(gdb) p *((PyDictObject*)((_PyObject_GetDictPtr(((PyObject 
*)__pyx_v_self)

Cannot access memory at address 0x7fff8ee0a000 # __pyx_v_self+144
(gdb) p ((PyDictObject*)((_PyObject_GetDictPtr(((PyObject 
*)__pyx_v_self)

$5 = (PyDictObject *) 0x7fff8ee09ff0 # __pyx_v_self+128
(gdb) p sizeof(PyDictObject)
$28 = 48 # if it starts at +128, it ends at +176

(gdb) p ((PyObject *)__pyx_v_self)->ob_type->tp_dictoffset
$25 = 128
(gdb) p ((PyObject *)__pyx_v_self)->ob_type->tp_weaklistoffset
$29 = 136
(gdb) p ((PyObject *)__pyx_v_self)->ob_type->tp_basicsize
$26 = 144
(gdb) p sizeof(*(__pyx_v_self))
$21 = 128 # PyDictObject is off the end of the C struct

This looks like Python thinks _Timedelta has a per-instance dict, but C 
thinks it doesn't and so doesn't allocate space for it, and the crash 
happens when Python tries to read off the end.


I suspect this is because cdef classes aren't supposed to have non-cdef 
attributes, which makes this an easy problem to fix:


--- a/pandas/_libs/tslibs/timedeltas.pyx
+++ b/pandas/_libs/tslibs/timedeltas.pyx
@@ -655,7 +655,7 @@ cdef class _Timedelta(timedelta):
 int64_t _d, _h, _m, _s, _ms, _us, _ns

 # higher than np.ndarray and np.matrix
-__array_priority__ = 100
+cdef public object __array_priority__ = 100

 def __hash__(_Timedelta self):
 if self._has_ns():

but the Cython documentation is ambiguous as to whether this is actually 
prohibited, and I haven't tested it yet.

Bug#940671: alacarte crashes on start with GNOME 3.34 installed

[Dmitry Shachnev]

Hi Matteo!

On Wed, Sep 18, 2019 at 09:51:39PM +0200, Matteo Settenvini wrote:
> whenever I attempt to start alacarte with GNOME 3.34 installed,
> I get the following output:
>
> $ alacarte
> [...]
> gi.repository.GLib.Error: g-markup-error-quark: Errore alla riga 1
> carattere 1: Il documento era vuoto oppure conteneva unicamente spazi (1)
>
> The program then exits.

Can you please check if you have any empty .menu files in your
~/.config/menus/?

If there are empty files, please remove them and then alacarte should start
working properly.

Also did you use alacarte before? The old version of it was known to corrupt
the .menu files, see [1]. If it still corrupts them somehow, please let me
know how to reproduce it.

[1]: https://gitlab.gnome.org/GNOME/alacarte/issues/1

--
Dmitry Shachnev



signature.asc
Description: PGP signature

Bug#939170: Also with systemctl suspend

[Daniel M.]

Hi,

this also happens to me when I try systemctl suspend instead of a GUI
action. So it's not a problem of the desktop environment but of kernel
or even systemd.

Maybe something with the thinkpad kernel module?

Cheers,
Daniel

Bug#940127: ghostscript makes c2esp autopkgtest timeout

[Brian Potkin]

On Sat 21 Sep 2019 at 17:39:20 +0200, Didier 'OdyX' Raboud wrote:

> Le samedi, 21 septembre 2019, 16.24:30 h CEST Brian Potkin a écrit :
> > > There's clearly a regression in ghostscript 9.28 that started segfaulting
> > > in the c2esp filter chain. But I can't manage to reproduce it outside of
> > > the "cups + c2esp + cups-filters (gstoraster) + ghostscript" environment.
> > > 
> > > Brian; Till: any idea?
> > 
> > No ideas from me really. I too get gstoraster stopping when attempting
> > to print /usr/share/cups/data/form_russian.pdf; but the same is true for
> > form_english.pdf.
> 
> Ah, sorry; I formulated my inquiry weakly. Let me try again:
> 
> Do you have a hint on how to reproduce the failing ghostscript call (or the 
> gstoraster call) directly, without using CUPS in the middle?

Bug#938747: uhd-host depends on python:any

[Andreas Henriksson]

Hello,

At a first glance on the source package of uhd it seems like
a pure python3 package.

However looking closer on the generated binary packages it can be seen
that the 'uhd-host' binary package has a dependency on python:any.

The reason seems to be that there are many python scripts that has
a shebang looking like this:
#!/usr/bin/env python

Someone should check if these scripts are compatible with both python2
and python3 and if so just switch the shebang to use python3. That
should make the python:any dependency go away.

Regards,
Andreas Henriksson

Bug#940849: Upgrade the package to 1.9.3

[Bernhard Übelacker]

Dear Maintainer,
I guess this has to do with the package libgtkd-3-0.

Currently testing contains the version 3.8.5-1+b2.
That one got compiled with ldc 1:1.17.0-2.

The version 3.8.5-1 got compiled with ldc 1:1.12.0-1.
Installing that version from [1] makes tilix at least
run and open its window.
That might be another workaround, until tilix 1.9.3-1
transitions to testing.

This situation might be a side effect of the rebuilt +b2
of tilix 1.8.9-1 failing against ldc 1:1.17.0-2.
That was taken care of by uploading tilix 1.9.3-1,
that currently waits for gtk-d to transition and
the armhf build before it transitions to testing.

Kind regards,
Bernhard

[1] 
https://snapshot.debian.org/archive/debian/20190107T030854Z/pool/main/g/gtk-d/libgtkd-3-0_3.8.5-1_amd64.deb
[2] https://buildd.debian.org/status/logs.php?pkg=tilix=amd64

Bug#940127: ghostscript makes c2esp autopkgtest timeout

[Brian Potkin]

On Sat 21 Sep 2019 at 17:39:20 +0200, Didier 'OdyX' Raboud wrote:

> Le samedi, 21 septembre 2019, 16.24:30 h CEST Brian Potkin a écrit :
> > > There's clearly a regression in ghostscript 9.28 that started segfaulting
> > > in the c2esp filter chain. But I can't manage to reproduce it outside of
> > > the "cups + c2esp + cups-filters (gstoraster) + ghostscript" environment.
> > > 
> > > Brian; Till: any idea?
> > 
> > No ideas from me really. I too get gstoraster stopping when attempting
> > to print /usr/share/cups/data/form_russian.pdf; but the same is true for
> > form_english.pdf.
> 
> Ah, sorry; I formulated my inquiry weakly. Let me try again:
> 
> Do you have a hint on how to reproduce the failing ghostscript call (or the 
> gstoraster call) directly, without using CUPS in the middle?


Would this do?

cat /usr/share/cups/data/form_russian.pdf | gs -dQUIET -dPARANOIDSAFER 
-dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dShowAcroForm 
-sstdout=%stderr -sOutputFile=%stdout -sDEVICE=cups -r600x600 
-dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=8 
-dcupsColorOrder=0 -dcupsColorSpace=4 -scupsPageSizeName=A4 
-I/usr/share/cups/fonts -c '<>setpagedevice' -f -_ > out.ras

Regards,

Brian.

Bug#940127: ghostscript makes c2esp autopkgtest timeout

[Didier 'OdyX' Raboud]

Le dimanche, 22 septembre 2019, 13.25:19 h CEST Brian Potkin a écrit :
> On Sat 21 Sep 2019 at 17:39:20 +0200, Didier 'OdyX' Raboud wrote:
> > Le samedi, 21 septembre 2019, 16.24:30 h CEST Brian Potkin a écrit :
> > > > There's clearly a regression in ghostscript 9.28 that started
> > > > segfaulting
> > > > in the c2esp filter chain. But I can't manage to reproduce it outside
> > > > of
> > > > the "cups + c2esp + cups-filters (gstoraster) + ghostscript"
> > > > environment.
> > > > 
> > > > Brian; Till: any idea?
> > > 
> > > No ideas from me really. I too get gstoraster stopping when attempting
> > > to print /usr/share/cups/data/form_russian.pdf; but the same is true for
> > > form_english.pdf.
> > 
> > Ah, sorry; I formulated my inquiry weakly. Let me try again:
> > 
> > Do you have a hint on how to reproduce the failing ghostscript call (or
> > the
> > gstoraster call) directly, without using CUPS in the middle?
> 
> Would this do?
> 
> cat /usr/share/cups/data/form_russian.pdf | gs -dQUIET -dPARANOIDSAFER
> -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dShowAcroForm
> -sstdout=%stderr -sOutputFile=%stdout -sDEVICE=cups -r600x600
> -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=8
> -dcupsColorOrder=0 -dcupsColorSpace=4 -scupsPageSizeName=A4
> -I/usr/share/cups/fonts -c '< 3.00] /Margins[00]>>setpagedevice' -f -_ > out.ras

The problem is… This doesn't segfault. :-(

-- 
OdyX

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

Bug#940959: Please downgrade gedit-plugin-zeitgeist to Recommends or Suggests

[Michael Biebl]

Package: gedit-plugins
Version: 3.30.1-3
Severity: normal

Hi,

it seems gedit-plugins-zeitgeist is currently the only package here on
my system keeping the zeitgeist stack installed.
Given the additional dependencies this plugin pulls in, it would be
great if it could be demoted to Recommends, so can be uninstalled
without also having to uninstall gedit-plugins.
Afaics zeitgeist is pretty much dead and QA maintained, so it might make
sense to even downgrade that dependency to Suggests so it is no longer
installed by default.

Regards,
Michael


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

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

Versions of packages gedit-plugins depends on:
ii  gedit-plugin-bookmarks   3.30.1-3
ii  gedit-plugin-bracket-completion  3.30.1-3
ii  gedit-plugin-character-map   3.30.1-3
ii  gedit-plugin-code-comment3.30.1-3
ii  gedit-plugin-color-picker3.30.1-3
ii  gedit-plugin-color-schemer   3.30.1-3
ii  gedit-plugin-commander   3.30.1-3
ii  gedit-plugin-draw-spaces 3.30.1-3
ii  gedit-plugin-find-in-files   3.30.1-3
ii  gedit-plugin-git 3.30.1-3
ii  gedit-plugin-join-lines  3.30.1-3
ii  gedit-plugin-multi-edit  3.30.1-3
ii  gedit-plugin-smart-spaces3.30.1-3
ii  gedit-plugin-synctex 3.30.1-3
ii  gedit-plugin-terminal3.30.1-3
ii  gedit-plugin-translate   3.30.1-3
ii  gedit-plugin-word-completion 3.30.1-3
ii  gedit-plugin-zeitgeist   3.30.1-3

gedit-plugins recommends no packages.

gedit-plugins suggests no packages.

-- no debconf information

Bug#940840: systemctl --no-ask-password restart apt-daily-upgrade.timer hangs indefinetely

[Marc Haber]

On Sat, Sep 21, 2019 at 05:05:10PM +0200, Michael Biebl wrote:
> >  58 systemd-time-wait-sync.service   start running
> 
> Hm, this service is not enabled by default and I'm guessing it prevents
> time-sync.target to be reached, blocking all subsequent services.
> 
> Have you enabled this service manually?

Not that I am aware of. The link dates back to August 8, the machine
has been updated and rebooted multiple times since then without
problems, there were no significant changes to the machine. The system
logs don't show the service being enabled manually (auth.log should have
a sudo entry if I did that manally, I never work in a root shell but
prefix every root command with its own sudo call for exactly this
reason).

> What happens if you disable this service?

Then, everything is fine.

> If you read man 8 systemd-time-wait-sync.service
> 
> >systemd-time-wait-sync is a system service that delays the start of 
> > units that depend on time-sync.target
> >until the system time has been synchronized with an accurate time 
> > source by systemd-timesyncd.service.
> > 
> >systemd-timesyncd.service notifies on successful synchronization.  
> > systemd-time-wait-sync also tries to
> >detect when the kernel marks the time as synchronized, but this 
> > detection is not reliable and is intended
> >only as a fallback for other servies that can be used to synchronize 
> > time (e.g., ntpd, chronyd).
> > 
> 
> 
> Maybe you should only use systemd-time-wait-sync.service in combination
> with systemd-timesyncd. The man page explicitly warns that using it
> combination with other NTP clients can be unreliable.

Yes, but I interpret this part of the man page as an information that I
might end up with a system that doesn't think that it's synchronized and
otherwise runs fine. It is is really meant to warn that the system might
be inhibited from finishing booting with unrelated systemctl calls
blocking indefinetely and upgrades stalling, this warning should be WAY
more explicit.

Or, preferably, the code should be made more robust so that using a
non-systemd time server doesn't endanger the system. This might be
misunderstood as another systemd conspiration to drive ntp and chrony
from the systems in favor of systemd-timesyncd.

I do have only two decades of Unix experience and I am not familiar with
the concept of time synchronization of the kernel. When does a regular
ntp server consider itself synced, and why did we live for so long
without the init systemd being informed about that state?

A new title for this bug report could probably be "using
systemd-time-wait-sync with non-systemd time sync services such as ntp
might lead to weird behavior and incomplete boots".

> > Now, speaking with my ippl maintainer hat on, what was the information
> > that made you take a closer look at ippl?
> 
> It was in the list of queued jobs and a quick apt-file search
> ippl.service did not reveal anything, so I was wondering if this was
> maybe a 3rd party service file.

Thanks. Good news is that I don't need to change anything there (the
package is dying away anyway, upstream hasn't been active in fifteen
years).

Thanks for helping with the issue at hand, I appreciate your patience
and speed of replies.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#940840: systemctl --no-ask-password restart apt-daily-upgrade.timer hangs indefinetely

[Marc Haber]

On Sun, Sep 22, 2019 at 04:46:24PM +0200, Michael Biebl wrote:
> Regression to an older systemd version (which one)? Or did other parts
> of the system change?

I guess either kernel (self-built) or systemd. I do a regular
dist-upgrade on the machine, and it doesn't do much else (it holds my
mini-buildd instance and I didn't build anything in last two weeks).

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#940960: ITP: linenoise -- Minimal replacement for readline

[Jeremy Sowden]

Package: wnpp
Severity: wishlist
Owner: Jeremy Sowden 

* Package name: linenoise
  Version : 1.0+git20180718.4a961c010872
  Upstream Author : Salvatore Sanfilippo 
* URL : https://github.com/antirez/linenoise
* License : BSD-2-Clause
  Programming Lang: C
  Description : Minimal replacement for readline

A minimal, zero-config, BSD licensed, readline replacement used in Redis,
MongoDB, and Android.

  * Single and multi line editing mode with the usual key bindings implemented.
  * History handling.
  * Completion.
  * Hints (suggestions at the right of the prompt as you type).
  * About 1,100 lines of BSD license source code.
  * Only uses a subset of VT100 escapes (ANSI.SYS compatible).

Bug#940936: dvb-tools: dvbv5-scan fails to scan channels

[Clément VUCHENER]

Le dim. 22 sept. 2019 à 15:54, Mauro Carvalho Chehab
 a écrit :
>
> Em Sun, 22 Sep 2019 13:20:42 +0200
> Gregor Jasny  escreveu:
>
> > Hello Mauro,
> >
> > Do you have an idea why scanning fails here?
>
> See comments below.
>
> Btw, not sure how often Debian updates the dtv-scan-tables package. This
> package contains only configuration settings to be used for Digital TV
> (and a Makefile with installs their contents at the right places),
> and it is updated upstream a few times per year, in order to reflect
> the current channel listings, as, from time to time, new frequencies
> are used, tuning parameters change or satellites got replaced.
>
> I strongly suggest to update this package from time to time, even on
> a LTS distro.
>
> Based on the report, it sounds that Clément is still using a very old
> channel table, with the channel frequencies used before March 2015.
> The channel parameters were updated in 2017 at frequency database
> tree, and the file itself was renamed in 2018, in order to follow
> the current name for the satellite: Eutelsat 5 West A.

Yes, the issue is actually with dts-scan-tables. I downloaded
Eutelsat-5-West-A-5.0W from the repository you linked and it scan
channels now. I checked packages.debian.org and even sid has the same
version for dts-scan-tables. I don't really know how bug are managed
here, can you reclassify it as a dts-scan-tables bug?

>
> > On 22.09.19 10:25, Clément Vuchener wrote:
>
> > > I am trying to receive DVB-S2 using a Hauppauge WinTV Starbust 2 tuner
> > > card. dvbv5-scan fails to find anything and always report status 00,
> > > while w_scan successfully scanned channels. As reportbug asked me to use
> > > the latest version, I installed sid versions of dvb-tools and libdvbv5-0
> > > on my Debian Buster installation, but this did not change the result.
> > >
> > > $ dvbv5-scan -l universal /usr/share/dvb/dvb-s/Atlantic-Bird-3-5.0W
> > > Using LNBf UNIVERSAL
> > > Old European Universal. Nowadays mostly replaced by Astra 19.2E
> > > Freqs : 10800 to 11800 MHz, LO: 9750 MHz
> > > Freqs : 11600 to 12700 MHz, LO: 10600 MHz
>
> First of all, the best is to use the "extended" LNBf, as this is the most
> common LNBf found in Europe those days. It has a wider frequency range.
> If you use "universal", you won't be able to tune a few transponders there,
> with have a frequency a little higher than 12,700 MHz.

My LNB is old, but I'll check. It worked with the "universal"
settings, and the channel I am interested in are in the universal
range any way.

>
> Also, looking a w_scan source code, S5W0 is not Atlantic Bird, but, instead,
> EUTELSAT 5 WEST A, with was renamed at DTV scan tables [1] in 2018:
>
>   commit 740c6b2eb7ad8c9ff77a2d8cc6811d6dbfa201c3
>   Author: Olliver Schinagl 
>   Date:   Thu May 10 21:41:13 2018 +0200
>
> Rename Atlantic Bird 3 to Eutelsat5
>
> [1] see https://git.linuxtv.org/dtv-scan-tables.git
>
> The scan table for it was also changed in 2017:
>
>   commit 3dc7a8d6b5f9a8218ac3763c3a4d5cc86100c5a0
>   Author: l...@netcourrier.com 
>   Date:   Wed Jan 11 14:28:51 2017 +0100
>
> dtv-scan-tables - dvb-s - update and rename the config file for 
> Atlantic-Bird-3-5.0W - Ku Band
>
> Hello,
>
> The latest update for the file Atlantic-Bird-3-5.0W (Ku Band) is 
> 2015-03-28:
> https://git.linuxtv.org/dtv-scan-tables.git/log/dvb-s/Atlantic-Bird-3-5.0W
> but since March 2015 there are a lot of changes in the tranponders list.
> And now, a lot of transponders for Algerian, French and Italian TV and
> Radio channels are missing.
> Attached is an updated config scan file (Atlantic-Bird-3-5.0W.patch
> file) for Atlantic-Bird-3-5.0W transponders in dvbv5 format.
> Could you please ensure that this new patch is committed into the DVB
> source code tree repositery?
> PS : Attached there is also the full up to date file :
> Atlantic-Bird-3-5.0W-2017-01-09.NEW.FULL if you need it
>
> Btw, on a quick look at w_scan code, it uses those frequencies:
>
> {5, 10971, 1, 29950, 7 , 0, 0 },  // EUTELSAT 5 WEST A 0  
> ;  48.3Mbps; NID=1375 ; TID=20600;
> {5, 11017, 0, 2048 , 5 , 0, 0 },  // EUTELSAT 5 WEST A 0  
> ;   3.1Mbps; NID=65500; TID=1;
> {5, 11054, 1, 29950, 7 , 0, 0 },  // EUTELSAT 5 WEST A 0  
> ;  48.3Mbps; NID=1375 ; TID=20500;
> {5, 11059, 0, 23700, 3 , 0, 0 },  // EUTELSAT 5 WEST A 0  
> ;  32.8Mbps; NID=1374 ; TID=10900;
> {5, 11096, 1, 29950, 7 , 0, 0 },  // EUTELSAT 5 WEST A 0  
> ;  48.3Mbps; NID=1375 ; TID=20400;
> {5, 11103, 0, 2043 , 5 , 0, 0 },  // EUTELSAT 5 WEST A 0  
> ;   3.1Mbps; NID=65500; TID=1;
> {5, 5, 0, 2725 , 5 , 0, 0 },  // EUTELSAT 5 WEST A 0  
> ;   1.0 bps; NID=0; TID=0;
> {5, 11139, 1, 27540, 2 , 0, 9 },  // EUTELSAT 5 WEST A 0  
> ;   0.0 bps; NID=8442 ; TID=4;
> {5, 

Bug#940955: override After and Wants in openvpn@.service

[Marc Haber]

Package: openvpn
Version: 2.4.7-1
Severity: normal

Hi,

On one machine that runs an OpenVPN server, I also have a name server
running that should also service requests from the VPN on the machine's
tun0 IP address. For reasons related to systemd, I therefore need to
delay the start of the name server to a point when the OpenVPN daemon
has already created the tun0 interface.

In stretch, this could be done with some aux unit:

- network initializes
- OpenVPN starts immediately
- a unit wait-vpn-ready.service, WantedBy=network-online.target waits
  fot tun0 to show up
- a unit wait-no-tentative-ipv6.service, also
  WantedBy=network-online.target, waits for IPv6 having left tentative
  state.
- bind9 waits for network-online.target

In buster, OpenVPN has After=network-online.target and
Wants=network-online.target itself, which breaks this scheme.
wait-vpn-ready.service times out because the OpenVPN service it is
waiting for has never started in the first place, and then OpenVPN and
the DNS server start simultaneously.

I do not know why it is necessary to have OpenVPN wait for
network-online.target other then log cosmetics, but there should be a
possibility to override this new behavior.

Unfortunately, dropping a
/etc/systemd/system/openvpn@.service.d/after-wants.conf with
[Unit]
After=
Wants=
doesn't help here. With the current state of the package, the only
method that helps is copying /lib/systemd/system/openvpn@.service to
/etc/systemd/system/openvpn@.service and making the necessary changes
there. This of course does make future packaging changes in
/lib/systemd/system/openvpn@.service ineffective on the system in
question since the entire Unit is overrideen. I am not sure whether this
is desireable. Having the entire unit as a dpkg-conffile in /etc would
probably be a policy violation.

A possible solution is:

[8/4996]mh@torres:~ $ sudo systemctl cat openvpn@.service
# /lib/systemd/system/openvpn@.service
[Unit]
Description=OpenVPN connection to %i
PartOf=openvpn.service
ReloadPropagatedFrom=openvpn.service
Before=systemd-user-sessions.service
Documentation=man:openvpn(8)
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO

[Service]
Type=notify
PrivateTmp=true
WorkingDirectory=/etc/openvpn
ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10 
--cd /etc/openvpn --config /etc/
PIDFile=/run/openvpn/%i.pid
KillMode=process
ExecReload=/bin/kill -HUP $MAINPID
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_
LimitNPROC=100
DeviceAllow=/dev/null rw
DeviceAllow=/dev/net/tun rw
ProtectSystem=true
ProtectHome=true
RestartSec=5s
Restart=on-failure

[Install]
WantedBy=multi-user.target

# /lib/systemd/system/openvpn@.service.d/after-wants.conf
[Unit]
After=network-online.target
Wants=network-online.target


While shipping both a unit file and an override file for this very unit
in the same package might look confusing at first, this allows the
After= and Wants= settings to be overridden by placing another override
file in /etc/systemd/system/openvpn@.service.d/after-wants.conf.

I am not sure whether the inability to override unit dependencies from a
Unit in an override file is a shortcoming in systemd or not and I don't
want to get into this level of politics today.

Please consider whether the suggested change might be suitwable for the
OpenVPN package, probably not without extensive documentation and
rationale.

Greetings
Marc

Bug#940840: systemctl --no-ask-password restart apt-daily-upgrade.timer hangs indefinetely

[Marc Haber]

On Sun, Sep 22, 2019 at 03:39:24PM +0200, Michael Biebl wrote:
> I wonder if you used something like "systemctl
> preset" in the past

not that I am aware of, I have not idea what that command does ;-)

> > Yes, but I interpret this part of the man page as an information that I
> > might end up with a system that doesn't think that it's synchronized and
> > otherwise runs fine. It is is really meant to warn that the system might
> > be inhibited from finishing booting with unrelated systemctl calls
> > blocking indefinetely and upgrades stalling, this warning should be WAY
> > more explicit.
> 
> For me the man page is pretty clear, fwiw.
> If you have ideas for how to improve the man page, please consider
> filing an upsteam bug report.

Considering the way Upstream likes to write in their man pages when
their software fails to honor the robustness principle, I won't do that.

> > A new title for this bug report could probably be "using
> > systemd-time-wait-sync with non-systemd time sync services such as ntp
> > might lead to weird behavior and incomplete boots".
> 
> does
> "systemd-time-wait-sync blocks indefinitely with alternative NTP
> implementations, stalling boot and units depending on time-sync.target"
> sound ok?

Yes ;-)

> In any case, if you want the documentation improved or the behaviour of
> the service changed, you should best file this upstream. This doesn't
> look like a downstream, Debian specific issue.

Agreed. Things are going to stay like they are then. I don't have the
energy these days to stand being told by Upstream that I am holding
their baby wrong.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#940840: systemctl --no-ask-password restart apt-daily-upgrade.timer hangs indefinetely

[Marc Haber]

On Sun, Sep 22, 2019 at 04:12:43PM +0200, Michael Biebl wrote:
> Since systemd-time-wait-sync.service doesn't seem to really work with
> alternative implementations, I wonder if it wouldn't be better to err on
> the safe safe and do the following:
> - Rename it systemd-timesyncd-wait-time-sync.service
> - Add Requires=systemd-timesyncd.service to
> systemd-timesyncd-wait-time-sync.service
> - Update the documentation and remove the section which says that it
> sort-of supports alternative implementations as fallback.

Maybe the same heuristics that prevent systemd-timesyncd from starting
on such systems can be used.

This is, btw, a regression, it worked until some time last week.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#940957: logging in affects ctime of ~/.gnupg/private-keys-v1.d

[Marc Haber]

Package: gpg-agent
Version: 2.2.17-3
Severity: normal

Hi,

when I log in to a system that has gpg-agent installed, the ctime of
~/.gnupg/private-keys-v1.d is update to the local time. This causes aide
to write out a report.

Why does the Agent need to update the _ctime_ of a directory when it
starts up in the first place?

Greetings
Marc


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

Kernel: Linux 5.2.13-zgws1 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gpg-agent depends on:
ii  gpgconf 2.2.17-3
ii  init-system-helpers 1.57
ii  libassuan0  2.5.3-7
ii  libc6   2.29-1
ii  libgcrypt20 1.8.5-2
ii  libgpg-error0   1.36-7
ii  libnpth01.6-1
ii  pinentry-gnome3 [pinentry]  1.1.0-3
ii  pinentry-qt [pinentry]  1.1.0-3

Versions of packages gpg-agent recommends:
ii  gnupg  2.2.17-3

Versions of packages gpg-agent suggests:
ii  dbus-user-session  1.12.16-1
ii  libpam-systemd 242-7
ii  pinentry-gnome31.1.0-3
ii  scdaemon   2.2.17-3

-- no debconf information

Bug#940958: why does python-apt depend on the full gnupg suite including agent?

[Marc Haber]

Package: python-apt
Version: 1.8.4
Severity: normal

Hi,

a few months ago, the gnupg package was split into multiple binary
packages, gnupg remaining a dependency helper pulling in everything.
python-apt (the python 2 version, the python 3 version for some reason
does it better) depends on "gnupg", pulling in the entire suite
including gnupg-agent, which in turn creates user sockets in /run/user.

This raises concerns with some security departments who rightfully
question why would somebody use a gnupg-agent on a server.

Please consider relaxing the dependency on gnupg, making it only depend
on the parts of the gnupg suite that python-apt it actually needs. I do
seriously doubt that a dependency on the parts of the suite that handle
secret keys and secret keyrings is really needed.

Thanks!

Greetings
Marc