Bug#946622: rpki-trust-anchors: French debconf templates translation

[Grégoire Scano]

Package: rpki-trust-anchors
Version: N/A
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

Please find attached the french debconf templates translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Best regards,

Grégoire
# Translation of rpki-trust-anchors debconf templates to French
# Copyright (C) 2019 French l10n team 
# This file is distributed under the same license as the rpki-trust-anchors 
package.
# Grégoire Scano , 2019.
msgid ""
msgstr ""
"Project-Id-Version: rpki-trust-anchors_20191019-3\n"
"Report-Msgid-Bugs-To: rpki-trust-anch...@packages.debian.org\n"
"POT-Creation-Date: 2019-10-19 22:10+0200\n"
"PO-Revision-Date: 2019-12-12 11:07+0800\n"
"Last-Translator: Grégoire Scano \n"
"Language-Team: French \n"
"Language: fr_FR\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../rpki-trust-anchors.templates:1001
msgid "Do you accept the ARIN Relying Party Agreement (RPA)?"
msgstr "Acceptez-vous les conditions générales d'utilisation (RPA) d'ARIN ?"

#. Type: boolean
#. Description
#: ../rpki-trust-anchors.templates:1001
msgid ""
"ARIN forbids third parties from distributing the Trust Anchor Locator (TAL) "
"for their RPKI repository, hence this package can download it only if you "
"will agree to ARIN's conditions."
msgstr ""
"ARIN interdit à des tierces parties de distribuer le Trust Anchor Locator "
"(TAL) pour leur dépôt RPKI. Ce paquet ne pourra le télécharger qu'à la "
"condition que vous acceptiez les conditions d'ARIN."

#. Type: boolean
#. Description
#: ../rpki-trust-anchors.templates:1001
msgid ""
"If you want that this package automatically download and install the ARIN "
"TAL, then you need to accept the ARIN Relying Party Agreement (RPA): https://;
"www.arin.net/resources/manage/rpki/rpa.pdf ."
msgstr ""
"Si vous souhaitez que ce paquet télécharge et installe de façon automatique "
"le TAL d'ARIN, vous devez accepter les conditions générales d'utilisation "
"(RPA) d'ARIN : https://www.arin.net/resources/manage/rpki/rpa.pdf ."

Bug#932461: unstable no longer works

[sp]

Thanks for the work-around
No idea why, but pcmanfm 1.3.1-1+b1 from Unstable no longer works for me on a 
fresh setup, so using work-around now.

Bug#946607: numpy: Please add stage1 sbuild profile for bootstrapping

[Helmut Grohne]

Hi,

TL;DR: Please figure out whether python3-scipy can be moved to
Build-Depends-Indep.

On Wed, Dec 11, 2019 at 09:23:15PM +0100, Helmut Grohne wrote:
>  * Maybe scipy is only used for testing numpy or vice versa? Then one
>could be annotated  and we'd be done.

I attempted doing so. numpy fails building its documentation without
python3-scipy.

>  * Similarly, maybe one is only needed for building Arch:all packages?
>Then maybe it could be demoted to Build-Depends-Indep. With luck
>that could also mean we're done.

I also attempted this. numpy appears to build successfully when
python3-numpy is moved to Build-Depends-Indep. It might silently drop
features though. Comparing it is difficult, because numpy isn't
reproducible. Someone with more clue about the package should have a
look here.

Helmut

Bug#933997: gamemode isn't automatically activated for rise of the tomb raider

[Jonathan Carter]

On 2019/12/11 23:36, Axel Regnat wrote:
> I've seen you uploaded a new version and tested again with shadow of the
> tomb raider (I currently don't have rise of the tomb raider installed).
> It seems that everything works fine now on my end. Gamemode is active
> while running the game without the need to set gamemoderun %command%.
> Thanks for your work.

Great, thanks for the feedback.

-Jonathan

Bug#911207: Fwd: stardict | close: #911207 (!1)

[肖盛文 Faris xiao]

I create a merge request on salsa to fix this bug.

Please see:

https://salsa.debian.org/debian/stardict/merge_requests/1/diffs


 转发的消息 
主题: stardict | close: #911207 (!1)
日期: Thu, 12 Dec 2019 04:34:23 +
发件人:faris xiao 
回复地址:   Debian / stardict

收件人:atzli...@163.com



GitLab

faris xiao  created a merge
request:

Project:Branches: atzlinux-guest/stardict:master to debian/stardict:master
Author: faris xiao
Assignees:

delete tools/src/DeKDic.exe tools/src/KSDrip.exe tools/src/Po2Tab.zip

—
Reply to this email directly or view it on GitLab
.
You're receiving this email because of your activity on
salsa.debian.org. If you'd like to receive fewer emails, you can
unsubscribe

from this thread or adjust your notification settings.

-- 
肖盛文 Faris Xiao
邮箱：atzli...@yeah.net
微信：atzlinux
ＱＱ：909868357
基于 Debian 的 Linux 中文桌面操作系统：http://118.24.9.73/



signature.asc
Description: OpenPGP digital signature

Bug#938909: zope.interface: Python2 removal in sid/bullseye

[peter green]

severity 938909 normal
thanks

Version 4.6.0-2 eliminates the unsatisfiable build-dependency and has migrated 
to testing. Returning this bug to normal severity.

Bug#946343: [DAViCal-devel] Bug#946343: davical: CVE-2019-18345 CVE-2019-18346 CVE-2019-18347

[Florian Schlichting]

Hello Salvatore, Security team,

On Wed, Dec 11, 2019 at 07:02:31PM +0100, Florian Schlichting wrote:
> I've just uploaded davical 1.1.9.2-1 to unstable, which (to the best of
> our knowledge) contains complete fixes for all three CVEs, along with a
> few other things that have accumulated since the last regular release.
> 
> In order to provide a more targeted fix for Debian (old-)stable, I've
> cherry-picked the four relevant commits onto a "buster" branch and
> turned them into a quilt patch. The result can be inspected here:
> https://gitlab.com/fsfs/davical/compare/master...buster

I've updated the changelog entry there to conform to the suggestions
from developers-reference for security uploads.

I've also pushed branches for stretch (trivial) and jessie (a little
more involved due to many changes and add forms in the affected files)
to that repo, currently limited to debian/patches and without a
changelog entry yet (not sure what you need there).

> Unfortunately, I am unfamiliar with the security team procedures and I
> will be AFK for ten days from Saturday. If there's anything else I can
> still do until then, like making sure the patch fits onto the stretch
> and jessie versions as well, or upload fixed packages (how exactly? I've
> only ever uploaded to unstable and -backports...) please tell and send
> pointers to more info!

please advise!

Florian

Bug#946620: bug#38574: Acknowledgement (Bug#946620: diff called 'GNU')

[GNU bug Tracking System]

Thank you for filing a new bug report with debbugs.gnu.org.

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.

As you requested using X-Debbugs-CC, your message was also forwarded to
  bug-diffut...@gnu.org
(after having been given a bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
 bug-diffut...@gnu.org

If you wish to submit further information on this problem, please
send it to 38...@debbugs.gnu.org.

Please do not send mail to help-debb...@gnu.org unless you wish
to report a problem with the Bug-tracking system.

-- 
38574: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=38574
GNU Bug Tracking System
Contact help-debb...@gnu.org with problems

Bug#946621: fluidsynth: new upstream 2.1

[Jonatan Nyberg]

package: fluidsynth
severity: normal

Please consider to upgrade to the current upstream version
(2.1).

Regards,
Jonatan

Bug#946620: diff called 'GNU'

[積丹尼 Dan Jacobson]

X-Debbugs-Cc: bug-diffut...@gnu.org
Package: diffutils
Version: 1:3.7-3
File: /usr/share/man/man1/diff.1.gz
Severity: important

$ COLUMNS=50 man diff | head
GNU(1)User Commands   GNU(1) << Say DIFF(1)

NAME
   GNU diff - compare files line by line

SYNOPSIS
   diff [OPTION]... FILES

DESCRIPTION
   Compare FILES line by line.
$ COLUMNS=50 man diff | tail -n 11
   The  full  documentation for GNU is main‐ << Say diff
   tained as a Texinfo manual.  If the  info
   and  GNU  programs are properly installed
   at your site, the command

  info GNU   << Say diff

   should give you access  to  the  complete
   manual.

diffutils 3.7 December 2018   GNU(1) << Say DIFF(1)

In fact this bug affects the diff3 etc. man pages too.

Bug#946520: FTBFS on ppc64el

[Benjamin Kaduk]

On Tue, Dec 10, 2019 at 03:03:02PM +0100, Frédéric Bonnard wrote:
> Package: src:openafs
> Version: 1.8.5-1
> 
> --
> 
> Dear maintainer,
> thanks for enabling ppc64el. It seems some more changes are needed for
> openafs to build properly :
> https://buildd.debian.org/status/fetch.php?pkg=openafs=ppc64el=1.8.5-1=1572239330=0
> 
> Here is a merge request that does the job here :
> https://salsa.debian.org/debian/openafs/merge_requests/2

Thanks for the patch, and heads-up.  It seems my salsa notification
settings needed some adjustment, too...

N.B. that upstream has dealt with osconf.m4 slightly differently
(https://gerrit.openafs.org/13980) but the idea is the same.

I'll get this in the next upload.

-Ben

Bug#946619: python3-pylint-django: Re-enable the tests after pylint 2.5 has been released.

[Joseph Herlant]

Package: python3-pylint-django
Version: 2.0.11-1
Severity: wishlist

As explained in #945426, pylint 2.4 has removed the unit tests from the package
installation and the test functional classes have only been re-introduced in
the package in pylint 2.5 so for now I'll disable the unit tests and re-enable
them when pylint 2.5 is back.
This report is a reminder to do it.



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

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

Versions of packages python3-pylint-django depends on:
ii  pylint   2.2.2-4
ii  python3  3.7.5-1
ii  python3-pylint-plugin-utils  0.6-1

python3-pylint-django recommends no packages.

python3-pylint-django suggests no packages.

-- no debconf information

Bug#895462: Please keep asciidoc in Debian

[Joseph Herlant]

Hi Simon,

I'd be interested in your use case. Do you have some examples of what
you call "proper localization with support for multiple languages and
flexibility through additional config files"?
I also work with asciidoctor so I'd be happy to see with them if
upstream has that on their backlog.

To be honest, asciidoc hasn't been really active over the last few
years (since its creator left the project) and even the current
maintainers have advise several times to switch to asciidoctor (which
has become the official reference for the asciidoc language), so the
package does now support python3, yes, but I would still advise to
look at alternatives long term.

The reason I keep this one open for now is to make sure people realize
that it's not because the language name is asciidoc that they should
use the asciidoc binary.

Joseph

Bug#916076: kamoso: segmentation fault in GStreamer opening hamburger menu

[John Scott]

An easy way to reproduce it is by rapidly clicking the button while pressing 
escape to close the menu. I've attached a comprehensive backtrace. Help finding 
whatever package has the debugging symbols for /usr/lib/x86_64-linux-gnu/
libgstvideo-1.0.so.0.1404.0 would be appreciated.Application: Kamoso (kamoso), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f45f6d1e800 (LWP 20083))]

Thread 73 (Thread 0x7f4537555700 (LWP 20193)):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x7f45fca1df9f in g_cond_wait (cond=cond@entry=0x55860ef76ac0, 
mutex=mutex@entry=0x55860ef76ab8) at ../../../glib/gthread-posix.c:1402
#2  0x7f45ec1e468c in gst_base_sink_wait_preroll 
(sink=sink@entry=0x55860ef76990) at gstbasesink.c:2267
#3  0x7f45ec1e4c18 in gst_base_sink_do_preroll 
(sink=sink@entry=0x55860ef76990, obj=obj@entry=0x7f4568091d90) at 
gstbasesink.c:2361
#4  0x7f45ec1e531a in gst_base_sink_do_sync 
(basesink=basesink@entry=0x55860ef76990, obj=obj@entry=0x7f4568091d90, 
late=late@entry=0x7f45375548a0, step_end=step_end@entry=0x7f45375548a4) at 
gstbasesink.c:2564
#5  0x7f45ec1e6938 in gst_base_sink_chain_unlocked 
(basesink=basesink@entry=0x55860ef76990, obj=obj@entry=0x7f4568091d90, 
is_list=is_list@entry=0, pad=) at gstbasesink.c:3513
#6  0x7f45ec1e7c00 in gst_base_sink_chain_main (basesink=0x55860ef76990, 
pad=, obj=0x7f4568091d90, is_list=0) at gstbasesink.c:3672
#7  0x7f45fcb1bc3a in gst_pad_chain_data_unchecked (data=0x7f4568091d90, 
type=4112, pad=0x7f45e0432ce0) at gstpad.c:4322
#8  gst_pad_push_data (pad=pad@entry=0x5586100347f0, type=type@entry=4112, 
data=data@entry=0x7f4568091d90) at gstpad.c:4578
#9  0x7f45fcb23ed2 in gst_pad_push (pad=0x5586100347f0, 
buffer=0x7f4568091d90) at gstpad.c:4697
#10 0x7f45ec1f1dfd in gst_base_transform_chain (pad=, 
parent=0x55860fdc7f60, buffer=) at gstbasetransform.c:2321
#11 0x7f45fcb1bc3a in gst_pad_chain_data_unchecked (data=0x7f4568091950, 
type=4112, pad=0x558610034a40) at gstpad.c:4322
#12 gst_pad_push_data (pad=pad@entry=0x558610034100, type=type@entry=4112, 
data=data@entry=0x7f4568091950) at gstpad.c:4578
#13 0x7f45fcb23ed2 in gst_pad_push (pad=0x558610034100, 
buffer=0x7f4568091950) at gstpad.c:4697
#14 0x7f45ec1f1dfd in gst_base_transform_chain (pad=, 
parent=0x55860fdc7ab0, buffer=) at gstbasetransform.c:2321
#15 0x7f45fcb1bc3a in gst_pad_chain_data_unchecked (data=0x7f4568091ea0, 
type=4112, pad=0x7f45f0021910) at gstpad.c:4322
#16 gst_pad_push_data (pad=pad@entry=0x7f45f0021b60, type=type@entry=4112, 
data=data@entry=0x7f4568091ea0) at gstpad.c:4578
#17 0x7f45fcb23ed2 in gst_pad_push (pad=0x7f45f0021b60, 
buffer=buffer@entry=0x7f4568091ea0) at gstpad.c:4697
#18 0x7f45d1a72b69 in gst_image_freeze_src_loop (pad=0x7f45f0021b60) at 
gstimagefreeze.c:799
#19 0x7f45fcb50f41 in gst_task_func (task=0x7f45745f9950) at gsttask.c:332
#20 0x7f45fc9fcdb3 in g_thread_pool_thread_proxy (data=) at 
../../../glib/gthreadpool.c:307
#21 0x7f45fc9fc415 in g_thread_proxy (data=0x7f45dc004ad0) at 
../../../glib/gthread.c:784
#22 0x7f45fa426fa3 in start_thread (arg=) at 
pthread_create.c:486
#23 0x7f45fad364cf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 72 (Thread 0x7f4541357700 (LWP 20192)):
#0  __gst_fast_write_swap32 (v=4279271552, p=0x7f450826 "") at 
/usr/include/gstreamer-1.0/gst/gstutils.h:207
#1  gst_geometric_transform_transform_frame (vfilter=0x55860fdb5df0, 
in_frame=0x7f45413564b0, out_frame=0x7f4541356750) at 
gstgeometrictransform.c:249
#2  0x7f45ec25fe03 in ?? () from /lib/x86_64-linux-gnu/libgstvideo-1.0.so.0
#3  0x7f45ec1f2609 in default_generate_output (trans=0x55860fdb5df0, 
outbuf=0x7f4541356a60) at gstbasetransform.c:2132
#4  0x7f45ec1f1cd6 in gst_base_transform_chain (pad=, 
parent=0x55860fdb5df0, buffer=) at gstbasetransform.c:2285
#5  0x7f45fcb1bc3a in gst_pad_chain_data_unchecked (data=0x7f45783217a0, 
type=4112, pad=0x7f45d4048810) at gstpad.c:4322
#6  gst_pad_push_data (pad=pad@entry=0x558610029310, type=type@entry=4112, 
data=data@entry=0x7f45783217a0) at gstpad.c:4578
#7  0x7f45fcb23ed2 in gst_pad_push (pad=0x558610029310, 
buffer=0x7f45783217a0) at gstpad.c:4697
#8  0x7f45ec1f1dfd in gst_base_transform_chain (pad=, 
parent=0x55860ed8d8d0, buffer=) at gstbasetransform.c:2321
#9  0x7f45fcb1bc3a in gst_pad_chain_data_unchecked (data=0x7f451f4afea0, 
type=4112, pad=0x7f45e0433ac0) at gstpad.c:4322
#10 gst_pad_push_data (pad=pad@entry=0x7f45e0433d10, type=type@entry=4112, 
data=data@entry=0x7f451f4afea0) at gstpad.c:4578
#11 0x7f45fcb23ed2 in gst_pad_push (pad=0x7f45e0433d10, 
buffer=buffer@entry=0x7f451f4afea0) at gstpad.c:4697
#12 0x7f45d1a72b69 in gst_image_freeze_src_loop (pad=0x7f45e0433d10) at 
gstimagefreeze.c:799
#13 0x7f45fcb50f41 in gst_task_func (task=0x7f45745f93b0) at gsttask.c:332
#14 

Bug#928710: drkonqi segfaults

[John Scott]

Control: tags -1 patch

They have a two line patch that fixes this upstream
https://phabricator.kde.org/D21801

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

Bug#946618: drkonqi: please support large backtraces

[John Scott]

Package: drkonqi
Version: 5.14.5-1
Severity: minor
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have tried to report a bug in Kamoso just now, but unfortunately my
backtrace is so huge Dr. Konqi doesn't like it. At 'Sending the Crash Report'
it says

Error sending the crash report: /Received unexpected error code 114 from
bugzilla. Error message was: Comments cannot be longer than 65535 characters../

When this happens, it should instead send it as an attachment or find another
way.

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

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

Versions of packages drkonqi depends on:
ii  kio   5.54.1-1
ii  libc6 2.28-10
ii  libkf5completion5 5.54.0-1
ii  libkf5configcore5 5.54.0-1+deb10u1
ii  libkf5configgui5  5.54.0-1+deb10u1
ii  libkf5configwidgets5  5.54.0-1
ii  libkf5coreaddons5 5.54.0-1
ii  libkf5crash5  5.54.0-1
ii  libkf5i18n5   5.54.0-1
ii  libkf5idletime5   5.54.0-1
ii  libkf5jobwidgets5 5.54.0-1
ii  libkf5kiocore55.54.1-1
ii  libkf5notifications5  5.54.0-1
ii  libkf5service-bin 5.54.0-1
ii  libkf5service55.54.0-1
ii  libkf5wallet-bin  5.54.0-1
ii  libkf5wallet5 5.54.0-1
ii  libkf5widgetsaddons5  5.54.0-1
ii  libkf5xmlrpcclient5   5.54.0-1
ii  libqt5core5a  5.11.3+dfsg1-1+deb10u2
ii  libqt5dbus5   5.11.3+dfsg1-1+deb10u2
ii  libqt5gui55.11.3+dfsg1-1+deb10u2
ii  libqt5widgets55.11.3+dfsg1-1+deb10u2
ii  libqt5x11extras5  5.11.3-2
ii  libqt5xml55.11.3+dfsg1-1+deb10u2
ii  libstdc++68.3.0-6

drkonqi recommends no packages.

drkonqi suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARMIAB0WIQQd3xxna2VescxVfdXYKFckL7guMwUCXfGdsQAKCRDYKFckL7gu
M8aDAP40UV9SytavbQn/AoNCX5Xbcd7XKNiLoHxH2muanyTz+AEAnvVfa385HDbg
C8fiCzpDBBTo+8q5ZxM/Sii2whlHOgE=
=Jb6c
-END PGP SIGNATURE-

Bug#944017: libsoxr: autopkgtest regression: segmentation fault

[Bernhard Übelacker]

Hello Adrian, hello Paul,
I could reproduce the issue in a minimal
revertable Unstable qemu VM with this command:

/usr/bin/autopkgtest libsoxr -- null


As far as I see the test is called this way:

src/debian/tests/inst-check
  src/inst-check
src/inst-check-soxr
  $gen# line 43, generates test data
  $tmp/3-options-input-fn # line 43, run test

In the end it runs:

dd if=/dev/urandom count=1000 | /tmp/tmp.bQI47Dtfhv/4-split-channels   7 6 
2 2 3

Unfortunately the "inst-check" runs just in the
autopkgtest, but not at build time.


All debugging attempts led me to the location below.
And the lines soxr.c:664 and soxr.c:786 point to
the fix-unaligned-access.patch introduced in bug #942746.

When a packages are installed without this patch the
autopkgtest gets not segfault.

Kind regards,
Bernhard


Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
0x0485210a in lsx_rint16_clip_dither_f (seed0=0x4c51500, n=6735, 
src=0x4ca4270, dest0=0x4c241a0) at ./src/rint-clip.h:67
67  DO_16;
(gdb) bt
#0  0x0485210a in lsx_rint16_clip_dither_f (seed0=0x4c51500, n=6735, 
src=0x4ca4270, dest0=0x4c241a0) at ./src/rint-clip.h:67
#1  _soxr_interleave_f (data_type=, dest0=0x4c241a0, 
src=, n=6735, ch=1, seed=0x4c51500) at ./src/data-io.c:213
#2  0x0484d60f in soxr_output_1ch (p=p@entry=0x4c513e0, i=0, 
dest=dest@entry=0x4c24100, len=, len@entry=6923, 
separated=separated@entry=true) at ./src/soxr.c:664
#3  0x0484d8cc in soxr_process._omp_fn.0 () at ./src/soxr.c:786
#4  0x04bcaa42 in GOMP_parallel (fn=0x484d830 , 
data=0x1fff000800, num_threads=4, flags=0) at 
../../../src/libgomp/parallel.c:171
#5  0x0484ef78 in soxr_process (p=0x4c513e0, in=0x4c24150, 
ilen0=, idone0=0x0, out=0x4c24100, olen=6923, 
odone0=0x1fff0008a8) at ./src/soxr.c:781
#6  0x00109fd8 in main (n=0, arg=0x1fff000b28) at 4-split-channels.c:142

# Unstable amd64 qemu VM 2019-12-12

apt update
apt dist-upgrade


apt install systemd-coredump mc autopkgtest quilt gdb rr valgrind 
libgomp1-dbgsym libsoxr0-dbgsym
apt build-dep libsoxr



##


root@debian:~# autopkgtest libsoxr -- null
...
/tmp/tmp.LScD5ODKNY/3-options-input-fn no error; 0 clips; I/O: no error (cr32s)
Segmentation fault (core dumped)
autopkgtest [00:22:20]: test inst-check: ---]
autopkgtest [00:22:21]: test inst-check:  - - - - - - - - - - results - - - - - 
- - - - -
inst-check   FAIL non-zero exit status 139
autopkgtest [00:22:21]: test inst-check:  - - - - - - - - - - stderr - - - - - 
- - - - -
Segmentation fault (core dumped)
...




root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Thu 2019-12-12 00:22:20 CET2744 0 0  11 present   
/tmp/tmp.LScD5ODKNY/4-split-channels



root@debian:~# journalctl --no-pager
Dez 12 00:22:20 debian kernel: 4-split-channel[2745]: segfault at 0 ip 
7f17b31ec10a sp 7f17b2e79c50 error 6 in 
libsoxr.so.0.1.2[7f17b31e7000+28000]
Dez 12 00:22:20 debian kernel: Code: d0 48 89 94 24 d0 00 00 00 49 c1 e8 06 41 
83 e0 1f 44 29 c7 f2 0f 2a c7 f2 0f 59 c1 f2 0f 58 c2 f2 0f 11 44 24 08 dd 44 
24 08 <41> df 1e 48 89 c7 66 0f ef c0 66 0f ef d2 49 89 d0 48 c1 ef 09 49
Dez 12 00:22:20 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Dez 12 00:22:20 debian systemd[1]: Started Process Core Dump (PID 2756/UID 0).
Dez 12 00:22:20 debian su[2651]: pam_unix(su:session): session closed for user 
root
Dez 12 00:22:20 debian systemd-coredump[2757]: Process 2744 (4-split-channel) 
of user 0 dumped core.
   
   Stack trace of thread 2745:
   #0  0x7f17b31ec10a n/a 
(libsoxr.so.0 + 0x910a)
   #1  0x7f17b31e760f n/a 
(libsoxr.so.0 + 0x460f)
   #2  0x7f17b31e78cc n/a 
(libsoxr.so.0 + 0x48cc)
   #3  0x7f17b2ec0946 n/a 
(libgomp.so.1 + 0x1a946)
   #4  0x7f17b2e88fb7 
start_thread (libpthread.so.0 + 0x8fb7)
   #5  0x7f17b311d2df __clone 
(libc.so.6 + 0xfa2df)
   
   Stack trace of thread 2753:
   #0  0x7f17b2ec32aa n/a 
(libgomp.so.1 + 0x1d2aa)
   #1  0x7f17b2ec0952 n/a 
(libgomp.so.1 + 0x1a952)
   #2  0x7f17b2e88fb7 
start_thread (libpthread.so.0 + 0x8fb7)
   #3  0x7f17b311d2df __clone 
(libc.so.6 + 0xfa2df)
   

Bug#928485: Error messages are not shown without --verbose

[Gunnar Wolf]

tags 928485 + patch,pending
thanks

I have submitted a patch upstream fixing this issue. Merge request
available at:

https://gitlab.com/larswirzenius/vmdb2/merge_requests/4

FWIW, the changes are basically trivial, so I'm inlining them here as
well:

diff --git a/vmdb/app.py b/vmdb/app.py
index 5073a05..30bcf17 100644
--- a/vmdb/app.py
+++ b/vmdb/app.py
@@ -34,7 +34,11 @@ class Vmdb2(cliapp.Application):
 
 self.settings.boolean(
 ['verbose', 'v'],
-'verbose output')
+'verbose output (print out all steps as they are processed). 
Implies (and overrides) output is not set to quiet.')
+
+self.settings.boolean(
+['quiet', 'q'],
+'quiet output (omit printing error messages). Ineffective if 
verbose is set.')
 
 def setup(self):
 self.step_runners = vmdb.StepRunnerList()
@@ -43,7 +47,7 @@ class Vmdb2(cliapp.Application):
 if len(args) != 1:
 sys.exit("No image specification was given on the command line.")
 
-vmdb.set_verbose_progress(self.settings['verbose'])
+vmdb.set_verbose_progress(self.settings['verbose'], 
self.settings['quiet'])
 
 spec = self.load_spec_file(args[0])
 state = vmdb.State()
diff --git a/vmdb/runcmd.py b/vmdb/runcmd.py
index e1d88a5..d37c955 100644
--- a/vmdb/runcmd.py
+++ b/vmdb/runcmd.py
@@ -24,16 +24,18 @@ import cliapp
 
 
 _verbose = False
+_quiet = False
 
-
-def set_verbose_progress(verbose):
+def set_verbose_progress(verbose, quiet):
 global _verbose
+global _quiet
+# Verbose implies not-quiet
 _verbose = verbose
-
+_quiet = verbose | quiet
 
 def error(msg):
 logging.error(msg, exc_info=True)
-if _verbose:
+if not _quiet:
 sys.stderr.write('ERROR: {}\n'.format(msg))
 
 






signature.asc
Description: PGP signature

Bug#946617: dwww: runman prints empty content

[Chad Wallace]

Package: dwww
Version: 1.13.4+nmu3
Severity: important

Dear Maintainer,

After upgrading to buster, I failed to get any man pages showing in my
dwww output.  The  tag is completely empty.

After editing dwww-convert for debugging, I found an error from man:
man: nroff: Bad system call

Then, I found an example of that on another bug report, which led me to
add a line to dwww-convert:

...begin patch
--- dwww-convert.orig   2019-12-11 14:51:25.131093890 -0800
+++ dwww-convert2019-12-11 15:14:02.625790098 -0800
@@ -246,6 +246,7 @@
 $dir =~ s/\/[^\/]*$//;
 chdir ("$dir/..") or die "Can't chdir!\n";
 $ENV{'MAN_KEEP_FORMATTING'} = 1;
+$ENV{'MAN_DISABLE_SECCOMP'} = 1;
 my $IN_FH = ("man  -EUTF-8 -P/bin/cat  -l \"$filename\" 
2>/dev/null | dwww-txt2html --man --utf8", "r");
 chdir ("/");
 while (<$IN_FH>) {
...end patch

That got it working... but I don't really know why. :-)
Hopefully this will lead you to the proper fix!

Thanks!
Chad.


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

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

Versions of packages dwww depends on:
ii  apache2 [httpd-cgi]2.4.38-3+deb10u3
ii  debconf [debconf-2.0]  1.5.71
ii  debianutils4.8.6.1
ii  doc-base   0.10.8
ii  file   1:5.35-4+deb10u1
ii  libc6  2.28-10
ii  libfile-ncopy-perl 0.36-2
ii  libmime-types-perl 2.17-1
ii  man-db 2.8.5-2
ii  mime-support   3.62
ii  perl   5.28.1-6
ii  ucf3.0038+nmu1

Versions of packages dwww recommends:
ii  apache2 [httpd]  2.4.38-3+deb10u3
ii  apt  1.8.2
ii  dlocate  1.07+nmu1
ii  info2www 1.2.2.9-24
ii  swish++  6.1.5-5

Versions of packages dwww suggests:
ii  chromium [www-browser]  78.0.3904.108-1~deb10u1
ii  doc-debian  6.4
pn  dpkg-www
ii  elinks [www-browser]0.13~20190125-3
ii  epiphany-browser [www-browser]  3.32.1.2-3~deb10u1
ii  firefox-esr [www-browser]   68.3.0esr-1~deb10u1
ii  w3m [www-browser]   0.5.3-37

-- Configuration Files:
/etc/apache2/conf-available/dwww.conf changed [not included]

-- debconf information:
* dwww/cgidir: /usr/lib/cgi-bin
* dwww/serverport: 80
  dwww/badport:
* dwww/docrootdir: /var/www
  dwww/nosuchuser:
* dwww/cgiuser: www-data
  dwww/index_docs: false
  dwww/nosuchdir:
* dwww/servername: ws78.int.tlc

Bug#946616: dh_auto_install should honor --destdir

[Paride Legovini]

Package: dh-cargo
Version: 21
Severity: normal

After trying to use `dh_auto_install --destdir` as documented in
dh_auto_install(1) I noticed that the option doesn't produce any effect.
I had a quick look at [1] and it seems that the option is currently
being ignored.

When packaging "binary" crates (= not libraries) it is sometimes very
useful to have the files installed in debian/tmp instead of to
debian/pkgname, as this allows more freedom to choose how to actually
install the files in the Debian package using e.g. dh_install and dh-exec.

Paride

[1] /usr/share/perl5/Debian/Debhelper/Buildsystem/cargo.pm

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

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

Versions of packages dh-cargo depends on:
ii  cargo  0.40.0-2
ii  debhelper  12.7.2
ii  perl   5.30.0-9
ii  python33.7.5-3

dh-cargo recommends no packages.

dh-cargo suggests no packages.

-- no debconf information

Bug#946606: libc-bin: catchsegv does not handle backtraces with parentheses

[Bernhard Übelacker]

Dear Maintainer,
sorry, did attempt to output the build-id unconditionally,
fixed in attached patch version.

Kind regards,
Bernhard
>From 0a4a73d4eeaa45acdbeb6ea8fea878e134cbc11b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Wed, 11 Dec 2019 19:56:39 +0100
Subject: Make catchsegv work again after format changed and add build-ids.

https://sourceware.org/bugzilla/show_bug.cgi?id=21830
---
 debug/backtracesymsfd.c | 32 +-
 debug/catchsegv.sh  | 50 -
 2 files changed, 70 insertions(+), 12 deletions(-)

diff --git a/debug/backtracesymsfd.c b/debug/backtracesymsfd.c
index 5751d62f..9bc058fb 100644
--- a/debug/backtracesymsfd.c
+++ b/debug/backtracesymsfd.c
@@ -35,13 +35,14 @@
 void
 __backtrace_symbols_fd (void *const *array, int size, int fd)
 {
-  struct iovec iov[9];
+  struct iovec iov[12];
   int cnt;
 
   for (cnt = 0; cnt < size; ++cnt)
 {
   char buf[WORD_WIDTH];
   char buf2[WORD_WIDTH];
+  char buf3[WORD_WIDTH];
   Dl_info info;
   struct link_map *map;
   size_t last = 0;
@@ -96,6 +97,35 @@ __backtrace_symbols_fd (void *const *array, int size, int fd)
    - (char *) iov[last].iov_base);
 	  ++last;
 
+	  /* Even when we have a symbol name, print the file offset to
+	 make processing in addr2line possible. */
+	  if (info.dli_sname != NULL)
+		{
+		  iov[last].iov_base = (void *) ",";
+		  iov[last].iov_len = 1;
+		  ++last;
+
+		  if (array[cnt] >= (void *) map->l_addr)
+		{
+		  iov[last].iov_base = (void *) "+0x";
+		  diff = array[cnt] - (void *) map->l_addr;
+		}
+		  else
+		{
+		  iov[last].iov_base = (void *) "-0x";
+		  diff = (void *) map->l_addr - array[cnt];
+		}
+		  iov[last].iov_len = 3;
+		  ++last;
+
+		  iov[last].iov_base = _itoa_word ((unsigned long int) diff,
+		   [WORD_WIDTH], 16, 0);
+		  iov[last].iov_len = ([WORD_WIDTH]
+		   - (char *) iov[last].iov_base);
+		  ++last;
+
+		}
+
 	  iov[last].iov_base = (void *) ")";
 	  iov[last].iov_len = 1;
 	  ++last;
diff --git a/debug/catchsegv.sh b/debug/catchsegv.sh
index 245c100f..fd6a232a 100755
--- a/debug/catchsegv.sh
+++ b/debug/catchsegv.sh
@@ -52,6 +52,7 @@ Written by Ulrich Drepper.'
 fi
 
 segv_output=`mktemp ${TMPDIR:-/tmp}/segv_output.XX` || exit
+used_libs=`mktemp ${TMPDIR:-/tmp}/used_libs.XX` || exit
 
 # Redirect stderr to avoid termination message from shell.
 (exec 3>&2 2>/dev/null
@@ -87,21 +88,48 @@ if test -s "$segv_output"; then
   sed '/Backtrace/q' "$segv_output"
   sed '1,/Backtrace/d' "$segv_output" |
   (while read line; do
- line=`echo $line | sed "s@^$prog\\(\\[.*\\)@\1@"`
  case "$line" in
-   \[*) addr=`echo "$line" | sed 's/^\[\(.*\)\]$/\1/'`
-	complete=`addr2line -f -e "$prog" $addr 2>/dev/null`
-	if test $? -eq 0; then
-	  echo "`echo "$complete"|sed 'N;s/\(.*\)\n\(.*\)/\2(\1)/;'`$line"
-	else
-	  echo "$line"
-	fi
-	;;
-	 *) echo "$line"
-	;;
+   *\(*\)\[*\])
+ lib=`echo $line  | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\1@"`
+ offs=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\2@"`
+ addr=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\3@"`
+ func=""
+ case "$offs" in
+   *,*) func=`echo $offs | sed "s@\(.*\),\(.*\)\\$@\1,@"`
+offs=`echo $offs | sed "s@\(.*\),\(.*\)\\$@\2@"`
+;;
+ esac
+ case "$offs" in
+   +*) case "$prog" in
+ */$lib)
+   lib="$prog"
+   ;;
+   esac
+   complete=`addr2line -p -i -f -e "$lib" $offs 2>/dev/null`
+   if test $? -eq 0; then
+ echo " [$addr] $complete $lib($func$offs)"
+   else
+ echo " $line"
+   fi
+   ;;
+   *) echo " $line"
+  ;;
+ esac
+ echo "$lib" >> "$used_libs"
+ ;;
+*) echo "$line"
+   ;;
  esac
done)
+  objdumptest=`objdump --version 2>/dev/null`
+  if test $? -eq 0; then
+echo "\nBuild-IDs:"
+sort -u "$used_libs" | while read lib; do
+  objdump -s -j .note.gnu.build-id "$lib"
+done
+  fi
 fi
 rm -f "$segv_output"
+rm -f "$used_libs"
 
 exit $exval
-- 
2.24.0

Bug#946599: libcrypt1: failure to switch from libc6 to libcrypt1 hoses the whole system

[Thorsten Glaser]

Aurelien Jarno dixit:

>I am not sure we can use a Pre-Depends given we have a dependency loop,

Ah, dependency loops cause unpredictable behaviour…

>I thing that's the issue. Multi-Arch forces some order for all the
>versions of libc6, and also all the versions of libcrypt1.

… plus that.

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

Bug#946606: libc-bin: catchsegv does not handle backtraces with parentheses

[Bernhard Übelacker]

Dear Maintainer,
while I was at it, I attempted to change the output to
deliver the before mentioned information for addr2line too.

Attached is a improved patch, that would now output following:

Backtrace:
 [0x55f317f9175b] main at 
/usr/share/doc/libsoxr-dev/examples/3-options-input-fn.c:79 (discriminator 4) 
/tmp/tmp.sSrfzsTKpn/3-options-input-fn(+0x175b)
 [0x7fd67920fbbb] __libc_start_main at 
/root/source/glibc/try1/glibc-2.29/csu/../csu/libc-start.c:342 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb,+0x26bbb)
 [0x55f317f911ba] _start at ??:? /tmp/tmp.sSrfzsTKpn/3-options-input-fn(+0x11ba)

At the end there is another small change to add the build-ids
of the in the backtrace involved binaries to the output.

Kind regards,
Bernhard
>From cb1fdbd4e5a7fbeb1de27b72a7945a0b4789d251 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Wed, 11 Dec 2019 19:56:39 +0100
Subject: Make catchsegv work again after format changed and add build-ids.

https://sourceware.org/bugzilla/show_bug.cgi?id=21830
---
 debug/backtracesymsfd.c | 32 +-
 debug/catchsegv.sh  | 51 -
 2 files changed, 71 insertions(+), 12 deletions(-)

diff --git a/debug/backtracesymsfd.c b/debug/backtracesymsfd.c
index 5751d62f..9bc058fb 100644
--- a/debug/backtracesymsfd.c
+++ b/debug/backtracesymsfd.c
@@ -35,13 +35,14 @@
 void
 __backtrace_symbols_fd (void *const *array, int size, int fd)
 {
-  struct iovec iov[9];
+  struct iovec iov[12];
   int cnt;
 
   for (cnt = 0; cnt < size; ++cnt)
 {
   char buf[WORD_WIDTH];
   char buf2[WORD_WIDTH];
+  char buf3[WORD_WIDTH];
   Dl_info info;
   struct link_map *map;
   size_t last = 0;
@@ -96,6 +97,35 @@ __backtrace_symbols_fd (void *const *array, int size, int fd)
    - (char *) iov[last].iov_base);
 	  ++last;
 
+	  /* Even when we have a symbol name, print the file offset to
+	 make processing in addr2line possible. */
+	  if (info.dli_sname != NULL)
+		{
+		  iov[last].iov_base = (void *) ",";
+		  iov[last].iov_len = 1;
+		  ++last;
+
+		  if (array[cnt] >= (void *) map->l_addr)
+		{
+		  iov[last].iov_base = (void *) "+0x";
+		  diff = array[cnt] - (void *) map->l_addr;
+		}
+		  else
+		{
+		  iov[last].iov_base = (void *) "-0x";
+		  diff = (void *) map->l_addr - array[cnt];
+		}
+		  iov[last].iov_len = 3;
+		  ++last;
+
+		  iov[last].iov_base = _itoa_word ((unsigned long int) diff,
+		   [WORD_WIDTH], 16, 0);
+		  iov[last].iov_len = ([WORD_WIDTH]
+		   - (char *) iov[last].iov_base);
+		  ++last;
+
+		}
+
 	  iov[last].iov_base = (void *) ")";
 	  iov[last].iov_len = 1;
 	  ++last;
diff --git a/debug/catchsegv.sh b/debug/catchsegv.sh
index 245c100f..8d8a38f0 100755
--- a/debug/catchsegv.sh
+++ b/debug/catchsegv.sh
@@ -52,6 +52,7 @@ Written by Ulrich Drepper.'
 fi
 
 segv_output=`mktemp ${TMPDIR:-/tmp}/segv_output.XX` || exit
+used_libs=`mktemp ${TMPDIR:-/tmp}/used_libs.XX` || exit
 
 # Redirect stderr to avoid termination message from shell.
 (exec 3>&2 2>/dev/null
@@ -87,21 +88,49 @@ if test -s "$segv_output"; then
   sed '/Backtrace/q' "$segv_output"
   sed '1,/Backtrace/d' "$segv_output" |
   (while read line; do
- line=`echo $line | sed "s@^$prog\\(\\[.*\\)@\1@"`
  case "$line" in
-   \[*) addr=`echo "$line" | sed 's/^\[\(.*\)\]$/\1/'`
-	complete=`addr2line -f -e "$prog" $addr 2>/dev/null`
-	if test $? -eq 0; then
-	  echo "`echo "$complete"|sed 'N;s/\(.*\)\n\(.*\)/\2(\1)/;'`$line"
-	else
-	  echo "$line"
-	fi
-	;;
-	 *) echo "$line"
-	;;
+   *\(*\)\[*\])
+ lib=`echo $line  | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\1@"`
+ offs=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\2@"`
+ addr=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\3@"`
+ func=""
+ case "$offs" in
+   *,*) func=`echo $offs | sed "s@\(.*\),\(.*\)\\$@\1,@"`
+offs=`echo $offs | sed "s@\(.*\),\(.*\)\\$@\2@"`
+;;
+ esac
+ case "$offs" in
+   +*) case "$prog" in
+ */$lib)
+   lib="$prog"
+   ;;
+   esac
+   complete=`addr2line -p -i -f -e "$lib" $offs 2>/dev/null`
+   if test $? -eq 0; then
+ echo " [$addr] $complete $lib($func$offs)"
+   else
+ echo " $line"
+   fi
+   ;;
+   *) echo " $line"
+  ;;
+ esac
+ echo "$lib" >> "$used_libs"
+ ;;
+*) echo "$line"
+   ;;
  esac
done)
 fi
 rm -f "$segv_output"
 
+objdumptest=`objdump --version 2>/dev/null`
+if test $? -eq 0; then
+  echo "\nBuild-IDs:"
+  sort -u /tmp/used_libs.kUDu9V | while read lib; do
+objdump -s -j .note.gnu.build-id "$lib"
+  done
+fi
+rm 

Bug#946613: Consider making gtk3.22-client the one installed by 'freeciv' package

[Markus Koschany]

Am 11.12.19 um 23:38 schrieb Marko Lindqvist:
[...]
>  Sorry, I didn't mean to file a bug about README.packaging, but about
> $subject. I just noticed the error in README.packaging when quoting it
> for you, so wanted to clarify the situation. Sorry for the confusion.

Hmm, the freeciv binary package already depends on freeciv-client-gtk3
which in turn depends on the latest gtk3.x version in Debian. I'm not
sure how I can improve that.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#946615: Please make autopkgtests cross-test-friendly

[Sebastien Bacher]

Package: libvncserver
Version: 0.9.12+dfsg-3
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can
do the right thing.

The libssh tests currently fail in this environment, because they are
build tests that do not invoke the toolchain in a cross-aware manner. 
I've verified that the attached patch lets the tests successfully build
(and run) i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so
this is a complete no-op in Debian for the moment.  Support for
cross-testing in autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a
'-a' option.  So this change should be safe to land in your package
despite this not being upstream in autopkgtest.

Thanks for considering,



diff -Nru libvncserver-0.9.12+dfsg/debian/changelog libvncserver-0.9.12+dfsg/debian/changelog
--- libvncserver-0.9.12+dfsg/debian/changelog	2019-12-11 17:25:41.0 +0100
+++ libvncserver-0.9.12+dfsg/debian/changelog	2019-12-11 23:26:23.0 +0100
@@ -1,3 +1,11 @@
+libvncserver (0.9.12+dfsg-5) unstable; urgency=medium
+
+  * debian/tests:
+- Use the correct compiler for proposed autopkgtest cross-testing
+  support.
+
+ -- Sebastien Bacher   Wed, 11 Dec 2019 23:26:00 +0100
+
 libvncserver (0.9.12+dfsg-4) unstable; urgency=medium
 .
   [ Antoni Villalonga ]
diff -Nru libvncserver-0.9.12+dfsg/debian/tests/smoketest-libvncclient libvncserver-0.9.12+dfsg/debian/tests/smoketest-libvncclient
--- libvncserver-0.9.12+dfsg/debian/tests/smoketest-libvncclient	2019-12-11 08:01:51.0 +0100
+++ libvncserver-0.9.12+dfsg/debian/tests/smoketest-libvncclient	2019-12-11 23:25:54.0 +0100
@@ -2,6 +2,13 @@
 set -e
 
 cd "$AUTOPKGTEST_TMP"
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat > test.c << EOF
 #include 
 
@@ -14,6 +21,6 @@
 }
 
 EOF
-gcc -Wall -o test test.c -lvncclient
+${CROSS_COMPILE}gcc -Wall -o test test.c -lvncclient
 ./test
 objdump -p test | grep "libvncclient"
diff -Nru libvncserver-0.9.12+dfsg/debian/tests/smoketest-libvncserver libvncserver-0.9.12+dfsg/debian/tests/smoketest-libvncserver
--- libvncserver-0.9.12+dfsg/debian/tests/smoketest-libvncserver	2019-12-11 08:01:51.0 +0100
+++ libvncserver-0.9.12+dfsg/debian/tests/smoketest-libvncserver	2019-12-11 23:25:38.0 +0100
@@ -2,6 +2,13 @@
 set -e
 
 cd "$AUTOPKGTEST_TMP"
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat > test.c << EOF
 #include 
 #include 
@@ -16,6 +23,6 @@
 }
 
 EOF
-gcc -Wall -o test test.c -lvncserver
+${CROSS_COMPILE}gcc -Wall -o test test.c -lvncserver
 ./test
 objdump -p test | grep "libvncserver"

Bug#946613: Consider making gtk3.22-client the one installed by 'freeciv' package

[Markus Koschany]

Hi Marko,

Am 11.12.19 um 22:46 schrieb Marko Lindqvist:
> Package: freeciv
> Version:   2.6.0-4
> 
> Freeciv doc/README.packaging about the new gtk3.22-client:
> "This client suits better for systems with gtk+-3.22 than the
> gtk3-client compatible with much older gtk+ versions."
> 
>  (Since that text has been written, gtk+ project changed their
> decision that 3.22 would be the last version of gtk+-3. Above should
> say that "...systems with gtk+-3.22 or gtk+-3.24...")

aren't you one of the upstream developers of Freeciv? If you change the
text upstream, Debian will automatically import the new
README.packaging. No need to file a bug report in this case. However I'm
always happy if you guys comment on the existing Debian bugs, especially
the ones related to game play or GUI design.

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#946599: libcrypt1: failure to switch from libc6 to libcrypt1 hoses the whole system

[Aurelien Jarno]

On 2019-12-11 17:54, Marco d'Itri wrote:
> On Dec 11, Thorsten Glaser  wrote:
> 
> > Thankfully, I had a root session in a chroot open and used
> > the program, statically linked, from http://koltsoff.com/pub/getroot/
> > to recover access outside the chroot, by using dpkg -i --force-all
> > first on libc6_*.deb, then libcrypt1_*.deb. Afterwards, normal recovery
> > mechanisms apply.
> I suspect that ldconfig would have been enough to fix this.
> 
> Theory A: maybe after all we really need some Pre-Depends in libc6?

A Depends should be enough, we don't need the package fully configured,
just unpacked. In the machines that I have upgraded, libcrypt1 is
unpacked before libc6, so it works.

I am not sure we can use a Pre-Depends given we have a dependency loop,
libcrypt1 depends on libc6 and libc6 depends on libcrypt1. In addition
we also have a Breaks + Replaces...

> Theory B: did we miss something related to x32?

On 2019-12-11 17:57, Thorsten Glaser wrote:
> Given it worked in the amd64-only chroot and on another machine,
> this most likely only fails if one has more than one architecture
> enabled in Multi-Arch, perhaps also needs the -dev packages installed
> to trigger.

I thing that's the issue. Multi-Arch forces some order for all the
versions of libc6, and also all the versions of libcrypt1.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#946198: Since upgrading to 1.25.13 no remote printer is made available anymore

[Simon John]

I've not seen either of my remote printers disappear, but am now getting 
"The PPD file for this printer is damaged" whenever I double-click on 
the printer in the print settings gui.


I downgraded cups-browsed to cups-browsed_1.25.12-1_amd64.deb but also 
get the error, so suspect its the filter or something that's gone wrong.


In /var/log/cups/error.log I get a lot of:

E [11/Dec/2019:22:05:53 +] [CGI] Saw EOF, expected \'}\'!

Which seem to point to bug #737709

I can still print fine to remote printers though (debian and raspbian 
servers) and the cups web interface doesn't show any errors.


Regards.

--
Simon John

Bug#946614: keystone: CVE-2019-19687

[Salvatore Bonaccorso]

Source: keystone
Version: 2:16.0.0-4
Severity: grave
Tags: security upstream
Forwarded: https://bugs.launchpad.net/keystone/+bug/1855080

Hi,

The following vulnerability was published for keystone.

CVE-2019-19687[0]:
| OpenStack Keystone 15.0.0 and 16.0.0 is affected by Data Leakage in
| the list credentials API. Any user with a role on a project is able to
| list any credentials with the /v3/credentials API when enforce_scope
| is false. Users with a role on a project are able to view any other
| users' credentials, which could (for example) leak sign-on information
| for Time-based One Time Passwords (TOTP). Deployments with
| enforce_scope set to false are affected. (There will be a slight
| performance impact for the list credentials API once this issue is
| fixed.)


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-2019-19687
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19687
[1] https://bugs.launchpad.net/keystone/+bug/1855080

Regards,
Salvatore

Bug#946613: Consider making gtk3.22-client the one installed by 'freeciv' package

[Marko Lindqvist]

Package: freeciv
Version:   2.6.0-4

Freeciv doc/README.packaging about the new gtk3.22-client:
"This client suits better for systems with gtk+-3.22 than the
gtk3-client compatible with much older gtk+ versions."

 (Since that text has been written, gtk+ project changed their
decision that 3.22 would be the last version of gtk+-3. Above should
say that "...systems with gtk+-3.22 or gtk+-3.24...")

 - ML

Bug#933997: gamemode isn't automatically activated for rise of the tomb raider

[Axel Regnat]

I've seen you uploaded a new version and tested again with shadow of the 
tomb raider (I currently don't have rise of the tomb raider installed). 
It seems that everything works fine now on my end. Gamemode is active 
while running the game without the need to set gamemoderun %command%. 
Thanks for your work.


Axel

Bug#946612: sqlite3: CVE-2019-19645

[Salvatore Bonaccorso]

Source: sqlite3
Version: 3.30.1-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for sqlite3.

CVE-2019-19645[0]:
| alter.c in SQLite through 3.30.1 allows attackers to trigger infinite
| recursion via certain types of self-referential views in conjunction
| with ALTER TABLE statements.


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-2019-19645
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19645
[1] 
https://github.com/sqlite/sqlite/commit/38096961c7cd109110ac21d3ed7dad7e0cb0ae06

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#946368: DeprecationWarning for using collections instead of collections.abc

[Toni Mueller]

Hi Thomas,

On Tue, Dec 10, 2019 at 08:47:02PM +0100, Thomas Goirand wrote:
> Do you feel like doing the work yourself for this? I have too many
> things to watch for stable updates...

I am strongly considering it if it's ok for you.


Cheers,
Toni

Bug#946580: No coqidetop in coq package breaks editor plugins

[Ralf Treinen]

Hello,

On Wed, Dec 11, 2019 at 10:31:57AM +0100, Julien Lepiller wrote:
> Package: coq
> Version: 8.9.0-1
> 
> Hi, sorry in advance if my message is not formated correctly. I'm not a 
> debian user, but I'm trying my best :)

your bug report is fine, don't worry ;-)

> I'm the developer of a coq plugin in neovim called coquille. One of my users 
> reported a failure at starting the plugin due to coq not being found, 
> although the package was installed. We have determined that the issue was 
> caused by the absence of coqidetop, although they had coq 8.9 installed.
> 
> Before coq 8.9, I could use coqtop with the -ide-slave option. That option is 
> now replaced by a separate binary, coqidetop, that I need in order to 
> evaluate coq expressions from my plugin.

coq 8.9.0 had building of the coqide switched off, and as a consequence there
was no coqide package for that version. I am currently working on updating
the coq package to version 8.10.2, including a coqide package. That package
will also include the coqidetop binary. I hope to upload the package
in the next days, but then it will have to be accepted by the ftp masters
before it will be visible in unstable, and I don't know how long that
will take.

-Ralf.

Bug#946611: ITP: golang-github-abeconnelly-autoio -- Golang io functions that provide standard scanner interfaces for compressed files.

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Package: wnpp
Severity: wishlist
Owner: Michael R. Crusoe 

* Package name: golang-github-abeconnelly-autoio
  Version : 0.0~git20150803.989b7b0-1
  Upstream Author : Abram Connelly
* URL : https://github.com/abeconnelly/autoio
* License : AGPL-3
  Programming Lang: Go
  Description : Golang IO functions that provide standard scanner 
interfaces for compressed files.

 autoio.go A lightweight (and work in progress) Go library to provide
 a simple interface to use compressed files like you use normal files.

 Needed for packaging https://github.com/arvados/l7g

Bug#946607: numpy: Please add stage1 sbuild profile for bootstrapping

[John Paul Adrian Glaubitz]

On 12/11/19 9:23 PM, Helmut Grohne wrote:
>> Normally, this is fixed by adding a stage1 sbuild profile for boostrapping
>> the package. When building with the stage1 profile, the build dependency
>> on python3-scipy should be disabled (i.e. python3-scipy [!stage1]) such that
>> the numpy package can be built without scipy.
> 
> I disagree. stage1 usually is the last resort for such situations. It
> should not be added lightly. In fact, stage1 has been deprecated as a
> profile for this reason. It shouldn't be introduced at all anymore.

Meh, whatever it's called these days.

>> Can you add such a stage1 profile so I can bootstrap numpy for all the
>> architectures where it's currently BD-Uninstallable?
> 
> Please don't. stage1 is undescriptive and in three years nobody will
> know what it was being added for.

I don't have a strong opinion on it. If it needs to be called !pkg.bla.foo,
I'm fine with that, too.

> That said, the BD-Uninstallable situation and the circular dependency
> are real and they deserve a solution. Let's try the less heavy
> approaches first:
>  * Maybe scipy is only used for testing numpy or vice versa? Then one
>could be annotated  and we'd be done.
>  * Similarly, maybe one is only needed for building Arch:all packages?
>Then maybe it could be demoted to Build-Depends-Indep. With luck
>that could also mean we're done.
>  * If that really doesn't help, we need to figure out how they integrate
>with one another. We need to describe the feature that they enable
>and add a descriptive profile for disabling that feature.
> 
> So please try  and Build-Depends-Indep before asking for a
> profile. These standard measures are regularly tested and have meaning
> beyond bootstrapping. Only if that fails, document and understanding for
> what features actually cause the cycle and add a profile disabling such
> a feature in particular.

My main point was notify about this circular dependency problem that should
always be resolved because these situations can always occur with packages
with circular dependencies. This is why packages like ffmpeg are always
rebootstrappable.

I haven't looked at the details yet. I normally assume that the maintainer
knows which of the two affected packages can be temporarily built with
the other.

But I can have a look tomorrow.

> Thank you. Also thanks for Ccing me.

Of course.

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#946198: Since upgrading to 1.25.13 no remote printer is made available anymore

[Till Kamppeter]

I have done several fixes on cups-filters upstream now, please try a current GIT 
snapshot of cups-filters.


   Till

Bug#946607: numpy: Please add stage1 sbuild profile for bootstrapping

[Helmut Grohne]

Hi,

On Wed, Dec 11, 2019 at 08:18:39PM +0100, John Paul Adrian Glaubitz wrote:
> numpy is currently BD-Uninstallable on a number of architectures due to
> a circular dependency with scipy.
> 
> Normally, this is fixed by adding a stage1 sbuild profile for boostrapping
> the package. When building with the stage1 profile, the build dependency
> on python3-scipy should be disabled (i.e. python3-scipy [!stage1]) such that
> the numpy package can be built without scipy.

I disagree. stage1 usually is the last resort for such situations. It
should not be added lightly. In fact, stage1 has been deprecated as a
profile for this reason. It shouldn't be introduced at all anymore.

> Can you add such a stage1 profile so I can bootstrap numpy for all the
> architectures where it's currently BD-Uninstallable?

Please don't. stage1 is undescriptive and in three years nobody will
know what it was being added for.

That said, the BD-Uninstallable situation and the circular dependency
are real and they deserve a solution. Let's try the less heavy
approaches first:
 * Maybe scipy is only used for testing numpy or vice versa? Then one
   could be annotated  and we'd be done.
 * Similarly, maybe one is only needed for building Arch:all packages?
   Then maybe it could be demoted to Build-Depends-Indep. With luck
   that could also mean we're done.
 * If that really doesn't help, we need to figure out how they integrate
   with one another. We need to describe the feature that they enable
   and add a descriptive profile for disabling that feature.

So please try  and Build-Depends-Indep before asking for a
profile. These standard measures are regularly tested and have meaning
beyond bootstrapping. Only if that fails, document and understanding for
what features actually cause the cycle and add a profile disabling such
a feature in particular.

Thank you. Also thanks for Ccing me.

Helmut

Bug#945426: pylint doesn't ship the test libraries anymore

[Sandro Tosi]

> FYI what I'm looking for is the test_functional-related classes
> and those have been moved to pylint/testutils.py in the upcoming
> version 2.5 so we can also wait until that new version is released and
> leave the tests in the source package only tooif you want.

i'd be ok to leave things as-is in pylint/2.4 and wait for pylint/2.5
to expose that functionality, but it depends on how much of
pylint-django is broken with the current pylint in debian; let me know

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

Bug#946395: RFS: mercurial-extension-utils/1.5.0-1 -- Contains functions for writing Mercurial extensions

[Christoph Mathys]

On 11.12.19 13:36, Andrej Shadura wrote:

Hi,

On Sun, 8 Dec 2019 at 15:57, Andrej Shadura  wrote:

I am looking for a sponsor for my package "mercurial-extension-utils"



I’ll sponsor both of your packages.


Wait, but the mercurial package hasn’t switched over to Python 3 yet,
I don’t think it would make sense to upload these two yet?


No, it has not. I figured it is better to upload a new version now that 
will not work until mercurial is switched to python3 than this package 
getting kicked out of Debian. Changing the current mercurial version to 
python3 seems to work, at least for my simple testcases.


Would it be better to just wait until mercurial has switched and then 
add this package again?

Bug#946561: Bug #946561

[Stefano Fabri]

Try to apt-get install hplip when you have in the system python >=3.8
(https://packages.debian.org/experimental/python3).

In this status hplip is not installable.

Bug#946610: zfs-dkms: livelock between ZFS evict and writeback threads

[Heitor Alves de Siqueira]

Source: zfs-linux
Severity: normal

Dear Maintainer,

For certain ZFS workloads, we start seeing hung task timeouts in the kernel 
logs due to zil_commit() stalling. This is due to zfs_zget() not detecting 
whether a znode has been marked for deletion before attempting to access it, 
causing a constant "retry loop" in zfs_get_data() if that znode has been 
unlinked already. An example of the stack traces follows:

[72742.051703] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[72742.070429] mysqld  D0  5713   2881 0x0320
[72742.073220] Call Trace:
[72742.075305]  __schedule+0x24e/0x880
[72742.090436]  schedule+0x2c/0x80
[72742.090438]  schedule_preempt_disabled+0xe/0x10
[72742.090441]  __mutex_lock.isra.5+0x276/0x4e0
[72742.090547]  ? dmu_tx_destroy+0x105/0x130 [zfs]
[72742.090555]  __mutex_lock_slowpath+0x13/0x20
[72742.115374]  ? __mutex_lock_slowpath+0x13/0x20
[72742.132266]  mutex_lock+0x2f/0x40
[72742.134207]  zil_commit_impl+0x1b0/0x1b30 [zfs]
[72742.150428]  ? spl_kmem_alloc+0x115/0x180 [spl]
[72742.152622]  ? mutex_lock+0x12/0x40
[72742.154819]  ? zfs_refcount_add_many+0x9a/0x100 [zfs]
[72742.171450]  zil_commit+0xde/0x150 [zfs]
[72742.173687]  zfs_fsync+0x77/0xe0 [zfs]
[72742.175044]  zpl_fsync+0x80/0x110 [zfs]
[72742.191690]  vfs_fsync_range+0x51/0xb0
[72742.193876]  do_fsync+0x3d/0x70
[72742.195126]  SyS_fsync+0x10/0x20
[72742.211059]  do_syscall_64+0x73/0x130
[72742.214078]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2

It's possible to hit this issue due to a race between the ZFS evict and 
writeback threads. If the z_iput task is trying to evict a znode that's 
currently sitting in the writeback thread, both will "livelock" each other and 
stall the ZIO pipeline, causing other ZFS operations (such as zil_commit) to 
hang indefinitely.

This has been documented and fixed upstream in PR#9583 [0]. We need to pull two 
fixes from upstream: the first one fixes the zfs_zget() issue in the writeback 
thread, while the second fixes a regression on O_TMPFILE descriptors caused by 
the first one.

Upstream patches:
 - Break out of zfs_zget early if unlinked znode (41e1aa2a06f8) [1]
 - Check for unlinked znodes after igrab() (0c46813805f4) [2]

[0] https://github.com/zfsonlinux/zfs/pull/9583
[1] https://github.com/zfsonlinux/zfs/commit/41e1aa2a06f8
[2] https://github.com/zfsonlinux/zfs/commit/0c46813805f4

Bug#946607: numpy: Please add stage1 sbuild profile for bootstrapping

[Sandro Tosi]

> Can you add such a stage1 profile so I can bootstrap numpy for all the
> architectures where it's currently BD-Uninstallable?

can you provide a patch?

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

Bug#946609: resolvconf: broken init script: "/run/resolvconf is neither a directory nor a symbolic link"

[Jakub Wilk]

Package: resolvconf
Version: 1.80
Tags: patch

The create_runtime_directories() function in the resolvconf init script 
worked under assumption that $RUN_DIR is a symlink (either broken or 
pointing to a directory). Now that $RUN_DIR is just /run/resolvconf, 
resolvconf no longer starts on boot:


  Setting up resolvconf...failed (/run/resolvconf is neither a directory nor a 
symbolic link).


-- System Information:
Architecture: i386

Versions of packages resolvconf depends on:
ii  lsb-base 11.1.0
ii  debconf  1.5.73

--
Jakub Wilk
--- /etc/init.d/resolvconf	2019-12-10 16:45:20.0 +0100
+++ /etc/init.d/resolvconf	2019-12-11 20:30:41.564651091 +0100
@@ -54,11 +54,8 @@
 {
 	umask 022
 	if [ ! -d "$RUN_DIR" ] ; then
-		[ -L "$RUN_DIR" ] || log_action_end_msg_and_exit 1 "$RUN_DIR is neither a directory nor a symbolic link"
-		# It's a symlink. Its target is not a dir.
-		{ RUN_CANONICALDIR="$(readlink -f "$RUN_DIR")" && [ "$RUN_CANONICALDIR" ] ; } || log_action_end_msg_and_exit 1 "Canonical path of the run directory could not be determined"
 		# Create directory at the target
-		mkdir "$RUN_CANONICALDIR" || log_action_end_msg_and_exit 1 "Error creating directory $RUN_CANONICALDIR"
+		mkdir "$RUN_DIR" || log_action_end_msg_and_exit 1 "Error creating directory $RUN_DIR"
 	fi
 	# The resolvconf run directory now exists.
 	if [ ! -d "${RUN_DIR}/interface" ] ; then

Bug#946608: shadow: [INTL:nl] Dutch po file for the shadow package

[Frans Spiesschaert]

Package: shadow
Severity: wishlist
Tags: l10n patch 


Dear Maintainer,

Please find attached the Dutch po file for the shadow package.
It should be put as "po/nl.po" in your package build tree.
The translation is updated to the 2019-06-13 templates (pot) file
(shadow_1_4.7-2).
In addition, the translation was also adapted to the guidelinesof the 
Translation Project for translating man pages into Dutch.

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#946198: Since upgrading to 1.25.13 no remote printer is made available anymore

[Brian Potkin]

On Fri 06 Dec 2019 at 15:31:59 +, Brian Potkin wrote:

> tags 946198 upstream
> thanks
> 
> 
> On Fri 06 Dec 2019 at 11:08:19 +0100, Michael Meskes wrote:
> 
> > > Which printers list? An application dialog?
> > 
> > Oops, sorry, I was referring to the printers tab on localhost:631. In
> > the add printer dialog on the administration tab they are still listed.
> > All application dialogs do not list the printers anymore either.
> > 
> > > The outputs of 'lpstat -a' and 'lpstat -l -e', please. Activating
> > > logging
> > 
> > 'lpstat -a' does not list any of the printers, 'lpstat -l -e' lists
> > them all.
> 
> The first command outputs local print queues; cups-browsed should form
> these from what CUPS tells it with, essentially, the second command. It
> obviously isn't doing that.
> 
> BTW, printing should still be available to you with 'lp -d...'. Also, if
> you stop cups-browsed, the dialogs of LibreOffice and Qt apps (and maybe
> GTK apps) should list printers and print queues.
>  
> > > in cups-browsed.conf and taking a look at a log wouldn't be a bad
> > > idea.
> > 
> > Fri Dec  6 11:00:58 2019 Removing entry B...
> > (ipps://host.local:631/printers/B...) and its CUPS queue.
> > Fri Dec  6 11:00:58 2019 Recording printer options for B... to
> > /var/cache/cups/cups-browsed-options-B...
> > Fri Dec  6 11:00:58 2019 Unable to get PPD file for B...: The printer
> > or class does not exist.
> > Fri Dec  6 11:00:58 2019 Unable to load PPD from local queue B...,
> > queue seems to be raw.
> > Fri Dec  6 11:00:58 2019 ERROR: Failed disabling printer 'B...': The
> > printer or class does not exist.
> > 
> > I guess that explains why the printer is no longer active, but what
> > changed from the prior version of cups-browsed? I just verified again,
> > downgrading cups-browsed from 1.25.13-1 to 1.25.12-1 fixes the problem
> > and makes the printers appear again. And, yes, I can print on any of
> > them without an issue. Or in other words, the system does have a PPD
> > for the printer.
> > 
> > Any idea?
> 
> In the past I have stopped cups and cups-browsed and removed the files
> in /var/cache/cups, checked that there aren't any files in /etc/cups/ppd
> and that /etc/cups/printers.conf is empty, then restarted the cups and
> cups-browsed services.
> 
> If you do not get anywhere, please report it upstream at
> 
> https://github.com/OpenPrinting/cups-filters/issues
> 
> perhaps after reading
> 
> https://github.com/OpenPrinting/cups-filters/issues/124

Any news?

Regards,
 
Brian.

Bug#870641:

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2019-12-11 at 12:38 +0300, dinar qurbanov wrote:
> possible solutions/wokarounds:
> 1) https://bbs.archlinux.org/viewtopic.php?pid=1671675#p1671675
> 2) 
> https://github.com/the-cavalry/light-locker/issues/108#issuecomment-502404552
> (i have not tried these).
> (i use ctrl+alt+f6 then ctrl+alt+f7 as a workaround for now. )

Do you still have the issue? Which kernel are you running? Are you on stable
or testing/unstable?

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl3xRB4ACgkQ3rYcyPpX
RFu3owgAo74nMup2gwt8p4jgmS0itmRNkEmvl4QH7TKDjN0cq0dwLWk9IdAX0NhK
KIsgCmWU6JAJ1zcDXzJNrQBEb6X4ZCE1rmm4TUgfx63sAuYZyO8QBPcGG/hVp9xI
T6vpWqGwRKinCOo6gZz5TRktGlykAv5q47B+0hzv9ABLpecs21TCxZbCImJEdxYY
3l2PWE8NsxDIRYtMHi8TfTUz4HNaYm6ieKBCKl7j+sNIM8ZJ8SNdisJOPL8b7Tf1
HWLkZSSwBePnwptRaHvIjpWqgGUBGyeVepJiG9l2RBXz0Aqy7ML9x6aZlENDsDnL
YZo467tdIgtN8Pp13qql+0yq0Lz5bg==
=hKLg
-END PGP SIGNATURE-

Bug#946607: numpy: Please add stage1 sbuild profile for bootstrapping

[John Paul Adrian Glaubitz]

Source: numpy
Severity: normal
User: helm...@debian.org
Usertags: rebootstrap

Hi!

numpy is currently BD-Uninstallable on a number of architectures due to
a circular dependency with scipy.

Normally, this is fixed by adding a stage1 sbuild profile for boostrapping
the package. When building with the stage1 profile, the build dependency
on python3-scipy should be disabled (i.e. python3-scipy [!stage1]) such that
the numpy package can be built without scipy.

Can you add such a stage1 profile so I can bootstrap numpy for all the
architectures where it's currently BD-Uninstallable?

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#946606: libc-bin: catchsegv does not handle backtraces with parentheses

[Bernhard Übelacker]

Package: libc-bin
Version: 2.29-3
Severity: wishlist
Tags: upstream patch


Dear Maintainer,
since upstream commit in 2012 [1] the function __backtrace_symbols_fd
seems to outputs in one of this formats:

program(+)[]
program(function+)[]

Therefore the /usr/bin/catchsegv cannot find the backtrace lines
and produces less useful outputs (see below)

There exists an upstream bug about the issue [2].

Attached patch is an attempt to parse the offset instead of the
address, which seems now less important due to ASLR.


Known symbols are currently written by __backtrace_symbols_fd
as such with the offset in relation to the function instead
of the library section.
To get for these also sourcefile and line information
either __backtrace_symbols_fd needs to be changed to
output the library section offset to the backtrace too,
or addr2line (binutils) needs a change to lookup the symbol and
calculate from there, but both would be different issues.

What do you think?

Kind regards,
Bernhard


Current:
Backtrace:
/tmp/tmp.sSrfzsTKpn/3-options-input-fn(+0x175b)[0x557275eb775b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f4f8194ebbb]
/tmp/tmp.sSrfzsTKpn/3-options-input-fn(+0x11ba)[0x557275eb71ba]


With proposed changes:
Backtrace:
 [0x5578ceb0575b] main at 
/usr/share/doc/libsoxr-dev/examples/3-options-input-fn.c:79 (discriminator 4) 
/tmp/tmp.sSrfzsTKpn/3-options-input-fn(+0x175b)
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7fcf5f243bbb]
 [0x5578ceb051ba] _start at ??:? /tmp/tmp.sSrfzsTKpn/3-options-input-fn(+0x11ba)


[1] 
https://sourceware.org/git/?p=glibc.git;a=commit;h=1d6c3d237d10606121c959b9bd2ae722f79ea899
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=21830



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

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

Versions of packages libc-bin depends on:
ii  libc6  2.29-3

Versions of packages libc-bin recommends:
ii  manpages  5.04-1

libc-bin suggests no packages.

-- no debconf information
>From fca03cd9af5ffaea1e4968fa27a7b28ee80903ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Wed, 11 Dec 2019 19:56:39 +0100
Subject: Make catchsegv work again after format changed.

https://sourceware.org/bugzilla/show_bug.cgi?id=21830
---
 debug/catchsegv.sh | 34 +++---
 1 file changed, 23 insertions(+), 11 deletions(-)

diff --git a/debug/catchsegv.sh b/debug/catchsegv.sh
index 245c100f..da87122c 100755
--- a/debug/catchsegv.sh
+++ b/debug/catchsegv.sh
@@ -87,18 +87,30 @@ if test -s "$segv_output"; then
   sed '/Backtrace/q' "$segv_output"
   sed '1,/Backtrace/d' "$segv_output" |
   (while read line; do
- line=`echo $line | sed "s@^$prog\\(\\[.*\\)@\1@"`
  case "$line" in
-   \[*) addr=`echo "$line" | sed 's/^\[\(.*\)\]$/\1/'`
-	complete=`addr2line -f -e "$prog" $addr 2>/dev/null`
-	if test $? -eq 0; then
-	  echo "`echo "$complete"|sed 'N;s/\(.*\)\n\(.*\)/\2(\1)/;'`$line"
-	else
-	  echo "$line"
-	fi
-	;;
-	 *) echo "$line"
-	;;
+   *\(*\)\[*\])
+ lib=`echo $line  | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\1@"`
+ offs=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\2@"`
+ addr=`echo $line | sed "s@^\(.*\)(\(.*\))\[\(.*\)\]\\$@\3@"`
+ case "$offs" in
+   +*) case "$prog" in
+ */$lib)
+   lib="$prog"
+   ;;
+   esac
+   complete=`addr2line -p -i -f -e "$lib" $offs 2>/dev/null`
+   if test $? -eq 0; then
+ echo " [$addr] $complete $lib($offs)"
+   else
+ echo " $line"
+   fi
+   ;;
+ *) echo " $line"
+;;
+ esac
+ ;;
+*) echo "$line"
+   ;;
  esac
done)
 fi
-- 
2.24.0

Bug#946605: ITP: libportal -- Flatpak portal library

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 

* Package name: libportal
  Version : 0.1.0
  Upstream Author : Matthias Clasen
* URL : https://github.com/flatpak/libportal
* License : LGPL-2.0+
  Programming Lang: C
  Description : Flatpak portal library

libportal provides GIO-style C APIs for most Flatpak portals' D-Bus
interfaces. It is primarily intended for installation in Flatpak runtimes,
where applications can use it to interact with portals; it can also be
used to test the portal services.

See the xdg-desktop-portal package's description for more information
about portals.



This is useful to package in Debian so that it can be included
in Flatpak runtimes that are based on Debian packages, similar to
flatpak-xdg-utils. It is also used in the automated tests of newer
versions of xdg-desktop-portal.

In addition to the library, this source package will build
org.gnome.PortalTest, a simple GTK application that interacts with
portals and can be used to test them.

Bug#946599: libcrypt1: failure to switch from libc6 to libcrypt1 hoses the whole system

[Thorsten Glaser]

Marco d'Itri dixit:

>Theory A: maybe after all we really need some Pre-Depends in libc6?

Pre-Depends + Replaces, maybe? (Though Replaces is already there.)

>Theory B: did we miss something related to x32?

Unsure if it’s about x32 or about Multi-Arch or the missing Pre-Depends.

>Is this an x32 perl?

>> /usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot 
>> open shared object file: No such file or directory

Yes. But /usr/bin/perl is linked against libcrypt.so.1 on amd64 as well.

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

Bug#931416: marked as done (klibc-utils: ipconfig denial of service when IP nameservers are configured on the kernel command line)

[Ben Hutchings]

Control: tag -1 upstream patch

On Tue, 08 Oct 2019 18:39:19 +0100 Ben Hutchings  wrote:
> Control: reopen -1
> 
> On Tue, 2019-10-08 at 02:14 +, Thorsten Glaser wrote:
> > Debian Bug Tracking System dixit:
> > 
> > >Your message dated Tue, 08 Oct 2019 01:35:33 +
> > >with message-id 
> > >and subject line Bug#931416: fixed in klibc 2.0.7-1
> > 
> > >> - ipconfig: Implement support -d ...:dns0:dns1 options (Closes: 
> > >> #931416)
> > 
> > >has caused the Debian Bug report #931416,
> > >regarding klibc-utils: ipconfig denial of service when IP nameservers are 
> > >configured on the kernel command line
> > >to be marked as done.
> > 
> > Not sure about that:
> > 
> > >>
> > >> ip=:
> > 
> > 1. is  also now handled?
> 
> No, but that was not required ("possibly even NTP configuration").
> 
> > 2. are any future colon-separated extensions now ignored
> >in a way to make it not fail should they be introduced,
> >i.e. to not repeat this problem?
> 
> Oops, no, that is still an error.
> 
> Ben.
> 
> > Both were requested in the original bugreport.

The handling of additional fields should be fixed by these patches:

https://lists.zytor.com/archives/klibc/2019-December/004266.html
https://lists.zytor.com/archives/klibc/2019-December/004267.html

Let me know if these don't work for you.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
   - Robert Coveyou




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

Bug#946343: [DAViCal-devel] Bug#946343: davical: CVE-2019-18345 CVE-2019-18346 CVE-2019-18347

[Florian Schlichting]

Hi Salvatore,

> The following vulnerabilities were published for davical.
> 
> CVE-2019-18345[0]:
> | Reflected Cross-Site Scripting (XSS) vulnerability
> 
> CVE-2019-18346[1]:
> | A CSRF issue was discovered in DAViCal through 1.1.8. If an
> | authenticated user visits an attacker-controlled webpage, the attacker
> | can send arbitrary requests in the name of the user to the
> | application. If the attacked user is an administrator, the attacker
> | could for example add a new admin user.
> 
> 
> CVE-2019-18347[2]:
> | A stored XSS issue was discovered in DAViCal through 1.1.8. It does
> | not adequately sanitize output of various fields that can be set by
> | unprivileged users, making it possible for JavaScript stored in those
> | fields to be executed by another (possibly privileged) user. Affected
> | database fields include Username, Display Name, and Email.
> 
> 
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

I've just uploaded davical 1.1.9.2-1 to unstable, which (to the best of
our knowledge) contains complete fixes for all three CVEs, along with a
few other things that have accumulated since the last regular release.

In order to provide a more targeted fix for Debian (old-)stable, I've
cherry-picked the four relevant commits onto a "buster" branch and
turned them into a quilt patch. The result can be inspected here:
https://gitlab.com/fsfs/davical/compare/master...buster

Unfortunately, I am unfamiliar with the security team procedures and I
will be AFK for ten days from Saturday. If there's anything else I can
still do until then, like making sure the patch fits onto the stretch
and jessie versions as well, or upload fixed packages (how exactly? I've
only ever uploaded to unstable and -backports...) please tell and send
pointers to more info!

Florian

Bug#946604: cuetools: Invalide Vcs-* fields

[Boyuan Yang]

Source: cuetools
Severity: important
Version: 1.4.0-2

Dear cuetools maintainer,

With the migration from Alioth to Salsa Debian GitLab, your package now has 
invalid Vcs-* fields. Please consider migrating the git packaging repo onto
salsa.debian.org.

-- 
Thanks,
Boyuan Yang


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

Bug#946603: cuetools: Please package the latest upstream release (1.4.1)

[Boyuan Yang]

Source: cuetools
Version: 1.4.0-2
Severity: normal

Dear cuetools maintainer,

The upstream has release the latest version 1.4.1 back in 2015. Please
consider providing the latest version in Debian.

-- 
Thanks,
Boyuan Yang


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

Bug#946602: RM: pyxb -- ROM; RC-buggy; abandoned upstream

[Michael Fladischer]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

pyxb has two RC bugs and does not work with Python 3.8. It has also been
abandoned by upstream[0]. There are no reverse dependencies.

Please remove pyxb. When upstream or someone takes over
maintenance, I can reintroduce the package if needed.

[0] https://github.com/pabigot/pyxb/issues/100

Thanks,
Michael

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAl3xI1oRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90Wqq0Af/YfnzkDEMSeMRDywTS2hzXszAsRTBvIst
wgpbbqbYLUHRo/iBnKqA/nSS1++wzrBtNj0c9aos4b5Oplxmgcw94WZgtxJXDU5y
DMaIyF3mqysHARXenQs5hg70P0t8LPvPMTJZw1CzG4Un5RhkkQGPi1AcPP/VoqtA
u+B+zU2jnCe4LqHigLs+VhWL25fHAw1ORjAYDf8eQnWeeq5VI3uFbtNhKF6TAy66
35X9Vzw1ZxFPIa6fo4fbWYM4smEuERRpd2kEwV+zJfC8xAbshTKgNI0WTo7PIqGG
IbJs720/BzL+6MSsms+58U8KFa9daXL8TrnFR2+zhxBfwvl0wV82RA==
=tyZ5
-END PGP SIGNATURE-

Bug#93435: Mein letzter Wunsch.

[CCULVERT FOUNDATION]

Wenn Sie sich f�r die Finanzierung der STIFTUNG interessieren, schreiben Sie 
bitte heute �ber meinen Anwalt zur�ck
Gr�฿e,
Mrs. Cindy Culvert.
skyteams...@gmail.com

Bug#946249: firefox 71 breaks most addons because of local storage errors

[Christian Weeks]

Package: firefox
Version: 71.0-1
Followup-For: Bug #946249

Dear Maintainer,

KeepassXC is also experiencing this issue, tracked here 
https://github.com/keepassxreboot/keepassxc-browser/issues/704

It should be noted that that github issue identifies an upstream bug with patch 
that seems it might
resolve this problem: https://bugzilla.mozilla.org/show_bug.cgi?id=1601707

I hope you can incorporate this patch into the next build of firefox on debian.

Thanks

-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox depends on:
ii  debianutils   4.9.1
ii  fontconfig2.13.1-2+b1
ii  libatk1.0-0   2.34.1-1
ii  libc6 2.29-6
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-2
ii  libdbus-glib-1-2  0.110-5
ii  libevent-2.1-72.1.11-stable-1
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2+b1
ii  libfreetype6  2.10.1-2
ii  libgcc1   1:9.2.1-21
ii  libgdk-pixbuf2.0-02.40.0+dfsg-1
ii  libglib2.0-0  2.62.3-2
ii  libgtk-3-03.24.13-1
ii  libnspr4  2:4.23-1
ii  libnss3   2:3.47.1-1
ii  libpango-1.0-01.42.4-7
ii  libsqlite3-0  3.30.1-1
ii  libstartup-notification0  0.12-6
ii  libstdc++69.2.1-21
ii  libx11-6  2:1.6.8-1
ii  libx11-xcb1   2:1.6.8-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.5-1
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.15-2+b1
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages firefox recommends:
ii  libavcodec58  10:4.2.1-dmo7

Versions of packages firefox suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-6
ii  libgtk2.0-02.24.32-4
ii  pulseaudio 13.0-3

-- no debconf information

Bug#946601: linux-image-4.19.0-6-amd64: High load by kworker, shutdown or reboot hangs

[Olaf Skibbe]

Package: src:linux
Version: 4.19.67-2+deb10u2
Severity: normal
Tags: newcomer

Dear Maintainer,

I experience the following issue:

When the system is running for some time (usually a few days, but sometimes
some hours), the load rises to about 5. The kernel log (dmesg) shows this
message (and repeats it several times):


[196473.819189] INFO: task kworker/u16:0:19009 blocked for more than 120
seconds.
[196473.819196]   Not tainted 4.19.0-6-amd64 #1 Debian 4.19.67-2+deb10u2
[196473.819199] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[196473.819202] kworker/u16:0   D0 19009  2 0x8000
[196473.819225] Workqueue: scsi_tmf_6 scmd_eh_abort_handler [scsi_mod]
[196473.819228] Call Trace:
[196473.819239]  ? __schedule+0x2a2/0x870
[196473.819244]  ? __switch_to_asm+0x41/0x70
[196473.819249]  schedule+0x28/0x80
[196473.819253]  schedule_timeout+0x26d/0x390
[196473.819259]  ? __switch_to_asm+0x35/0x70
[196473.819263]  ? __switch_to_asm+0x41/0x70
[196473.819267]  ? __switch_to_asm+0x35/0x70
[196473.819271]  ? __switch_to_asm+0x41/0x70
[196473.819275]  ? __switch_to_asm+0x35/0x70
[196473.819280]  ? __switch_to_asm+0x41/0x70
[196473.819284]  ? __switch_to_asm+0x35/0x70
[196473.819288]  ? __switch_to_asm+0x41/0x70
[196473.819292]  wait_for_completion+0x11f/0x190
[196473.819299]  ? wake_up_q+0x70/0x70
[196473.819306]  command_abort+0x5b/0x90 [usb_storage]
[196473.819320]  scmd_eh_abort_handler+0x85/0x220 [scsi_mod]
[196473.819327]  process_one_work+0x1a7/0x3a0
[196473.819332]  worker_thread+0x30/0x390
[196473.819337]  ? create_worker+0x1a0/0x1a0
[196473.819340]  kthread+0x112/0x130
[196473.819344]  ? kthread_bind+0x30/0x30
[196473.819349]  ret_from_fork+0x35/0x40

The load then stays high until shutdown. It remains fully usable, top looks
like this:

top - 17:52:44 up 2 days,  6:57,  1 user,  load average: 5.43, 5.21, 4.32
Tasks: 217 total,   1 running, 216 sleeping,   0 stopped,   0 zombie
%Cpu0  :  2.3 us,  1.3 sy,  0.0 ni, 96.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  4.7 us,  2.5 sy,  0.0 ni, 92.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  1.0 us,  0.3 sy,  0.0 ni,  0.0 id, 98.7 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu4  :  0.0 us,  0.3 sy,  0.0 ni,  0.0 id, 99.7 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu5  :  0.3 us,  0.3 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu6  :  0.0 us,  0.3 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu7  :  1.0 us,  0.3 sy,  0.0 ni, 98.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  31998.7 total,  26462.0 free,   1366.2 used,   4170.5 buff/cache
MiB Swap:  32595.0 total,  32595.0 free,  0.0 used.  29682.1 avail Mem

At shutdown, the system hangs for about 20 minutes with the message "watchdog:
watchdog did not stop" (quoted from mind memory) until it finally shuts down.
This is always related to the increased load and the respective dmesg messages.

I experienced this behaviour about 20 times within the last few months. I did
not find any workaround t solve this situation.

Cheers,
Olaf



-- Package-specific info:
** Version:
Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-amd64 
root=UUID=889f4d9e-013e-4a64-8e5d-422d4675126f ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: FUJITSU
product_name: ESPRIMO_P956
product_version: 
chassis_vendor: FUJITSU
chassis_version: C$WX06
bios_vendor: FUJITSU // American Megatrends Inc.
bios_version: V5.0.0.11 R1.17.0 for D3402-A1x   
board_vendor: FUJITSU
board_name: D3402-A1
board_version: S26361-D3402-A1

** Loaded modules:
intel_rapl
snd_hda_codec_hdmi
snd_hda_codec_realtek
x86_pkg_temp_thermal
intel_powerclamp
snd_hda_codec_generic
coretemp
kvm_intel
snd_hda_intel
snd_hda_codec
kvm
mei_wdt
snd_hda_core
sg
irqbypass
snd_hwdep
crct10dif_pclmul
crc32_pclmul
snd_pcm
ghash_clmulni_intel
snd_timer
intel_cstate
intel_uncore
snd
iTCO_wdt
iTCO_vendor_support
pcspkr
intel_rapl_perf
soundcore
mei_me
mei
intel_pch_thermal
tpm_crb
pcc_cpufreq
fujitsu_laptop
sparse_keymap
tpm_tis
tpm_tis_core
tpm
evdev
rng_core
acpi_pad
parport_pc
ppdev
lp
parport
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
hid_generic
crc32c_generic
usbhid
fscrypto
ecb
hid
ums_realtek
uas
usb_storage
sr_mod
cdrom
sd_mod
i915
crc32c_intel
i2c_algo_bit
drm_kms_helper
xhci_pci
ahci
xhci_hcd
libahci
drm
libata
usbcore
e1000e
scsi_mod
aesni_intel
usb_common
aes_x86_64
crypto_simd
cryptd
glue_helper
i2c_i801
wmi
thermal
fan
video
button

** Network interface configuration:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000

Bug#946599: libcrypt1: failure to switch from libc6 to libcrypt1 hoses the whole system

[Thorsten Glaser]

On Wed, 11 Dec 2019, Thorsten Glaser wrote:

> Justification: breaks the whole system
> 
> I’ve did a “sudo apt-get --purge dist-upgrade” and ended with,

Given it worked in the amd64-only chroot and on another machine,
this most likely only fails if one has more than one architecture
enabled in Multi-Arch, perhaps also needs the -dev packages installed
to trigger.

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

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#946599: libcrypt1: failure to switch from libc6 to libcrypt1 hoses the whole system

[Marco d'Itri]

On Dec 11, Thorsten Glaser  wrote:

> Thankfully, I had a root session in a chroot open and used
> the program, statically linked, from http://koltsoff.com/pub/getroot/
> to recover access outside the chroot, by using dpkg -i --force-all
> first on libc6_*.deb, then libcrypt1_*.deb. Afterwards, normal recovery
> mechanisms apply.
I suspect that ldconfig would have been enough to fix this.

Theory A: maybe after all we really need some Pre-Depends in libc6?

Theory B: did we miss something related to x32?

Is this an x32 perl?

> Preparing to unpack .../0-libc6_2.29-6_x32.deb ...
> De-configuring libc6:i386 (2.29-3) ...
> De-configuring libc6:amd64 (2.29-3) ...
> Unpacking libc6:x32 (2.29-6) over (2.29-3) ...
> Preparing to unpack .../1-libc6_2.29-6_amd64.deb ...
> /usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot 
> open shared object file: No such file or directory
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-vKsDE7/1-libc6_2.29-6_amd64.deb (--unpack):
>  new libc6:amd64 package pre-installation script subprocess returned error 
> exit status 127

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#946599: libcrypt1: failure to switch from libc6 to libcrypt1 hoses the whole system

[Thorsten Glaser]

Package: libcrypt1
Version: 1:4.4.10-5
Severity: critical
Justification: breaks the whole system

I’ve did a “sudo apt-get --purge dist-upgrade” and ended with,
see screenshot below.

Thankfully, I had a root session in a chroot open and used
the program, statically linked, from http://koltsoff.com/pub/getroot/
to recover access outside the chroot, by using dpkg -i --force-all
first on libc6_*.deb, then libcrypt1_*.deb. Afterwards, normal recovery
mechanisms apply.

Log:

Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  fonts-noto-hinted fonts-noto-ui-core liblouis19 libxml-simple-perl
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  libpcre2-posix0*
The following NEW packages will be installed:
  fonts-cantarell libcrypt1:i386 libcrypt1:amd64 libcrypt1 libcrypt1-dev:i386 
libcrypt1-dev liblouis20
  libpcre2-posix2 libxstring-perl linux-image-5.3.0-3-amd64:amd64
The following packages have been kept back:
  libegl1 libgl1 libgles2 libglvnd0 libglx0 librsvg2-2:i386 libselinux1:i386 
libv4l-0:i386 libv4lconvert0:i386
  libvirt-clients libvirt-daemon libvirt-daemon-system libvirt0 python3-libvirt 
tomcat9
The following packages will be upgraded:
  bochsbios debhelper debianutils drkonqi dwz fig2dev fonts-comfortaa git 
git-doc git-man gitk gitweb glibc-doc
  gstreamer1.0-alsa:i386 gstreamer1.0-alsa gstreamer1.0-libav:i386 
gstreamer1.0-plugins-bad:i386
  gstreamer1.0-plugins-base gstreamer1.0-plugins-base:i386 
gstreamer1.0-plugins-good:i386
  gstreamer1.0-plugins-ugly:i386 intel-microcode:amd64 iptables kde-spectacle 
kinit kio kwalletmanager
  libbrlapi0.7 libc-bin libc-dev-bin libc-l10n libc6:i386 libc6 libc6:amd64 
libc6-dbg libc6-dev:i386 libc6-dev
  libdbus-glib-1-2:i386 libdbus-glib-1-2 libdebhelper-perl 
libgstreamer-plugins-bad1.0-0:i386
  libgstreamer-plugins-base1.0-0:i386 libgstreamer-plugins-base1.0-0 
libgstreamer1.0-0:i386 libgstreamer1.0-0
  libhttp-cookies-perl libio-pty-perl libip4tc2 libip6tc2 libiptc0 
libjs-bootstrap4 libjs-popper.js
  libjs-sphinxdoc libkaccounts1 libkf5activities5 libkf5bookmarks5 
libkf5completion5 libkf5configwidgets5
  libkf5crash5 libkf5declarative5 libkf5globalaccel-bin libkf5globalaccel5 
libkf5globalaccelprivate5
  libkf5iconthemes5 libkf5jobwidgets5 libkf5kcmutils5 libkf5khtml5 
libkf5kiocore5 libkf5kiontlm5
  libkf5kiowidgets5 libkf5kipi32.0.0 libkf5kirigami2-5 libkf5newstuff5 
libkf5newstuffcore5 libkf5notifications5
  libkf5parts5 libkf5purpose-bin libkf5purpose5 libkf5quickaddons5 
libkf5textwidgets5 libkf5wallet-bin
  libkf5wallet5 libkwalletbackend5-5 liblinux-epoll-perl liblist-someutils-perl 
liblouis-bin liblouis-data
  liblouisutdml-bin liblouisutdml-data liblouisutdml9 libmime-lite-perl 
libmoox-late-perl libmysofa0:i386
  libmysofa0 libokular5core8 libpcre2-16-0 libpcre2-32-0 libpcre2-8-0:i386 
libpcre2-8-0 libpcre2-dev
  libqmobipocket2 libsepol1 libsepol1-dev libserd-0-0:i386 libserd-0-0 
libslirp0 libsnappy1v5:i386 libsnappy1v5
  libsord-0-0:i386 libsord-0-0 libspecio-perl libsratom-0-0:i386 libsratom-0-0 
libtype-tiny-perl libvncclient1
  libvncserver1 libwireshark-data libwmf0.2-7 libx265-179:i386 libx265-179 
libxtables12 libz3-4:i386
  linux-image-amd64:amd64 linux-libc-dev linux-libc-dev:i386 locales 
locales-all netbase node-glob okular
  python3-requests python3-urllib3 qml-module-org-kde-kcm 
qml-module-org-kde-kirigami2
  qml-module-org-kde-kquickcontrolsaddons systemsettings tcpdump texlive 
texlive-base texlive-bibtex-extra
  texlive-extra-utils texlive-font-utils texlive-fonts-extra 
texlive-fonts-extra-doc texlive-fonts-extra-links
  texlive-fonts-recommended texlive-fonts-recommended-doc texlive-formats-extra 
texlive-full texlive-games
  texlive-humanities texlive-humanities-doc texlive-lang-arabic 
texlive-lang-chinese texlive-lang-cjk
  texlive-lang-cyrillic texlive-lang-czechslovak texlive-lang-english 
texlive-lang-european texlive-lang-french
  texlive-lang-german texlive-lang-greek texlive-lang-italian 
texlive-lang-korean texlive-lang-other
  texlive-lang-polish texlive-lang-portuguese texlive-lang-spanish 
texlive-latex-base texlive-latex-base-doc
  texlive-latex-extra texlive-latex-extra-doc texlive-latex-recommended 
texlive-latex-recommended-doc
  texlive-luatex texlive-metapost texlive-metapost-doc texlive-music 
texlive-pictures texlive-pictures-doc
  texlive-plain-generic texlive-pstricks texlive-pstricks-doc 
texlive-publishers texlive-publishers-doc
  texlive-science texlive-science-doc texlive-xetex
188 upgraded, 10 newly installed, 1 to remove and 15 not upgraded.
Need to get 2756 MB of archives.
After this operation, 306 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://deb.debian.org/debian-ports unstable/main x32 debianutils x32 
4.9.1 [100 kB]
Get:2 http://deb.debian.org/debian sid/main amd64 libcrypt1 amd64 1:4.4.10-5 
[84.8 kB]
[…]
Get:198 http://deb.debian.org/debian sid/main 

Bug#946598: libvncserver-dev depends on libvncserver-config which has been deprecated/removed

[Sebastien Bacher]

Package: libvncserver
Version: 0.9.11+dfsg-1.3

The attached patch fixes the issue


diff -Nru libvncserver-0.9.12+dfsg/debian/changelog libvncserver-0.9.12+dfsg/debian/changelog
--- libvncserver-0.9.12+dfsg/debian/changelog	2019-12-11 08:02:19.0 +0100
+++ libvncserver-0.9.12+dfsg/debian/changelog	2019-12-11 17:25:41.0 +0100
@@ -1,3 +1,11 @@
+libvncserver (0.9.12+dfsg-4) unstable; urgency=medium
+
+  * debian/control:
+- don't have libvncserver-dev depends libvncserver-config which
+  has been deprecated
+
+ -- Sebastien Bacher   Wed, 11 Dec 2019 17:25:07 +0100
+
 libvncserver (0.9.12+dfsg-3) unstable; urgency=medium
 
   * Re-upload to unstable as-is.
diff -Nru libvncserver-0.9.12+dfsg/debian/control libvncserver-0.9.12+dfsg/debian/control
--- libvncserver-0.9.12+dfsg/debian/control	2019-12-11 08:01:51.0 +0100
+++ libvncserver-0.9.12+dfsg/debian/control	2019-12-11 17:25:00.0 +0100
@@ -56,7 +56,6 @@
  libgnutls28-dev,
  libjpeg-dev,
  zlib1g-dev,
- libvncserver-config
 Multi-Arch: same
 Description: API to write one's own VNC server - development files
  LibVNCServer makes writing a VNC server (or more correctly, a program

Bug#946597: python-apt: security regression in 1.9.1

[Julian Andres Klode]

Package: python-apt
Version: 1.9.1
Severity: critical
Tags: security experimental

I made python-apt use all available hashes instead of defaulting to md5 in
1.9.1 (and 1.9.0 was just broken); but now, if there are no hashes, that'd
verify correctly as well, so I gotta fix that, but might not make it today,
so filing this to let people running apt-listbugs now.

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

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

Versions of packages python-apt depends on:
ii  dirmngr2.2.17-3ubuntu1
ii  gnupg  2.2.17-3ubuntu1
ii  libapt-pkg5.90 1.9.5+0~201912061248~ubuntu20.04.1
ii  libc6  2.30-0ubuntu2
ii  libgcc11:9.2.1-21ubuntu1
ii  libstdc++6 9.2.1-21ubuntu1
ii  python-apt-common  1.9.1
ii  python22.7.17-1

Versions of packages python-apt recommends:
ii  iso-codes4.4-1
ii  lsb-release  11.1.0ubuntu1
ii  xz-utils 5.2.4-1

Versions of packages python-apt suggests:
ii  apt 1.9.5+0~201912061248~ubuntu20.04.1
pn  python-apt-dbg  
pn  python-apt-doc  

-- no debconf information

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#946588: thunderbird's dowgrade prevention is being triggered after upgrade from stretch

[Carsten Schoenert]

Control: forcemerge -1 946347

Hello Jens,

this issue was first submitted by #946347
https://bugs.debian.org/946347

Am 11.12.19 um 12:33 schrieb Jens Holzkämper:
> The current package of thunderbird in stretch (68.2.2-1~deb9u1) reports a
> bigger version number than the current package in buster (68.2.2-1~deb10u1) 
> due
> to the inclusion of the build timestamp. The version reported by stretch is
> 68.2.2_20191116203149/20191116203149 and buster
> 68.2.2_20191116193034/20191116193034.
> 
> This information is then used by thunderbird to fill the compatibility.ini in
> the profile and after an upgrade from stretch to buster leads to thunderbird
> prompting to either quit or create a new profile because it detects that an
> older version of thunderbird is trying to open a profile last used by a newer
> version. I believe
> using the same profile should be safe, as the underlying upstream version is
> the same at the moment and should probably never be newer in oldstable than
> stable.
> 
> As a workaround it's possible to start thunderbird with the parameter 
> "--allow-
> downgrade" or manually delete the line starting with "LastVersion=" in the
> compatibility.ini in the profile but less savy users may use access to the 
> data
> in their old profiles (the data is still there but a regular user will 
> probably
> not be able to access it without further instructions).

currently I don't test such upgrade scenarios and until now we don't had
any need to do such testing.
If we would know which variable is used within the build we could use
the same date for all builds of the thunderbird packages and prevent
such situations.

For now I can only build technically the stretch version before the
buster version to get the older date hard included within the
thunderbird binary.

@Emilio
Updating from jessie to stretch will of course affected by this issue.
I've no idea how we could solve as in the end the jessie version would
be needed built first of all.
Do you have contact to Mike or Sylvestre which might know if there is
such an variable we could use while building the packages?

-- 
Regards
Carsten Schoenert

Bug#946596: puppetdb: An illegal reflective access operation has occurred - puppetdb killed

[Matt Zagrabelny]

Package: puppetdb
Version: 6.2.0-3
Severity: important

Greetings,

Thank you for your support of puppetdb.

I have successfully installed and configured puppetdb and it seemed to have
been running smoothly for a number of weeks.

This morning it started to fail with the following error:

Dec 11 09:00:18 puppet-5-5 java[922]: WARNING: An illegal reflective access 
operation has occurred
Dec 11 09:00:18 puppet-5-5 java[922]: WARNING: Illegal reflective access by 
clojure.lang.InjectedInvoker/0x0008401e8040 
(file:/usr/share/java/clojure.jar) to method 
sun.nio.ch.ChannelInputStream.close()
Dec 11 09:00:18 puppet-5-5 java[922]: WARNING: Please consider reporting this 
to the maintainers of clojure.lang.InjectedInvoker/0x0008401e8040
Dec 11 09:00:18 puppet-5-5 java[922]: WARNING: Use --illegal-access=warn to 
enable warnings of further illegal reflective access operations
Dec 11 09:00:18 puppet-5-5 java[922]: WARNING: All illegal access operations 
will be denied in a future release
Dec 11 09:00:19 puppet-5-5 java[922]: #
Dec 11 09:00:19 puppet-5-5 java[922]: # java.lang.OutOfMemoryError: Java heap 
space
Dec 11 09:00:19 puppet-5-5 java[922]: # -XX:OnOutOfMemoryError="kill -9 %p"
Dec 11 09:00:19 puppet-5-5 java[922]: #   Executing /bin/sh -c "kill -9 922"...
Dec 11 09:00:19 puppet-5-5 systemd[1]: puppetdb.service: Main process exited, 
code=killed, status=9/KILL
Dec 11 09:00:19 puppet-5-5 systemd[1]: puppetdb.service: Failed with result 
'signal'.

I've tweaked the systemd unit file via:

sudo cp /lib/systemd/system/puppetdb.service 
/etc/systemd/system/puppetdb.service

and removed the line:

  -XX:OnOutOfMemoryError="kill -9 %%p" \

Then:

sudo systemctl daemon-reload
sudo systemctl restart puppetdb

It seems to be working okay again, but I thought I should submit a report to 
document the issue.

Please let me know if there is something I can do to triage this more.

Thank you!

Bug#946595: ITP: acme-dns -- Limited DNS server to handle ACME DNS challenges

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: Jérémy Lal 

* Package name: acme-dns
  Version : 0.8
  Upstream Author : Joona Hoikkala
* URL : https://github.com/joohoi/acme-dns
* License : Expat
  Programming Lang: Go
  Description : Limited DNS server to handle ACME DNS challenges

This DNS server is specialized to handle ACME dns-01 challenges,
by providing a simple HTTP API exclusively for TXT record updates
of the "_acme-challenge" subdomain that has been configured with
a CNAME record.

This way, in the unfortunate exposure of API keys, the effects are
limited to the subdomain TXT record in question.

Supports SQLite and PostgreSQL database backends.

A Certbot authentication hook for acme-dns is available separately.

I never packaged go applications so anyone is welcome to co-maintain
or even package this app entirely.

Bug#939310: missing systray icon for blueman-applet

[Jens Holzkämper]

> Tom, awesomewm with KDE as well?
>

No. i3


same issue in Xfce/xfwm4 as well

Bug#775761: libguestfs incorrectly detects host CPU architecture

[Vincent Danjean]

  Hi,

On Thu, 5 Dec 2019 11:12:56 + "Richard W.M. Jones"  
wrote:
> I believe this is a new bug and nothing much to do with:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775761

  So I just cloned the bug into #946594 in order to manage the bug reported
by Pierre Neyron.

> However about this new bug, what is supposed to happen is that
> common/mlstdutils/guestfs_config.ml is generated by ./configure with
> the correct @host_cpu@ substituted.  If that's not happening then it's
> a build issue on Debian of some kind.

  I closely look at the build system with him. It occurs that :
- the Debian package use an 'out-of-source' build (ie the build is
  *not* done into the source directories)
- Debian applies some patches to archive this
- but the current rules about guestfs_config.ml especially target
  the source directory (whereas ./configure generates it in the
  build directory, as for all other configure generated files)

Easy test :
- remove common/mlstdutils/guestfs_config.ml in the source directory
- build the Debian package (dpkg-buildpackage -us -uc)
  => the build fails with:
ocamlfind ocamlopt -g -annot -safe-string -warn-error CDEFLMPSUVYZX+52-3 -ccopt 
'-g -O2 -fdebug-prefix-map=/home/polaris/danjean/libguestfs/libguestfs=. 
-fstack-protector-strong -Wformat -Werror=format-security -fno-strict-overflow 
-Wno-strict-overflow' -package str,unix -I . -c 
../../../../common/mlstdutils/std_utils.ml -o std_utils.cmx
File "_none_", line 1:
Warning 58: no cmx file was found in path for module Guestfs_config, and its 
interface was not compiled with -opaque

=> the guestfs_config.ml generated in the build directory is not
taken into account.
=> the Debian package is currently using the provided (x86-64)
guestfs_config.ml in the source directory and ignore the generated
one (in the build directory) on all architectures
=> the Debian package is correctly built only on x86-64...

  The root of the problem is in subdir-rules.mk at the root of the
package. I found a fix the seems to work:
=
--- subdir-rules.mk 2019-12-11 15:45:01.274572831 +0100
+++ subdir-rules.mk.fixed   2019-12-11 15:44:23.738419530 +0100
@@ -79,12 +79,12 @@
 guestfs_am_v_jar_ = $(guestfs_am_v_jar_@AM_DEFAULT_V@)
 guestfs_am_v_jar_0 = @echo "  JAR " $@;

-%.cmi: $(srcdir)/%.mli
+%.cmi: %.mli
$(guestfs_am_v_ocamlcmi)$(OCAMLFIND) ocamlc $(OCAMLFLAGS) 
$(OCAMLPACKAGES) -c $< -o $@
-%.cmo: $(srcdir)/%.ml
+%.cmo: %.ml
$(guestfs_am_v_ocamlc)$(OCAMLFIND) ocamlc $(OCAMLFLAGS) 
$(OCAMLPACKAGES) -c $< -o $@
 if HAVE_OCAMLOPT
-%.cmx: $(srcdir)/%.ml
+%.cmx: %.ml
$(guestfs_am_v_ocamlopt)$(OCAMLFIND) ocamlopt $(OCAMLFLAGS) 
$(OCAMLPACKAGES) -c $< -o $@
 endif
=

  The idea is to let "make" to check itself in the build directory and then
in the source directory by not forcing a path and using the VPATH feature
(as for all internal automake rules)

  Looking at the ChangeLog, I saw that the build rules about cmi/cmo/cmx/...
seems tricky, so I would prefer that someone that know ocaml builds checks
my patch.
  In any case, the Debian build is broken.
  As upstream does not seem to support out-of-source build, this problem should
not appear for it. So the fix can go into a debian patch (even if I think that
my patch is a no-op for a 'in-source' build)

  Regards,
Vincent


> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
> 
> 
> 

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#946359: pg-snakeoil: Selftest apears to be broken

[Sebastian Andrzej Siewior]

On 2019-12-11 11:48:00 [+0100], Christoph Berg wrote:
> Re: Sebastian Andrzej Siewior 2019-12-07 
> <20191207201131.v563o62fpmjnz7ol@flow>
> > clamav can't migrate because the debci-test for pg-snakeoil fails. I
> > *think* that the test itself is somehow borken since after installing
> > the bytecode.cvd itself appears on my system. Could you please take a
> > look?
> 
> The test fails in my sid chroot as well because freshclam can't
> download the database, /var/lib/clamav/ is empty except for a "tmp"
> directory.

Do you have a special inet setup? Kind of web proxy or something like
that.

> $ cat /var/log/clamav/freshclam.log
> Wed Dec 11 10:32:47 2019 -> --
> Wed Dec 11 10:32:47 2019 -> freshclam daemon 0.102.1 (OS: linux-gnu, ARCH: 
> x86_64, CPU: x86_64)
> Wed Dec 11 10:32:47 2019 -> ClamAV update process started at Wed Dec 11 
> 10:32:47 2019
> Wed Dec 11 10:32:47 2019 -> daily database available for download (remote 
> version: 25660)
> Wed Dec 11 10:32:52 2019 -> WARNING: Mirror https://database.clamav.net is 
> not synchronized.
> Wed Dec 11 10:32:52 2019 -> ERROR: Unexpected error when attempting to update 
> database: daily
> Wed Dec 11 10:32:52 2019 -> WARNING: fc_update_databases: fc_update_database 
> failed: Up-to-date (1)
> Wed Dec 11 10:32:52 2019 -> ERROR: Database update process failed: Up-to-date 
> (1)
> Wed Dec 11 10:32:52 2019 -> ERROR: Update failed.
> Wed Dec 11 10:32:52 2019 -> --

Could you start `freshclam' by hand with --verbose (not sure if --debug
works) and provide more output? It appears that the version downloaded
is one less than available and that is where things go south.

> > However. The complete database (/var/lib/clamav/) contains today 454MiB.
> > I don't know what your self-test but using
> > 
> > | clamav$ cat unit_tests/input/clamav.hdb
> > | aa15bcf478d165efd2065190eb473bcb:544:ClamAV-Test-File
> > 
> > as a databse will find the un-offical test file:
> > 
> > |$ clamscan -d clamav.hdb split.clam.exe
> > |split.clam.exe: ClamAV-Test-File.UNOFFICIAL FOUND
> 
> Using a smaller database instead of downloading the whole thing for
> each test run makes sense.
> 
> We just need to figure out how to compile it to a
> /var/lib/clamav/*.cld database that cl_load() understands. At the
> moment the database path is not configurable in pg_snakeoil, maybe we
> need to change that as well.

Bug. The .cld files are signed by upstream if I am not mistaken. I will
try to check.

> Christoph

Sebastian

Bug#946213: RFS: git-delta/0.0.15 -- Syntax-highlighting pager for git and diff output

[Adam Borowski]

On Tue, Dec 10, 2019 at 06:14:43PM -0800, Matthew Fernandez wrote:
> > On Dec 10, 2019, at 17:44, Adam Borowski  wrote:
> > Sorry, having an executable in $PATH named "delta" is not an option at all.
> > Policy §10.1.
> 
> I am not involved in this present RFS and §10.1 is perfectly clear, but
> how does this apply to some existing packages?  Specifically, I’m thinking
> about ninja and ninja-build.  Both install a binary called ‘ninja’ albeit
> to different paths.

src:ninja is no more, it got dropped after jessie.  And, before then:

ninja (0.1.3-3) unstable; urgency=medium

  * QA upload.
  * Set maintainer to the QA group.
  * Convert to dh 10, 3.0 source format.
  * Enable hardening. (Closes: #785152).
  * Rename the daemon to ninja-daemon. (Closes: #695652).

 -- Adam Borowski   Fri, 09 Dec 2016 11:26:23 +0100

as it had no reason to name its executable "ninja" -- it was not something a
human would need to type.  Thus, it was reasonable to rename the existing
owner to make place for an oft-invoked CLI tool.

I don't know swap-cwm.  Its "delta" executable is a CLI tool thus you don't
have a stronger claim; on the other hand, it seems a nearly unused package,
with no maintainer upload for 4.5 years despite the maintainer being
otherwise active, and with a RC bug.  So asking for the name might succeed,
but I wouldn't hold my breath.

It's much simpler to rename to, say, "gdelta", "gdiff" or something.

> Is this permissible because one installs to /usr/bin and the other to
> /usr/sbin?

This is not spelt explicitly in the Policy, but a consensus of a bunch of
random developers on IRC said "no", which I agree with.


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

Bug#946593: RM: ruby-hpricot -- ROM; deprecated, no reverse-depends

[Antonio Terceiro]

Package: ftp.debian.org
Severity: normal

Please remove ruby-hpricot from unstable. It's deprecated, and was only
kept around because a reverse dependency (ronn) was still very useful
and used by a lot of other packages. ronn has since been ported away
from ruby-hpricot, to a maintained library, so it's now OK to drop
ruby-hpricot.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796020
for details.

There are still two reverse build-dependencies, ruby-premailer and
ruby-premailer-rails, but those are spurious: upstream moved away from
it but they were never dropped from the Debian package. I will make
uploads dropping them just after I send this email.


signature.asc
Description: PGP signature

Bug#946592: libreoffice-calc: [Wayland?] Insert/delete cells prompt doesn't always appear, Libreoffice freezes

[johan]

Package: libreoffice-calc
Version: 1:6.1.5-3+deb10u5
Followup-For: Bug #946592

Additional information: "Selecting" the invisible prompt using Alt+Tab, then
using Alt+F4 seems to close it and Calc becomes responsive again.



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

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

Versions of packages libreoffice-calc depends on:
ii  coinor-libcbc3   2.9.9+repack1-1
ii  coinor-libcoinmp1v5  1.8.3-2+b11
ii  coinor-libcoinutils3v5   2.10.14+repack1-1
ii  libatlas3-base [liblapack.so.3]  3.10.3-8
ii  libblas3 [libblas.so.3]  3.8.0-2
ii  libboost-filesystem1.67.01.67.0-13
ii  libboost-iostreams1.67.0 1.67.0-13
ii  libbz2-1.0   1.0.6-9.2~deb10u1
ii  libc62.28-10
ii  libetonyek-0.1-1 0.1.9-1
ii  libgcc1  1:8.3.0-6
ii  libicu63 63.1-6
ii  liblapack3 [liblapack.so.3]  3.8.0-2
ii  liblcms2-2   2.9-3
ii  libmwaw-0.3-30.3.14-1
ii  libodfgen-0.1-1  0.1.7-1
ii  liborcus-0.14-0  0.14.1-6
ii  libreoffice-base-core1:6.1.5-3+deb10u5
ii  libreoffice-core 1:6.1.5-3+deb10u5
ii  librevenge-0.0-0 0.0.4-6
ii  libstaroffice-0.0-0  0.0.6-1
ii  libstdc++6   8.3.0-6
ii  libwps-0.4-4 0.4.10-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  lp-solve 5.5.0.15-4+b1
ii  uno-libs36.1.5-3+deb10u5
ii  ure  6.1.5-3+deb10u5
ii  zlib1g   1:1.2.11.dfsg-1

libreoffice-calc recommends no packages.

Versions of packages libreoffice-calc suggests:
ii  ocl-icd-libopencl1  2.2.12-2

Versions of packages libreoffice-core depends on:
ii  fontconfig2.13.1-2
ii  fonts-opensymbol  2:102.10+LibO6.1.5-3+deb10u5
ii  libboost-date-time1.67.0  1.67.0-13
ii  libboost-locale1.67.0 1.67.0-13
ii  libc6 2.28-10
ii  libcairo2 1.16.0-4
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v52.3.3.4+dfsg-1
ii  libcmis-0.5-5v5   0.5.2-1
ii  libcups2  2.2.10-6+deb10u1
ii  libcurl3-gnutls   7.64.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libdconf1 0.30.1-2
ii  libeot0   0.01-5
ii  libepoxy0 1.5.3-0.1
ii  libexpat1 2.2.6-2+deb10u1
ii  libexttextcat-2.0-0   3.4.5-1
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3+deb10u1
ii  libgcc1   1:8.3.0-6
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgpgmepp6   1.12.0-6
ii  libgraphite2-31.3.13-7
ii  libharfbuzz-icu0  2.3.1-1
ii  libharfbuzz0b 2.3.1-1
ii  libhunspell-1.7-0 1.7.0-2
ii  libhyphen02.8.8-7
ii  libice6   2:1.0.9-2
ii  libicu63  63.1-6
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  liblcms2-22.9-3
ii  libldap-2.4-2 2.4.47+dfsg-3+deb10u1
ii  libmythes-1.2-0   2:1.2.4-3
ii  libneon27-gnutls  0.30.2-3
ii  libnspr4  2:4.20-1
ii  libnss3   2:3.42.1-1+deb10u1
ii  libnumbertext-1.0-0   1.0.5-1
ii  libodfgen-0.1-1   0.1.7-1
ii  liborcus-0.14-0   0.14.1-6
ii  libpng16-16   1.6.36-6
ii  libpoppler82  0.71.0-5
ii  librdf0   1.0.17-1.1+b1
ii  libreoffice-common1:6.1.5-3+deb10u5
ii  librevenge-0.0-0  0.0.4-6
ii  libsm62:1.2.3-1
ii  libstdc++68.3.0-6
ii  libx11-6  2:1.6.7-1
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.4-2
ii  libxml2   2.9.4+dfsg1-7+b3
ii  libxmlsec11.2.27-2
ii  libxmlsec1-nss1.2.27-2
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxslt1.11.1.32-2.2~deb10u1
ii  uno-libs3 6.1.5-3+deb10u5
ii  ure   6.1.5-3+deb10u5
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages libreoffice-core recommends:
ii  libpaper-utils  1.1.28

-- no debconf information

Bug#929597: CVE-2019-12211 CVE-2019-12212 CVE-2019-12213 CVE-2019-12214

[Hugo Lefeuvre]

Hi,

small update:

I have updated jessie with the cherry picked patch for CVE-2019-12213 and
CVE-2019-12211.

I have contacted upstream to know when he is planning to release 3.18.1 so
that we can get this fixed in testing without cherry picking.

I am currently testing stretch and buster updates with the cherry picked
patch.

cheers,
Hugo

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


signature.asc
Description: PGP signature

Bug#944205: spacefm: 100% cpu when creating files/folders

[Bernhard Übelacker]

Hello Jack Barns,
I am not involved in packaging spacefm, but just tried
to reproduce the issue. "Unfortunately" for my test it
did not freeze.

If you still can reproduce it, maybe you can execute
following command while a single spacefm process is in
the system and hangs:

script -a "spacefm-gdb_$(date +%Y-%m-%d_%H-%M-%S).txt" -c "ps -C spacefm 
-mo %cpu,pid,tid,user,args; gdb -q --pid $(pidof spacefm) -ex 'set width 0' -ex 
'set pagination off' -ex 'thread apply all bt full' -ex 'detach' -ex 'quit'"

This should generate a file spacefm-gdb*.txt which could be
forwarded to this bug.

Even better if the dbgsym packages could be installed before,
like described in [1].

   spacefm-dbgsym libgtk2.0-0-dbgsym libglib2.0-0-dbgsym

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

Bug#946592: libreoffice-calc: [Wayland?] Insert/delete cells prompt doesn't always appear, Libreoffice freezes

[johan]

Package: libreoffice-calc
Version: 1:6.1.5-3+deb10u5
Severity: normal

Dear Maintainer,

This happens on KDE+Wayland, and I suspect that this might be a Wayland-related
problem.

Sometimes, when you choose some cells in Libreoffice Calc, then right click and
choose "Insert..." or "Delete...", the popup that asks for insert/delete
options (e.g. "shift cells up") does not appear, and this causes Calc to stop
reacting to any user input.

If you use Alt+Tab to cycle through open applications, you can see the "Insert
(or Delete) cells" prompt there but you cannot select it. The only option to
recover seems to be killing Libreoffice from console or via a process manager.



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

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

Versions of packages libreoffice-calc depends on:
ii  coinor-libcbc3   2.9.9+repack1-1
ii  coinor-libcoinmp1v5  1.8.3-2+b11
ii  coinor-libcoinutils3v5   2.10.14+repack1-1
ii  libatlas3-base [liblapack.so.3]  3.10.3-8
ii  libblas3 [libblas.so.3]  3.8.0-2
ii  libboost-filesystem1.67.01.67.0-13
ii  libboost-iostreams1.67.0 1.67.0-13
ii  libbz2-1.0   1.0.6-9.2~deb10u1
ii  libc62.28-10
ii  libetonyek-0.1-1 0.1.9-1
ii  libgcc1  1:8.3.0-6
ii  libicu63 63.1-6
ii  liblapack3 [liblapack.so.3]  3.8.0-2
ii  liblcms2-2   2.9-3
ii  libmwaw-0.3-30.3.14-1
ii  libodfgen-0.1-1  0.1.7-1
ii  liborcus-0.14-0  0.14.1-6
ii  libreoffice-base-core1:6.1.5-3+deb10u5
ii  libreoffice-core 1:6.1.5-3+deb10u5
ii  librevenge-0.0-0 0.0.4-6
ii  libstaroffice-0.0-0  0.0.6-1
ii  libstdc++6   8.3.0-6
ii  libwps-0.4-4 0.4.10-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  lp-solve 5.5.0.15-4+b1
ii  uno-libs36.1.5-3+deb10u5
ii  ure  6.1.5-3+deb10u5
ii  zlib1g   1:1.2.11.dfsg-1

libreoffice-calc recommends no packages.

Versions of packages libreoffice-calc suggests:
ii  ocl-icd-libopencl1  2.2.12-2

Versions of packages libreoffice-core depends on:
ii  fontconfig2.13.1-2
ii  fonts-opensymbol  2:102.10+LibO6.1.5-3+deb10u5
ii  libboost-date-time1.67.0  1.67.0-13
ii  libboost-locale1.67.0 1.67.0-13
ii  libc6 2.28-10
ii  libcairo2 1.16.0-4
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v52.3.3.4+dfsg-1
ii  libcmis-0.5-5v5   0.5.2-1
ii  libcups2  2.2.10-6+deb10u1
ii  libcurl3-gnutls   7.64.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libdconf1 0.30.1-2
ii  libeot0   0.01-5
ii  libepoxy0 1.5.3-0.1
ii  libexpat1 2.2.6-2+deb10u1
ii  libexttextcat-2.0-0   3.4.5-1
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3+deb10u1
ii  libgcc1   1:8.3.0-6
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgpgmepp6   1.12.0-6
ii  libgraphite2-31.3.13-7
ii  libharfbuzz-icu0  2.3.1-1
ii  libharfbuzz0b 2.3.1-1
ii  libhunspell-1.7-0 1.7.0-2
ii  libhyphen02.8.8-7
ii  libice6   2:1.0.9-2
ii  libicu63  63.1-6
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  liblcms2-22.9-3
ii  libldap-2.4-2 2.4.47+dfsg-3+deb10u1
ii  libmythes-1.2-0   2:1.2.4-3
ii  libneon27-gnutls  0.30.2-3
ii  libnspr4  2:4.20-1
ii  libnss3   2:3.42.1-1+deb10u1
ii  libnumbertext-1.0-0   1.0.5-1
ii  libodfgen-0.1-1   0.1.7-1
ii  liborcus-0.14-0   0.14.1-6
ii  libpng16-16   1.6.36-6
ii  libpoppler82  0.71.0-5
ii  librdf0   1.0.17-1.1+b1
ii  libreoffice-common1:6.1.5-3+deb10u5
ii  librevenge-0.0-0  0.0.4-6
ii  libsm62:1.2.3-1
ii  libstdc++68.3.0-6
ii  libx11-6  2:1.6.7-1
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.4-2
ii  libxml2   2.9.4+dfsg1-7+b3
ii  libxmlsec11.2.27-2
ii  libxmlsec1-nss1.2.27-2
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxslt1.11.1.32-2.2~deb10u1
ii  uno-libs3 

Bug#931862: O: citadel

[PICCORO McKAY Lenz]

i'm interesting in packaged and mantain citadel, have my own packages...

i used citadel and noted the debian package are currently not working
(does not created the socket)


Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#946137: nvidia-legacy-340xx-driver: Fails to build with kernel 5.4

[Andreas Beckmann]

On 10/12/2019 22.13, Patrice Duroux wrote:
> Hi Andreas,
> 
> From my memory I got also a problem with nvidia-tesla-kernel-dkms to build 
> with
> kernel 5.4

Correct. That was fixed upstream in 418.113. For the tesla driver either
a new upstream release is needed or someone who backports the
corresponding changes. But that should be a separate bug report.

Andreas

Bug#946557: buster-pu: package clamav/0.102.1+dfsg-0+deb10u1

[Sebastian Andrzej Siewior]

On 2019-12-11 10:46:36 [+0100], Christoph Berg wrote:
> Re: Sebastian Andrzej Siewior 2019-12-10 
> <20191210224647.dk4svg65hleftr7r@flow>
> > +clamav (0.101.4+dfsg-0+deb10u1) buster; urgency=medium
> > +
> > +   - update symbols file (bump to 101.4 and drop unused cli_strnstr).
> 
> Did all these symbols change semantics? I'm surprised to see so many
> symbols bumped.

The CLAMAV_PRIVATE symbols are only used internaly by clamav. From one
release to another, the semantics/ABI of one or more of those functions
may change. The result is something between a crash/not working properly
and refusing to start because 'clamd' in clamav-daemon has a higher
"functionality" than the provided libclamav.
Instead of tracking this I go the easy way and bump all private symbols
on each release. The CLAMAV_PUBLIC symbols are only touched on a so bump
since they are also used by third party (i.e. libclamav-dev users).

Sebastian

Bug#945932: logrotate: did not preserve the user's configuration file, logs lost

[Vincent Lefevre]

On 2019-12-10 14:51:10 +0100, Christian Göttsche wrote:
> Control: tags -1 moreinfo
> 
> > there wasn't even a warning about that
> 
> Where did you place the configuration for /var/log/wtmp ?

/etc/logrotate.conf before, /etc/logrotate.d/wtmp after the upgrade.

> II. dpkg should also ask If you had modified /etc/logrotate.conf
> 
> Configuration file '/etc/logrotate.conf'
>  ==> Modified (by you or by a script) since installation.
>  ==> Package distributor has shipped an updated version.
>What would you like to do about it ?  Your options are:
> Y or I  : install the package maintainer's version
> N or O  : keep your currently-installed version
>   D : show the differences between the versions
>   Z : start a shell to examine the situation
>  The default action is to keep your current version.
> *** logrotate.conf (Y/I/N/O/D/Z) [default=N] ?

I don't remember exactly what questions I got. I probably assumed that
in such a case, the existing config was *moved* to the new location
(thus preserving the user's configuration as required), instead of
being reset at the new location. The above question was just about
the new /etc/logrotate.conf contents, for which I was OK with "Y",
but nothing was said about the new /etc/logrotate.d/wtmp file.

BTW, I've just checked at the logrotate NEWS.Debian file, and it does
not have an entry about this change. Thus there was no attempt to
clearly inform the user about the reset.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#946584: Acknowledgement (Needs to Build-Depends on python2 for tests)

[Sebastien Bacher]

Or another way would be to cherry pick

https://github.com/HOST-Oman/libraqm/commit/57749edb1

And use python3

Bug#946395: RFS: mercurial-extension-utils/1.5.0-1 -- Contains functions for writing Mercurial extensions

[Andrej Shadura]

Hi,

On Sun, 8 Dec 2019 at 15:57, Andrej Shadura  wrote:
> > I am looking for a sponsor for my package "mercurial-extension-utils"

> I’ll sponsor both of your packages.

Wait, but the mercurial package hasn’t switched over to Python 3 yet,
I don’t think it would make sense to upload these two yet?

-- 
Cheers,
  Andrej

Bug#946579: Please make autopkgtests cross-test-friendly

[Sebastien Bacher]

The previous patch missed to update the pkg-config call, please that new
one instead

diff -Nru raqm-0.7.0/debian/changelog raqm-0.7.0/debian/changelog
--- raqm-0.7.0/debian/changelog	2019-07-07 04:36:51.0 +0200
+++ raqm-0.7.0/debian/changelog	2019-12-11 09:53:17.0 +0100
@@ -1,3 +1,11 @@
+raqm (0.7.0-4) unstable; urgency=medium
+
+  * debian/tests/libssh-server:
+- Use the correct compiler for proposed autopkgtest cross-testing
+  support. 
+
+ -- Sebastien Bacher   Tue, 10 Dec 2019 11:56:08 +0100
+
 raqm (0.7.0-3) unstable; urgency=medium
 
   * d/rules: override dh_auto_configure to pass --enable-gtk-doc option
diff -Nru raqm-0.7.0/debian/tests/build raqm-0.7.0/debian/tests/build
--- raqm-0.7.0/debian/tests/build	2019-07-07 04:36:51.0 +0200
+++ raqm-0.7.0/debian/tests/build	2019-12-10 11:58:04.0 +0100
@@ -7,6 +7,13 @@
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat < raqmtest.c
 #include 
 
@@ -19,7 +26,7 @@
 }
 EOF
 
-gcc -o raqmtest raqmtest.c `pkg-config --cflags --libs raqm`
+${CROSS_COMPILE}gcc -o raqmtest raqmtest.c `${CROSS_COMPILE}pkg-config --cflags --libs raqm`
 echo "build: OK"
 [ -x raqmtest ]
 ./raqmtest

Bug#939929: terminator: crash when trying to start

[Jens Holzkämper]

I can confirm the same problem with a profile name containing 'ß'. The 
config file .config/terminator/config is correctly encoded as UTF-8. 
Removing the letter resolves the problem.

Bug#946591: mkesmtpdcert does not make file where it said

[PICCORO McKAY Lenz]

Package: courier-mta
Version: 1.0.6-1
Severity: critical
Justification: causes serious data loss

the mkesmtpdcert pgrogram in debian was altered, BUT are not in sync
around documentations.. that may cause confusion and data loss due
admins does not find resulting cert file and daemons does not start
never:

root@mail:/etc/courier# man mkesmtpdcert | grep pem
   /usr/lib/courier/esmtpd.pem. The mkesmtpdcert generates a
self-signed X.509 certificate, mainly for testing.
   /usr/lib/courier/esmtpd.pem must be owned by the courier user
and have no group or world permissions. The
   /usr/lib/courier/esmtpd.pem already exists.

root@mail:/etc/courier# mkesmtpdcert
/etc/courier/esmtpd.pem already exists.
root@mail:/etc/courier#


Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#946590: python3-dolfin: cannot find -lmpi

[Nico Schlömer]

Package: python3-dolfin
Version: 2019.1.0-7
Severity: normal

I don't know if this is a bug in the package or in my system. With the simplest
of python dolfin projects, I'm getting
```
--- Start compiler output 
/usr/bin/ld: cannot find -lmpi
collect2: error: ld returned 1 exit status

---  End compiler output  
Compilation failed! Sources, command, and errors have been written to:
/tmp/jitfailure-dolfin_expression_0ca911efb98de95f0dd6d82a8f353384
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/dolfin/jit/jit.py", line 167, in
compile_class
mpi_comm=mpi_comm)
  File "/usr/lib/python3/dist-packages/dolfin/jit/jit.py", line 47, in mpi_jit
return local_jit(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/dolfin/jit/jit.py", line 103, in
dijitso_jit
return dijitso.jit(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/dijitso/jit.py", line 217, in jit
% err_info['fail_dir'], err_info)
dijitso.jit.DijitsoError: Dijitso JIT compilation failed, see '/tmp/jitfailure-
dolfin_expression_0ca911efb98de95f0dd6d82a8f353384' for details

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "l.py", line 37, in 
u0 = Expression("a*sin(2.5*pi*x[1])*x[0]", a=0.2, degree=5)
  File "/usr/lib/python3/dist-packages/dolfin/function/expression.py", line
400, in __init__
self._cpp_object = jit.compile_expression(cpp_code, params)
  File "/usr/lib/python3/dist-packages/dolfin/function/jit.py", line 158, in
compile_expression
expression = compile_class(cpp_data, mpi_comm=mpi_comm)
  File "/usr/lib/python3/dist-packages/dolfin/jit/jit.py", line 170, in
compile_class
raise RuntimeError("Unable to compile C++ code with dijitso")
RuntimeError: Unable to compile C++ code with dijitso
```

Is there a missing dependency? MPI seems to be there:
```
$ ls /usr/lib/x86_64-linux-gnu/libmpi.so.40*
/usr/lib/x86_64-linux-gnu/libmpi.so.40
/usr/lib/x86_64-linux-gnu/libmpi.so.40.20.2
```



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

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

Versions of packages python3-dolfin depends on:
ii  libc6   2.30-0ubuntu2
ii  libdolfin-dev   2019.1.0-7
ii  libdolfin2019.1 2019.1.0-7
ii  libgcc1 1:9.2.1-21ubuntu1
ii  libopenmpi3 4.0.2-4
ii  libpetsc-real3.11   3.11.4+dfsg1-3build1
ii  libstdc++6  9.2.1-21ubuntu1
ii  python3 3.7.5-1ubuntu1
ii  python3-dijitso 2019.1.0-3
ii  python3-ffc 2019.1.0.post0-2
ii  python3-numpy [python3-numpy-abi9]  1:1.17.4-3ubuntu2
ii  python3-petsc4py3.11.0-4
ii  python3-pkgconfig   1.5.1-3
ii  python3-ply 3.11-3
ii  python3-pybind112.3.0-2
ii  python3-six 1.12.0-2build1
ii  python3-slepc4py3.11.0-2build1
ii  python3-sympy   1.4-1
ii  python3-ufl 2019.1.0-2

python3-dolfin recommends no packages.

Versions of packages python3-dolfin suggests:
pn  dolfin-doc  

-- no debconf information

Bug#946588: Acknowledgement (thunderbird's dowgrade prevention is being triggered after upgrade from stretch)

[Jens Holzkämper]

The same issue arrises in firefox: 
.

Bug#946589: Acknowledgement (firefox-esr: firefox's dowgrade prevention is being triggered after upgrade from stretch)

[Support (Jens)]

The same issue arises in thunderbird: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946588

Bug#930572: vala-panel-appmenu-common: Global Menu doesn't work for GTK applications

[Mike Gabriel]

On  Mi 11 Dez 2019 05:37:32 CET, Jacob Sims wrote:


A quick update:

I realized that the commands from the gtk-module README are in fact  
needed for XFCE. I added them to the shell script.


-JTS


Great. So, can this issue be closed?

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

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



pgpbBWINpeD7B.pgp
Description: Digitale PGP-Signatur

Bug#946589: firefox-esr: firefox's dowgrade prevention is being triggered after upgrade from stretch

[Jens Holzkämper]

Package: firefox-esr
Version: 68.3.0esr-1~deb10u1
Severity: important

The current package of firefox-esr in stretch (68.3.0esr-1~deb9u1) reports a
bigger version number than the current package in buster (68.3.0esr-1~deb10u1)
due to the inclusion of the build timestamp. The version reported by stretch is
68.3.0_20191206235801/20191206235801 and buster
68.3.0_20191203235607/20191203235607.

This information is then used by firefox to fill the compatibility.ini in the
profile and after an upgrade from stretch to buster leads to firefox prompting
to either quit or create a new profile because it detects that an older version
of firefox is trying to open a profile last used by a newer version. I believe
using the same profile should be safe, as the underlying upstream version is
the same at the moment and should probably never be newer in oldstable than
stable.

As a workaround it's possible to start firefox with the parameter "--allow-
downgrade" or manually delete the line starting with "LastVersion=" in the
compatibility.ini in the profile but less savy users may use access to the data
in their old profiles (the data is still there but a regular user will probably
not be able to access it without further instructions).



-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.6.1
ii  fontconfig2.13.1-2
ii  libasound21.1.8-1
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3+deb10u1
ii  libgcc1   1:8.3.0-6
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgtk-3-03.24.5-1
ii  libjsoncpp1   1.7.4-3
ii  libpango-1.0-01.42.4-7~deb10u1
ii  libstartup-notification0  0.12-6
ii  libstdc++68.3.0-6
ii  libvpx5   1.7.0-3+deb10u1
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.15-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages firefox-esr recommends:
ii  libavcodec57  10:3.3.9-dmo1+deb9u1
ii  libavcodec58  10:4.1.4-dmo1+deb10u1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-3
ii  libgtk2.0-02.24.32-3
ii  pulseaudio 12.2-4+deb10u1

-- Configuration Files:
/etc/firefox-esr/firefox-esr.js changed [not included]

-- no debconf information

Bug#946588: thunderbird's dowgrade prevention is being triggered after upgrade from stretch

[Jens Holzkämper]

Package: thunderbird
Version: 1:68.2.2-1~deb10u1
Severity: important


The current package of thunderbird in stretch (68.2.2-1~deb9u1) reports a
bigger version number than the current package in buster (68.2.2-1~deb10u1) due
to the inclusion of the build timestamp. The version reported by stretch is
68.2.2_20191116203149/20191116203149 and buster
68.2.2_20191116193034/20191116193034.

This information is then used by thunderbird to fill the compatibility.ini in
the profile and after an upgrade from stretch to buster leads to thunderbird
prompting to either quit or create a new profile because it detects that an
older version of thunderbird is trying to open a profile last used by a newer
version. I believe
using the same profile should be safe, as the underlying upstream version is
the same at the moment and should probably never be newer in oldstable than
stable.

As a workaround it's possible to start thunderbird with the parameter "--allow-
downgrade" or manually delete the line starting with "LastVersion=" in the
compatibility.ini in the profile but less savy users may use access to the data
in their old profiles (the data is still there but a regular user will probably
not be able to access it without further instructions).



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

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

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6.1
ii  fontconfig2.13.1-2
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3+deb10u1
ii  libgcc1   1:8.3.0-6
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgtk-3-03.24.5-1
ii  libgtk2.0-0   2.24.32-3
ii  libjsoncpp1   1.7.4-3
ii  libpango-1.0-01.42.4-7~deb10u1
ii  libstartup-notification0  0.12-6
ii  libstdc++68.3.0-6
ii  libvpx5   1.7.0-3+deb10u1
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  psmisc23.2-1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-de-de [hunspell-dictionary]  20161207-7
ii  hunspell-en-us [hunspell-dictionary]  1:2018.04.16-1
ii  lightning 1:68.2.2-1~deb10u1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.2-10
ii  fonts-lyx 2.3.2-1
ii  libgssapi-krb5-2  1.17-3

-- no debconf information

Bug#946585: RM: octave-ocs -- RoQA; uninstallable, indirectly depends on gcc-7

[Simon McVittie]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: octave-...@packages.debian.org
Control: block 932051 by -1

Please consider removing octave-ocs from unstable.

octave-ocs was removed from testing more than a year ago, and is
uninstallable in unstable (it depends on liboctave6, but octave now
provides liboctave7). It is one of a few remaining packages blocking
the removal of gcc-7, which was first requested back in March.

Maintainers in CC to check for objections; if you object to this removal,
please fix #902198 in octave-odepkg and get both packages uploaded or
binNMU'd with the current gcc version.

ftp team: if octave-ocs is removed, please revisit #932051, which will
be unblocked at that point as far as I can see.

smcv

Bug#946586: RM: herwig++ -- RoQA; FTBFS, dependencies FTBFS, indirectly depends on gcc-7

[Simon McVittie]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: herwi...@packages.debian.org
Control: block 932051 by -1

Please consider removing herwig++ from unstable. It has two RC FTBFS bugs
open since 2016 and 2018, depends on thepeg which FTBFS with gcc 9,
indirectly depends on lhapdf which FTBFS with gcc 8, and indirectly depends
on gcc 7 which is obsolete.

Maintainers in CC to check for objections; if you object to this removal,
please fix the various FTBFS bugs in herwig++ and its dependencies thepeg
and lhapdf, so that they can all be rebuilt with the current gcc version.

smcv

Bug#946587: RM: thepeg -- RoQA; FTBFS, dependency FTBFS, indirectly depends on gcc-7

[Simon McVittie]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: the...@packages.debian.org
Control: block 932052 by -1

Please consider removing thepeg from unstable. It FTBFS with gcc 9 without
any obvious signs of progress, depends on lhapdf which FTBFS with gcc 8,
and indirectly depends on gcc 7 which is obsolete.

Maintainers in CC to check for objections; if you object to this removal,
please fix the various FTBFS bugs in thepeg and its dependency lhapdf,
so that they can be rebuilt with the current gcc version.

ftp team: if thepeg is removed, I believe it's lhapdf's last
reverse-dependency, so please revisit #932052 at that time.

smcv

Bug#925826: shim: FTBFS w/ GCC 9 fix

[Steve McIntyre]

On Tue, Dec 10, 2019 at 11:06:49PM -0500, John Scott wrote:
>Control: tags -1 patch
>
>Merge request with fix at https://github.com/rhboot/shim/pull/170

Thanks for the heads-up!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
There's no sensation to compare with this
Suspended animation, A state of bliss

Bug#885505: bumping severity of pygtk bugs

[Moritz Muehlenhoff]

On Wed, Dec 11, 2019 at 09:52:15AM +0100, Thibaut Paumard wrote:
> Le 10/12/2019 à 19:59, Moritz Mühlenhoff a écrit :
> > On Mon, Oct 07, 2019 at 04:51:09PM +0200, Thibaut Paumard wrote:
> >> Dear Jeremy,
> >>
> >> Thanks, I have warned upstream that spydr will be removed if not updated
> >> to Python 3 and Gtk 3.
> > 
> > Was there any reaction? Otherwise let's go ahead with the removal from
> > the archive.
> > 
> > Cheers,
> > Moritz
> 
> Yes, upstream did say they would fix this. As this is a leaf package, I
> would propose to wait until after the vacation and remove it on, say,
> Jan. 15th. In the meantime I ill ping them and maybe they manage by then.
> 
> Else, I can always reintroduce it later.

Sounds good!

Cheers,
Moritz

Bug#946359: pg-snakeoil: Selftest apears to be broken

[Christoph Berg]

Re: Sebastian Andrzej Siewior 2019-12-07 <20191207201131.v563o62fpmjnz7ol@flow>
> clamav can't migrate because the debci-test for pg-snakeoil fails. I
> *think* that the test itself is somehow borken since after installing
> the bytecode.cvd itself appears on my system. Could you please take a
> look?

The test fails in my sid chroot as well because freshclam can't
download the database, /var/lib/clamav/ is empty except for a "tmp"
directory.

$ cat /var/log/clamav/freshclam.log
Wed Dec 11 10:32:47 2019 -> --
Wed Dec 11 10:32:47 2019 -> freshclam daemon 0.102.1 (OS: linux-gnu, ARCH: 
x86_64, CPU: x86_64)
Wed Dec 11 10:32:47 2019 -> ClamAV update process started at Wed Dec 11 
10:32:47 2019
Wed Dec 11 10:32:47 2019 -> daily database available for download (remote 
version: 25660)
Wed Dec 11 10:32:52 2019 -> WARNING: Mirror https://database.clamav.net is not 
synchronized.
Wed Dec 11 10:32:52 2019 -> ERROR: Unexpected error when attempting to update 
database: daily
Wed Dec 11 10:32:52 2019 -> WARNING: fc_update_databases: fc_update_database 
failed: Up-to-date (1)
Wed Dec 11 10:32:52 2019 -> ERROR: Database update process failed: Up-to-date 
(1)
Wed Dec 11 10:32:52 2019 -> ERROR: Update failed.
Wed Dec 11 10:32:52 2019 -> --

> However. The complete database (/var/lib/clamav/) contains today 454MiB.
> I don't know what your self-test but using
> 
> | clamav$ cat unit_tests/input/clamav.hdb
> | aa15bcf478d165efd2065190eb473bcb:544:ClamAV-Test-File
> 
> as a databse will find the un-offical test file:
> 
> |$ clamscan -d clamav.hdb split.clam.exe
> |split.clam.exe: ClamAV-Test-File.UNOFFICIAL FOUND

Using a smaller database instead of downloading the whole thing for
each test run makes sense.

We just need to figure out how to compile it to a
/var/lib/clamav/*.cld database that cl_load() understands. At the
moment the database path is not configurable in pg_snakeoil, maybe we
need to change that as well.

Christoph

Bug#946460: tcmu: Fix for 32 bit builds

[Raphael Hertzog]

Hi,

On Mon, 09 Dec 2019, James Page wrote:
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * Resolve issues with compilation on 32 bit architectures:
> - d/p/32bit-size_t-cast.patch: Ensure same type comparison
>   avoiding compilation error.

Thanks, merged this one.

> - d/p/Disable-Werror.patch: Drop, no longer needed.

But not this one, -Werror is generally not a good idea in the context of
Debian.

I wonder why Ubuntu is interested in a build working cleanly with -Werror.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#937811: python-hkdf: Python2 removal in sid/bullseye

[Sascha Steinbiss]

> It looks like all reverse deps are currently exclusively using the Python3 
> version: 

Or maybe not, looks like not all rdeps are displayed. Looks like things
like python-omemo and friends still depend on this.
So no removal upload for me then.

S.

Bug#946584: Needs to Build-Depends on python for tests

[Sebastien Bacher]

In fact it should be 'python', updated patch coming

diff -Nru raqm-0.7.0/debian/control raqm-0.7.0/debian/control
--- raqm-0.7.0/debian/control   2019-07-07 04:36:51.0 +0200
+++ raqm-0.7.0/debian/control   2019-12-11 11:15:05.0 +0100
@@ -6,6 +6,7 @@
 Build-Depends:
  debhelper (>= 12),
  pkg-config,
+ python,
  libfreetype6-dev (>= 2.4.2),
  libfribidi-dev,
  libharfbuzz-dev,