Bug#972855: python3-humanize: due to use_scm_version, humanize.__version__ reports 0.0.0

[Nicolas Noirbent]

Package: python3-humanize
Version: 3.1.0-1
Severity: important

Dear Maintainer,

Similarly to black [1], I suspect use_scm_version in humanize's setup.py
[2] breaks humanize.__version__ when built by debian (more accurately,
it breaks pkg_resources.get_distribution(__name__).version).

Not really a big deal except other tools / packages rely on said version:

% dpkg -l python3-humanize | tail -1
ii  python3-humanize 3.1.0-1  all  Python Humanize library (Python 
3)
% python3 -c 'import humanize; print(humanize.__version__)'
0.0.0
% grep '^Version:' 
/usr/lib/python3/dist-packages/humanize-0.0.0.egg-info/PKG-INFO
Version: 0.0.0
% pgcli
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 567, in 
_build_master
ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 884, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 775, in 
resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (humanize 0.0.0 
(/usr/lib/python3/dist-packages), Requirement.parse('humanize>=0.5.1'), 
{'pgcli'})

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/pgcli", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3239, 
in 
def _initialize_master_working_set():
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3222, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3251, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 569, in 
_build_master
return cls._build_from_requirements(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 582, in 
_build_from_requirements
dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 770, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'humanize>=0.5.1' distribution was not 
found and is required by pgcli


Not really sure how this can be fixed considering the source package is
downloaded from PyPi, i.e. there's no SCM version information anymore at
this point.

The source tarball however *does* carry the correct version number
(3.1.0), so maybe there's also an issue in debhelper / debian/rules ?


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970901
[2] https://github.com/jmoiron/humanize/blob/master/setup.py#L34


Cheers,

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

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

Versions of packages python3-humanize depends on:
ii  python33.8.6-1
ii  python3-pkg-resources  50.3.0-1

python3-humanize recommends no packages.

python3-humanize suggests no packages.

-- no debconf information

Bug#875306: python-debian: include a type for buildinfo files

[Stuart Prescott]

Dear reproducible-builds folks,

python-debian has classes to wrap many of Debian's deb822 format files, trying 
to use an underlying parser that always exposes the data in more or less the 
same key/value way via a dictionary, plus also providing extra syntactic sugar 
to help make sense of the values that are included. For example, package 
dependencies such as Depends or Build-Depends are split up into a list of 
relationships, with the standard syntax that we use everywhere interpreted to 
include version restrictions etc.

The .buildinfo files have two places where interpreting the values seems 
worthwhile:

Environment: split the lines and extract the key="value" data into a
dictionary in the same format as Python's normal `os.environ`. (Some
dequoting is needed but not currently implemented.)

Installed-Build-Depends: use the standard package-relation code on this 
to
return interpret the list of packages.

We could thus do something like:

In [1]: from debian import deb822

In [2]: info = deb822.BuildInfo(open("debian/tests/test_BuildInfo"))

In [3]: info.get_environment()
Out[3]: 
{'DEB_BUILD_OPTIONS': 'parallel=4',
 'LANG': 'en_AU.UTF-8',
 'LC_ALL': 'C.UTF-8',
 'LC_TIME': 'en_GB.UTF-8',
 'LD_LIBRARY_PATH': '/usr/lib/libeatmydata',
 'SOURCE_DATE_EPOCH': '1601784586'}

In [4]: info.relations['installed-build-depends']
Out[4]: 
[[{'name': 'autoconf',
   'archqual': None,
   'version': ('=', '2.69-11.1'),
   'arch': None,
   'restrictions': None}],
 [{'name': 'automake',
   'archqual': None,
   'version': ('=', '1:1.16.2-4'),
   'arch': None,
   'restrictions': None}],
 [{'name': 'autopoint',
   'archqual': None,
   'version': ('=', '0.19.8.1-10'),
   'arch': None,
   'restrictions': None}],
 [{'name': 'autotools-dev',
   'archqual': None,
   'version': ('=', '20180224.1'),
   'arch': None,
   'restrictions': None}],
 [{'name': 'base-files',
   'archqual': None,
   'version': ('=', '11'),
   'arch': None,
   'restrictions': None}],
...(trimmed)...

In [5]: for dep in info.relations['installed-build-depends']:
   ...: print("Installed %s/%s" % (dep[0]['name'], dep[0]['version'][1]))
   ...: 
Installed autoconf/2.69-11.1
Installed automake/1:1.16.2-4
Installed autopoint/0.19.8.1-10
Installed autotools-dev/20180224.1
Installed base-files/11
...(trimmed)...


The standard format for the list of package relationships contains features 
that the buildinfo format doesn't need ("foo | bar", architecture and build-
profile restrictions), but it seems better to use exactly the same format as is 
used for Packages and Sources. That does however mean there are lots of 
single-element lists used, as seen in the `dep[0]` usage above. A bit ugly, 
but consistency wins here, I think.

How does this look to you?

Are there additional data that would be nice to extract and interpret in a 
structured way?

The current code doesn't handle dequoting the environment values and will 
react particularly badly to environment values with newlines in them.

The current work-in-progress code is at 

https://salsa.debian.org/python-debian-team/python-debian/-/merge_requests/29

Comments, suggestions and encouragement gratefully accepted :)

thanks
Stuart

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

Bug#972859: libsejda-java FTBFS: cannot find symbol

[Adrian Bunk]

Source: libsejda-java
Version: 4.1.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=libsejda-java=all=4.1.1-1=1603575235=0

...
[INFO] 
[INFO] Reactor Summary for sejda 4.1.1:
[INFO] 
[INFO] sejda .. SUCCESS [  0.007 s]
[INFO] sejda model  SUCCESS [  3.005 s]
[INFO] sejda core . SUCCESS [  0.385 s]
[INFO] sejda fonts  SUCCESS [  0.211 s]
[INFO] sejda image writers  SUCCESS [  0.234 s]
[INFO] sejda sambox ... FAILURE [  0.927 s]
[INFO] sejda conversion ... SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  4.949 s
[INFO] Finished at: 2020-10-24T21:33:50Z
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) 
on project sejda-sambox: Compilation failure: Compilation failure: 
[ERROR] 
/<>/sejda-sambox/src/main/java/org/sejda/impl/sambox/component/PDDocumentHandler.java:[258,48]
 cannot find symbol
[ERROR]   symbol:   variable ASYNC_BODY_WRITE
[ERROR]   location: class org.sejda.sambox.output.WriteOption
[ERROR] 
/<>/sejda-sambox/src/main/java/org/sejda/impl/sambox/component/PDDocumentHandler.java:[301,17]
 cannot find symbol
[ERROR]   symbol:   method sanitizeDictionary()
[ERROR]   location: variable imported of type org.sejda.sambox.pdmodel.PDPage
[ERROR] 
/<>/sejda-sambox/src/main/java/org/sejda/impl/sambox/component/split/PageCopier.java:[101,13]
 cannot find symbol
[ERROR]   symbol:   method sanitizeDictionary()
[ERROR]   location: variable copy of type org.sejda.sambox.pdmodel.PDPage
[ERROR] 
/<>/sejda-sambox/src/main/java/org/sejda/impl/sambox/component/PageImageWriter.java:[131,34]
 cannot find symbol
[ERROR]   symbol:   method 
createFromSeekableSource(org.sejda.io.SeekableSource,java.lang.String)
[ERROR]   location: class org.sejda.sambox.pdmodel.graphics.image.PDImageXObject
[ERROR] 
/<>/sejda-sambox/src/main/java/org/sejda/impl/sambox/component/PageImageWriter.java:[136,38]
 cannot find symbol
[ERROR]   symbol:   method 
createFromSeekableSource(org.sejda.io.SeekableSource,java.lang.String)
[ERROR]   location: class org.sejda.sambox.pdmodel.graphics.image.PDImageXObject
[ERROR] 
/<>/sejda-sambox/src/main/java/org/sejda/impl/sambox/component/PageImageWriter.java:[140,42]
 cannot find symbol
[ERROR]   symbol:   method 
createFromSeekableSource(org.sejda.io.SeekableSource,java.lang.String)
[ERROR]   location: class org.sejda.sambox.pdmodel.graphics.image.PDImageXObject
[ERROR] 
/<>/sejda-sambox/src/main/java/org/sejda/impl/sambox/component/PageImageWriter.java:[157,52]
 incompatible types: org.sejda.io.SeekableSource cannot be converted to 
java.io.File
[ERROR] 
/<>/sejda-sambox/src/main/java/org/sejda/impl/sambox/component/PageImageWriter.java:[164,50]
 cannot find symbol
[ERROR]   symbol:   method asNewInputStream()
[ERROR]   location: variable source of type org.sejda.io.SeekableSource
[ERROR] 
/<>/sejda-sambox/src/main/java/org/sejda/impl/sambox/component/PageImageWriter.java:[191,82]
 cannot find symbol
[ERROR]   symbol:   method asNewInputStream()
[ERROR]   location: variable source of type org.sejda.io.SeekableSource
[ERROR] 
/<>/sejda-sambox/src/main/java/org/sejda/impl/sambox/component/PageImageWriter.java:[237,82]
 cannot find symbol
[ERROR]   symbol:   method asNewInputStream()
[ERROR]   location: variable source of type org.sejda.io.SeekableSource
[ERROR] 
/<>/sejda-sambox/src/main/java/org/sejda/impl/sambox/SetMetadataTask.java:[79,50]
 cannot find symbol
[ERROR]   symbol:   class OnBeforeWrite
[ERROR]   location: class org.sejda.sambox.pdmodel.PDDocument
[ERROR] 
/<>/sejda-sambox/src/main/java/org/sejda/impl/sambox/SetMetadataTask.java:[80,13]
 method does not override or implement a method from a supertype
[ERROR] 
/<>/sejda-sambox/src/main/java/org/sejda/impl/sambox/component/image/ExifHelper.java:[41,110]
 cannot find symbol
[ERROR]   symbol:   method asNewInputStream()
[ERROR]   location: interface org.sejda.io.SeekableSource
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :sejda-sambox

Bug#969222: New patch for Cyrus-Imapd HTTP/2

[Xavier]

Hi all,

I just pushed Cyrus-Imapd 3.2.4-4 in experimental. This release applies
an upstream patch and re-enable HTTP/2. Could you test it ?

Cheers,
Xavier

Bug#972689: Some more details

[Karsten]

Regarding the Debian documentation https://wiki.debian.org/PulseAudio

Setting "autospawn = no" in /etc/pulse/client.conf has no effect!
I did also try

cp /etc/pulse/client.conf ~/.config/pulse/

pulseaudio --kill


You always have this process "00:00:00 /usr/bin/pulseaudio --daemonize=no"


I tried to delete the configuration in ~/.config/pulse/ without no effect.


When you rename /usr/bin/pulseaudio then pulseaudio cannot start but you don't 
have any sound in KDE!

What must be done to get rid of pulseaudio and to get direct sound with ALSA?


When you try to remove the package there are to much dependencies:

# apt-get purge pulseaudio
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.  
Statusinformationen werden eingelesen Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr 
benötigt:
  freeglut3 g++-6 gnuradio gnuradio-dev gr-fcdproplus gr-fosphor gr-iqbal 
gr-osmosdr libairspy0 libairspyhf1 libbladerf1
  libboost-atomic1.67-dev libboost-chrono1.67-dev libboost-chrono1.67.0 
libboost-date-time-dev libboost-date-time1.67-dev
  libboost-date-time1.67.0 libboost-filesystem-dev libboost-filesystem1.67-dev 
libboost-program-options-dev
  libboost-program-options1.67-dev libboost-regex1.67.0 
libboost-serialization1.67-dev libboost-serialization1.67.0
libboost-system-dev
  libboost-system1.67-dev libboost-test-dev libboost-test1.67-dev 
libboost-test1.67.0 libboost-thread-dev
libboost-thread1.67-dev
  libboost-timer1.67.0 libboost1.67-dev libcomedi0 libcppunit-1.14-0 
libcppunit-dev libfreesrp0 libglfw3
libgnuradio-analog3.7.13
  libgnuradio-atsc3.7.13 libgnuradio-audio3.7.13 libgnuradio-blocks3.7.13 
libgnuradio-channels3.7.13
libgnuradio-comedi3.7.13
  libgnuradio-digital3.7.13 libgnuradio-dtv3.7.13 libgnuradio-fcd3.7.13 
libgnuradio-fcdproplus3.7.11 libgnuradio-fec3.7.13
  libgnuradio-fft3.7.13 libgnuradio-filter3.7.13 libgnuradio-fosphor3.7.12 
libgnuradio-iqbalance3.7.11
libgnuradio-noaa3.7.13
  libgnuradio-osmosdr0.1.4 libgnuradio-pager3.7.13 libgnuradio-pmt3.7.13 
libgnuradio-qtgui3.7.13 libgnuradio-runtime3.7.13
  libgnuradio-trellis3.7.13 libgnuradio-uhd3.7.13 libgnuradio-video-sdl3.7.13 
libgnuradio-vocoder3.7.13
libgnuradio-wavelet3.7.13
  libgnuradio-wxgui3.7.13 libgnuradio-zeromq3.7.13 libhackrf0 libhamlib2 
libjs-jquery-ui liblimesuite18.06-1
liblog4cpp5-dev liblog4cpp5v5
  libmirisdr0 libnorm1 libosmosdr0 libpgm-5.2-0 libpulsedsp libqt4-help 
libqt4-scripttools libqt4-test
libqtassistantclient4 libqwt-qt5-6
  librtaudio6 librtlsdr0 libsoapysdr0.6 libsodium23 libstdc++-6-dev 
libuhd3.13.1 libvolk1-bin libvolk1-dev libvolk1.4
libzmq5
  limesuite-udev pkg-config pulseaudio-utils python-cheetah python-cycler 
python-gobject-2 python-gtk2 python-kiwisolver
python-matplotlib
  python-matplotlib2-data python-networkx python-opengl python-pygraphviz 
python-pyparsing python-qt4 python-scipy
python-subprocess32
  python-yaml python-zmq rtkit rtl-sdr soapyosmo-common0.6 
soapysdr0.6-module-airspy soapysdr0.6-module-all
soapysdr0.6-module-audio
  soapysdr0.6-module-bladerf soapysdr0.6-module-hackrf soapysdr0.6-module-lms7 
soapysdr0.6-module-osmosdr
soapysdr0.6-module-redpitaya
  soapysdr0.6-module-remote soapysdr0.6-module-rtlsdr soapysdr0.6-module-uhd 
uhd-host

Bug#972837: sysvinit: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adam Borowski]

Control: tag -1 +pending

On Sat, Oct 24, 2020 at 02:53:47PM -0300, Adriano Rafael Gomes wrote:
> Please, Could you update the Brazilian Portuguese Translation?
> 
> Attached you will find the file pt_BR.po.

In git, thanks!


-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ “Exegi monumentum aere perennius” -- “I made a monument more
⢿⡄⠘⠷⠚⠋⠀ durable than bronze”.
⠈⠳⣄   -- Horace (65-8 BC), leaving the loo, constipated

Bug#972849: useful-clojure FTBFS: Could not locate clojure/tools/macro__init.class, clojure/tools/macro.clj or clojure/tools/macro.cljc on classpath

[Adrian Bunk]

Source: useful-clojure
Version: 0.11.6-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=useful-clojure=all=0.11.6-2=1603520988=0

...
dh_auto_test
(cd test && find . -name "*.clj" | \
xargs clojure -cp 
/<>/useful.jar:/usr/share/java/clojure.jar:/usr/share/java/useful.jar)
Syntax error (FileNotFoundException) compiling at 
(flatland/useful/utils.clj:1:1).
Could not locate clojure/tools/macro__init.class, clojure/tools/macro.clj or 
clojure/tools/macro.cljc on classpath.

Full report at:
/tmp/clojure-11069530683106326717.edn
make[1]: *** [debian/rules:23: override_dh_auto_test] Error 123

Bug#934273: python3-debian: please support parsing Source: package (version)

[David Bremner]

Stuart Prescott  writes:

> Control: tags -1 patch
>
>
> In [2]: def whatmade(name, cat): 
>   ...: p = [pkg for pkg in cat if pkg['Package'] == name][0] 
>   ...: print("Source %s/%s made binary %s/%s" % ( 
>   ...: p.source, 
>   ...: p.source_version, 
>   ...: p['Package'], 
>   ...: p.get_version(), 
>   ...: )) 
>

Yes, that seems like it would work for my use case.

d

Bug#904732: autopkgtest-build-lxc doesn't work

[intrigeri]

Hi,

Ben Hutchings (2018-07-27):
> lxc-start: lxccontainer.c: wait_on_daemonized_start: 754 Received container 
> state "ABORTING" instead of "RUNNING"
> lxc-start: tools/lxc_start.c: main: 368 The container failed to start.
> lxc-start: tools/lxc_start.c: main: 370 To get more details, run the 
> container in foreground mode.
> lxc-start: tools/lxc_start.c: main: 372 Additional information can be 
> obtained by setting the --logfile and --logpriority options.

FWIW, I had the same problem, and it got fixed by starting
lxc-net.service.

I had /etc/default/lxc-net configured already for other reasons;
I don't know if that's necessary here.

Cheers!

Bug#972858: zim FTBFS: FileNotFoundError: [Errno 2] No such file or directory: '/run/user/2952'

[Adrian Bunk]

Source: zim
Version: 0.73.3-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=zim=all=0.73.3-1=1603610569=0

...
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:217: python3.8 setup.py clean
Unable to init server: Could not connect: Connection refused
Unable to init server: Could not connect: Connection refused

(setup.py:32456): Gdk-CRITICAL **: 07:22:44.197: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(setup.py:32456): Gdk-CRITICAL **: 07:22:44.197: gdk_keymap_get_modifier_mask: 
assertion 'GDK_IS_KEYMAP (keymap)' failed

(setup.py:32456): Gdk-CRITICAL **: 07:22:44.197: gdk_keymap_get_for_display: 
assertion 'GDK_IS_DISPLAY (display)' failed

(setup.py:32456): Gtk-CRITICAL **: 07:22:44.197: 
_gtk_replace_virtual_modifiers: assertion 'GDK_IS_KEYMAP (keymap)' failed
Traceback (most recent call last):
  File "/<>/zim/main/ipc.py", line 82, in 
os.mkdir(runtime_dir, mode=0o700)
FileNotFoundError: [Errno 2] No such file or directory: '/run/user/2952'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "setup.py", line 25, in 
import makeman # helper script
  File "/<>/makeman.py", line 13, in 
from zim.main import HelpCommand
  File "/<>/zim/main/__init__.py", line 39, in 
from .ipc import dispatch as _ipc_dispatch
  File "/<>/zim/main/ipc.py", line 90, in 
raise AssertionError('Either you are not the owner of "%s" or the 
permissions are un-safe.\n'
AssertionError: Either you are not the owner of "/run/user/2952" or the 
permissions are un-safe.
If you can not resolve this, try setting $XDG_RUNTIME_DIR or set $TMP to a 
different location.
E: pybuild pybuild:352: clean: plugin distutils failed with: exit code=1: 
python3.8 setup.py clean
dh_auto_clean: error: pybuild --clean -i python{version} -p 3.8 returned exit 
code 13
make: *** [debian/rules:12: clean] Error 25

Bug#972556: ffmpeg: Fails to build from source with newer src:srt

[Sebastian Ramacher]

Control: severity -1 wishlist
Control: retitle -1 ffmpeg: re-enable support for libsrt

On 2020-10-20 12:05:10 +0200, Sebastian Ramacher wrote:
> Control: block -1 by 971754
> 
> On 2020-10-20 11:42:47, John Paul Adrian Glaubitz wrote:
> > Control: tags -1 +patch
> > 
> > Hello!
> > 
> > This FTBFS is fixed by the following upstream patch [1]:
> > 
> > From: Jun Zhao 
> > Date: Sun, 12 Jul 2020 05:48:48 + (+0800)
> > Subject: lavf/srt: fix build fail when used the libsrt 1.4.1
> > X-Git-Url: 
> > http://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff_plain/7c59e1b0f285cd7c7b35fcd71f49c5fd52cf9315
> > 
> > lavf/srt: fix build fail when used the libsrt 1.4.1
> > 
> > libsrt changed the:
> > SRTO_SMOOTHER   -> SRTO_CONGESTION
> > SRTO_STRICTENC  -> SRTO_ENFORCEDENCRYPTION
> > and removed the front of deprecated options (SRTO_SMOOTHER/SRTO_STRICTENC)
> > in the header, it's lead to build fail
> > 
> > fix #8760
> > 
> > Signed-off-by: Jun Zhao 
> 
> FWIW, srt broke its ABI (see the blocking bug). Unless this situation is
> sorted out soon, we'd have a ffmpeg that is stuck in unstable. So I'd
> consider dropping srt support until the srt situation has been fixed.

I have now temporarily disabled support for libsrt. Once libsrt gets
unbroken, it can be renabled again.

Cheers

> 
> > So, this patch and the patch from #968574 would be great!
> 
> Has the patch from #968574 been merged upstream in the meantime?
> 
> Cheers
> 
> > 
> > Thanks,
> > Adrian
> > 
> > > [1] 
> > > https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/7c59e1b0f285cd7c7b35fcd71f49c5fd52cf9315
> > 
> > -- 
> >  .''`.  John Paul Adrian Glaubitz
> > : :' :  Debian Developer - glaub...@debian.org
> > `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
> >   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> > 
> 
> -- 
> Sebastian Ramacher
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#972848: kdevelop: FTBFS - dh_install: error: missing files, aborting

[John Paul Adrian Glaubitz]

Source: kdevelop
Severity: serious
Justification: FTBFS

Hi!

kdevelop fails to build from source due to dh_install missing files:

make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
   debian/rules override_dh_install
   make[1]: Entering directory '/<>'
   # create this directory if not existing, so kdevelop-data.install
   # is the same, no matter whether clang is built
   mkdir -p debian/tmp/usr/share/kdevclangsupport/
   dh_install
   dh_install: warning: Cannot find (any matches for) 
"usr/share/kservices5/kdevelopsessions.desktop" (tried in ., debian/tmp)

dh_install: warning: plasma-kdevelop missing files: 
usr/share/kservices5/kdevelopsessions.desktop
dh_install: error: missing files, aborting
make[1]: *** [debian/rules:18: override_dh_install] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:9: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

Thanks,
Adrian

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

Bug#972857: JACK is destroying any audio connection from clients after update

[Arnaldo Pirrone]

Package: jackd2
Version: 1.9.16~dfsg-1
Severity: important
X-Debbugs-Cc: it9...@gmail.com

Running as always, here's the log:

10:30:28.474 Resetta le statistiche.
10:30:28.495 Connessioni di ALSA cambiate.
10:30:28.501 D-BUS: Servizio disponibile (org.jackaudio.service aka jackdbus).
Cannot connect to server socket err = File o directory non esistente
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
unlock
10:30:28.547 Cambiamento nel grafico delle connessioni di ALSA.
10:31:54.499 D-BUS: JACK si sta avviando...
10:31:54.501 D-BUS: JACK è stato avviato (org.jackaudio.service aka jackdbus).
Cannot connect to server socket err = File o directory non esistente
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
unlock
10:31:54.503 Cambiamento nel grafico delle connessioni di ALSA.
Sun Oct 25 10:31:54 2020: Starting jack server...
Sun Oct 25 10:31:54 2020: JACK server starting in realtime mode with priority
10
Sun Oct 25 10:31:54 2020: self-connect-mode is "Don't restrict self connect
requests"
Sun Oct 25 10:31:54 2020: Acquired audio card Audio1
Sun Oct 25 10:31:54 2020: creating alsa driver ...
hw:PCH,0|hw:PCH,0|1024|2|48000|0|0|hwmon|hwmeter|-|32bit
Sun Oct 25 10:31:54 2020: configuring for 48000Hz, period = 1024 frames (21.3
ms), buffer = 2 periods
Sun Oct 25 10:31:54 2020: ALSA: final selected sample format for capture: 32bit
integer little-endian
Sun Oct 25 10:31:54 2020: ALSA: use 2 periods for capture
Sun Oct 25 10:31:54 2020: ALSA: final selected sample format for playback:
32bit integer little-endian
Sun Oct 25 10:31:54 2020: ALSA: use 2 periods for playback
Sun Oct 25 10:31:54 2020: port created: Midi-Through:midi/playback_1
Sun Oct 25 10:31:54 2020: port created: Midi-Through:midi/capture_1
Sun Oct 25 10:31:54 2020: graph reorder: new port 'system:capture_1'
Sun Oct 25 10:31:54 2020: New client 'system' with PID 0
Sun Oct 25 10:31:54 2020: graph reorder: new port 'system:capture_2'
Sun Oct 25 10:31:54 2020: graph reorder: new port 'system:playback_1'
Sun Oct 25 10:31:54 2020: graph reorder: new port 'system:playback_2'
Sun Oct 25 10:31:54 2020: graph reorder: new port 'system:midi_capture_1'
Sun Oct 25 10:31:54 2020: graph reorder: new port 'system:midi_playback_1'
Sun Oct 25 10:31:54 2020: New client 'PulseAudio JACK Sink' with PID 1904
Sun Oct 25 10:31:54 2020: Connecting 'PulseAudio JACK Sink:front-left' to
'system:playback_1'
Sun Oct 25 10:31:54 2020: Connecting 'PulseAudio JACK Sink:front-right' to
'system:playback_2'
Sun Oct 25 10:31:54 2020: New client 'PulseAudio JACK Source' with PID 1904
Sun Oct 25 10:31:54 2020: Connecting 'system:capture_1' to 'PulseAudio JACK
Source:front-left'
Sun Oct 25 10:31:54 2020: Connecting 'system:capture_2' to 'PulseAudio JACK
Source:front-right'
Sun Oct 25 10:31:55 2020: Saving settings to
"/home/it9exm/.config/jack/conf.xml" ...
10:31:56.553 Resetta le statistiche.
10:31:56.570 Client attivato.
10:31:56.570 Patchbay disattivato.
10:31:56.571 Grafico delle connessioni di JACK modificato.
Sun Oct 25 10:31:56 2020: New client 'qjackctl' with PID 177136
10:31:59.299 Grafico delle connessioni di JACK modificato.
10:31:59.356 XRUN callback (1).
10:31:59.384 Grafico delle connessioni di JACK modificato.
Sun Oct 25 10:31:59 2020: New client 'qsynth' with PID 177169
Sun Oct 25 10:31:59 2020: ERROR: JackEngine::XRun: client = qsynth was not
finished, state = Triggered
Sun Oct 25 10:31:59 2020: ERROR: JackAudioDriver::ProcessGraphAsyncMaster:
Process error
Sun Oct 25 10:31:59 2020: ERROR: Cannot read socket fd = 36 err = Success
Sun Oct 25 10:31:59 2020: ERROR: Could not read notification result
Sun Oct 25 10:31:59 2020: ERROR: ClientNotify fails name = qsynth notification
= 18 val1 = 0 val2 = 0
Sun Oct 25 10:31:59 2020: ERROR: Cannot write socket fd = 36 err = Broken pipe
Sun Oct 25 10:31:59 2020: ERROR: CheckRes error
Sun Oct 25 10:31:59 2020: ERROR: Could not write notification
Sun Oct 25 10:31:59 2020: ERROR: ClientNotify fails name = qsynth notification
= 18 val1 = 1 val2 = 0
Sun Oct 25 10:31:59 2020: ERROR: Cannot write socket fd = 36 err = Broken pipe
Sun Oct 25 10:31:59 2020: ERROR: CheckRes error
Sun Oct 25 10:31:59 2020: ERROR: Could not write notification
Sun Oct 25 10:31:59 2020: ERROR: ClientNotify fails name = qsynth notification
= 10 val1 = 11 val2 = 0
Sun Oct 25 10:31:59 2020: ERROR: Cannot write socket fd = 36 err = Broken pipe
Sun Oct 25 10:31:59 2020: ERROR: CheckRes error
Sun Oct 25 10:31:59 2020: ERROR: Could not write notification
Sun Oct 25 10:31:59 2020: ERROR: ClientNotify fails name = qsynth notification
= 10 val1 = 12 val2 = 0
Sun Oct 25 10:31:59 2020: 

Bug#972543: apt-file: Apt-update downloads full Contents file, not pdiffs

[Niels Thykier]

Hi again,

Thanks for the data.  Unfortunately, it did reveal a smoking gun, so I
think we need /tmp/update.log generated from this command.

 apt -o Debug::pkgAcquire::Worker=1  \
-o Debug::pkgAcquire::Diffs=1 update \
  2>&1 | tee /tmp/update.log


Please attach the file rather than copy-paste in the output from it.

calumlikesapple...@gmail.com:
>>> [...]
>> [...]
> 
>>   $ apt-config dump Acquire::IndexTargets
> 
> I'll paste the full output below
> 

Thanks.  Everything looks like it was in order.

>>   file:/etc/apt/apt-file.conf  (if it exists)
> 
> This file doesn't exist, though I attached what I think is it's
> equivalent in my initial message.

That is fine.  I hoped as much as most people do not need it. :)

>> This will show the effective fetching configuration for apt and apt-
>> file.
>> Relatedly, just to confirm: The bug is on the system you are
>> reporting
>> from (i.e. running testing/sid) and you run "apt update" at least
>> once a week.  Are these assumptions of mine correct?
> Yes, that's correct.
> 
> [...]
> 

Thanks for confirming.

Bug#972809: dracut-core: Acts on /boot/initramfs-... instead of /boot/initrd... by default

[Thomas Lange]

Thanks for the patch. But when I tried to apply it on my local machine
it failed. Can you please check this


$ git merge --no-ff "aerusso-guest/dracut-mrs/initrd-no-initramfs
Auto-merging debian/patches/series
CONFLICT (content): Merge conflict in debian/patches/series
Removing debian/patches/initramfs-restore
Automatic merge failed; fix conflicts and then commit the result.

$ git st
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Changes to be committed:

deleted:debian/patches/initramfs-restore
new file:   debian/patches/initrd-not-initramfs.patch

Unmerged paths:
  (use "git add ..." to mark resolution)

both modified:   debian/patches/series

-- 
regards Thomas

Bug#972853: Parameter -comand doesn't work

[Daniel Baumann]

Package: tty-share
Version: 0.6.2+ds1-1

Hi,

when trying to use a different shell (or, bash with an option), I've
tried using '-command' as described in 'tty-share --help', which then fails:

daniel@daniel:~$ tty-share -comand /bin/bash
flag provided but not defined: -comand
Usage of tty-share:
  -args string
The command arguments
  -command string
The command to run (default "/bin/bash")
  -logfile string
The name of the file to log (default "-")
  -server string
tty-server address (default "go.tty-share.com:7654")
  -useTLS
Use TLS to connect to the server (default true)
  -version
Print the tty-share version
daniel@daniel:~$

Regards,
Daniel

Bug#971786: [Pkg-javascript-devel] Bug#971786: src:pdf.js: please package new upstream version

[Carsten Schoenert]

Hi Xavier,

Am 13.10.20 um 16:46 schrieb Xavier:
> I pushed my work to https://salsa.debian.org/js-team/pdf.js
> Could you verify that this package is OK for you ?

unfortunately until now I was unable to check the preparations you've made.

The kopano-webapp package is mainly depending on a recent kopanocore
version. But this update is much more work than the time I've spend
until now on -webapp. So it will take an undefinable amount of time
right now until I can really dig into details on kopano-webapp.

I've seen you have updated the version of pdf.js in unstable. If not
already happen I'd suggest to do that. So thanks, makes working locally
on all the stuff a bit easier.

I guess by that we can close this issue?

-- 
Regards
Carsten

Bug#972854: seems not to work

[Daniel Baumann]

Package: tty-server
Version: 0.0~git20201003.5fcfdf5+ds-1

Hi,

I've tried tty-server out, but it seems not to work for me.

I'm using "example.net" in the following commands, but have been using a
proper dns entry in reality of course.

Also, before making it work "properly" behind an apache reverse proxy
with proper ssl, I thought I'd just try it out quick

On the server, I did:

  # tty-server -url http://tty.example.net
  INFO[] Listening on address: http://:80, and TCP://:6543

On the client, I've been using:
  # tty-share -server tty.example.net:6543 -useTLS false

Which gives me the following output on the server:

  WARN[0655] Cannot create session with 1.2.3.4:35688. Error:
  Cannot decode message: invalid character '\x16' looking for beginning
  of value

And the following output on the client:

  Cannot connect (TLS) to the server (tty.example.net:6543): EOF

Disabling TLS doesn't work then.

Furhter observations:

  * neither '-useTLS false' nor '-useTLS no' work at all when
being 'reordered', so when calling:

tty-share -useTLS false -server tty.example.net:6543

then all commandline options are ignored entirely and
a normal session to go.tty-share.com is established,
eventhough -server has been specified.

  * the default ports from the server and the client don't seem
to match; the server by default starts on 6543, the client
tries by default 7654.

  * it would be nice to have systemd unit files and apache configs
integrated into the package, so that a 'apt install tty-server'
works out of the box.

Regards,
Daniel

Bug#972856: linux-image-5.9.0-1-amd64: lightdm display manager dont start. black screen

[andy]

Package: src:linux
Version: 5.9.1-1
Severity: important
X-Debbugs-Cc: 2704...@gmx.de

Dear Maintainer,

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

   * What led up to the situation?

After last kernel upgrade the display manager dont start

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Only dist-upgrade

   * What was the outcome of this action?

black screen after reboot with new kernel

   * What outcome did you expect instead?

kernel broken

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



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

** Model information
sys_vendor: Micro-Star International Co., Ltd.
product_name: MS-7A38
product_version: 5.0
chassis_vendor: Micro-Star International Co., Ltd.
chassis_version: 5.0
bios_vendor: American Megatrends Inc.
bios_version: P.40
board_vendor: Micro-Star International Co., Ltd.
board_name: B450M BAZOOKA V2 (MS-7A38)
board_version: 5.0

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Root Complex [1022:15d0]
Subsystem: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root Complex 
[1022:15d0]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 
Capabilities: [64] MSI: Enable+ Count=1/4 Maskable- 64bit+
Address: fee04000  Data: 4021
Capabilities: [74] HyperTransport: MSI Mapping Enable+ Fixed+

00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0
ExtTag+ RBE+
DevCtl: CorrErr+ NonFatalErr+ FatalErr+ UnsupReq+
RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
MaxPayload 256 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- 
TransPend-
LnkCap: Port #0, Speed 8GT/s, Width x8, ASPM L1, Exit Latency 
L1 <64us
ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s (downgraded), Width x8 (ok)
TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt+
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- 
Surprise-
Slot #0, PowerLimit 0.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- 
LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- 
Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ 
Interlock-
Changed: MRL- PresDet- LinkState+
RootCap: CRSVisible+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ 
CRSVisible+
RootSta: PME ReqID , PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- 
LTR-
 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt+ 
EETLPPrefix+, MaxEETLPPrefixes 1
 EmergencyPowerReduction Not Supported, 
EmergencyPowerReductionInit-
 FRS- LN System CLS Not Supported, TPHComp- ExtTPHComp- 
ARIFwd+
 AtomicOpsCap: Routing- 32bit+ 64bit+ 128bitCAS-
DevCtl2: Completion Timeout: 65ms to 210ms, TimeoutDis- LTR- 
OBFF Disabled, ARIFwd-
 AtomicOpsCtl: ReqEn- EgressBlck-
LnkCap2: Supported Link Speeds: 2.5-8GT/s, Crosslink- Retimer- 
2Retimers- DRS-
LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
 Transmit Margin: Normal Operating Range, 
EnterModifiedCompliance- ComplianceSOS-
 Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, 
EqualizationComplete+ EqualizationPhase1+
 EqualizationPhase2+ EqualizationPhase3+ 
LinkEqualizationRequest-
 Retimer- 2Retimers- 

Bug#972850: ITP: soong -- Soong build system for Android

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: soong
  Version : 20201014 (17e97d9)
  Upstream Author : Google Inc et al
* URL : https://android.googlesource.com/platform/build/soong
* License : Apache-2.0
  Programming Lang: Go
  Description : Soong build system for Android

Soong is a build system for Android built on top of Blueprint, a
meta-build system. Soong is the replacement for the old Android
make-based build system. It replaces Android.mk files with Android.bp
files, which are JSON-like simple declarative descriptions of modules
to build.

This initial packaging is mostly to bring the relevant Go package into
Debian; the binary package will not initially be directly usable except
within a full Android build tree. At some point, a Debian-specific build
of Soong (dh_soong?) may appear allowing to build Debian packages of
Android tools directly with Soong.

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl+VMakUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdJyuQf8C0iZzGGI6dIKS+g3y3VOQFYLdQzx
sfu2qP2coxMHFNoGEd0XZCvyxcprq8rKpL6kFgJ2plLbibuVWRKYIUqxbh1NVg35
ejqpll+QU3zhEoF5A1mW2DIqlfX6D6h//RDkP3LGvbK+82AFNjHFKCwGgoqPD/TD
s1R6g4mhGVC0ZUUCX6L2bEH+xKupUxU+nTbKTieaHKS2rs5G9RNBkulrDCdFETcn
vwByriR6m9tMFu1SAo3xCcOgJvv83KSY81zJnRLTCHuU705R5W8B9bh+AU0WhlMZ
JOsUSAjttXAdAojgVk2EAUUFaP9NTfLpUZ9+10vo/tySTKRX+cLMGwZh0g==
=Yr8Y
-END PGP SIGNATURE-

Bug#972851: ITP: golang-github-evanw-esbuild -- extremely fast JavaScript bundler and minifier

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-evanw-esbuild
  Version : 0.7.19-1
  Upstream Author : Evan Wallace
* URL : https://github.com/evanw/esbuild
* License : Expat
  Programming Lang: Go
  Description : extremely fast JavaScript bundler and minifier

 esbuild is a JavaScript bundler and minifier.  It packages up
 JavaScript and TypeScript code for distribution on the web.
 .
 Why build another JavaScript build tool?  The current build tools for the web
 are at least an order of magnitude slower than they should be.  It is hoped
 that this project serves as an "existence proof" that JavaScript tooling
 can be much, much faster.

Reason for packaging: Needed by Hugo 0.74.0 and up.

Bug#972852: gdm3: Gdm3 comes to invoke gdm-x-session at the beginning of the user session

[nozzy123nozzy]

Package: gdm3
Version: 3.38.1-2
Severity: grave

Dear Maintainer,
 After I upgraded my Debian box using the command of "apt upgrade" on
17th Oct 2020, I always get an "Oops! A problem occurred!" screen after
login.

 According to system logs, I seem gdm3 come to invoke gdm-x-session
always at the beginning of the user session, even though gdm3 is
running in Wayland on the login screen. Therefore gnome-shell of the
user session seems to fail.

 Does anyone fix this problem?

Thanks,
Takahide Nojima

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

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

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.55-3
ii  adduser   3.118
ii  dbus  1.12.20-1
ii  dconf-cli 0.38.0-1
ii  dconf-gsettings-backend   0.38.0-1
ii  debconf [debconf-2.0] 1.5.74
ii  gir1.2-gdm-1.03.38.1-2
ii  gnome-session-bin 3.38.0-2
ii  gnome-session-common  3.38.0-2
ii  gnome-settings-daemon 3.38.0-2
ii  gnome-shell   3.38.1-1
ii  gnome-terminal [x-terminal-emulator]  3.38.0-1
ii  gsettings-desktop-schemas 3.38.0-2
ii  libaccountsservice0   0.6.55-3
ii  libaudit1 1:2.8.5-3.1
ii  libc6 2.31-4
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf2.0-02.40.0+dfsg-5
ii  libgdm1   3.38.1-2
ii  libglib2.0-0  2.66.1-2
ii  libglib2.0-bin2.66.1-2
ii  libgtk-3-03.24.23-2
ii  libkeyutils1  1.6.1-2
ii  libpam-modules1.3.1-5
ii  libpam-runtime1.3.1-5
ii  libpam-systemd246.6-2
ii  libpam0g  1.3.1-5
ii  librsvg2-common   2.50.1+dfsg-1
ii  libselinux1   3.1-2+b1
ii  libsystemd0   246.6-2
ii  libx11-6  2:1.6.12-1
ii  libxau6   1:1.0.8-1+b2
ii  libxcb1   1.14-2
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  11.1.0
ii  policykit-1   0.105-29
ii  procps2:3.3.16-5
ii  ucf   3.0043
ii  x11-common1:7.7+21
ii  x11-xserver-utils 7.7+8

Versions of packages gdm3 recommends:
ii  at-spi2-core2.38.0-2
ii  desktop-base10.0.3
ii  x11-xkb-utils   7.7+5
ii  xserver-xephyr  2:1.20.9-2
ii  xserver-xorg1:7.7+21
ii  zenity  3.32.0-6

Versions of packages gdm3 suggests:
ii  gnome-orca3.38.0-1
pn  libpam-fprintd
ii  libpam-gnome-keyring  3.36.0-1

-- debconf information:
  gdm3/daemon_name: /usr/sbin/gdm3
* shared/default-x-display-manager: gdm3

Bug#972808: [3dprinter-general] Bug#972808: cura-engine FTBFS: error: ‘find_if’ is not a member of ‘std’

[Gregor Riepl]

> A native build of cura-engine on unstable amd64 ends with:
> 
> | In file included from /usr/include/gtest/gtest.h:387,
> |  from /<>/tests/utils/SparseGridTest.cpp:4:
> | /<>/tests/utils/SparseGridTest.cpp: In member function 
> ‘virtual void cura::GetNearbyTest_GetNearby_Test::TestBody()’:
> | /<>/tests/utils/SparseGridTest.cpp:48:38: error: ‘find_if’ is 
> not a member of ‘std’; did you mean ‘find’?
> |48 | EXPECT_NE(result.end(), std::find_if(result.begin(), 
> result.end(), [](const typename SparsePointGridInclusive::Elem 
> ) { return elem.val == point; }))
> |   |  ^~~

This has been fixed upstream:
https://github.com/Ultimaker/CuraEngine/issues/1318

> This must be a very recent issue as neither crossqa (10 days ago) nor
> reproducible builds (6 days ago) have run into this issue. It's reliably
> reproducible anyhow. I'm unsure what might cause it. Neither gcc-10 nor
> cura-engine were uploaded in that time. It would be a good idea to add
> the missing #include  any how.

Not sure, perhaps it was a change in one of the dependent libraries
(such as gtest).

Anyway, the fix should be in the next CuraEngine release (4.8), but we
can adopt the trivial patch from here in the meantime:
https://github.com/Ultimaker/CuraEngine/commit/ae354d80b25d90576f37222b6500f0e7ac45405b

Bug#649882: Split arch:all contents to Contents-all.gz

[Niels Thykier]

On Sun, 9 Feb 2020 10:18:40 +0100 Niels Thykier  wrote:
> [...]
> 
> Hi,
> 
> Can we try to deploy this to experimental?  All blockers that I am aware
> of have been solved.
> 
> ~Niels
> 
> 

Just adding this for future reference, so people know where this task is:

Ganneff mentioned on IRC that this was missing dak support/code.
Patches welcome.


~Niels

Bug#934747:

[حبیب بلوچ]

Bug#968204: Removal of packges which depend on GTK2

[Pál Tamás Ács]

Technically, Gtk2 and Gtk3 are two different toolkits with a similar name.
It's a completely different thing that Red Hat is trying to make us believe
that GTK3 is an improved successor of GTK2. It isn't. It never has been.

GTK3 has been very much unstable, full of API breaks and annoyances from
the get-go. It's slower due to CPU bloat under certain circumstances, eats
up more RAM and is suffering from a serious UX dumbing down to the level of
consumer devices like smartphones thus being made less suitable for
desktop. Anti-features like mandatory recursive search
 in File Dialog have also
been introduced.

GTK3 was marked stable in many distros despite it wasn't stable at all.
Software creators and package maintainers didn't want to migrate to a
poorly designed, underdeveloped, buggy graphical toolkit. They either moved
forward to Qt or stayed with Gtk2. A famous precedent case is the cancelled
GTK3 migration of Audacious. They went back to Gtk2 then moved forward
toward Qt.

There must be a cooperation among Linux maintainters outside of Red Hat to
save Gtk2 and provide security updates and some critical bug fixes on the
maintainer level.

On Sun, Oct 25, 2020 at 12:43 PM Simon McVittie  wrote:

> On Sat, 10 Oct 2020 at 09:11:23 -0700, Sean Whitton wrote:
> > Hello GNOME team,
>
> Note that pkg-gnome-maintainers receives bugmail etc. for the entire
> GNOME suite, and most (all?) GNOME maintainers aren't subscribed to that
> particular fire hose (we get bug mail for packages of interest, or for
> all GNOME packages, via tracker.debian.org instead). Our discussion list
> is debian-gtk-gnome; I only saw this because I happened to follow the
> link on a removal notification for one of the GTK2 mass-bug-filing mails.
>
> > The FTP Team are starting to see removal requests for packages which
> > use GTK2 and are unlikely to be ported to GTK3, but are not RC-buggy.
> > Examples are #968204 and #968283.
> >
> > I read your bug report against one of those two packages and smcv writes
> >
> > GTK 2 is used by some important productivity applications like GIMP,
> > and has also historically been a popular UI toolkit for proprietary
> > software that we can't change, so perhaps removing GTK 2 from Debian
> > will never be feasible. However, it has reached the point where a
> > dependency on it is a bug - not a release-critical bug, and not a
> > bug that can necessarily be fixed quickly, but a piece of technical
> > debt that maintainers should be aware of.
> >
> > My interpretation of this is that use of GTK2 is not really grounds for
> > removal by itself, because there is no removal of GTK2 planned for the
> > time being.
>
> Yes. As I said in the mass-bug-filing, I think use of GTK 2 is a bug,
> but not release-critical for bullseye. Depending what happens in the
> next 1-2 years, it might be RC for bookworm - I don't know.
>
> However, if a package hasn't been able to move from GTK 2 to GTK 3 in
> the time since GTK 2 was superseded (about a decade), that's a data point
> for assessing how actively maintained it is, both upstream and in Debian.
>
> > So maintainers who don't want to deal with a package which
> > is not likely to be updated for newer versions of GTK (which is fair
> > enough) should orphan rather than request removal.
>
> Not necessarily: a package's maintainer is in a good position to assess
> whether that package has a future in Debian, and whether it's suitable for
> inclusion in a stable release. I think we need to distinguish between
> "I think this package is suitable for Debian, but I can't/won't
> maintain it" (orphaning) and "from my knowledge as maintainer, I think
> this package is unsuitable for Debian" (RM: RoM).
>
> There's little point in orphaning a package if the most likely outcome
> is that several weeks or months later, someone with less knowledge of
> this particular package has to spend time on deciding that *now* it's
> time to remove it.
>
> smcv
>
>

Bug#972163: Rising severities

[Sylvestre Ledru]

Hello,

Le 25/10/2020 à 14:57, Lisandro Damián Nicanor Pérez Meyer a écrit :

severity 972163 serious
severity 972166 serious
block 972176 by 972163
block 972176 by 972166
thanks

Hi! We are close to begin the Qt transition that will remove
qt5-default, so I'm raising the severities.  If everything goes well
I'll be NMUing your package today with an upload to delayed/5. Of
course feel free to ping me if needed.

Thanks, Lisandro.


I tried to upload it with your fix but the build failed for me.

If it works for you, please upload (without delay)

many thanks

S

Bug#972861: emacs: please make the generated .el files reproducible

[Chris Lamb]

Source: emacs
Version: 1:27.1+1-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
emacs is now generating .el files that do not build reproducibly.

Specifically, it adds "Generated package description from "
to these files that then get installed under the
/usr/share/emacs/site-lisp/elpa-src dir. This seems to be affecting
most packages that use dh-elpa.

Here's nose-el, for example:

 -;;; Generated package description from 
/build/1st/nose-el-0.1.1/debian/elpa-nose/usr/share/emacs/site-lisp/elpa-src/nose-0.1.1/nose.el
  -*- no-byte-compile: t -*-
 +;;; Generated package description from 
/build/2/nose-el-0.1.1/2nd/debian/elpa-nose/usr/share/emacs/site-lisp/elpa-src/nose-0.1.1/nose.el
  -*- no-byte-compile: t -*-

Patch attached that drops this particular filename; it probably isn't
very useful in a Debian package context. An alternative approach could
be to regexp it down to "nose-0.1.1/nose.el" or similar; I suppose my
patch is more of an exact clarification on the issue rather than a
request for it to be fixed in this specific way.

  [0] https://reproducible-builds.org/


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 7d6be3c..a8e1ec3 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -962,8 +962,7 @@ untar into a directory named DIR; otherwise, signal an 
error."
   (print-length nil))
   (write-region
(concat
-";;; Generated package description from "
-(replace-regexp-in-string "-pkg\\.el\\'" ".el" pkg-file)
+";;; Generated package description "
 "  -*- no-byte-compile: t -*-\n"
 (prin1-to-string
  (nconc

Bug#968204: Removal of packges which depend on GTK2

[Simon McVittie]

On Sat, 10 Oct 2020 at 09:11:23 -0700, Sean Whitton wrote:
> Hello GNOME team,

Note that pkg-gnome-maintainers receives bugmail etc. for the entire
GNOME suite, and most (all?) GNOME maintainers aren't subscribed to that
particular fire hose (we get bug mail for packages of interest, or for
all GNOME packages, via tracker.debian.org instead). Our discussion list
is debian-gtk-gnome; I only saw this because I happened to follow the
link on a removal notification for one of the GTK2 mass-bug-filing mails.

> The FTP Team are starting to see removal requests for packages which
> use GTK2 and are unlikely to be ported to GTK3, but are not RC-buggy.
> Examples are #968204 and #968283.
> 
> I read your bug report against one of those two packages and smcv writes
> 
> GTK 2 is used by some important productivity applications like GIMP,
> and has also historically been a popular UI toolkit for proprietary
> software that we can't change, so perhaps removing GTK 2 from Debian
> will never be feasible. However, it has reached the point where a
> dependency on it is a bug - not a release-critical bug, and not a
> bug that can necessarily be fixed quickly, but a piece of technical
> debt that maintainers should be aware of.
> 
> My interpretation of this is that use of GTK2 is not really grounds for
> removal by itself, because there is no removal of GTK2 planned for the
> time being.

Yes. As I said in the mass-bug-filing, I think use of GTK 2 is a bug,
but not release-critical for bullseye. Depending what happens in the
next 1-2 years, it might be RC for bookworm - I don't know.

However, if a package hasn't been able to move from GTK 2 to GTK 3 in
the time since GTK 2 was superseded (about a decade), that's a data point
for assessing how actively maintained it is, both upstream and in Debian.

> So maintainers who don't want to deal with a package which
> is not likely to be updated for newer versions of GTK (which is fair
> enough) should orphan rather than request removal.

Not necessarily: a package's maintainer is in a good position to assess
whether that package has a future in Debian, and whether it's suitable for
inclusion in a stable release. I think we need to distinguish between
"I think this package is suitable for Debian, but I can't/won't
maintain it" (orphaning) and "from my knowledge as maintainer, I think
this package is unsuitable for Debian" (RM: RoM).

There's little point in orphaning a package if the most likely outcome
is that several weeks or months later, someone with less knowledge of
this particular package has to spend time on deciding that *now* it's
time to remove it.

smcv

Bug#971277: dpdk 18.11.10-1~deb10u1 flagged for acceptance

[Luca Boccassi]

On Sat, 24 Oct 2020 at 18:38, Adam D. Barratt  wrote:
>
> On Fri, 2020-10-16 at 17:05 +, Adam D Barratt wrote:
> > Package: dpdk
> > Version: 18.11.10-1~deb10u1
> >
> > Explanation: new upstream stable release; fix remote code execution
> > issue [CVE-2020-14374], TOCTOU issues [CVE-2020-14375], buffer
> > overflow [CVE-2020-14376], buffer over read [CVE-2020-14377] and
> > integer underflow [CVE-2020-14377]
>
> Unfortunately, this FTBFS on armhf (in three attempts across two
> different buildds):
>
> --- start log extract ---
>
> FAILED: drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o
> cc -Idrivers/a715181@@tmp_rte_pmd_i40e@sta -Idrivers -I../drivers 
> -Idrivers/net/i40e -I../drivers/net/i40e -Idrivers/net/i40e/base 
> -I../drivers/net/i40e/base -Ilib/librte_ethdev -I../lib/librte_ethdev -I. 
> -I../ -Iconfig -I../config -Ilib/librte_eal/common -I../lib/librte_eal/common 
> -Ilib/librte_eal/common/include -I../lib/librte_eal/common/include 
> -Ilib/librte_eal/common/include/arch/arm 
> -I../lib/librte_eal/common/include/arch/arm 
> -I../lib/librte_eal/linuxapp/eal/include 
> -Ilib/librte_eal/linuxapp/eal/../../../librte_compat 
> -I../lib/librte_eal/linuxapp/eal/../../../librte_compat -Ilib/librte_eal 
> -I../lib/librte_eal -Ilib/librte_kvargs/../librte_eal/common/include 
> -I../lib/librte_kvargs/../librte_eal/common/include -Ilib/librte_kvargs 
> -I../lib/librte_kvargs -Ilib/librte_compat -I../lib/librte_compat 
> -Ilib/librte_net -I../lib/librte_net -Ilib/librte_mbuf -I../lib/librte_mbuf 
> -Ilib/librte_mempool -I../lib/librte_mempool -Ilib/librte_ring 
> -I../lib/librte_ring -Ilib/librte_cmdline/../librte_eal/common/include 
> -I../lib/librte_cmdline/../librte_eal/common/include -Ilib/librte_cmdline 
> -I../lib/librte_cmdline -Idrivers/bus/pci -I../drivers/bus/pci 
> -I../drivers/bus/pci/linux -Ilib/librte_pci -I../lib/librte_pci 
> -Idrivers/bus/vdev -I../drivers/bus/vdev -Ilib/librte_hash 
> -I../lib/librte_hash -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 
> -include rte_config.h -Wsign-compare -Wcast-qual -Wno-pointer-to-int-cast 
> -D_GNU_SOURCE -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -fPIC -march=armv7-a -mfpu=neon -Wno-format-truncation 
> -DPF_DRIVER -DVF_DRIVER -DINTEGRATED_VF -DX722_A0_SUPPORT 
> -DALLOW_EXPERIMENTAL_API  -MD -MQ 
> 'drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o' -MF 
> 'drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o.d' -o 
> 'drivers/a715181@@tmp_rte_pmd_i40e@sta/net_i40e_i40e_rxtx_vec_neon.c.o' -c 
> ../drivers/net/i40e/i40e_rxtx_vec_neon.c
> ../drivers/net/i40e/i40e_rxtx_vec_neon.c: In function ‘desc_to_olflags_v’:
> ../drivers/net/i40e/i40e_rxtx_vec_neon.c:142:31: warning: implicit 
> declaration of function ‘vqtbl1q_u8’; did you mean ‘vtbl1_u8’? 
> [-Wimplicit-function-declaration]
>   vlan0 = vreinterpretq_u32_u8(vqtbl1q_u8(vlan_flags,
>^~
>vtbl1_u8
> ../drivers/net/i40e/i40e_rxtx_vec_neon.c:142:31: error: incompatible type for 
> argument 1 of ‘vreinterpretq_u32_u8’
>   vlan0 = vreinterpretq_u32_u8(vqtbl1q_u8(vlan_flags,
>^~
>vreinterpretq_u8_u32(vlan1)));
> [...]
> ../drivers/net/i40e/i40e_rxtx_vec_neon.c: In function ‘_recv_raw_pkts_vec’:
> ../drivers/net/i40e/i40e_rxtx_vec_neon.c:320:11: error: incompatible types 
> when assigning to type ‘uint8x16_t’ from type ‘int’
>pkt_mb4 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[3]), shuf_msk);
>^
> ../drivers/net/i40e/i40e_rxtx_vec_neon.c:321:11: error: incompatible types 
> when assigning to type ‘uint8x16_t’ from type ‘int’
>pkt_mb3 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[2]), shuf_msk);
>^
> ../drivers/net/i40e/i40e_rxtx_vec_neon.c:351:11: error: incompatible types 
> when assigning to type ‘uint8x16_t’ from type ‘int’
>pkt_mb2 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[1]), shuf_msk);
>^
> ../drivers/net/i40e/i40e_rxtx_vec_neon.c:352:11: error: incompatible types 
> when assigning to type ‘uint8x16_t’ from type ‘int’
>pkt_mb1 = vqtbl1q_u8(vreinterpretq_u8_u64(descs[0]), shuf_msk);
>^
> ../drivers/net/i40e/i40e_rxtx_vec_neon.c:383:13: error: incompatible types 
> when assigning to type ‘uint8x16_t’ from type ‘int’
> eop_bits = vqtbl1q_u8(eop_bits, eop_shuf_mask);
>
>  ^
>
> --- end log extract ---
>
> Regards,
>
> Adam

Mh that looks familiar, I thought it was already fixed. I'll have a
look on Monday morning, and also see why the CI missed it.

Kind regards,
Luca Boccassi

Bug#934747: Info received ()

[حبیب بلوچ]

در تاریخ یکشنبه ۲۵ اکتبر ۲۰۲۰،‏ ۱۵:۵۷ Debian Bug Tracking System <
ow...@bugs.debian.org> نوشت:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Alessandro Ghedini 
>
> If you wish to submit further information on this problem, please
> send it to 934...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 934747: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934747
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#834724:

[حبیب بلوچ]

Bug#972862: swi-prolog: FTBFS with OpenSSL 1.1.1h

[Kurt Roeckx]

Package: swi-prolog
Version: 8.2.1+dfsg-2
Severity: serious

Hi,

swi-prolog fails to build using OpenSSL 1.1.1h. See
https://ci.debian.net/data/autopkgtest/testing/amd64/s/swi-prolog/7715788/log.gz
for a log.

I've filed an upstream bug about this at:
https://github.com/SWI-Prolog/packages-ssl/issues/158


Kurt

Bug#972556: ffmpeg: Fails to build from source with newer src:srt

[Sebastian Ramacher]

On 2020-10-20 12:08:01, John Paul Adrian Glaubitz wrote:
> On 10/20/20 12:05 PM, Sebastian Ramacher wrote:
> >> So, this patch and the patch from #968574 would be great!
> > 
> > Has the patch from #968574 been merged upstream in the meantime?
> 
> Apparently not. But merging won't break anything due to the #ifdef guards and 
> unbreaks ffmpeg
> on powerpc and ppc64 which is important due to the way Debian Ports works 
> with no support
> for cruft [1].

I'd be more comfortable with the patch if it was at least merged on
upstream's master branch.

Cheers

> 
> Adrian
> 
> > [1] https://lists.debian.org/debian-sparc/2017/12/msg00060.html
> 
> -- 
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#972865: opencfu fails tu start with " Gtk-ERROR **: GTK+ 2.x symbols detected"

[Wolf-Dieter Groll]

Package: opencfu
Version: 3.9.0-3
Severity: important

Dear Maintainer,

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

I installed the package as a possible solution to count nanoparticles on a SEM
image.

Trying to run the program results in the error-message:

(opencfu:13255): Gtk-ERROR **: 14:25:04.548: GTK+ 2.x symbols detected. Using
GTK+ 2.x and GTK+ 3 in the same process is not supported
Trace/Breakpoint ausgelöst

A Version compiled from the source (https://sourceforge.net/projects/opencfu/)
showed the same behaviour, so it doesn't seem to be a matter of dependencies.

I also looked in the unstable repositories, but the version in Sid seems to be
exactly the same as in Buster.



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

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

Versions of packages opencfu depends on:
ii  libatk1.0-0  2.30.0-2
ii  libatkmm-1.6-1v5 2.28.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcairomm-1.0-1v5   1.12.2-4
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u2
ii  libgcc1  1:8.3.0-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libglibmm-2.4-1v52.58.0-2
ii  libgomp1 8.3.0-6
ii  libgtk2.0-0  2.24.32-3
ii  libgtkmm-2.4-1v5 1:2.24.5-4
ii  libopencv-calib3d3.2 3.2.0+dfsg-6
ii  libopencv-contrib3.2 3.2.0+dfsg-6
ii  libopencv-core3.23.2.0+dfsg-6
ii  libopencv-features2d3.2  3.2.0+dfsg-6
ii  libopencv-flann3.2   3.2.0+dfsg-6
ii  libopencv-highgui3.2 3.2.0+dfsg-6
ii  libopencv-imgcodecs3.2   3.2.0+dfsg-6
ii  libopencv-imgproc3.2 3.2.0+dfsg-6
ii  libopencv-ml3.2  3.2.0+dfsg-6
ii  libopencv-objdetect3.2   3.2.0+dfsg-6
ii  libopencv-photo3.2   3.2.0+dfsg-6
ii  libopencv-shape3.2   3.2.0+dfsg-6
ii  libopencv-stitching3.2   3.2.0+dfsg-6
ii  libopencv-superres3.23.2.0+dfsg-6
ii  libopencv-video3.2   3.2.0+dfsg-6
ii  libopencv-videoio3.2 3.2.0+dfsg-6
ii  libopencv-videostab3.2   3.2.0+dfsg-6
ii  libopencv-viz3.2 3.2.0+dfsg-6
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpangoft2-1.0-01.42.4-8~deb10u1
ii  libpangomm-1.4-1v5   2.42.0-2
ii  libsigc++-2.0-0v52.10.1-2
ii  libstdc++6   8.3.0-6

opencfu recommends no packages.

opencfu suggests no packages.

-- no debconf information

Bug#972873: ITP: fdb -- FDB (Fields DataBase) is a domain-specific object store for storing, indexing and retrieving GRIB data.

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: fdb
  Version : 5.7.0
  Upstream Author : ECMWF (European Centre for Medium-Range Weather Forecasts)
* URL : http://github.com/ecmwf/fdb
* License : Apache 2
  Programming Lang: C++
  Description : FDB (Fields DataBase) is a domain-specific object store for 
storing, indexing and retrieving GRIB data.

FDB (Fields DataBase) is a domain-specific object store developed at ECMWF
for storing, indexing and retrieving GRIB data. Each GRIB message is stored as 
a field and indexed
trough semantic metadata (i.e. physical variables such as temperature, 
pressure, ...).
A set of fields can be retrieved specifying a request using a specific language 
developed for accessing MARS_ Archive

FDB exposes a C++ API as well as CLI tools_.
 
This is to be used by the rest of the ECMWF (European Centre for Medium-Range 
Weather Forecasts)
stack currently on Debian - Metview, etc.

Bug#972163: Rising severities

[Sylvestre Ledru]

Le 25/10/2020 à 18:54, Lisandro Damián Nicanor Pérez Meyer a écrit :

Hi Sylvestre!

On Sun, 25 Oct 2020 at 11:20, Lisandro Damián Nicanor Pérez Meyer
 wrote:

Hi!

El dom., 25 oct. 2020 11:07, Sylvestre Ledru  escribió:

Hello,

[snip]

I tried to upload it with your fix but the build failed for me.

If it works for you, please upload (without delay)

many thanks

tl;dr: I could build the package with just my changes, but only using
the uploaded debian source package.

# Building using the salsa repo

I cloned the repo and noticed that apart from the merge of the MR I
created there are other changes to the packaging. I tried building
master's HEAD but autoconf fails almost immediately. I'm afraid I
don't know a thing about it, so I switched to commit
673f53defb054873e40860ba11937860b3266863 (the one in which you accept
my MR) and the build failed with missing installation files more on
this below.
I then switched to tag 5.3.7-4 (which should be "the same thing" as
the last upload to the archive) and got the same error.

See buildlog.xz attached to this mail for the full build log of this
last two cases.

The builds where done in an schroot-managed chroot which is not
exactly clean: it also has git and a few more packages installed in
it, I normally use it for development.

# Building with the package uploaded to the archive

I then tried to build the latest uploaded version to the archive,
fwbuilder_5.3.7-4 using an sbuild chroot. It just went fine. I then
added my changes on top of it and the build succeeded again. So it's
either a difference in my build environment or the packaging and
what's in salsa.

In order to fix this bug I could upload an NMU containing just my
changes, but I don't think I'll be able to also add the ones you added
in the repo.


Please upload your version, it is fine :)

Thanks

S

Bug#972163: Rising severities

[Lisandro Damián Nicanor Pérez Meyer]

severity 972163 serious
severity 972166 serious
block 972176 by 972163
block 972176 by 972166
thanks

Hi! We are close to begin the Qt transition that will remove
qt5-default, so I'm raising the severities.  If everything goes well
I'll be NMUing your package today with an upload to delayed/5. Of
course feel free to ping me if needed.

Thanks, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#972868: xkcdpass: TAB-completion after --wordfile completes at directories

[Jonas Smedegaard]

Package: xkcdpass
Version: 1.16.5+dfsg.1-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

When in a bash shell typing "xkcdpass --wordfile /us" and hitting TAB,
it completes to "xkcdpass --wordfile /usr ".

I would expect it to instead expand to "xkcdpass --wordfile /usr/"
to indicate that files exist within that directory but (missing a space)
the expansion is incomplete because the option takes a file as argument.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl+VjKgACgkQLHwxRsGg
ASEcow//WXZdBBGB58+/li2XV2APtm9gf/9gFZYtMbZeLXDq2d9uKPO8qjvK5a7L
fgfsKagNOO569sXbrmXXrWUx3b1qXsnrwX/Se07R2nmIPG7A36kjvbezHqo3t12T
SoVrVfiIMmRtYxKvFdMsjzEpEAPDTjOLWN3rUbGKo8Sajf0Ba/xIw7ij7WNLVmgy
Ck9n4SZgHG4XHOglSCORlZP1hD4M06gzZaPhhRvGKz7EjQWPFZPeG0TO5p/luTsN
+y+srIwTPCEt21KWloe93ZpBG1WzvyUEepU1GsW248k6GUTOexCMwdlfIcOxibqb
QJogpuzAvledf/JFEw5hppS4o1sOVQghg3kCuXbWD2JYLNLtSWuTzIHvzcto7Q/z
VkDoNavChXmaEtHXWJ0TgxsjHyUdZOJTzwNZ+vM+C9RQ2dIFc4gTE6eznhzGRR7/
Yng21/Q1By4KNt6h3p8gfFLhV3SZo4gml6uu+L5JBliifpufYkmygRjyEu/lCexr
kAJxGF6vLjFW3nBJKBgZmw55WnZi3bYlsW5ABbgqNPLj2WsBHeqbLDP7qlAC023b
v4YlIbaxMPTuU4WZLgId9S2YL/tj10a2xYuCE8bapmMKVgb3pmctxc8FfODI5wFO
t+sO1FQEeM0YyJKtMynbkiNI/EuHnJEQy8FKNRDDRMQ8dONULEE=
=Gc4q
-END PGP SIGNATURE-

Bug#972874: django-ldapdb 1.5.1-1 fails its autopkgtest

[Ryan Tandy]

Source: django-ldapdb
Version: 1.5.1-1
Severity: serious

Dear Maintainer,

The autopkgtest of django-ldapdb 1.5.1-1 fails in testing and unstable.

https://ci.debian.net/data/autopkgtest/testing/amd64/d/django-ldapdb/7719338/log.gz


django.core.exceptions.ImproperlyConfigured: Requested setting INSTALLED_APPS, 
but settings are not configured. You must either define the environment 
variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing 
settings.


I see the same failure in a pure unstable chroot without any packages from 
testing.

Could you please take a look? This is blocking openldap from migrating to 
testing. (https://qa.debian.org/excuses.php?package=openldap)

Thank you,
Ryan

Bug#972305: catch2: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath

[Mathieu Mirmont]

control: tag -1 confirmed
control: tag -1 pending

On Thu, Oct 15, 2020 at 05:08:09PM -0700, Vagrant Cascadian wrote:

The attached patch works around this issue by disabling the fixfilepath
feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath. 


Thanks, I'm applying it and releasing. I've been scratching my head
about this FTBFS but never had the time to get to the bottom of it. 

Cheers, 


--
Mathieu Mirmont 


signature.asc
Description: PGP signature

Bug#958454: From a minimum installation of Sid, metapackage Cinnamon installs neither X nor a login manager

[Fabio Fantoni]

@Daniel Tourde: 'apt install cinnamon' don't install the meta packages
but only the main component and its deps.
For install the meta packages that include login manager as recommends
(that are installed by default) you need install cinnamon-core or for a
additional software for a full desktop use cinnamon-desktop-environment
(same used by tasksel, or simply install cinnamon using tasksel that
include also task-desktop).
When cinnamon was added also in DE selection in debian install I tested
it and was ok, on 4.6 (and probably also 4.4, I not remember good) I not
tested clean install of debian with cinnamon but only upgrade on
existant Sid installation, if for unexpected case something important is
missed please tell me it.

Bug#972879: tor: fail to start if the ipv6 addr is not yet assigned

[Domenico Andreoli]

Package: tor

A friend of mine has a relay that receives the ipv6 address from the
router but needs to specify it in the torrc file, they are not aware
of any other way of configuring an ipv6 relay.

There is a window of time during boot when the ipv6 address is not
assigned yet, if tor is started in such window it then fails to bind
to the configured ipv6 address and the execution is aborted.

Almost every time they reboot the relay they then need to restart the
tor daemon manually in order to bind and announce properly on the net.

It should be possible to configure systemd so that the tor daemon is
started only after the ipv6 address has been assigned.

-- 
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05

Bug#972844: lintian: E: musescore2 source: malformed-override Unknown tag testsuite-autopkgtest-missing in line 5

[Thorsten Glaser]

Felix Lechner dixit:

>We are unsure about the last bug, especially because you did not
>report it in unstable (and it would have been hard to miss). The Perl

Ehm, but I’m running unstable and reported it against the version
in unstable. (I was actually seeing this in a cowbuilder buildd
chroot.)

bye,
//mirabilos

Bug#972177: zeal: FTBFS with Qt 5.15: error: aggregate 'QPainterPath path' has incomplete type and cannot be defined

[Dmitry Shachnev]

Control: tags -1 + pending

On Tue, Oct 13, 2020 at 08:44:41PM +0300, Dmitry Shachnev wrote:
> Dear Maintainer,
>
> zeal fails to build with Qt 5.15, currently available in experimental:
>
>   /build/zeal-0.6.1/src/libs/ui/searchitemdelegate.cpp: In member function 
> 'virtual void Zeal::WidgetUi::SearchItemDelegate::paint(QPainter*, const 
> QStyleOptionViewItem&, const QModelIndex&) const':
>   [...]
>   /build/zeal-0.6.1/src/libs/ui/searchitemdelegate.cpp:143:26: error: 
> aggregate 'QPainterPath path' has incomplete type and cannot be defined
> 143 | QPainterPath path;
> |  ^~~~
>
> The full build log is attached.

I have just uploaded the NMU fixing this to DELAYED/5.

The debdiff is attached, and I have also pushed the change to salsa.

--
Dmitry Shachnev
diff -Nru zeal-0.6.1/debian/changelog zeal-0.6.1/debian/changelog
--- zeal-0.6.1/debian/changelog	2018-10-31 09:44:09.0 +0300
+++ zeal-0.6.1/debian/changelog	2020-10-25 13:29:32.0 +0300
@@ -1,3 +1,10 @@
+zeal (1:0.6.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream patch to fix build with Qt 5.15 (closes: #972177).
+
+ -- Dmitry Shachnev   Sun, 25 Oct 2020 13:29:32 +0300
+
 zeal (1:0.6.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru zeal-0.6.1/debian/patches/0002-Fix-compilation-error-with-Qt-5.15.patch zeal-0.6.1/debian/patches/0002-Fix-compilation-error-with-Qt-5.15.patch
--- zeal-0.6.1/debian/patches/0002-Fix-compilation-error-with-Qt-5.15.patch	1970-01-01 03:00:00.0 +0300
+++ zeal-0.6.1/debian/patches/0002-Fix-compilation-error-with-Qt-5.15.patch	2020-10-25 13:29:32.0 +0300
@@ -0,0 +1,21 @@
+From: Dmitry Atamanov 
+Date: Sun, 26 Apr 2020 02:26:53 +0500
+Subject: fix(ui): fix compilation error with Qt 5.15 (#1218)
+
+(cherry picked from commit 064aaa05d6a3ba4ba3cf648199a3109aba2f41fe)
+---
+ src/libs/ui/searchitemdelegate.cpp | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/libs/ui/searchitemdelegate.cpp b/src/libs/ui/searchitemdelegate.cpp
+index 4bd6d0a..d8ad79b 100644
+--- a/src/libs/ui/searchitemdelegate.cpp
 b/src/libs/ui/searchitemdelegate.cpp
+@@ -27,6 +27,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ 
+ using namespace Zeal::WidgetUi;
diff -Nru zeal-0.6.1/debian/patches/series zeal-0.6.1/debian/patches/series
--- zeal-0.6.1/debian/patches/series	2018-10-12 13:20:53.0 +0300
+++ zeal-0.6.1/debian/patches/series	2020-10-25 13:29:32.0 +0300
@@ -1 +1,2 @@
 0001-Disable-ad-by-default.patch
+0002-Fix-compilation-error-with-Qt-5.15.patch


signature.asc
Description: PGP signature

Bug#972676: dde-qt5integration: FTBFS with Qt 5.15: error: aggregate ‘QPainterPath path’ has incomplete type and cannot be defined

[Dmitry Shachnev]

Control: tags -1 + pending

On Thu, Oct 22, 2020 at 01:55:09PM +0300, Dmitry Shachnev wrote:
> Dear Maintainer,
>
> dde-qt5integration fails to build with Qt 5.15, currently available in
> experimental.
>
> After rebuilding dde-qt-dbus-factory, dtkcore and libqtxdg, and building a
> fixed version of dtkwidget (see #972155), I get this error:
>
>   pushbuttonhelper.cpp: In member function ‘bool 
> dstyle::Style::drawPushButtonFrame(QPainter*, const QRect&, const QBrush&, 
> const QBrush&, const QColor&, const QWidget*) const’:
>   pushbuttonhelper.cpp:221:18: error: aggregate ‘QPainterPath path’ has 
> incomplete type and cannot be defined
> 221 | QPainterPath path;
> |  ^~~~
>   pushbuttonhelper.cpp:231:26: error: aggregate ‘QPainterPath rightHalf’ has 
> incomplete type and cannot be defined
> 231 | QPainterPath rightHalf;
> |  ^
>   pushbuttonhelper.cpp:235:26: error: aggregate ‘QPainterPath leftHalf’ has 
> incomplete type and cannot be defined
> 235 | QPainterPath leftHalf;
> |  ^~~~
>
> This is fixed upstream, see the linked pull request.

I have just uploaded the NMU fixing this to DELAYED/5.

The debdiff is attached.

This change is also available in qt-5.15 branch on my fork on salsa:
https://salsa.debian.org/mitya57/dde-qt5integration/-/commits/qt-5.15

(I couldn't make a merge request because there is no branch for unstable
version.)

--
Dmitry Shachnev
diff -Nru dde-qt5integration-5.0.0/debian/changelog dde-qt5integration-5.0.0/debian/changelog
--- dde-qt5integration-5.0.0/debian/changelog	2020-06-06 18:27:34.0 +0300
+++ dde-qt5integration-5.0.0/debian/changelog	2020-10-25 13:21:15.0 +0300
@@ -1,3 +1,10 @@
+dde-qt5integration (5.0.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream patch to fix build with Qt 5.15 (closes: #972676).
+
+ -- Dmitry Shachnev   Sun, 25 Oct 2020 13:21:15 +0300
+
 dde-qt5integration (5.0.0-2) unstable; urgency=medium
 
   [ Dmitry Shachnev ]
diff -Nru dde-qt5integration-5.0.0/debian/patches/qt-5.15.patch dde-qt5integration-5.0.0/debian/patches/qt-5.15.patch
--- dde-qt5integration-5.0.0/debian/patches/qt-5.15.patch	1970-01-01 03:00:00.0 +0300
+++ dde-qt5integration-5.0.0/debian/patches/qt-5.15.patch	2020-10-25 13:21:15.0 +0300
@@ -0,0 +1,60 @@
+From: Felix Yan 
+Date: Thu, 11 Jun 2020 16:19:53 +0800
+Subject: Fix build failures under Qt 5.15+
+
+(cherry picked from commit 5d2fbe972f495ec5ddadf9062612e042cf0ea07a)
+---
+ dstyleplugin/painterhelper.cpp| 1 +
+ dstyleplugin/pushbuttonhelper.cpp | 1 +
+ dstyleplugin/tabbarhelper.cpp | 1 +
+ dstyleplugin/tabwidgethelper.cpp  | 1 +
+ 4 files changed, 4 insertions(+)
+
+diff --git a/dstyleplugin/painterhelper.cpp b/dstyleplugin/painterhelper.cpp
+index 3db216d..66d548f 100644
+--- a/dstyleplugin/painterhelper.cpp
 b/dstyleplugin/painterhelper.cpp
+@@ -18,6 +18,7 @@
+ #include "painterhelper.h"
+ 
+ #include 
++#include 
+ #include 
+ 
+ namespace dstyle {
+diff --git a/dstyleplugin/pushbuttonhelper.cpp b/dstyleplugin/pushbuttonhelper.cpp
+index 8069070..168b009 100644
+--- a/dstyleplugin/pushbuttonhelper.cpp
 b/dstyleplugin/pushbuttonhelper.cpp
+@@ -30,6 +30,7 @@
+ 
+ #include 
+ #include 
++#include 
+ 
+ DWIDGET_USE_NAMESPACE
+ 
+diff --git a/dstyleplugin/tabbarhelper.cpp b/dstyleplugin/tabbarhelper.cpp
+index 51f677b..e0ef36c 100644
+--- a/dstyleplugin/tabbarhelper.cpp
 b/dstyleplugin/tabbarhelper.cpp
+@@ -33,6 +33,7 @@ DWIDGET_USE_NAMESPACE
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+diff --git a/dstyleplugin/tabwidgethelper.cpp b/dstyleplugin/tabwidgethelper.cpp
+index a2b6756..f51d43d 100644
+--- a/dstyleplugin/tabwidgethelper.cpp
 b/dstyleplugin/tabwidgethelper.cpp
+@@ -20,6 +20,7 @@
+ #include "painterhelper.h"
+ 
+ #include 
++#include 
+ #include 
+ #include 
+ 
diff -Nru dde-qt5integration-5.0.0/debian/patches/series dde-qt5integration-5.0.0/debian/patches/series
--- dde-qt5integration-5.0.0/debian/patches/series	2020-06-06 18:27:34.0 +0300
+++ dde-qt5integration-5.0.0/debian/patches/series	2020-10-25 13:21:15.0 +0300
@@ -1 +1,2 @@
 qt-5.14.patch
+qt-5.15.patch


signature.asc
Description: PGP signature

Bug#969529: libxml2: diff for NMU version 2.9.10+dfsg-6.2

[Salvatore Bonaccorso]

Control: tags 969529 + patch
Control: tags 969529 + pending


Dear maintainer,

I've prepared an NMU for libxml2 (versioned as 2.9.10+dfsg-6.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Additionally to the attached debdiff prepared merge request is at
https://salsa.debian.org/xml-sgml-team/libxml2/-/merge_requests/5

Regards,
Salvatore
diff -Nru libxml2-2.9.10+dfsg/debian/changelog libxml2-2.9.10+dfsg/debian/changelog
--- libxml2-2.9.10+dfsg/debian/changelog	2020-10-14 08:45:25.0 +0200
+++ libxml2-2.9.10+dfsg/debian/changelog	2020-10-25 13:56:23.0 +0100
@@ -1,3 +1,11 @@
+libxml2 (2.9.10+dfsg-6.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix out-of-bounds read with 'xmllint --htmlout' (CVE-2020-24977)
+(Closes: #969529)
+
+ -- Salvatore Bonaccorso   Sun, 25 Oct 2020 13:56:23 +0100
+
 libxml2 (2.9.10+dfsg-6.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libxml2-2.9.10+dfsg/debian/patches/Fix-out-of-bounds-read-with-xmllint-htmlout.patch libxml2-2.9.10+dfsg/debian/patches/Fix-out-of-bounds-read-with-xmllint-htmlout.patch
--- libxml2-2.9.10+dfsg/debian/patches/Fix-out-of-bounds-read-with-xmllint-htmlout.patch	1970-01-01 01:00:00.0 +0100
+++ libxml2-2.9.10+dfsg/debian/patches/Fix-out-of-bounds-read-with-xmllint-htmlout.patch	2020-10-25 13:56:23.0 +0100
@@ -0,0 +1,39 @@
+From: Nick Wellnhofer 
+Date: Fri, 7 Aug 2020 21:54:27 +0200
+Subject: Fix out-of-bounds read with 'xmllint --htmlout'
+Origin: https://gitlab.gnome.org/GNOME/libxml2/-/commit/50f06b3efb638efb0abd95dc62dca05ae67882c2
+Bug: https://gitlab.gnome.org/GNOME/libxml2/-/issues/178
+Bug-Debian: https://bugs.debian.org/969529
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2020-24977
+
+Make sure that truncated UTF-8 sequences don't cause an out-of-bounds
+array access.
+
+Thanks to @SuhwanSong and the Agency for Defense Development (ADD) for
+the report.
+
+Fixes #178.
+---
+ xmllint.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/xmllint.c b/xmllint.c
+index f6a8e463639a..c647486f39b4 100644
+--- a/xmllint.c
 b/xmllint.c
+@@ -528,6 +528,12 @@ static void
+ xmlHTMLEncodeSend(void) {
+ char *result;
+ 
++/*
++ * xmlEncodeEntitiesReentrant assumes valid UTF-8, but the buffer might
++ * end with a truncated UTF-8 sequence. This is a hack to at least avoid
++ * an out-of-bounds read.
++ */
++memset([sizeof(buffer)-4], 0, 4);
+ result = (char *) xmlEncodeEntitiesReentrant(NULL, BAD_CAST buffer);
+ if (result) {
+ 	xmlGenericError(xmlGenericErrorContext, "%s", result);
+-- 
+2.28.0
+
diff -Nru libxml2-2.9.10+dfsg/debian/patches/series libxml2-2.9.10+dfsg/debian/patches/series
--- libxml2-2.9.10+dfsg/debian/patches/series	2020-10-13 09:39:13.0 +0200
+++ libxml2-2.9.10+dfsg/debian/patches/series	2020-10-25 13:56:23.0 +0100
@@ -4,3 +4,4 @@
 Fix-freeing-of-nested-documents.patch
 python3-unicode-errors.patch
 parenthesize-type-checks.patch
+Fix-out-of-bounds-read-with-xmllint-htmlout.patch

Bug#972862: swi-prolog: FTBFS with OpenSSL 1.1.1h

[Lev Lamberov]

Hi Kurt,

Вс 25 окт 2020 @ 13:30 Kurt Roeckx :

> Package: swi-prolog
> Version: 8.2.1+dfsg-2
> Severity: serious
>
> Hi,
>
> swi-prolog fails to build using OpenSSL 1.1.1h. See
> https://ci.debian.net/data/autopkgtest/testing/amd64/s/swi-prolog/7715788/log.gz
> for a log.
>
> I've filed an upstream bug about this at:
> https://github.com/SWI-Prolog/packages-ssl/issues/158

Thanks for your report and for submitting it upstream too.

Cheers!
Lev

Bug#972870: Should libhal1-flash be shipped in bullseye?

[Adrian Bunk]

Package: libhal1-flash
Version: 0.3.3-3
Severity: serious
Tags: bullseye sid

This package was needed for older versions of Flash,
which itself is both EOL before the release of bullseye
and already no longer supported by any major browser.

Bug#972429: djview4: djview4 as a server

[Janusz S. Bień]

The problem is solved:

https://github.com/andy-portmen/external-application-button/issues/50

The question is only how to distribute it in Debian.

Regards

Janusz

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#972429: djview4: djview4 as a server

[Janusz S. Bień]

On Sun, Oct 25 2020 at 15:27 +00, Barak A. Pearlmutter wrote:
> That's great. If the extension is in Debian, than djview4 could
> "Suggest:" it. Or maybe would could just put appropriate instructions
> in /usr/share/doc/djview4/README.Debian, if you have wording for such
> a paragraph I'm happy to slip it in.

I think the extension is worth a separate package in Debian, but for
djview for a configuration file is needed (cf. the end of the issue
thread). I think it can be distributed with djview, but perhaps you will
ask the author of the extension for an advice?

Regards

Janusz

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#972788: openjdk-11-jre-dcevm: incompatible with openjdk-11-jre 11.0.9

[tony mancill]

On Fri, Oct 23, 2020 at 05:21:00PM +0200, Michael Meier wrote:
> Package: openjdk-11-jre-dcevm
> Version: 11.0.7+1-1
> Severity: normal
> X-Debbugs-Cc: schissdra...@rmm.li
> 
> my system just upgraded to openjdk-11-jre 11.0.9.
> when starting up java with dcevm support you get following error:
> java --version -dcevm
> Error occurred during initialization of VM
> Unable to load native library: /usr/lib/jvm/java-11-openjdk-
> amd64/lib/libjava.so: undefined symbol: JVM_IsUseContainerSupport, version
> SUNWprivate_1.1
> 
> Downgrading openjdk-11-jre to 11.0.8 makes it work again.
> 
> So the dcevm package is broken (again) for newer java versions.

Thank you for the bug report.

I just uploaded a new upstream version, 11.0.9+1, which will prevent
users from having to downgrade.  I feel like this was warranted given
the CVEs addressed in JDK 11.0.9.  However, there is a more general
issue of dependency version testing (and maybe pinning).  At a minimum,
we can add an autopkgtest to instantiate a JVM with the -dcevm option.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#969114: apparmor-profiles: usr.sbin.dovecot does not allow reading /usr/share/dovecot/dh.pem (dovecot fails to start)

[Vincas Dargis]

I think it's for upstream. There's more rules to add too. I'll try to work on 
that.

On 2020-10-24 16:05, intrigeri wrote:

Hi Vincas!

Vincas Dargis (2020-08-27):

This is produced if usr.sbin.dovecot is copied to /etc/apparmor.d:

```
type=AVC msg=audit(1598556536.092:901): apparmor="DENIED" operation="open" profile="dovecot" 
name="/usr/share/dovecot/dh.pem" pid=12625 comm="doveconf" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
```

This results in dovecot failing to start:

```
Aug 27 22:31:47 systemd[1]: Started Dovecot IMAP/POP3 email server.
Aug 27 22:31:47 dovecot[13693]: doveconf: Fatal: Error in configuration file 
/etc/dovecot/conf.d/10-ssl.conf line 50: ssl_dh: Can't open file /usr/share/dove
Aug 27 22:31:47 systemd[1]: dovecot.service: Main process exited, code=exited, 
status=89/n/a
Aug 27 22:31:47 systemd[1]: dovecot.service: Failed with result 'exit-code'.
```

It is fixed by adding single rule:

```
/usr/share/dovecot/dh.pem r,
```


Do you think it's too Debian-specific to fix upstream?

Cheers!

Bug#970606: [Openjdk] Bug#970606: Bug#970606: Bug#970606: Bug#970606: src:openjdk-*: autopkgtest times out on Debian/Ubuntu infrastructure

[Matthias Klose]

On 10/25/20 12:22 PM, Matthias Klose wrote:
> On 10/24/20 10:18 PM, Paul Gevers wrote:
>> Hi Matthias
>>
>> On 23-10-2020 13:31, Matthias Klose wrote:
>>> On 10/7/20 10:33 PM, Paul Gevers wrote:
 Hi Matthias,

 On 21-09-2020 17:52, Paul Gevers wrote:
>> Apparently
>> the very same tests don't time out on the buildds.
>
> I don't know what timeouts apply to buildds, but indeed I think they are
> much higher to cope with *building* some extremely big packages.

 Do you know how much time these tests would take? If so, I wonder if we
 should make it possible for individual packages to have a longer
 timeout. It would be work on the debci/ci.d.n side of things, but not
 impossible of course.
>>>
>>> For an upper bound, use the build time: The very same tests are run during 
>>> the
>>> build.
>>
>> Ack. Side note: I see a hell load of errors and failures in the build
>> log, is that expected? And some builds took more than a day, is that
>> reasonable to do for these tests (if they're ignored anyways, your tests
>> are marked flaky)?
>>
>>> The other question is, if it's sensible to run the upstream test suite as an
>>> autopkg test, if it's already run during the build.  Ideally it should only 
>>> run
>>> the autopkg tests which test on integration issues with run time 
>>> dependencies,
>>> but this would require analyzing some 1 tests and
>>>
>>> For now I just disabled the jdk tests as an autopkg test. So please clear 
>>> the
>>> test results, to run it again, and let it migrate.
>>
>> Also the hotpot test times out, so only having the jdk tests disabled
>> doesn't really help at this stage.
> 
> where can I see this?
> https://ci.debian.net/data/autopkgtest/testing/amd64/o/openjdk-15/7738063/log.gz
> doesn't point to anywhere

instead I see
https://ci.debian.net/data/autopkgtest/unstable/amd64/o/openjdk-15/7725394/log.gz
which doesn't look like a timeout.

> and it doesn't really help to not let openjdk-15 migrate, so that we finally 
> can
> remove openjdk-14.

Bug#972831: tar: produces incorrect TAR+zstd archive when creating archive remotely

[Laurent Bonnaud]

On 10/24/20 6:22 PM, Bdale Garbee wrote:


I took a quick look and the problem is with the use of localhost: in
the filename,


Thanks for checking!  In fact the problem also exists for remote hosts.


it appears to be unrelated to the compression algorithm chosen.


With xz I can create correct archives on remote hosts.

--
Laurent.

Bug#834724: Info received ()

[حبیب بلوچ]

در تاریخ یکشنبه ۲۵ اکتبر ۲۰۲۰،‏ ۱۶:۰۳ Debian Bug Tracking System <
ow...@bugs.debian.org> نوشت:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Alessandro Ghedini 
>
> If you wish to submit further information on this problem, please
> send it to 834...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 834724: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834724
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#972864: qemu: CVE-2020-27661: divide by zero in dwc2_handle_packet() in hw/usb/hcd-dwc2.c

[Salvatore Bonaccorso]

Source: qemu
Version: 1:5.1+dfsg-4
Severity: important
Tags: security upstream
Forwarded: 
https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg04263.html
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for qemu.

CVE-2020-27661[0]:
| divide by zero in dwc2_handle_packet() in hw/usb/hcd-dwc2.c

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-27661
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27661
[1] https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg04263.html
[2] 
https://git.qemu.org/?p=qemu.git;a=commit;h=bea2a9e3e00b275dc40cfa09c760c715b8753e03

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#972867: gdcm: FTBFS in testing and unstable

[Graham Inggs]

Source: gdcm
Version: 3.0.7-3
Severity: serious
Tags: ftbfs bullseye sid


Hi Maintainer

As per reproducible builds [1], gdcm recently started failing to build
in testing and unstable.

I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gdcm.html


/usr/bin/c++ -DgdcmMSFF_EXPORTS -I../Source/Common -ISource/Common
-I../Source/DataStructureAndEncodingDefinition
-I../Source/DataDictionary -I../Source/InformationObjectDefinition
-I../Source/MediaStorageAndFileFormat -I../Utilities -IUtilities
-I/usr/include/openjpeg-2.3 -I/usr/include/json-c -I/usr/include/json
-g -O2 -ffile-prefix-map=/build/1st/gdcm-3.0.7=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -fPIC -DCHARLS_DLL -MD -MT
Source/MediaStorageAndFileFormat/CMakeFiles/gdcmMSFF.dir/gdcmJPEGLSCodec.cxx.o
-MF 
Source/MediaStorageAndFileFormat/CMakeFiles/gdcmMSFF.dir/gdcmJPEGLSCodec.cxx.o.d
-o 
Source/MediaStorageAndFileFormat/CMakeFiles/gdcmMSFF.dir/gdcmJPEGLSCodec.cxx.o
-c ../Source/MediaStorageAndFileFormat/gdcmJPEGLSCodec.cxx
In file included from
../Source/MediaStorageAndFileFormat/gdcmJPEGLSCodec.cxx:24:
../Utilities/gdcm_charls.h:21:11: fatal error: CharLS/charls.h: No
such file or directory
   21 | # include 
  |   ^
compilation terminated.

Bug#972429: djview4: djview4 as a server

[Barak A. Pearlmutter]

That's great. If the extension is in Debian, than djview4 could
"Suggest:" it. Or maybe would could just put appropriate instructions
in /usr/share/doc/djview4/README.Debian, if you have wording for such
a paragraph I'm happy to slip it in.

Cheers,

--Barak.

Bug#972785: zeromq3: Include cmake files for cppzmq

[GCS]

On Fri, Oct 23, 2020 at 4:57 PM Gordon Ball  wrote:
> src:zeromq3 and libzmq3-dev currently embed headers from the separate
> cppzmq repository. However, the associated cmake files are not included,
> which means when trying to build downstream projects which use cppzmq
> and cmake, it's necessary to hack the buildsystem or embed the cmake
> files from cppzmq.
 These are different projects and should be packaged differently. As
czmq is packaged by Luca, I think cppzmq should be packaged by him as
well. But let's hear what he says.

Regards,
Laszlo/GCS

Bug#972867: CharLS should have changed its SOVERSION

[Mathieu Malaterre]

Control: tags -1 upstream

For details:

https://github.com/team-charls/charls/issues/81

Bug#972883: apparmor-profiles: dovecot needs usr.lib.dovecot.script-login profile

[Vincas Dargis]

Package: apparmor-profiles
Version: 2.13.2-10
Severity: normal
Tags: upstream

Dear Maintainer,

Debian Buster,Bullseye needs usr.lib.dovecot.script-login, which was addred not
long ago [0].

I'll work for backport to AppArmor 2.13.


[0]
https://gitlab.com/apparmor/apparmor/-/commit/6e59f454b136c4103e5b37e125715dfa8ba7b0bd

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

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

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


-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

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

Versions of packages apparmor-profiles depends on:
ii  apparmor  2.13.2-10

apparmor-profiles recommends no packages.

apparmor-profiles suggests no packages.

-- Configuration Files:
/etc/apparmor.d/bin.ping changed [not included]
/etc/apparmor.d/sbin.klogd changed [not included]
/etc/apparmor.d/sbin.syslog-ng changed [not included]
/etc/apparmor.d/sbin.syslogd changed [not included]
/etc/apparmor.d/usr.sbin.avahi-daemon changed [not included]
/etc/apparmor.d/usr.sbin.dnsmasq changed [not included]
/etc/apparmor.d/usr.sbin.identd changed [not included]
/etc/apparmor.d/usr.sbin.mdnsd changed [not included]
/etc/apparmor.d/usr.sbin.nmbd changed [not included]
/etc/apparmor.d/usr.sbin.nscd changed [not included]
/etc/apparmor.d/usr.sbin.smbd changed [not included]
/etc/apparmor.d/usr.sbin.smbldap-useradd changed [not included]
/etc/apparmor.d/usr.sbin.traceroute changed [not included]

-- no debconf information

Bug#972884: apparmor-profiles: usr.lib.dovecot.stats profile is needed

[Vincas Dargis]

Package: apparmor-profiles
Version: 2.13.2-10
Severity: normal

Dear Maintainer,

AppArmor 2.13.3 got usr.lib.dovecot.stats profile:
https://gitlab.com/apparmor/apparmor/-/commit/36bdd6ea7011455f94106e6ea6d4aad626863815

To make dovecot work on Debian Buster, I need to modify
`/etc/apparmor.d/local/usr.sbin.dovecot` file to add:
```
/usr/lib/dovecot/stats Px,
```
and of course add missing profile.

Is it possible to get this fix for.. stable release?

-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

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

Versions of packages apparmor-profiles depends on:
ii  apparmor  2.13.2-10

apparmor-profiles recommends no packages.

apparmor-profiles suggests no packages.

-- Configuration Files:
/etc/apparmor.d/bin.ping changed [not included]
/etc/apparmor.d/sbin.klogd changed [not included]
/etc/apparmor.d/sbin.syslog-ng changed [not included]
/etc/apparmor.d/sbin.syslogd changed [not included]
/etc/apparmor.d/usr.sbin.avahi-daemon changed [not included]
/etc/apparmor.d/usr.sbin.dnsmasq changed [not included]
/etc/apparmor.d/usr.sbin.identd changed [not included]
/etc/apparmor.d/usr.sbin.mdnsd changed [not included]
/etc/apparmor.d/usr.sbin.nmbd changed [not included]
/etc/apparmor.d/usr.sbin.nscd changed [not included]
/etc/apparmor.d/usr.sbin.smbd changed [not included]
/etc/apparmor.d/usr.sbin.smbldap-useradd changed [not included]
/etc/apparmor.d/usr.sbin.traceroute changed [not included]

-- no debconf information

Bug#970606: [Openjdk] Bug#970606: Bug#970606: Bug#970606: src:openjdk-*: autopkgtest times out on Debian/Ubuntu infrastructure

[Matthias Klose]

On 10/24/20 10:18 PM, Paul Gevers wrote:
> Hi Matthias
> 
> On 23-10-2020 13:31, Matthias Klose wrote:
>> On 10/7/20 10:33 PM, Paul Gevers wrote:
>>> Hi Matthias,
>>>
>>> On 21-09-2020 17:52, Paul Gevers wrote:
> Apparently
> the very same tests don't time out on the buildds.

 I don't know what timeouts apply to buildds, but indeed I think they are
 much higher to cope with *building* some extremely big packages.
>>>
>>> Do you know how much time these tests would take? If so, I wonder if we
>>> should make it possible for individual packages to have a longer
>>> timeout. It would be work on the debci/ci.d.n side of things, but not
>>> impossible of course.
>>
>> For an upper bound, use the build time: The very same tests are run during 
>> the
>> build.
> 
> Ack. Side note: I see a hell load of errors and failures in the build
> log, is that expected? And some builds took more than a day, is that
> reasonable to do for these tests (if they're ignored anyways, your tests
> are marked flaky)?
> 
>> The other question is, if it's sensible to run the upstream test suite as an
>> autopkg test, if it's already run during the build.  Ideally it should only 
>> run
>> the autopkg tests which test on integration issues with run time 
>> dependencies,
>> but this would require analyzing some 1 tests and
>>
>> For now I just disabled the jdk tests as an autopkg test. So please clear the
>> test results, to run it again, and let it migrate.
> 
> Also the hotpot test times out, so only having the jdk tests disabled
> doesn't really help at this stage.

where can I see this?
https://ci.debian.net/data/autopkgtest/testing/amd64/o/openjdk-15/7738063/log.gz
doesn't point to anywhere

and it doesn't really help to not let openjdk-15 migrate, so that we finally can
remove openjdk-14.

Matthias

Bug#972427: mbuffer: no need to look for target build tools

[Peter Pentchev]

Hi,

Thanks a lot for your continuing work on mbuffer!

What do you think about the attached trivial patch that makes mbuffer
consistently look for host tools, not target tools, when
cross-compiling? It was brought to my attention by Helmut Grohne, who
does a lot of work on cross-building Debian packages, in a Debian bug:
https://bugs.debian.org/972427

As far as I understand the difference between build, host, and target
architectures in the GNU autotools paradigm, if an object file that was
built for the host system needs to be examined, the host version of
objdump should be used, just as the host version of the compiler was
used to generate it. Of course, it is possible that we could be missing
some specific reason that you chose to look for a target tool.

Thanks in advance and keep up the great work!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
Description: Unbreak cross-compilation: we do not need target tools.
Forwarded: no
Author: Helmut Grohne 
Bug-Debian: https://bugs.debian.org/972427
Last-Update: 2020-10-25

--- a/configure.in
+++ b/configure.in
@@ -113,7 +113,7 @@
 AC_SYS_LARGEFILE
 AC_STRUCT_ST_BLKSIZE
 
-AC_CHECK_TARGET_TOOLS(OBJDUMP,gobjdump objdump)
+AC_CHECK_TOOLS(OBJDUMP,gobjdump objdump)
 
 AC_HEADER_ASSERT
 AC_CHECK_LIB(pthread, pthread_mutex_init)


signature.asc
Description: PGP signature

Bug#972866: xkcdpass: man page documents non-working option --valid_chars

[Jonas Smedegaard]

Package: xkcdpass
Version: 1.16.5+dfsg.1-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

manpage for xkcdpass documents an option --valid_chars, but that fails.

Instead, option --valid-chars works.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl+VirUACgkQLHwxRsGg
ASEzsg//YA3zma4CNJaJIFXuC+QKQtaWv1X3gBcJ5n3k3Pt01DT+sWD8Dt8lNB39
0ScritVXlHxrifOR4BFYFmtuZtOW6uSKQyhJgXWosGiOpEpeH6CzsmIUuivuXTed
q/F5C9d73Ab2/96NS5ksOhVHXv/A1AjAfhE1o5nmeQOJKPCYcG4TUtZb8ubVSH0C
hFnXOWvd5r1oUtu2ZUf72jho0P1jof6M2D7d8ehzV3TRfaJv7cXJ404H47IPw2/o
7aij2xllg373gr5Mxck8M67pKVSdl8dy2HN3m6RWec8OJOHvRHgLeVAwQ/c2H9z5
SDAPZG2sUDU4gfny0ea05cmJ8l+ONglFljBxUuTPUmsCGCZ1q22S7Esmx0lrATHT
rHWt8tkWzurV6ce+NIfmkJ3hAlLw9ON4itWABEQzMKGxrfiznl8Ur/DeErExuwVD
TV8DORfS4IrHdT5k+QOuE8A6iSYWZsRBN5NoAZktNtbSK0F+OWjIPn113LzcS7Xn
lT/WF3ILyj6OZ8KJzZWo4iF8meBVn9batQs2HOoi6hUu4Y/4Sx/zxlE2A0PAMfKb
po51S5puGr/6kj7hdBhxoosqrDKfIZUALDgMdX9CbPZ3o1EI0+xPeI9hmWGGYGe+
aBSFMAk9HqRLwWPLEJrQmMpu3zHmgjU8Sjs/26HHcQu0jKrAx4Y=
=x6F0
-END PGP SIGNATURE-

Bug#972556: ffmpeg: Fails to build from source with newer src:srt

[John Paul Adrian Glaubitz]

On 10/25/20 3:04 PM, Sebastian Ramacher wrote:
> I'd be more comfortable with the patch if it was at least merged on
> upstream's master branch.

Upstream isn't responding which would mean the package will remain unfixed in 
Debian
for the next months and I will have to keep pinging both you and upstream which 
would
be rather annoying.

The guaeded code itself is built on powerpc and ppc64 only so there is no risk 
in breaking
any other architecture. Currently, ffmpeg does not build on powerpc and ppc64 
at all which
means I will have to build the package locally with the patch applied everytime 
a new version
or Debian revision of the ffmpeg package gets uploaded which I would rather 
like to avoid.

Adrian

> [1] https://lists.debian.org/debian-sparc/2017/12/msg00060.html

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

Bug#972543: apt-file: Apt-update downloads full Contents file, not pdiffs

[calumlikesapplepie]

On Sun, 2020-10-25 at 11:24 -0400, calumlikesapple...@gmail.com wrote:
> On Sun, 2020-10-25 at 11:04 +0100, Niels Thykier wrote:
> > Hi again,
> > 
> > Thanks for the data.  Unfortunately, it did reveal a smoking gun,
> > so
> > I
> > think we need /tmp/update.log generated from this command.
> > 
> >  apt -o Debug::pkgAcquire::Worker=1  \
> > -o Debug::pkgAcquire::Diffs=1 update \
> >   2>&1 | tee /tmp/update.log
> 
> Attached.
> 
> > Please attach the file rather than copy-paste in the output from
> > it.
> 
> Sure! I just wasn't sure if attaching was standard, or if you'd
> gotten
> my original attachment.

I just realized that I forgot to mention something important: the issue
doesn't happen every time I run apt update, and even sometimes when it
needs to update other files, it doesn't wind up updating the contents.
I'll log my manual updates for the next week (gnome-software sometimes
runs it in the background), in case this log is useless.


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

Bug#972543: apt-file: Apt-update downloads full Contents file, not pdiffs

[Niels Thykier]

calumlikesapple...@gmail.com:
> On Sun, 2020-10-25 at 11:04 +0100, Niels Thykier wrote:
>> Hi again,
>>
>> Thanks for the data.  Unfortunately, it did reveal a smoking gun, so
>> I
>> think we need /tmp/update.log generated from this command.
>>
>>  apt -o Debug::pkgAcquire::Worker=1  \
>> -o Debug::pkgAcquire::Diffs=1 update \
>>   2>&1 | tee /tmp/update.log
> 
> Attached.
> 

Apologies, I should have been more precise.

Please use that command next time you need to run an apt update and when
you get a run where you should have had PDiffs but did not get any, then
submit the log file for that run.
  The log file provided is for a "no-changes" run. Accordingly, I cannot
tell if it skipped PDiffs or not because it concluded there was no need
for an update at all.

>> Please attach the file rather than copy-paste in the output from it.
> 
> Sure! I just wasn't sure if attaching was standard, or if you'd gotten
> my original attachment.
> 

My rule of thumb is more about length and whether the mail programs line
wrap long lines. :)  For mail programs that don't, "short" inline
copy-paste is often nicer, but for long files or zealous line wrapping
attachments are often more readable.

~Niels

Bug#972863: ITP: ttyd -- Share your terminal over the web

[Daniel Baumann]

Package: wnpp

  * Package name : ttyd
  * Upstream Author : Shuanglei Tao
  * License : MIT
  * Homepage : https://github.com/tsl0922/ttyd

ttyd is a leightweight straight-forward terminal over http/https
program. Compared to ajaxterm, anyterm, shellinabox and others it is
much better because it's using xterm.js and websockets, hence better
response times.

Regards,
Daniel

Bug#972163: Rising severities

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El dom., 25 oct. 2020 11:07, Sylvestre Ledru 
escribió:

> Hello,
>
> Le 25/10/2020 à 14:57, Lisandro Damián Nicanor Pérez Meyer a écrit :
> > severity 972163 serious
> > severity 972166 serious
> > block 972176 by 972163
> > block 972176 by 972166
> > thanks
> >
> > Hi! We are close to begin the Qt transition that will remove
> > qt5-default, so I'm raising the severities.  If everything goes well
> > I'll be NMUing your package today with an upload to delayed/5. Of
> > course feel free to ping me if needed.
> >
> > Thanks, Lisandro.
> >
> I tried to upload it with your fix but the build failed for me.
>
> If it works for you, please upload (without delay)
>
> many thanks
>


Great, I'll check the build then! Thanks to you too!

>

Bug#972869: RFA: fmtlib

[Eugene V. Lyubimkin]

Package: wnpp
Severity: normal

Hello,

This package needs a more responsive maintainer. I unfortunately haven't
had enough time for months and this is unlikely to change in the near
future.

fmtlib is a modern C++ library, it provides fast and type-safe
replacement of (s)printf and related machinery.

What needs to be done:
 - package a new upstream release;
 - solve a (documentation-related) FTBFS;
 - potentially make a shared library instead of a static library.


Regards,
-- 
Eugene V. Lyubimkin
C++ GNU/Linux userspace developer, Debian Developer

Bug#972543: apt-file: Apt-update downloads full Contents file, not pdiffs

[calumlikesapplepie]

On Sun, 2020-10-25 at 11:04 +0100, Niels Thykier wrote:
> Hi again,
> 
> Thanks for the data.  Unfortunately, it did reveal a smoking gun, so
> I
> think we need /tmp/update.log generated from this command.
> 
>  apt -o Debug::pkgAcquire::Worker=1  \
> -o Debug::pkgAcquire::Diffs=1 update \
>   2>&1 | tee /tmp/update.log

Attached.

> Please attach the file rather than copy-paste in the output from it.

Sure! I just wasn't sure if attaching was standard, or if you'd gotten
my original attachment.

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Starting method '/usr/lib/apt/methods/http'
 <- http:100%20Capabilities%0aSend-Config:%20true%0aPipeline:%20true%0aVersion:%201.2
Configured access method http
Version:1.2 SingleInstance:0 Pipeline:1 SendConfig:1 LocalOnly: 0 NeedsCleanup: 0 Removable: 0 AuxRequests: 0
Starting method '/usr/lib/apt/methods/https'
 <- https:100%20Capabilities%0aSend-Config:%20true%0aPipeline:%20true%0aVersion:%201.2
Configured access method https
Version:1.2 SingleInstance:0 Pipeline:1 SendConfig:1 LocalOnly: 0 NeedsCleanup: 0 Removable: 0 AuxRequests: 0
Starting method '/usr/lib/apt/methods/http'
 <- http:100%20Capabilities%0aSend-Config:%20true%0aPipeline:%20true%0aVersion:%201.2
Configured access method http
Version:1.2 SingleInstance:0 Pipeline:1 SendConfig:1 LocalOnly: 0 NeedsCleanup: 0 Removable: 0 AuxRequests: 0
 -> 

Bug#972871: git-el: .el files not installed / byte-compiled

[Zack Weinberg]

Package: git-el
Version: 1:2.28.0-1
Severity: grave
Justification: renders package unusable

While updating my emacs configuration for 27.1 (now in unstable)
I noticed that /etc/emacs/site-start.d/50git-core.el prints

git removed but not purged, skipping setup

and does not autoload either git.el or git-blame.el.  This appears to
be because /usr/lib/emacsen-common/packages/install/git does nothing
when $FLAVOR is “emacs”:

| # The emacs startup file looks for these files in
| # /usr/share/${debian-emacs-flavor}/site-lisp/git.
| # Installing to the generic /usr/share/emacs/site-list/git would be
| # pointless.
| [ "$FLAVOR" != emacs ] || exit 0

This has been incorrect for quite some time - I’m not sure how long
ago it was that (symbol-name debian-emacs-flavor) was changed to
evaluate to “emacs” for the ordinary packages of GNU Emacs, but
probably more than one release by now.

I think a sufficient fix is to remove the above quoted lines from
/usr/lib/emacsen-common/packages/install/git.

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/32 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-el depends on:
ii  emacs1:27.1+1-2
ii  emacs-gtk [emacsen]  1:27.1+1-2
ii  git  1:2.28.0-1

Versions of packages git-el recommends:
ii  elpa-magit  2.99.0.git0957.ge8c7bd03-1

git-el suggests no packages.

-- no debconf information

Bug#972872: apt.systemd.daily should vary exit code based on unattended-upgrades failures

[Filippo Giunchedi]

Package: apt
Version: 1.8.2.1
Severity: normal

Hi,
I've ran into a situation where an unattended-upgrades run would fail to
upgrade packages on an host. I'm using the u-u APT integration, thus u-u is
called via /usr/lib/apt/apt.systemd.daily and its corresponding service+timer.

Even on a failed u-u run the apt-daily-upgrade.service unit is still reported a
successful, AFAICT because apt.systemd.daily exits 0 even when u-u fails. I
think it makes sense to surface u-u errors back and thus fail the systemd
service, does that seem reasonble? What do you think re: surfacing other errors
as well?

thank you!
Filippo

Bug#972844: lintian: E: musescore2 source: malformed-override Unknown tag testsuite-autopkgtest-missing in line 5

[Felix Lechner]

Control: clone -1 -2 -3
Control: retitle -1 lintian: mark tag as renamed to missing-tests-control
Control: retitle -2 lintian: fix override usage detection for renamed tags
Control: retitle -3 lintian: Wide character in say at Lintian::Output line 156

Hi Thorsten,

On Sat, Oct 24, 2020 at 4:39 PM Thorsten Glaser  wrote:
>
> I’ve been recompiling musescore2_2.3.2+dfsg3-10.dsc (currently
> in sid) on latest sid

On Debian stable. this package actually triggers three Lintian bugs:

1. The tag testsuite-autopkgtest-missing was renamed to
missing-tests-control, the old name was not recorded properly. This is
remedied quite easily and will result in a 'renamed-tag' warning.
2. The override comes up as unused, but that does not seem to be true.
Your sources do not declare a d/tests/control.
3. At least on stable your override comment for cute-field, "what the
ever…", which contains the Unicode codepoint U+2026 (e2 80 a6)
HORIZONTAL ELLIPSIS, triggers the following warning:

Wide character in say at
/lcl/lechner/lintian/git/bin/../lib/Lintian/Output.pm line 156.
Lintian::Output::msg(Lintian::Output::EWI=HASH(0x5639082d1c60),
"oh really?! what the ever\x{2026}") called at
/lcl/lechner/lintian/git/bin/../lib/Lintian/Output/EWI.pm line 170
Lintian::Output::EWI::print_tag(Lintian::Output::EWI=HASH(0x5639082d1c60),
Lintian::Tag::Standard=HASH(0x56390e6ec1d0)) called at
/lcl/lechner/lintian/git/bin/../lib/Lintian/Output/EWI.pm line 113
Lintian::Output::EWI::issue_tags(Lintian::Output::EWI=HASH(0x5639082d1c60),
ARRAY(0x56391071feb8)) called at
/lcl/lechner/lintian/git/bin/../lib/Lintian/Pool.pm line 286
Lintian::Pool::process(Lintian::Pool=HASH(0x5639082d2378),
Lintian::Profile=HASH(0x56390955ace0), SCALAR(0x563909616fc0),
HASH(0x56390960a388), GLOB(0x563909692948),
Lintian::Output::EWI=HASH(0x5639082d1c60)) called at bin/lintian line
758
N: oh really?! what the ever…
O: musescore2 source: cute-field debian/control@source VCS-git vs Vcs-Git

We are unsure about the last bug, especially because you did not
report it in unstable (and it would have been hard to miss). The Perl
folks are telling us it is probably a bug in Perl. The output layer
"encoding:uft-8" is active on the handle being printed to. We are at a
loss for now.

This bug is being cloned and retitled to deal with each of the
described conditions. Thanks for bringing them to our attention.

> lintian output has
> become less reliable and more hard to parse in the last few
> months…

I disagree with that broad condemnation. As a community project that
touches the lives of many contributors, Lintian accepted bug fixes in
many wrong places. The ripples you see stem from a careful but
difficult reshuffling of decades of hard work into a modern code base.

Lintian is no longer multi-threaded, and when that is accounted for,
the software runs better and faster than ever. It will also be much
easier to maintain (and contribute to) going forward.

Kind regards
Felix Lechner

Bug#972809: dracut-core: Acts on /boot/initramfs-... instead of /boot/initrd... by default

[Antonio Russo]

Hello,

On 10/25/20 4:03 AM, Thomas Lange wrote:

Thanks for the patch. But when I tried to apply it on my local machine
it failed. Can you please check this

[snip]

Hmm... it looks like 050+65-1 isn't on salsa, only 050+35-4 (and that's
what the patch is based on).

If you push 050+65-1 to salsa and ping me, I'll rebase on that.

Antonio


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#972677: deepin-image-viewer: FTBFS with Qt 5.15: error: aggregate ‘QPainterPath path’ has incomplete type and cannot be defined

[Dmitry Shachnev]

Control: tags -1 + pending

On Thu, Oct 22, 2020 at 02:05:20PM +0300, Dmitry Shachnev wrote:
> Dear Maintainer,
>
> deepin-image-viewer fails to build with Qt 5.15, currently available in
> experimental.
>
> After rebuilding dde-qt-dbus-factory and libqtxdg, and building a fixed
> version of dtkwidget (see #972155), I get this error:
>
>   widgets/popupmenustyle.cpp: In member function ‘virtual void 
> PopupMenuStyle::drawPrimitive(QStyle::PrimitiveElement, const QStyleOption*, 
> QPainter*, const QWidget*) const’:
>   widgets/popupmenustyle.cpp:117:22: error: aggregate ‘QPainterPath path’ has 
> incomplete type and cannot be defined
> 117 | QPainterPath path;
> |  ^~~~
>   widgets/popupmenustyle.cpp:133:13: error: ‘QPainterPathStroker’ was not 
> declared in this scope; did you mean ‘QPainterPath’?
> 133 | QPainterPathStroker stroker;
> | ^~~
> | QPainterPath
>   widgets/popupmenustyle.cpp:134:13: error: ‘stroker’ was not declared in 
> this scope; did you mean ‘strtok_r’?
> 134 | stroker.setWidth(FRAME_BORDER_WIDTH);
> | ^~~
> | strtok_r
>   widgets/popupmenustyle.cpp:136:26: error: variable ‘QPainterPath 
> borderPath’ has initializer but incomplete type
> 136 | QPainterPath borderPath = stroker.createStroke(path);
> |  ^~
>
>   widgets/thumbnaillistview.cpp: In member function ‘virtual void 
> ThumbnailListView::paintEvent(QPaintEvent*)’:
>   widgets/thumbnaillistview.cpp:301:18: error: aggregate ‘QPainterPath bp’ 
> has incomplete type and cannot be defined
> 301 | QPainterPath bp;
> |  ^~
>
> This is fixed upstream, see the linked commit.

I have just uploaded the NMU fixing this to DELAYED/5.

The debdiff is attached.

--
Dmitry Shachnev
diff -Nru deepin-image-viewer-5.0.0/debian/changelog deepin-image-viewer-5.0.0/debian/changelog
--- deepin-image-viewer-5.0.0/debian/changelog	2019-10-04 18:08:11.0 +0300
+++ deepin-image-viewer-5.0.0/debian/changelog	2020-10-25 20:33:15.0 +0300
@@ -1,3 +1,10 @@
+deepin-image-viewer (5.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream patch to fix build with Qt 5.15 (closes: #972677).
+
+ -- Dmitry Shachnev   Sun, 25 Oct 2020 20:33:15 +0300
+
 deepin-image-viewer (5.0.0-1) unstable; urgency=medium
 
   * New upstream release 5.0.0.
diff -Nru deepin-image-viewer-5.0.0/debian/patches/fix-build-failed-under-Qt-5.15.0.patch deepin-image-viewer-5.0.0/debian/patches/fix-build-failed-under-Qt-5.15.0.patch
--- deepin-image-viewer-5.0.0/debian/patches/fix-build-failed-under-Qt-5.15.0.patch	1970-01-01 03:00:00.0 +0300
+++ deepin-image-viewer-5.0.0/debian/patches/fix-build-failed-under-Qt-5.15.0.patch	2020-10-25 20:33:15.0 +0300
@@ -0,0 +1,60 @@
+From: zhangjinqiang 
+Date: Mon, 14 Sep 2020 02:54:58 +
+Subject: fix: build failed under Qt 5.15.0
+
+(cherry picked from commit b11d7cbdcdd99c82e3feff2aac21e28c6a81f7e7)
+---
+ viewer/widgets/dspinner.cpp  | 1 +
+ viewer/widgets/popupmenustyle.cpp| 1 +
+ viewer/widgets/thumbnaildelegate.cpp | 1 +
+ viewer/widgets/thumbnaillistview.cpp | 1 +
+ 4 files changed, 4 insertions(+)
+
+diff --git a/viewer/widgets/dspinner.cpp b/viewer/widgets/dspinner.cpp
+index 2931f3e..ccfae88 100644
+--- a/viewer/widgets/dspinner.cpp
 b/viewer/widgets/dspinner.cpp
+@@ -2,6 +2,7 @@
+ 
+ #include 
+ #include 
++#include 
+ #include 
+ 
+ #include 
+diff --git a/viewer/widgets/popupmenustyle.cpp b/viewer/widgets/popupmenustyle.cpp
+index ddb509c..0fd91f7 100644
+--- a/viewer/widgets/popupmenustyle.cpp
 b/viewer/widgets/popupmenustyle.cpp
+@@ -19,6 +19,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ 
+diff --git a/viewer/widgets/thumbnaildelegate.cpp b/viewer/widgets/thumbnaildelegate.cpp
+index 64bd65e..1a09702 100644
+--- a/viewer/widgets/thumbnaildelegate.cpp
 b/viewer/widgets/thumbnaildelegate.cpp
+@@ -23,6 +23,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+diff --git a/viewer/widgets/thumbnaillistview.cpp b/viewer/widgets/thumbnaillistview.cpp
+index f27fa22..cb7e015 100644
+--- a/viewer/widgets/thumbnaillistview.cpp
 b/viewer/widgets/thumbnaillistview.cpp
+@@ -30,6 +30,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
diff -Nru deepin-image-viewer-5.0.0/debian/patches/series deepin-image-viewer-5.0.0/debian/patches/series
--- deepin-image-viewer-5.0.0/debian/patches/series	1970-01-01 03:00:00.0 +0300
+++ deepin-image-viewer-5.0.0/debian/patches/series	2020-10-25 20:33:15.0 +0300
@@ -0,0 +1 @@
+fix-build-failed-under-Qt-5.15.0.patch


signature.asc
Description: PGP signature

Bug#972882: linux-image-4.19.0-12-amd64: startx fails

[Damjan]

Package: src:linux
Version: 4.19.152-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
Regular upgrade of linux-image-amd64.

   * What exactly did you do (or not do) that was effective (or ineffective)?
After an upgrade, XWindows don't start. Selecting older linux-image from the
boot menu (4.19.0-11) still works.

   * What was the outcome of this action?
   * What outcome did you expect instead?




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

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: A320M-S2H
product_version: Default string
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: F42
board_vendor: Gigabyte Technology Co., Ltd.
board_name: A320M-S2H-CF
board_version: x.x

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Root Complex [1022:15d0]
Subsystem: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root Complex 
[1022:15d0]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 

00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Internal PCIe GPP Bridge 0 to Bus B [1022:15dc] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
[1022:790b] (rev 61)
Subsystem: Gigabyte Technology Co., Ltd FCH SMBus Controller [1458:5001]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

01:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] Device 
[1022:43b8] (rev 02) (prog-if 01 [AHCI 1.0])
Subsystem: ASMedia Technology Inc. Device [1b21:1062]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ahci
Kernel modules: ahci

01:00.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device 
[1022:43b3] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

02:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series 
Chipset PCIe Port [1022:43b4] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

02:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series 
Chipset PCIe Port [1022:43b4] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- 

Bug#972163: Rising severities

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Sun, 25 Oct 2020 at 15:00, Sylvestre Ledru  wrote:
[snip]
> Please upload your version, it is fine :)

Done! Of course I'll keep an eye on the buildds in case something goes wrong.

Thanks!!!


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#449606: Watch "JEEZY-BACK 2 THA TRAP [FULL MIXTAPE]" on YouTube

[Jarrod Jackson]

https://youtu.be/vKlCKz0M8_U

Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure

[intrigeri]

Hi,

Paul Gevers (2020-05-25):
> The most obvious alternative is that your run it locally, but I guess
> you tried and couldn't reproduce?

I usually use the libvirt backend but I tried today with the lxc
backend locally, and could not reproduce. Note I don't see this
problem on Salsa CI either.

I took a closer look and the problem happens after successfully
running the compile-policy test. I can't imagine how what this test
does can interfere with shutting down the container, *but* that test
installs a bunch of packages:

  apparmor, apparmor-profiles-extra, bind9, cups-browsed, cups-daemon,
  evince, haveged, kopano-dagent, kopano-server, libreoffice-common,
  libvirt-daemon-system, man-db, ntp, onioncircuits, tcpdump, tor

I suspect one of those failed to stop within the 600s timeout in the
ci.d.n environment.

This being said, this was a while ago, and I wonder if the problem got
somehow fixed in one of those packages in the meantime. Could you
please give it another try with 2.13.5-1 (sid) or 3.0.0-1
(experimental), and ideally both? This would establish an updated
baseline for further investigation.

>> Is there a better way for me to investigate?

> We have given DD's temporarily access to one of our workers before. If
> you're interested we could do that again for this case. That way you
> could even skip the upload to experimental, assuming it reproduces if
> run from a local tree. And you can check what's going on in the test bed.

This looks great. I'd like to do this once the updated baseline is
established, if it still fails. I could book time for this on Nov
28-29.

Cheers!

Bug#972651: buster-pu: package fastd/18-3+deb10u1

[Sven Eckelmann]

On Saturday, 24 October 2020 20:37:36 CET Adam D. Barratt wrote:
> Please go ahead.

Thanks, uploaded [1] with appended CVE in the changelog.

Kind regards,
Sven

[1] 
https://release.debian.org/proposed-updates/buster_diffs/fastd_18-3+deb10u1.debdiff

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

Bug#972887: libgstreamer1-perl: Deprecated upstream

[intrigeri]

Source: libgstreamer1-perl
Severity: serious
X-Debbugs-Cc: Mike Gabriel 
User: debian-p...@lists.debian.org
Usertags: rm-candidate

Hi,

upstream announced¹ that the GStreamer Perl module would be deprecated
and archived in December 2020:

 - The module will no longer be updated with security patches, bug
   fixes, or when changes are made in the Perl ABI.

 - It will no longer be possible to submit new issues or pull requests
   for these modules, or push new changes to their Git repos.

Therefore, I don't think we should ship this package in Bullseye.

Any objection to removing the package from testing & sid?

This is a leaf package and popcon is 4/19 (vote/inst).

[1] https://mail.gnome.org/archives/gtk-perl-list/2020-October/msg2.html

Bug#821037: adt-virt-lxc: leaves used containers behind

[Paul Gevers]

Hi all,

On Sun, 22 Mar 2020 12:17:08 +0100 Paul Gevers  wrote:
> We're seeing this quite a lot currently on our ci.d.n infrastructure,
> and maybe also on Ubuntu's infra, as reported in bug #908193 (I'm not
> sure if that is actually a duplicate or different.)

Another example:

https://ci.debian.net/data/autopkgtest/testing/amd64/o/openjdk-15/7742200/log.gz

jaxp SKIP exit status 77 and marked as skippable
autopkgtest [19:39:42]: ERROR: "rm -rf
/tmp/autopkgtest-lxc.9db11r52/downtmp/jaxp-artifacts
/tmp/autopkgtest-lxc.9db11r52/downtmp/autopkgtest_tmp" failed with
stderr "rm: cannot remove
'/tmp/autopkgtest-lxc.9db11r52/downtmp/autopkgtest_tmp/hotspot/JTwork':
Directory not empty
"

I checked the worker, it had a tree in /tmp with (however, this is
probably from another run):
admin@ci-worker05:/tmp/autopkgtest-lxc._w5283nq/downtmp/autopkgtest_tmp/hotspot/JTwork$
ls -al
total 24
drwxr-xr-x  6 admin admin 4096 Oct 25 15:55 .
drwxr-xr-x  3 admin admin 4096 Oct 25 15:55 ..
drwxr-xr-x  3 admin admin 4096 Oct 25 15:55 classes
drwxr-xr-x 11 admin admin 4096 Oct 25 15:55 runtime
drwxr-xr-x  3 admin admin 4096 Oct 25 15:55 scratch
drwxr-xr-x 12 admin admin 4096 Oct 25 15:55 serviceability

There was one lxc present:
admin@ci-worker05:~$ sudo lxc-ls -f
NAMESTATE   AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED
autopkgtest-oldstable-amd64 STOPPED 0 -  --false
autopkgtest-stable-amd64STOPPED 0 -  --false
autopkgtest-testing-amd64   STOPPED 0 -  --false
autopkgtest-unstable-amd64  STOPPED 0 -  --false
ci-298-ba5278af STOPPED 0 -  --false

But I could not start it:admin@ci-worker05:~$ sudo lxc-start ci-298-ba5278af
lxc-start: ci-298-ba5278af: lxccontainer.c: wait_on_daemonized_start:
851 Received container state "ABORTING" instead of "RUNNING"
lxc-start: ci-298-ba5278af: tools/lxc_start.c: main: 329 The container
failed to start
lxc-start: ci-298-ba5278af: tools/lxc_start.c: main: 332 To get more
details, run the container in foreground mode
lxc-start: ci-298-ba5278af: tools/lxc_start.c: main: 335 Additional
information can be obtained by setting the --logfile and --logpriority
options
admin@ci-worker05:~$ sudo lxc-start ci-298-ba5278af --foreground
lxc-start: ci-298-ba5278af: start.c: proc_pidfd_open: 1619 Function not
implemented - Failed to send signal through pidfd

 lxc-start:
ci-298-ba5278af: utils.c: safe_mount: 1225 Permission denied - Failed to
mount "proc" onto "/proc"

  lxc-start: ci-298-ba5278af: conf.c:
lxc_mount_auto_mounts: 728 Permission denied - Failed to mount "proc" on
"/proc" with flags 14

lxc-start: ci-298-ba5278af: conf.c: lxc_setup:
3561 Failed to setup first automatic mounts
  lxc-start:
ci-298-ba5278af: start.c: do_start: 1311 Failed to setup container
"ci-298-ba5278af"
 lxc-start: ci-298-ba5278af: sync.c: __sync_wait: 62 An
error occurred in another process (expected sequence number 5)
  lxc-start: ci-298-ba5278af: start.c: __lxc_start: 2031 Failed to spawn
container "ci-298-ba5278af"

lxc-start: ci-298-ba5278af:
tools/lxc_start.c: main: 329 The container failed to start
lxc-start: ci-298-ba5278af: tools/lxc_start.c: main: 335 Additional
information can be obtained by setting the --logfile and --logpriority
options


Paul




signature.asc
Description: OpenPGP digital signature

Bug#972895: node-pathval: CVE-2020-7751

[Salvatore Bonaccorso]

Source: node-pathval
Version: 1.1.0-3
Severity: important
Tags: security upstream
Forwarded: https://github.com/chaijs/pathval/pull/58
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for node-pathval.

 * CVE-2020-7751[0]

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-7751
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7751
[1] https://github.com/chaijs/pathval/pull/58
[2] https://snyk.io/vuln/SNYK-JS-PATHVAL-596926

Regards,
Salvatore

Bug#972514: nvidia-kernel-dkms: fails to build with linux-headers-5.9.0-1-amd64

[Heinz Repp]

I too confirm the bug with my Debian testing setup and Linux 5.9.0-1. In 
message #30 Rob points out that nvidia-kernel-dkms 455.23.04-1 works, 
and I can confirm this too. You won't find it in unstable (this has the 
same 450.66-1 as testing), but in experimental. Do not forget to install 
all other nvidia dependencies also from experimental.


So for the time being: grab the whole nvidia files from experimental, 
and then you will be able to use the 5.9 kernel. Guess they should 
accelerate the propagation to unstable and then to testing pretty soon, 
as the 5.9 kernel installed per default else breaks all nvidia owners/users.


Heinz

Bug#972394: likely cause: Python.h not found because of version mismatch 3.8 vs 3.9

[Stephen Sinclair]

On Wed, Oct 21, 2020 at 10:39 AM Adrian Bunk  wrote:
>
> Control: retitle -1 siconos FTBFS with more than one supported python3 version
>
> On Mon, Oct 19, 2020 at 11:38:42PM +0200, Markus Koschany wrote:
> >
> > I built siconos in a clean chroot environment. The recent rebuild of
> > siconos also shows build failures
> >
> > https://buildd.debian.org/status/package.php?p=siconos
> >
> > I don't think it's specific to my environment.
>
> You need something like python3-dev -> python3-all-dev in the build
> dependencies.

I can confirm that making this change allows the package to build.
However, some Python-related tests in autopkgtest fail when trying to
import the Siconos python modules, so something still needs to be
fixed.  I will investigate.
As for this change, however, is it the correct one to make?  Or should
I wait for more information in #972551?

> The next problem is what it builds - it then builds for the highest
> version only, not for the default version.

Can I ask how you determined this?  It is not surprising that
something could be wrong, as the CMake configuration is very
complicated in this package.
However, the configure step includes the line,

-DPYTHON_EXECUTABLE=$(shell which python3)"

which should specify the path to the default Python interpreter.  Is
there a better way to determine this path?

> This bug could be solved by either adjusting the build dependencies
> and the build to build for all supported python3 versions, or by fixing
> whatever in the build system does not use the default version.

I would prefer the latter as the package is already quite complicated
and does not play well with multiple pythons.

regards,
Steve

Bug#972832: dialog: can't change menu border lines

[Ennio-Sr]

In reply to:
> 
> From: Thomas Dickey 
> To: 972...@bugs.debian.org
> Cc: 972832-submit...@bugs.debian.org
> Subject: Re: Bug#972832: dialog: can't change menu border lines
> Date: Sun, 25 Oct 2020 16:27:13 -0400
> 
> [Message part 1
> 
> (text/plain, inline)]
> 
> On Sat, Oct 24, 2020 at 06:17:39PM +0200, Ennio-Sr wrote:
> > Package: dialog
> > Version: 1.3-20160828-2
> > Severity: minor
> >
> > Hi all!
> >
> > As I like to work on virtual console with black background, when I try to
> > use dialog with my personalized colors (and a .dialogrc file) the 'upper
> > left inner box'  and 'lower right external box' lines appear as black
> > lines on white background, whereas the remaining lines come out on a black
> > background as the whole dialog background.
> > Deleting the .dialogrc file the corner lines are still in differnet
> > colors, but on the same 'grey' background.
> 
> I'd start by seeing if this option helps:
> 
>--no-shadow
>   Suppress  shadows that would be drawn to the right and bottom of
>   each dialog box.
> 
> -- 
> Thomas E. Dickey
> https://invisible-island.netftp://ftp.invisible-island.net

Thanks for your reply! 
Unluckily the --no-shadow option doesn't solve the problem as my
foreground is black.
But, if I delete the .dialogrc file the whole screen foreground is
blue. In this case I can see that the --no-shadow eliminates the right
end corner (black) shadow but not the problem described above.

Afaic understand, in the dialog structure the border lines are written
as 'black on white fg' which does not go well on my black background.
Perhaps I should modify some of the dialog sources files but I don't
know how and which one to adjust...

Regards,
  Ennio

PS: If necessary I could send a copy of the script I'm testing with an
abridged .dialogrc. But where to send it? As an attachement or within a
massage (with '<< EOF - EOF')?

-- 
[Perché usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo.  \\?//
 Fà qualche cosa di cui non sei capace!"  (diceva Henry Miller) (°|°)
[Why use Win$ozz (I say) if ... "even a fool can do that.   .)=(. 
 Do something you aren't good at!" (as Henry Miller used to say)]  /_\ 

Bug#972898: hplip: no network scanner detection with 3.20.9

[Ahzo]

Package: hplip
Version: 3.20.9+dfsg0-4
Severity: important
Tags: patch

Dear Maintainer,

hplip version 3.20.9 replaced the custom mDNS implementation for scanner 
discovery (protocol/discovery/mdns.c) with using avahi 
(protocol/discovery/avahiDiscovery.c).
While this is a welcome change in principle, unfortunately the new code does 
not work.

The main problem is that it does not wait until all callbacks are called before 
stopping via avahi_simple_poll_quit.
Thus there is a 50/50 chance whether the '_scanner._tcp.local' or the 
'_uscan._tcp.local' mDNS reply gets processed (in the browse_callback) and it 
is practically impossible that any scanner gets processed (in the 
resolve_callback), because avahi_simple_poll_quit is called when the first mDNS 
reply has been processed.
It seems like this code was never really tested with an actual scanner on the 
network.

Attached is a patch fixing this by implementing a check_terminate function 
similar to the one used by avahi-browse.

The second problem is that the code expects the 'ty' part of the mDNS reply, 
which contains the device name, to start with 'HP'. However this is not always 
the case.
Previous versions of hplip would simply remove the first three letters of the 
scanner name and continue, which could be worked around by also removing these 
three letters in the models.dat. That issue has been reported two years ago 
upstream without response from HP. (see: 
https://bugs.launchpad.net/hplip/+bug/1797501)
The new code however  discards the scanner if its 'ty' name does not start with 
'HP', breaking that workaround.
Fortunately, since the new code now uses avahi, a proper fix is relatively 
simple: If the 'ty' part of the mDNS response does not start with 'HP', check 
whether the 'mfg' part does.

The second attached patch implements this fix.

While debugging this I also noticed that the log level for one message is 
wrong, causing spurious errors to be reported.

The third attached patch changes the log level for this message from BUG to DBG 
to fix this.

I hope HP solves this eventually, but until then please include these patches 
in the Debian package, so that scanner detection works again.

Thanks in advance,
Ahzo

PS: I tried to report this upstream, but my Launchpad login attempts always 
fail, because "something just went wrong in Launchpad".

>From 67dbad25f503e1d8c6794efba3f17718c77848ea Mon Sep 17 00:00:00 2001
From: Ahzo 
Date: Sun, 25 Oct 2020 22:17:04 +0100
Subject: [PATCH 1/3] avahiDiscovery: wait for all callbacks

When calling avahi_simple_poll_quit too early, not all callbacks will be called.
---
 protocol/discovery/avahiDiscovery.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/protocol/discovery/avahiDiscovery.c b/protocol/discovery/avahiDiscovery.c
index 8d325ffc0..395aec088 100644
--- a/protocol/discovery/avahiDiscovery.c
+++ b/protocol/discovery/avahiDiscovery.c
@@ -28,6 +28,7 @@ char ipAddressBuff[MAX_IP_ADDR_LEN]={'\0'};
 static int aBytesRead = 0;
 static AvahiSimplePoll *aSimplePoll = NULL;
 static int aMemAllocated = 0;
+static int n_all_for_now = 0, n_resolving = 0;
 
 /*
 This function will fill the dictionary arguments for the dbus function call
@@ -237,6 +238,15 @@ static bool getHPScannerModel(AvahiStringList *iStrList, const char *ikey,char *
 return aValueFound;  
 }
 
+static void check_terminate() {
+
+assert(n_all_for_now >= 0);
+assert(n_resolving >= 0);
+
+if (n_all_for_now <= 0 && n_resolving <= 0)
+avahi_simple_poll_quit(aSimplePoll);
+}
+
 /*
 This function will gets called whenever a service has been resolved successfully or timed out
 */
@@ -300,6 +310,9 @@ static void resolve_callback(
 }
 }
 //avahi_service_resolver_free(r);
+assert(n_resolving > 0);
+n_resolving--;
+check_terminate();
 }
 /* Called whenever a new services becomes available on the LAN or is removed from the LAN */
 static void browse_callback(
@@ -337,11 +350,14 @@ static void browse_callback(
 
 if (!(avahi_service_resolver_new(c, interface, protocol, name, type, domain, AVAHI_PROTO_INET, (AvahiLookupFlags)0, resolve_callback, c)))
 BUG( "Failed to resolve service '%s': %s\n", name, avahi_strerror(avahi_client_errno(c)));
+else
+n_resolving++;
 
 break;
 
 case AVAHI_BROWSER_ALL_FOR_NOW:
- avahi_simple_poll_quit(aSimplePoll);
+ n_all_for_now--;
+ check_terminate();
  break;
 }
 }
@@ -444,6 +460,7 @@ static void avahi_setup(const int iCommandType, const char* iHostName)
 goto fail;
 }
}
+   n_all_for_now++;
 
/* Create the service browser */
if (!(sb = avahi_service_browser_new(client, AVAHI_IF_UNSPEC, AVAHI_PROTO_INET, "_scanner._tcp", NULL, (AvahiLookupFlags)0, browse_callback, client))) 
@@ -451,6 +468,7 @@ static void avahi_setup(const int 

Bug#703656: mp3gain: Segfault in III_dequantize_sample

[Paul Wise]

On Thu, 21 Mar 2013 22:49:01 +0100 Matthieu Dalstein wrote:

> I am facing systematic segfaults when running mp3gain on some mp3 files.

I know it was a long time ago, but it would be interesting to know if
you can reproduce this issue with the new version of mp3gain in
Debian unstable. If the crash has been solved or is still present, or
if you are unable to test this, please let us know.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#972903: buster-pu: package node-pathval/1.1.0-3+deb10u1

[Xavier Guimard]

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

[ Reason ]
node-pathval is vulnerable to a prototype pollution (CVE-2020-7751,
#972895)

[ Impact ]
Little security risk

[ Tests ]
The same patch is applied to debian/sid (same version) and tests are
enabled (and succeeds of course)

[ Risks ]
No risk, patch just adds a check

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Just one check
diff --git a/debian/changelog b/debian/changelog
index 91b3ad0..05749be 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+node-pathval (1.1.0-3+deb10u1) buster; urgency=medium
+
+  * Fix prototype pollution (Closes: #972895, CVE-2020-7751)
+
+ -- Xavier Guimard   Mon, 26 Oct 2020 04:44:16 +0100
+
 node-pathval (1.1.0-3) unstable; urgency=medium
 
   * Point d/watch to /releases instead of /tags.
diff --git a/debian/patches/CVE-2020-7751.diff 
b/debian/patches/CVE-2020-7751.diff
new file mode 100644
index 000..7d1ed9a
--- /dev/null
+++ b/debian/patches/CVE-2020-7751.diff
@@ -0,0 +1,21 @@
+Description: fix prototype pollution
+Author: Adam Gold 
+Origin: upstream, https://github.com/chaijs/pathval/commit/21a9046
+Bug: https://snyk.io/vuln/SNYK-JS-PATHVAL-596926
+Bug-Debian: https://bugs.debian.org/972895
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2020-10-25
+
+--- a/index.js
 b/index.js
+@@ -76,6 +76,9 @@
+   var str = path.replace(/([^\\])\[/g, '$1.[');
+   var parts = str.match(/(\\\.|[^.]+?)+/g);
+   return parts.map(function mapMatches(value) {
++if (value === "constructor" || value === "__proto__" || value === 
"prototype") {
++  return {}
++}
+ var regexp = /^\[(\d+)\]$/;
+ var mArr = regexp.exec(value);
+ var parsed = null;
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..2c7bbd9
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CVE-2020-7751.diff

Bug#700765: rednotebook: Crashes when holding down ctrl-pgup or ctrl-pgdn to move through dates

[Paul Wise]

On Sat, 16 Feb 2013 22:47:13 -0800 Andrew Bennett wrote:

> If I hold down the ctrl key and the pgup or pgdn key to *quickly*
 > move through many dates, Rednotebook crashes.

I know it was a long time ago, but it would be interesting to know if
you can reproduce this issue with the new version of rednotebook in
Debian unstable. If the crash has been solved or is still present, or
if you are unable to test this, please let us know.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#788797: rednotebook: crashing at startup with segmentation fault - SOLVED

[Paul Wise]

On Mon, 15 Jun 2015 19:02:49 +0200 Stefano De Toni wrote:

> I moved the old directory .rednotebook in a backup directory and then I
> launched rednotebook to create a new .rednotebook directory. Finally I
> copied the data directory to new .rednotebook folder.

I know it was a long time ago, but it would be interesting to know if
you can reproduce this issue with the new version of rednotebook in
Debian unstable. If the crash has been solved or is still present, or
if you no longer have a backup of the old .rednotebook folder or are
otherwise unable to test this, please let us know.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#965098: migrated to guile 2.2

[Kai-Martin Knaak]

Just a heads-up: 
Upstream pushed a few patches to the git repository to make the package
compatible with guile 2.2. 

This removes the road block that triggered this removal request. Is
there anything else that prevents geda-gaf from staying in the Debian
repos?

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882


pgpkbooHNwbcN.pgp
Description: OpenPGP digital signature

Bug#971523: ntpsec-ntpdate: ntpdate fail if DNS name for server resolve to IPv6

[Richard Laager]

tags 971523 upstream
forwarded 971523 https://gitlab.com/NTPsec/ntpsec/-/issues/680

On 10/1/20 4:13 AM, Petter Reinholdtsen wrote:
> ntpdig: socket error on transmission: [Errno 101] Network is unreachable
> 
> My guess is that you have working IPv6, while I do not.
> 
> root@devuan-n900:~# ping6 2001:67c:558::43
> connect: Network is unreachable
> root@devuan-n900:~# 

I previously had IPv6 enabled, but no (non-link-local) IPv6 address. If
I disable IPv6 entirely, I get:
[Errno 99] Cannot assign requested address

That's slightly different than your error, but the principle of the
failure is the same.

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Bug#972904: git-debrebase: provide bash-completions

[Calum McConnell]

Package: git-debrebase
Version: 9.12
Severity: wishlist
X-Debbugs-Cc: calumlikesapple...@gmail.com

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It would be really neat if there were bash-completions for the git-debrebase
command.  I could put them together, but I am currently a bit busy, so I
figure I should file a bug, and work on it later.

It would really be quite straightforward, I think, since you could reuse a
lot of the code from git's autocompletions.

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

Kernel: Linux 5.8.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-debrebase depends on:
ii  devscripts  2.20.4
ii  git [git-core]  1:2.28.0-1
ii  libdpkg-perl1.20.5
ii  libfile-fnmatch-perl0.02-2+b7
ii  liblocale-gettext-perl  1.07-4
ii  perl5.30.3-4

Versions of packages git-debrebase recommends:
ii  dgit  9.12
ii  git-buildpackage  0.9.20

git-debrebase suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEE/vC/PEGxsMPJ5u5w7/Xh1+DNmzIFAl+WVmIdHGNhbHVtbGlr
ZXNhcHBsZXBpZUBnbWFpbC5jb20ACgkQ7/Xh1+DNmzKvBBAA4FUmJlm6NOI1enF4
zVhQk+Rb9DwIupBaHQLlh6VzGi/N5J1voeVrdZ9oHySONmTxfpBdC4UsViAnVXe1
vT8Zt1911XaTfNMqlw0eDIJn52r1MPVzVh9YnFtGbD1oag7SdeCr80f05MSRluxz
hJTrwG3oohps3CNkaGvqr+x6tZ23va9pgU7i7L99D59KCZtnwj6nX5Iv3ZTbDJnD
5FtOzIlZPPQ7oAkrzJVNlX9ZRo9LkkxvrFzDTL8kdz0og4713dfuW3df0ohEJ/Hr
caiGx1rzejyh2JJKoqDew0Bv71FxThJiB229MiOzM7om7YHeJcRv+XbvaPzCLhLv
fzY2Au5IebgD1kp951ksxz5MNQ7eqKXa468t7wgzWoH/YvFUIWv/xjOqF+rCy0FI
rjkfYLnwzDCRJAw5Hs+yVdOxjcuC27nCZ7zb5Gle+M2jHQQodxxlHumzJhBlNUQQ
Q6Si7cZLlkZa7fVJtdOTwS7BtzyEPuY8YsVuoToGDG/VgD0O9jhByQ+aa9r6bVij
F5rP3RzPGz1jXh+xPRaHCU7y8vRJrazEyetNuvNVbEmkcChQS+nCAAKsG0Qhib/9
LIoy9Ka9uyrkFo3viRkM46M2GipafSlFNzrXdkdWgfaU6po1pYDJcL+AexjN9r+R
SwpJtdnQ1LPNeRzoccYtWD0PmM0=
=Qb9a
-END PGP SIGNATURE-

Bug#972514: nvidia-kernel-dkms: fails to build with linux-headers-5.9.0-1-amd64

[Rob Oosterling]

On Sat, 24 Oct 2020 18:32:10 +0200 Alexander Heinlein <
alexander.heinl...@web.de> wrote:
> 
> Installing nvidia-kernel-dkms from unstable (455.23.04-1) works.
> 
Yes, that does work, but 455.23.04-1 does not provide a working OpenCl
with kernel 5.9 (it does with 5.8).

Bug#972844: lintian: E: musescore2 source: malformed-override Unknown tag testsuite-autopkgtest-missing in line 5

[Felix Lechner]

Hi Thorsten,

On Sun, Oct 25, 2020 at 11:23 AM Thorsten Glaser  wrote:
>
> Ehm, but I’m running unstable and reported it against the version
> in unstable.

Yes, you are using a newer Perl version. Did you see a
"wide-character" Perl warning?

Kind regards
Felix Lechner

Bug#972885: emacs: Bundled Gnus unable to enter any group

[Florent Rougon]

Package: emacs
Version: 1:27.1+1-2
Severity: normal

Hello,

After upgrading my emacs packages today:

   [UPGRADE] emacs:amd64 1:26.3+1-2 -> 1:27.1+1-2
   [UPGRADE] emacs-bin-common:amd64 1:26.3+1-2 -> 1:27.1+1-2
   [UPGRADE] emacs-bin-common-dbgsym:amd64 1:26.3+1-2 -> 1:27.1+1-2
   [UPGRADE] emacs-common:amd64 1:26.3+1-2 -> 1:27.1+1-2
   [UPGRADE] emacs-el:amd64 1:26.3+1-2 -> 1:27.1+1-2
   [UPGRADE] emacs-gtk:amd64 1:26.3+1-2 -> 1:27.1+1-2
   [UPGRADE] emacs-gtk-dbgsym:amd64 1:26.3+1-2 -> 1:27.1+1-2

Gnus bundled with Emacs 27 can't enter any group anymore (from the
*Group* buffer). If I try to enter a group, I get the following error:

  Symbol's value as variable is void: article

Here is a backtrace of the error:

Debugger entered--Lisp error: (void-variable article)
  #f(compiled-function () #)()
  funcall(#f(compiled-function () #))
  (let ((face (funcall (gnus-summary-highlight-line-0 (if (eq face 
(gnus-get-text-property-excluding-characters-with-faces beg 'face)) nil 
(gnus-put-text-property-excluding-characters-with-faces beg (point-at-eol) 
'face (setq face (if (boundp face) (symbol-value face) face))) (if 
gnus-summary-highlight-line-function (progn (funcall 
gnus-summary-highlight-line-function article face)
  (let* ((beg (point-at-bol)) (article (or (gnus-summary-article-number) 
gnus-current-article)) (score (or (cdr (assq article gnus-newsgroup-scored)) 
gnus-summary-default-score 0)) (mark (or (let ((cl-x (gnus-data-find-in ... 
gnus-newsgroup-data))) (progn (progn (nth 1 cl-x gnus-unread-mark)) 
(inhibit-read-only t) (default gnus-summary-default-score) (default-high 
gnus-summary-default-high-score) (default-low gnus-summary-default-low-score) 
(uncached (and gnus-summary-use-undownloaded-faces (memq article 
gnus-newsgroup-undownloaded) (not (memq article gnus-newsgroup-cached) (let 
((face (funcall (gnus-summary-highlight-line-0 (if (eq face 
(gnus-get-text-property-excluding-characters-with-faces beg 'face)) nil 
(gnus-put-text-property-excluding-characters-with-faces beg (point-at-eol) 
'face (setq face (if (boundp face) (symbol-value face) face))) (if 
gnus-summary-highlight-line-function (progn (funcall 
gnus-summary-highlight-line-function article face))
  gnus-summary-highlight-line()
  gnus-summary-insert-line([0 "" "" "05 Apr 2001 23:33:09 +0400" "" "" 0 0 "" 
nil] 0 nil t 90 t nil "" nil 1)
  gnus-update-summary-mark-positions()
  gnus-summary-setup-buffer("nnml+mail:AUCTeX")
  gnus-summary-read-group-1("nnml+mail:AUCTeX" nil t nil nil nil)
  gnus-summary-read-group("nnml+mail:AUCTeX" nil t nil nil nil nil)
  gnus-group-read-group(nil t)
  gnus-group-select-group(nil)
  gnus-topic-select-group(nil)
  funcall-interactively(gnus-topic-select-group nil)
  call-interactively(gnus-topic-select-group nil nil)
  command-execute(gnus-topic-select-group)

This happens when `gnus-summary-highlight-line' from
/usr/share/emacs/27.1/lisp/gnus/gnus-sum.el.gz calls the byte-compiled
function that `gnus-summary-highlight-line-0' evaluates to. I've used my
nnml+mail:AUCTeX group as an example here, but this happens with all
groups I've tried. Hence, I can't read any mail with this version of the
emacs package. :-|

Thanks for your work!

Regards

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

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

Versions of packages emacs depends on:
ii  emacs-gtk  1:27.1+1-2

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information