Bug#943750: network-manager: wifi hotspot changes frequency and network connection breaks down

[Malte Schmidt-Tychsen]

Package: network-manager
Version: 1.14.6-2
Severity: wishlist

Hi there,

When I sit on a train and that train moves through densely populated 
areas, I lose connection to the wifi hotspot in that the pings stop, but 
network manager believes the connection is still working and shows 
everything as connected.


I believe this may be related to the wifi hotspot changing wifi channels 
trying to avoid interference of other networks in the area. In those 
densely populated areas a network scan will reveal 40 or more wifi 
networks. Sometimes it works and the laptop keeps the connection through 
a channel change. The pings will cease for up to five seconds and 
continue. But sometimes the network connection will not reestablish. I 
have also seen a channel change in the log files while the connection 
has already ceased to work and it still won't come back. I have not 
found much in the system log that would help me here. The only messages 
that occur around the times of the issue I found are these:


wpa_supplicant[6181]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 
signal=-30 noise= txrate=13


wpa_supplicant[6181]: wlp2s0: CTRL-EVENT-CHANNEL-SWITCH freq=2442 
ht_enabled=0 ch_offset=0 ch_width=20 MHz (no HT) cf1=2442 cf2=0


In fact, the following four lines appeared back to back in my logfile 
right before I lost connection:


Okt 29 05:51:38 debian wpa_supplicant[6181]: wlp2s0: 
CTRL-EVENT-CHANNEL-SWITCH freq=2442 ht_enabled=1 ch_offset=0 ch_width=20 
MHz cf1=2442 cf2=0


Okt 29 05:52:45 debian wpa_supplicant[6181]: wlp2s0: 
CTRL-EVENT-CHANNEL-SWITCH freq=2457 ht_enabled=1 ch_offset=0 ch_width=20 
MHz cf1=2457 cf2=0


Okt 29 05:53:09 debian wpa_supplicant[6181]: wlp2s0: 
CTRL-EVENT-CHANNEL-SWITCH freq=2442 ht_enabled=1 ch_offset=0 ch_width=20 
MHz cf1=2442 cf2=0


Okt 29 05:53:21 debian wpa_supplicant[6181]: wlp2s0: 
CTRL-EVENT-CHANNEL-SWITCH freq=2457 ht_enabled=1 ch_offset=0 ch_width=20 
MHz cf1=2457 cf2=0


If someone could point me towards more comprehensive log files I could 
post their contents.



I use the following:

- Dell E7450
- Intel Corporation Wireless 7265
- firmware-iwlwifi 20190717-1
- linux-image-4.19.0-6-amd64

- Google Pixel 3 Wifi Hotspot

I have been having the issue described before I got Debian 10 Buster.

Please also note that this issue did not occur with other phones used as 
hotspots. And this issue is also not limited to Debian or this laptop. 
Older devices connected to the same hotspot also seem to have issues 
staying connected during the same time. OTOH


I raised this issue with Google in the appropriate forum [1] as well as 
on XDA-Developers as well as a feedback on the phone but have received 
no response as of now. And I suspect I won't. As far as I understand 
Google will use machine learning to analyze incoming reports and only 
follow up with human readers if an issue reaches a threshhold and enough 
users are reporting it. But this could also be an expected behavior on 
newer wifi hotspots and crop up more often over time.


[1] https://support.google.com/pixelphone/thread/14799895?hl=en

Thx!

Malte

Bug#943749: dmrconfig FTCBFS: hard codes the build architecture pkg-config

[Helmut Grohne]

Source: dmrconfig
Version: 1.1+git20190919.e47491e-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

dmrconfig fails to cross build from source, because the upstream
Makefile hard codes the build architecture pkg-config. Please consider
applying the attached patch to fix that.

Helmut
--- dmrconfig-1.1+git20190919.e47491e.orig/Makefile
+++ dmrconfig-1.1+git20190919.e47491e/Makefile
@@ -1,4 +1,5 @@
 CC ?= gcc
+PKG_CONFIG ?= pkg-config
 
 VERSION = $(shell git describe --tags --abbrev=0)
 GITCOUNT= $(shell git rev-list HEAD --count)
@@ -8,14 +9,14 @@
   gd77.o hid.o serial.o d868uv.o dm1801.o
 CFLAGS ?= -g -O -Wall -Werror 
 CFLAGS += -DVERSION='"$(VERSION).$(GITCOUNT)"' \
-  $(shell pkg-config --cflags libusb-1.0)
+  $(shell $(PKG_CONFIG) --cflags libusb-1.0)
 LDFLAGS?= -g
-LIBS= $(shell pkg-config --libs --static libusb-1.0)
+LIBS= $(shell $(PKG_CONFIG) --libs --static libusb-1.0)
 
 #
 # Make sure pkg-config is installed.
 #
-ifeq ($(shell pkg-config --version),)
+ifeq ($(shell $(PKG_CONFIG) --version),)
 $(error Fatal error: pkg-config is not installed)
 endif
 

Bug#943748: Firefox-esr upgrade issue [60.9.0esr-1~deb10u1 -> 68.2.0esr-1~deb10u1]

[local10]

Package: firefox-esr
Version: 68.2.0esr-1~deb10u1

Hi,

Firefox v60 had a nice feature: One could go to, say, domain.tld/page_1.html, 
then increase/decrease the font size on the page and it would affect all pages 
in the domain.tld. What's more, firefox would remember the font size setting 
between firefox restarts. It's was a very useful feature for websites that 
mismanage fonts, making text either too big or too small.

In Firefox v68 it's no longer true. It appears font size increase/decrease only 
affects a tab (instead of website domain) and firefox only remembers the font 
size setting as long as the tab stays open. If the tab is closed the font size 
resets to default.

Is it a bug or a feature? Based on what I read, Firefox v70 works the same way 
as FF v60 did so it's unclear why FF v68 behaves differently.

Any way to get Firefox v60 per domain font size behavior back?

Thanks

# uname -a
Linux srvtst 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 
GNU/Linux

Bug#943583: sysv-rc: information from the Policy Manual for README.runlevels

[Sean Whitton]

Hello,

On Tue 29 Oct 2019 at 02:13AM +00, Dmitry Bogatov wrote:

> Thank you for you work on comparing with README.runlevels. I included
> provided paragraphs.

Cool!

>> but I'm not sure this text has actually ever been updated since Ian
>> Jackson wrote it the mid-nineties.
>
> It seems it is still correct. I double-checked last part, about
> runlevels 0/6, reading source of /etc/init.d/rc -- it is still accurate.

What I meant here was that it might be that only Ian holds copyright on
the text, not the other copyright holders listed for the Policy Manual
in general.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#547722: Contemplation:I'd like to ask the media to envision a world where this bone hard truth sticks in people's minds and strikes a chord.

[elisabeth.mueller]

Hi there. How is it going? Hope you're doing well and find this worth your 
time,contemplation despite your hectic schedules.
It's my belief that these revelations were given for us to know the truth and 
choose the right path accordingly.It would be much appreciated if you 
acknowledge that the truth must be known to all and make as much effort as 
possible to promote public awareness of these testimonies.UK mirror news  
https://www.youtube.com/watch?v=Ecy8YUmFAek   (  unwelcome truth )  
https://www.youtube.com/watch?v=dWXkBBIaiVc  a trip to hell ( extremely graphic 
)
  http://heavencometrue.com/?lang=eng         


                                                                      
unsubscribe

Bug#943747: RFA: python-expiringdict -- Python3 caching library

[Daniel Kahn Gillmor]

Package: wnpp
Severity: normal

I am looking for external adoption of the python-expiringdict package.
I'm assuming that Debian Python Modules Team (DPMT) is a reasonable
candidate if that group is interested.

The package description is:
 expiringdict is a Python caching library, providing an ordered
 dictionary with auto-expiring values for caching purposes. Expiration
 happens on any access, object is locked during cleanup from expired
 values.  ExpiringDict stores at most a maximum number of elements -
 the oldest will be deleted.

python3-expiringdict is used by python3-dnsq and python3-pyaff4, but I'm
no longer using this immediately myself, so i'm not a good candidate for
solo maintenance.

I've updated the package source to use gbp, to use DEP-14, and to be
close to lintian-clean (only testsuite-autopkgtest-missing remains),
and i've placed it on salsa to make it easier for adoption by the DPMT
in case that's useful.  I've also updated the packaging to the most
recent upstream release, which appears to be 1.1.4.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#943697: [Pkg-javascript-devel] Bug#943697: RM: node-stringset -- RoM, abandoned upstream

[Pirate Praveen]

On 2019, ഒക്‌ടോബർ 28 3:18:07 PM IST, Julien Puydt  
wrote:
>Package: node-stringset
>
>Hi,
>
>I'm the maintainer of this package within the Debian Javascript
>Maintainer team. It's not used anymore, abandoned upstream, so I'd like
>to see it removed from unstable.

Hi Julian,

This should be filed against ftp.debian.org pseudo package.

You should reassign this bug now.

>Thanks!
>
>JP
>
>-- 
>Pkg-javascript-devel mailing list
>pkg-javascript-de...@alioth-lists.debian.net
>https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#943746: ITP: ruby-rqrcode-core -- Ruby Gem Library to encode QR Codes

[Samyak Jain]

Package: wnpp
Severity: wishlist
Owner: Samyak Jain 

* Package name: ruby-rqrcode-core
  Version : 0.1.0
  Upstream Author : 2008, Duncan Robertson
* URL : https://github.com/whomwah/rqrcode_core
* License : Expat
  Programming Lang: Ruby
  Description : Ruby Gem Library to encode QR Codes

 rqrcode_core is a Ruby library for encoding QR Codes. The simple
 interface (with no runtime dependencies) allows you to create QR Code
 data structures.


It is a dependency for diaspora and hence needs to be packaged.

Thanks,
Samyak Jain

Bug#943745: lintian: 'file-missing-in-md5sums' and 'md5sums-lists-nonexistent-file' are reversed

[Felix Lechner]

Package: lintian

Hi,

The tags 'file-missing-in-md5sums' and
'md5sums-lists-nonexistent-file' are reversed. [1] To which tag does
the exemption for aspell/ispell belong, please?

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/blob/master/checks/md5sums.pm#L122-131

Bug#943744: caja: Cannot move file to Trash, do you want to delete immediately?

[scott092707]

Package: caja
Version: 1.22.2-1
Severity: normal

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Scott Jacobs 
To: Debian Bug Tracking System 
Subject: caja: Cannot move file to Trash, do you want to delete immediately?
Bcc: Scott Jacobs 
Message-ID: 
<157231618695.27987.4352493207987785411.reportbug@ASUS-PRIME-B350M-A-CSM>
X-Mailer: reportbug 7.5.3
Date: Mon, 28 Oct 2019 22:29:46 -0400
X-Debbugs-Cc: scott092...@aol.com


Dear Maintainer,

I try to delete a file, but get the above subject text.

At first, I thought it was because all of my personal data directories
(Documents/Desktop/Pictures/...) are bind-mounted to directories in a separate 
data partition.
However, the rest of /home is within the system partition /, and I get the same
result there.
If I sudo caja, and try to delete a (copy of a) system file (say, /etc/fstab),
this works fine. It appears in /root/.local/share/Trash/files.
I DO have a ~/.local/share/Trash/files directory, and my /data partition has a
.Trash-1000 directory.

I also note, that when I view a picture with eog, invoked from caja's context 
menu,
and hit the delete key, eog also tells me it cannot trash the file, 
and would I like to delete it.  eog apparently inherits the faulty information 
that caja feeds it.

If I use nemo or pcmanfm-qt, there is no problem trashing the files, and if eog
is invoked from them, it has no problem trashing them with the delete key as 
well.

(I don't know why ~/.local/share/Trash[/files] is somehow owned by root, but
this is not a problem for the other FMs, and I suspect that it is intentional;
that individually, trashed files officially ought not to be deleted
individually, but are allowed to be deleted en masse when "Empty Trash" is
invoked as a command - but this is only a supposition...)

I just noticed something interesting:
If I try to trash a file in my bind-mounted /data partition, I just get the
subject text, but if I try to trash a file in my ~/ directory, I ALSO get the
following text, under the "Show more details" arrow:
"Unable to find or create trash directory for /home/scott/.reportbugrc (copy)"

-
scott@ASUS-PRIME-B350M-A-CSM:~$ ls -lha /
...
drwxrwxr-x  10 scott scott 4.0K Oct 28 20:15 data

scott@ASUS-PRIME-B350M-A-CSM:~$ ls -lha /data
...
drwxrwxr-x 64 scott scott 4.0K Mar 14  2019 scott
drwx--  5 scott scott 4.0K Feb 28  2014 .Trash-1000

scott@ASUS-PRIME-B350M-A-CSM:~$ ls -lha .local/share
drwx--  4 root  root  4.0K Mar 16  2019 Trash

scott@ASUS-PRIME-B350M-A-CSM:~$ sudo ls -lha .local/share/Trash
...
drwx--  2 root  root  4.0K Mar 16  2019 files
drwx--  2 root  root  4.0K Mar 16  2019 info




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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
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 caja depends on:
ii  caja-common   1.22.2-1
ii  desktop-file-utils0.24-1
ii  gvfs  1.38.1-5
ii  libatk1.0-0   2.34.1-1
ii  libc6 2.29-2
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libcaja-extension11.22.2-1
ii  libexempi82.5.1-1
ii  libexif12 0.6.21-5.1
ii  libgail-3-0   3.24.12-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-1
ii  libglib2.0-0  2.62.2-1
ii  libglib2.0-bin2.62.2-1
ii  libglib2.0-data   2.62.2-1
ii  libgtk-3-03.24.12-1
ii  libice6   2:1.0.9-2
ii  libmate-desktop-2-17  1.22.2-1
ii  libnotify40.7.8-1
ii  libpango-1.0-01.42.4-7
ii  libpangocairo-1.0-0   1.42.4-7
ii  libselinux1   2.9-2+b2
ii  libsm62:1.2.3-1
ii  libx11-6  2:1.6.8-1
ii  libxml2   2.9.4+dfsg1-7+b3
ii  mate-desktop  1.22.2-1
ii  shared-mime-info  1.10-1

Versions of packages caja recommends:
ii  gvfs-backends  1.38.1-5

Versions of packages caja suggests:
pn  engrampa
pn  gstreamer1.0-tools  
pn  meld

-- no debconf information

Bug#943743: ITP: golang-github-varlink-go -- Golang implementation of the Varlink protocol

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org

   Package name: golang-github-varlink-go
Version: 0.0+git20191018
License: Apache-2.0
URL: https://github.com/varlink/go
Vcs-Browser: 
https://salsa.debian.org/go-team/packages/golang-github-varlink-go
Description: Golang implementation of the Varlink protocol
 Golang library implementing the Varlink protocol.
 http://varlink.org/


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

Bug#943583: sysv-rc: information from the Policy Manual for README.runlevels

[Dmitry Bogatov]

control: tags -1 +pending

[2019-10-26 14:11] Sean Whitton 
> We are removing some implementation details of the runlevels system from
> the Policy Manual.  Most of the information is duplicated in
> README.runlevels as shipped by sysv-rc, and is anyway not relevant to
> package maintainers as such, who are only allowed to invoke update-rc.d.
>
> Directly comparing the text we're removing with the contents of
> README.runlevels, however, reveals that the old Policy Manual text
> assumes a lot less knowledge of classic UNIX init practices than does
> README.runlevels.
>
> It seems to me that someone who had only ever worked with systems using
> systemd, and who now needed to learn how sysvinit runlevels work, would
> have an easier time of it if they had the Policy Manual text in addition
> to README.runlevels.
>
> In particular, these three paragraphs explain ideas which are (at least
> partially) implicitly assumed by README.runlevels:
>
> [...]

Thank you for you work on comparing with README.runlevels. I included
provided paragraphs.

> but I'm not sure this text has actually ever been updated since Ian
> Jackson wrote it the mid-nineties.

It seems it is still correct. I double-checked last part, about
runlevels 0/6, reading source of /etc/init.d/rc -- it is still accurate.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#943395: runit: Minor fixes to invoke-run

[Dmitry Bogatov]

[2019-10-27 18:31] Lorenz 
>  > > - "${initscript}" stop
>  > > + "${initscript}" stop >/dev/null
>  >
>  > Why?

> The output from Sysv init script goes to the runit log and it's not
> clear that is from sysv script; also, it's a stop message during a
> start sequence.  It's quite confusing.

Reasonable. Can you please refresh patch aganist latest head
(4b1d0685456442f033c00ab0d3cb594d92d0a786), without whitespace changes?

Patch you have sent have missing From: header.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#943742: ITP: python-sop -- Framework for implementing the Stateless OpenPGP CLI in Python

[Daniel Kahn Gillmor]

Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor 

* Package name: python-sop
  Version : 0.1.1
  Upstream Author : Daniel Kahn Gillmor 
* URL : https://gitlab.com/dkg/python-sop
* License : MIT
  Programming Lang: Python
  Description : Framework for implementing the Stateless OpenPGP CLI in 
Python

The Stateless OpenPGP Command-Line Interface (or `sop`) is a
specification that encourages OpenPGP implementators to provide a
common, relatively simple command-line API for purposes of object
security.

This Python module helps implementers build such a CLI from any
implementation accessible to the Python interpreter.

It does *not* provide such an implementation itself -- this is just
the scaffolding for the command line, which should make it relatively
easy to supply a handful of Python functions as methods to a class.

-

This is a useful component in building out a `sop` implementation.  I
am hoping to convince the upstream maintainer of PGPy to build one,
and to convince the GnuPG team to maintain one as part of GPGME.
Having this framework available should make it easier to get wider
adoption.

Bug#943741: duplicity: fix source build with multiple supported python3 versions

[Steve Langasek]

Package: duplicity
Version: 0.8.05-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi Alexander,

The duplicity source package includes code in debian/rules to specifically
iterate over all currently-supported versions of python3 in the archive
(py3versions -rv) in order to build its extension for them.  However, it
only build-depends on python3-dev, not on python3-all-dev, which is required
in order to ensure all of these versions of python are available at build
time.

The attached patch fixes the source to build-depend on python3-all-dev, and
also to ensure that the correct version of python is used when invoking
../bin/duplicity at each iteration through the test suite.

Note, however, that even with this patch, duplicity still fails to build
from source in Ubuntu right now where python3.8 has been added as a
supported version of python, due to python3.8-specific test failures:
https://launchpad.net/ubuntu/+source/duplicity/0.8.05-1ubuntu2

Since python3.8 will become the default python in Ubuntu 20.04 (and
presumably also in Debian soon, although I haven't yet seen a timeline
communicated yet on that transition), you may want to care about these
failures as well.  The python3-defaults which adds python3.8 as supported is
currently in Debian experimental.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru duplicity-0.8.05/debian/control duplicity-0.8.05/debian/control
--- duplicity-0.8.05/debian/control 2019-10-22 08:42:17.0 -0700
+++ duplicity-0.8.05/debian/control 2019-10-25 22:34:10.0 -0700
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Alexander Zangerl 
-Build-Depends: debhelper (>= 10.0.0), librsync-dev (>=0.9.6), python3-dev, 
dh-python, python3-setuptools, rdiff, gnupg | gnupg1, par2, python3-lockfile, 
python3-mock, python3-pexpect, python3-fasteners, python3-requests, 
python3-urllib3, python3-coverage, python3-pycodestyle, pylint, python3-pytest, 
python3-pytest-runner, python3-pytest-cov, tox, python3-future, rename, rsync
+Build-Depends: debhelper (>= 10.0.0), librsync-dev (>=0.9.6), python3-all-dev, 
dh-python, python3-setuptools, rdiff, gnupg | gnupg1, par2, python3-lockfile, 
python3-mock, python3-pexpect, python3-fasteners, python3-requests, 
python3-urllib3, python3-coverage, python3-pycodestyle, pylint, python3-pytest, 
python3-pytest-runner, python3-pytest-cov, tox, python3-future, rename, rsync
 Standards-Version: 4.1.3.0
 Homepage: http://duplicity.nongnu.org/
 X-Python3-Version: >= 3.7
diff -Nru duplicity-0.8.05/debian/rules duplicity-0.8.05/debian/rules
--- duplicity-0.8.05/debian/rules   2019-10-22 08:42:17.0 -0700
+++ duplicity-0.8.05/debian/rules   2019-10-25 22:34:10.0 -0700
@@ -8,6 +8,7 @@
 ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
set -e -x;\
for py in $(PYVERS); do \
+  TOXPYTHON=python$$py \
   PYTHONPATH=$(CURDIR)/build/lib.*-$$py  python$$py ./setup.py test ;\
   done
 endif

Bug#943716: systemd: generates a directory name with the /etc/machine-id value, which is confidential

[Vincent Lefevre]

On 2019-10-28 23:22:54 +0100, Michael Biebl wrote:
> I don't see a problem with /etc/machine-id being word-readable, I don't
> see a problem either with the journal directory containing the
> machine-id. If someone posts the id to a forum, I don't consider this
> problematic either.
> 
> The man pages recommends to not broadcast the machine-id via the network
> for the simple reason, as this would easily allow the machine to be
> tracked. This does not apply here.

No, this is not what the man page is saying. It just says that
is it confidential. So, for instance, someone could decide that
it is used for machine authentication. Thus a foreign machine
could steal the ID to access services it should not be allowed
to.

In any case, the man page says "must not be exposed in untrusted
environments, in particular on the network." And this part has
been broken.

Note also that the same paragraph recommends to use a hash as a
stable unique identifier. But since this is meant to be stable
and unique, this would also allow the machine to be tracked if
such a hash is exposed on the network. So the reason you give
is obviously wrong.

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

Bug#942235: dask: autopkgtest needs update for new version of pytest

[Drew Parsons]

On 2019-10-29 03:01, Rebecca N. Palmer wrote:

Assuming we're talking about

https://salsa.debian.org/python-team/modules/dask/blob/experimental/debian/patches/use-local-intersphinx.patch

I think the actual problem is on the numpy line: it adds the local
inventory but doesn't remove the online one, so the tuple is too long.
(I haven't actually tried this.)



Thanks Rebecca, that makes sense.  I can scrutinize that patch more 
closely.


Drew

Bug#943731: gimp: New upstream release (2.10.14)

[Jeremy Bicha]

On Mon, Oct 28, 2019 at 2:51 PM Michael Schumacher  wrote:
> a new release of the stable branch of GIMP has been made: 2.10.14.

Yeah, we just need to get the new gegl to build with meson first.

Traditionally, requests for new version updates are marked as Wishlist
instead of Important.

Thanks,
Jeremy Bicha

Bug#917108: cura: Please consider packaging latest version 3.6

[karlnorma]

Actually version 4.3 -- lots of improvements - is there a licensing issue with 
cura and cura-engine?
939...@bugs.debian.org

The alternative is running an AppImage package - always have to consider security risks AND When 
every app runs a different library, the bugs don't get squashed (like in commercial OSs).


It looks like archlinux has 4.3 - why not Debian?




Karl Schmidt  EMail k...@lrak.net
3209 West 9th Street Ph (785) 979-8397
Lawrence, KS 66049

"Venture Vultures" Those people that get venture capital to
pay inflated salaries with ideas that have no chance to work.
Often involves a patent that should never have been issued.

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

[積丹尼 Dan Jacobson]

> "GFTG" == Gabriel F T Gomes  writes:

GFTG> I'm trying to understand what to expand, thus I need your help.

Maybe in the meantime expand everything, as it is hard to figure out
anyway. At least for me too.

Bug#942901: Tor Browser 9.0 shows only black screens

[antistress]

ALso note that the solution given by Paul Wise worked for me after rebooting

Thanks

Le 28/10/2019 à 17:11, antistress a écrit :

Same bug for me on Debian Sid
see screnshot attached
Thanks

Bug#709161: Help Desk

[LEVINE ALAN]

You have received this message because you have reached your mailbox Quota
limit. Incoming messages will therefore bounce or return to sender.
Reset your quota using this link Click on (*GATEWAY
*)
  to avoid losing incoming messages.

Thanks,
Webmail IT Help Desk

Bug#943740: amanda-server: IPv6 support is disabled for 10 years already.

[Heiko Schlittermann (HS12-RIPE)]

Package: amanda-server
Version: ipv6 support disabled for 10 years already
Severity: important
Tags: ipv6

Dear Maintainer,

is there any reason that IPv6 support is disabled for about 10 years
already?

Amanda builds cleanly with the --without-ipv6 option removed.
If it works I've to find out.


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

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

Versions of packages amanda-server depends on:
pn  amanda-common  
ii  libc6  2.28-10
pn  libcurl3   
ii  libcurl4   7.64.0-4
ii  libglib2.0-0   2.58.3-2+deb10u1
ii  libjson-perl   4.02000-1
ii  libssl1.1  1.1.1d-0+deb10u2
ii  mailutils [mailx]  1:3.5-3
ii  perl   5.28.1-6

amanda-server recommends no packages.

Versions of packages amanda-server suggests:
pn  amanda-client 
ii  cpio  2.12+dfsg-9
ii  gnuplot   5.2.6+dfsg1-1+deb10u1
ii  gnuplot-qt [gnuplot]  5.2.6+dfsg1-1+deb10u1

Bug#943739: RM: golang-websocket -- ROM; source package renamed to golang-github-gorilla-websocket

[Anthony Fok]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear FTP Masters,

The golang-websocket source package has been renamed to
golang-github-gorilla-websocket following the naming conventions
of the Debian Go Packaging Team.

golang-github-gorilla-websocket is now in the NEW queue.

Many thanks!

Anthony Fok

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEFCQhsZrUqVmW+VBy6iUAtBLFms8FAl23cScACgkQ6iUAtBLF
ms9hcxAAih8A6PdhCbYvNRQzoPqgSKe3cNM8aaaosY3zPd0fN9ZYyqy8vxSOr/WY
NgawENBRhtvkUhW4v27VpIVc1LLe0tnE44LNOHAf21vggaSob1P0sWsq20im7Nas
4YonTmv9ZllARcJ3zT7NgE++7/dprAwwPsbZk2sIALuUcCtmVKeox0Ld/xQHUGXW
omlHirhMZsJoOY8WBZjYv0ep83zLp+fqerHvmh+rZovU/9deE1Xw1kBaNLnEnCqJ
bByrMZXUKGtsQKV7YxoXAvbLXjekFj8dpcnj+wtEAdMStcggAy67/weW9Z1EyUOj
CrdZMOy/h6CAVPntkekj3OVSxUka3wS2loFBRMxRLhrmXdEpEFtX702Z30Mm0dVL
vxlZe0WjdAPKrfKAab7e+qlys+H4uoht08IP03TZMN9Fa1azRfR4XxB5aDJ4nh8J
018q5k2tc8CbOSRqECuSxNOfvEDY0/hofiD/0a3BtfhtWg0TBrS3ZV8zYYGtOXqJ
ZmlOOBErngEIjUGmxya05jVQU1lhNfFGNaPAfn2P5bpJ+SbaAkKRmJP3glb9x7F4
lRduqk3AsB4abrEFwMGgXaYFDNQzb/95tMo98jEq8XBmFgcqGnW5rrUWLKbRNU16
zkDRZqqC9aP3f0PJPe6PGRCTVPvuf2m8AmPnZT2H/aF7zwGfk5g=
=Hrmz
-END PGP SIGNATURE-

Bug#874880: [freemedforms-project] Future Qt4 removal from Buster

[Andreas Tille]

I'll do so once I'm back from vacation.
Its a shame that Eric does not take this issue serious since
re-introduction will take probably quite some time for compx
packages like this, Andreas.

On Mon, Oct 28, 2019 at 10:47:28PM +0100, Moritz Mühlenhoff wrote:
> On Tue, Oct 08, 2019 at 04:17:13PM +0200, Andreas Tille wrote:
> > Hi again,
> > 
> > I'm sorry to repeat myself but please pretty please help finding some
> > solution.  Freemedform-project is about to be removed from Debian and
> > I see no way to prevent this.
> 
> Andreas,
> can you file a removal bug? If it gets ported to Qt5, it can still
> be re-introduced before the Bullseye release.
> 
> Cheers,
> Moritz
> 

-- 
http://fam-tille.de

Bug#943738: Syncing to an external device should not remove files from the device (at least without asking)

[Sven Bartscher]

Package: rhythmbox
Version: 3.4.3-2+b1
Severity: normal

Today I was exploring how Rythmbox can sync files between my local
music collection and my Android phone via USB. Much to my dismay, I
noticed that “sync” in Rhythmbox apparently means to sync the state of
my local music colletion onto the external device and also includes
deleting all music files from the device that aren't in my local
collection.

Now this was quite a shock for me. Usually I would expect a warning,
preferably a big fat one, before files get irrevocably deleted. But
apparently pressing a button labeled “Sync” is all it took to start
deleting files. Because of this I lost several files today, some of
which I will probably never get back.

Instead of just deleting files, I think Rhythmbox should do one of the
following:

* Suggest to import the files, which would have been deleted, into my
  local collection

* Leave the files where they are, without doing anything

* Ask me clearly if I really want these files deleted before deleting
  them. This warning should include a list of the files being deleted.

Regards
Sven

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

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

Versions of packages rhythmbox depends on:
ii  dbus1.12.16-2
ii  gstreamer1.0-plugins-base   1.16.1-1
ii  gstreamer1.0-plugins-good   1.16.1-1
ii  gstreamer1.0-x  1.16.1-1
ii  libc6   2.29-2
ii  libglib2.0-02.62.2-1
ii  libgstreamer-plugins-base1.0-0  1.16.1-1
ii  libgstreamer1.0-0   1.16.1-1
ii  libgtk-3-0  3.24.12-1
ii  libpeas-1.0-0   1.22.0-4
ii  librhythmbox-core10 3.4.3-2+b1
ii  libx11-62:1.6.8-1
ii  media-player-info   24-2
ii  rhythmbox-data  3.4.3-2

Versions of packages rhythmbox recommends:
ii  avahi-daemon 0.7-4+b1
ii  gstreamer1.0-plugins-ugly1.16.1-1
ii  gstreamer1.0-pulseaudio  1.16.1-1
ii  gvfs-backends1.42.1-1
ii  notification-daemon  3.20.0-4
ii  rhythmbox-plugins3.4.3-2+b1
ii  xfce4-notifyd [notification-daemon]  0.4.4-1+b1
ii  yelp 3.34.0-1

Versions of packages rhythmbox suggests:
pn  gnome-codec-install  
pn  gnome-control-center 
ii  gstreamer1.0-plugins-bad 1.16.1-1+b1
pn  rhythmbox-plugin-cdrecorder  

-- no debconf information

Bug#943737: RM: furiusisomount -- RoQA; dead upstream, depends on obsolete libs

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove furiusisomount. It's dead upstream, depends on pygtk/Python 2
and is unmaintained (last upload over six years ago).

Cheers,
Moritz

Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

[Rene Engelhard]

Hi,

On Mon, Oct 28, 2019 at 10:39:37PM +0100, Matthias Klose wrote:
> > but let's try to work together to fix the current situation.

That's what I tried, but... Disabling make check (as will be done)
is not "fix"ing but just hiding it.

> my moreinfo tag was removed, and I'm not interested in a bts war, which rene
> likes to start very often. and, no, I won't start citing rene's private
> messages here.

You imply they were bad. I can cite them myself if you want. There wasn't bad
messages, it was basically the same which was in the bug but in german.

You like to make other people bad where this is not the case. In this
case this is not a LO bug since the exact same LO version worked until
said gcc upload.

Regards,

Rene

Bug#943716: systemd: generates a directory name with the /etc/machine-id value, which is confidential

[Michael Biebl]

Control: tags -1 + moreinfo

Am 28.10.19 um 15:23 schrieb Vincent Lefevre:
> Package: systemd
> Version: 242-7
> Severity: important
> Tags: security
> 
> systemd generates a directory name under /var/log/journal with
> the /etc/machine-id value, which is confidential according to
> the machine-id(5) man page:
> 
>   This ID uniquely identifies the host. It should be considered
>   "confidential", and must not be exposed in untrusted environments, in
>   particular on the network. If a stable unique identifier that is tied
>   to the machine is needed for some application, the machine ID or any
>   part of it must not be used directly. Instead the machine ID should be
>   hashed with a cryptographic, keyed hash function, using a fixed,
>   application-specific key. That way the ID will be properly unique, and
>   derived in a constant way from the machine ID but there will be no way
>   to retrieve the original machine ID from the application-specific one.
>   The sd_id128_get_machine_app_specific(3) API provides an implementation
>   of such an algorithm.
> 
> This directory name is not directly exposed on the network, but most
> users do not know where it comes from and that it is confidential,
> so that it may end up on the net, e.g. in debugging exchanges and
> when asking for help. An example:
> 
>   https://forum.ubuntu-fr.org/viewtopic.php?pid=21992288#p21992288
> 
> As a consequence, the machine-id is also present in journalctl output,
> which may also end up on the net.
> 
> BTW, the fact that this ID is available in a file, in particular
> word-readable, instead of an API to generate a hash, is a bad idea.

I don't see a problem with /etc/machine-id being word-readable, I don't
see a problem either with the journal directory containing the
machine-id. If someone posts the id to a forum, I don't consider this
problematic either.

The man pages recommends to not broadcast the machine-id via the network
for the simple reason, as this would easily allow the machine to be
tracked. This does not apply here.

Please elaborate what the actual problem is you are seeing.
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#943736: RFS: gyrus/0.3.12-1 [QA] -- GNOME tool for Cyrus-IMAP servers administration

[Yavor Doganov]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I'm looking for a sponsor for a QA upload of the package "gyrus".

 * Package name: gyrus
   Version : 0.3.12-1
   Upstream Author : Alejandro Valdés Jiménez 
 Jorge Bustos Bustos 
 Claudio Saavedra Valdés 
 Francisco Rojas 
 * URL : https://wiki.gnome.org/Attic/Gyrus
 * License : GPL-2+
 * Vcs : None
   Section : mail

It builds this binary package:

  gyrus - GNOME tool for Cyrus-IMAP servers administration

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/g/gyrus/gyrus_0.3.12-1.dsc

Changes since the last upload:

   * QA upload.
   * New upstream release.
   * debian/patches/643404.diff: Remove; fixed upstream.
   * debian/patches/713631.diff: Likewise.
   * debian/patches/deprecated-macros.patch: New; remove a deprecated
 gnome-common macro (Closes: #830014).
   * debian/patches/gsettings-port.patch: New; port to GSettings as GConf
 is about to be removed (Closes: #886065).
   * debian/patches/gtk3-port.patch: New; port to GTK 3.
   * debian/patches/glib-deprecations.patch: New; replace some deprecated
 GLib functions/macros.
   * debian/patches/compiler-warnings.patch: New; fix some warnings.
   * debian/patches/desktop.patch: New; remove deprecated Encoding entry in
 the .desktop file; add Keywords entry.
   * debian/patches/series: Update.
   * debian/compat: Bump to 12.
   * debian/control: Run wrap-and-sort -ast.
 (Build-Depends): Remove cdbs, libgconf2-dev, libglade2-dev (unused)
 and libxml-parser-perl (pulled in by intltool).  Bump debhelper
 version requirement.  Add autoconf-archive.  Replace libgtk2.0-dev
 with libamtk-5-dev.  Remove intltool version constraint.
 (Homepage): Set to the project page at wiki.gnome.org.
 (Rules-Requires-Root): Set to no.
 (Standards-Version): Compliant with 4.4.1 as of this release.
   * debian/rules: Rewrite for dh, enable hardening.
   * debian/dirs: Delete; useless.
   * debian/watch: Bump version, use https and .xz extension.
   * debian/gyrus.1: New file.
   * debian/manpages: Install it.
   * debian/copyright: Rewrite as machine-readable.
   * debian/NEWS: Warn users that all stored sessions are lost.
   * debian/changelog: Strip trailing whitespace.

Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

[Rene Engelhard]

Hi,

On Mon, Oct 28, 2019 at 10:39:37PM +0100, Matthias Klose wrote:
> On 28.10.19 22:17, Paul Gevers wrote:
> > Dear all,
> > 
> > The visible progress on this bug report stopped several days ago. I'd
> > like to try an get it a bit further. I'm expecting frustration on all
> > sides,
> 
> yes, and side note that I will use the same terms of "several days ago" for
> a three day silence including two non-work days.
> 
> > but let's try to work together to fix the current situation.
> 
> my moreinfo tag was removed, and I'm not interested in a bts war, which rene

Because you got the needed info. "Run debian/tests/smoketest". I don't
have more info, and simply don't have time or knowledge on C++
exceptions to handle this either way.

> likes to start very often. and, no, I won't start citing rene's private

*You* reassigned the bug back with "with what rationale" and failed
to read the bug log that I mentioned the gcc upload and the exception
failure and still insisted on Dmitrys dates in the subject which I said
to be non-true in the first message of the bug.

You started the BTS war, not me. If you read the bug you could have just
kept it at gcc without any BTS war.

> > Matthias, did you have time to look into the issue? Have you discovered
> > anything that is worth knowing already? If not, do you intent to work on
> > this soon. I noticed you uploaded a new version that doesn't address
> > this RC bug, for the reason I mentioned above, could you please refrain
> > from uploading new versions unless critical issues that aren't present
> > in testing are fixed in those uploads until a version of gcc-9 migrates?
> 
> I asked for a test case, not a multi-hour build and a multi-hour test run.

And I said it exceeds my knowledge.

debian/tests/smoketest is not a "multi hour test run". It builds part of LO,
yes, but it definitely is not multi hour. It is actually ONE test.

See the script.

The autopktest actually times itself out when it takes too long (which doesn't 
happen
even on older hardware.)

> Sure I can start looking at this myself, but I don't have the LO domain
> knowledge anymore.  Yes, I could start bisecting, however that doesn't sound

Neither do I. I just maintain and build this. Let alone time-wise...
Regards.

Rene

Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

[Rene Engelhard]

Hi,

On Mon, Oct 28, 2019 at 10:17:49PM +0100, Paul Gevers wrote:
> Rene, I really appreciate the fact that libreoffice has an extensive
> test suite. But just to get options on the table can you please tell us
> how severe this particular failure is? In other words, how much is this
> telling you about libreoffice? I think the failure is "just" that you

No idea. The test doesn't run. No more info. And the failure is beyond
my skills anyway.

> can't compile a test that used to be able to compile. And you suspect
> that the libreoffice test may not be the only code that breaks.

No, I didn't say that.

Actually, I disabled running make check already for the next upload.
"at scheduled" for Thursday.

Regards,

Rene

Bug#936883: libkate: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Tue, Sep 03, 2019 at 06:50:02AM -0400, Scott Kitterman wrote:
> On Fri, 30 Aug 2019 07:23:42 + Matthias Klose  wrote:
> > Package: src:libkate
> > Version: 0.4.1-9
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2removal
> > 
> > Python2 becomes end-of-live upstream, and Debian aims to remove
> > Python2 from the distribution, as discussed in
> > https://lists.debian.org/debian-python/2019/07/msg00080.html
> > 
> > Your package either build-depends, depends on Python2, or uses Python2
> > in the autopkg tests.  Please stop using Python2, and fix this issue
> > by one of the following actions.
> ...
> 
> This looks pretty dead upstream.  Any reason not to go ahead an remove this?

Python (and pythoncard) are only needed by the libkate-tools binary package,
the rest can be kept.

Cheers,
Moritz

Bug#874880: [freemedforms-project] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Tue, Oct 08, 2019 at 04:17:13PM +0200, Andreas Tille wrote:
> Hi again,
> 
> I'm sorry to repeat myself but please pretty please help finding some
> solution.  Freemedform-project is about to be removed from Debian and
> I see no way to prevent this.

Andreas,
can you file a removal bug? If it gets ported to Qt5, it can still
be re-introduced before the Bullseye release.

Cheers,
Moritz

Bug#936528:

[Emmanuel Arias]

Hi Ondrej,

I send the ITA some time ago [1] (sorry for my delay), I've just create
the repo on salsa [2].

I will apply your patch.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836500
[2] https://salsa.debian.org/python-team/modules/python-flask-principal

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

Bug#942793: RM: trafficserver/7.0.0-6+deb9u2

[Moritz Mühlenhoff]

On Mon, Oct 21, 2019 at 04:36:23PM +0200, Jean Baptiste Favre wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: rm
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear release managers,
> Please remove trafficserver from Stretch next point release.
> This version hass been EOL upstream for 2 years now, and security patches 
> backport
> became to much invasive to be efficient.
> I prefer this version to be removed from old-stable releases.

JFTR, we already added a note to DSA-4520-1 which advises to upgrade to Buster
if HTTP/2 is used, so +1 from me.

Cheers,
Moritz

Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

[Matthias Klose]

On 28.10.19 22:17, Paul Gevers wrote:

Dear all,

The visible progress on this bug report stopped several days ago. I'd
like to try an get it a bit further. I'm expecting frustration on all
sides,


yes, and side note that I will use the same terms of "several days ago" for a 
three day silence including two non-work days.



but let's try to work together to fix the current situation.


my moreinfo tag was removed, and I'm not interested in a bts war, which rene 
likes to start very often. and, no, I won't start citing rene's private messages 
here.



Matthias, did you have time to look into the issue? Have you discovered
anything that is worth knowing already? If not, do you intent to work on
this soon. I noticed you uploaded a new version that doesn't address
this RC bug, for the reason I mentioned above, could you please refrain
from uploading new versions unless critical issues that aren't present
in testing are fixed in those uploads until a version of gcc-9 migrates?


I asked for a test case, not a multi-hour build and a multi-hour test run. Sure 
I can start looking at this myself, but I don't have the LO domain knowledge 
anymore.  Yes, I could start bisecting, however that doesn't sound very effective.


My main effort however now is to restore native and cross builds, an issue I 
didn't cause myself and I'd like to see fixed.


Matthias

Bug#943679: Apt fails to update ANY package if ONE source gives a malformed package list

[Chris]

On Mon, Oct 28, 2019 at 2:21 PM David Kalnischkies 
wrote:

> Both aren't a particular good idea as we always want to be faster & not
> waste memory so constraint [virtual or real] machines continue to work.
> So that seems "very difficult to fix due to major design considerations"
> (if you read on you might notice why I use that quote).
>

Is there an alternative to apt that can use the same package repos, but
process them in a fault-tolerant manner (e.g. load the merged-so-far list,
try to merge the next source, save if successful, repeat)? If so, I'll want
to switch to that, even if it means only having support for 10-year-old
instead of 20-year-old hardware. I thought fault-tolerance and graceful
degradation were important enough to the design of Debian that that would
be a hard requirement.

Bug#943735: ITS: resolvconf -- name server information handler

[Andrej Shadura]

Package: src:resolvconf
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

X-Debbugs-CC: Thomas Hood , Marco Nenciarini 
, resolvconf maintainers 
, m...@qa.debian.org

Dear Maintainers,

The resolvconf package hasn’t seen much development or bugfixing in
Debian, and as someone who uses it a lot, I’d like to take care of it.
I intend to start with the Git repo Thomas keeps at his GitLab [1] and
review and cherry-pick fixes from Ubuntu and the bug tracker. I have
currently mirrored the above mentioned Git repo at Salsa [2] where I
plan to keep it in future.

Should you have any objections or anything else to share, I’d be happy
to hear from you.

References:
 [1]: https://gitlab.com/jdthood/resolvconf
 [2]: https://salsa.debian.org/debian/resolvconf

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl23Xh0UHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdL1EAf/Z/ulX7yw7uHVOkL7rytjrZr+Azwz
nLCY9plqSh2ca5AEtJ3fmP72UxzTI9lLBClYpnHNFp3mOUdhB1RUF9bCBLn8zSxV
9aAeSEU2tZWF5e0A0ZtYsb1QjRlYmRWEgIux1hedwxpsl2tTnWl5RqqvzNYezgL6
obad4jUM/mTeaDzlxv4EIJFIEK5sYH9JDtCv0C6eXX5JEtV3TcCbJ6FP7fRPRhr6
0bzuc6KXWKra2c+ve9ro7rg55YoQUiUdUE9i3wplJ12i3way+pvZXz0BwnT7YzBa
0DNR4hbNoFRaxMKJXtrOD157q156X8gPF5JlhEmkl71KTxqk5/rFkSjYew==
=51Cl
-END PGP SIGNATURE-

Bug#943679: Apt fails to update ANY package if ONE source gives a malformed package list

[David Kalnischkies]

Control: severity -1 wishlist

Hi,

On Sun, Oct 27, 2019 at 02:51:02PM -0700, Chris wrote:
> update or check the version of doesn't depend on adoptopenjdk. Shouldn't
> apt still be able to process the package lists from unaffected sources, and
> install and upgrade packages that don't come from or depend on the affected
> sources?

Perhaps, but that is hard to do without making it worse for others: You
can e.g. parse everything first temporarily and only after that parse it
again for real – practically doubles execution time – or you keep
a snapshot of the previously parsed data so you can roll back in a pinch
– practically doubles memory consumption.

Both aren't a particular good idea as we always want to be faster & not
waste memory so constraint [virtual or real] machines continue to work.
So that seems "very difficult to fix due to major design considerations"
(if you read on you might notice why I use that quote).

What we could do is automating what is currently basically required from
the user to do manually: Remove this crappy source. Would be nice, but
as a new feature the appropriate severity is wishlist – and I wouldn't
hold my breath for it as having such bad sources and wanting to keep
them isn't a very common usecase… honestly, if the source doesn't manage
to produce valid files I would have serious doubts about how good the
rest of what they do is given I basically grant them root access to my
machine by using it.


So, that both being my reasoning for downgrading to wishlist. For your
next bugreport it might be a good idea to not start out with a high
severity as that will raise flags for many people to look at it, which
end up being annoyed because the severity was overinflated.

See https://debian.org/Bugs/Developer#severities for details on what the
severities mean – which will a) explain the quoting from above and b)
why "serious" is nearly always wrong.

Thanks none the less for taking the time to report a bug and
Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency

[Olly Betts]

On Mon, Oct 28, 2019 at 05:15:15PM -0400, Scott Talbert wrote:
> The fpga test failure is also occurring with autopkgtest:
> https://ci.debian.net/data/packages/unstable/amd64/m/meson/latest-autopkgtest/log.gz
> 
> Jussi also mentioned it.  Perhaps it's related to the recent upload of
> fpga-icestorm?

I see meson also FTBFS in reproducible build testing:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/meson.html

Given meson already FTBFS in unstable for unrelated reasons and will be
trivial to update to use wxwidgets3.0's GTK3 flavour once that is
addressed, I've made a wxwidgets3.0 upload to drop the GTK2 flavour
packages.

Cheers,
Olly

Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency

[Scott Talbert]

On Mon, 28 Oct 2019, Olly Betts wrote:


However, then the build fails for me running tests using ccache - the
problem is that $HOME is /sbuild-nonexistent under sbuild, which
doesn't exist, and cache tries to create its cache under $HOME/.ccache
by default.


I don't have that, but I also have failing tests.


I think this is #935817 - if so it's not tests using ccache that are the
problem, but that meson automatically tries to use ccache if it's
installed, plus mk-sbuild seems to install ccache in chroots.

(That seems a mis-feature to me - the usual ways to use ccache are to
either something like `CC="ccache gcc"`, or to add /usr/lib/ccache to
your PATH ahead of /usr/bin, which both require a concious extra action,
but I think that's a good thing - it's surprising for building some
software to create a persistent hidden directory under your home
directory potentially using a lot of diskspace just because the package
happens to use meson for its build system and you're on a multi-user
system which happens to have ccache installed).

It seems brittle for a build to fail because an extra package is
installed, especially one like ccache which might reasonably have
been added to a chroot to speed up builds.


[2/3] /usr/bin/arachne-pnr -q -d 1k -p '../test cases/fpga/1
simple/spin.pcf' spin.blif -o spin.asc
FAILED: spin.asc
/usr/bin/arachne-pnr -q -d 1k -p '../test cases/fpga/1 simple/spin.pcf'
spin.blif -o spin.asc
spin.blif:50: fatal error: invalid formal-actual
ninja: build stopped: subcommand failed.


For me, fpga also fails, but the failure looks different:


I also see that eatmydata seems to cause problems (#917501), which again
is something that might reasonably be in use.  I've been running my
package builds under it for the best part of a decade (including many
NMUs) and this is the first issue I've hit.

I tried temporarily disabling that, but meson still fails to build.


The fpga test failure is also occurring with autopkgtest:
https://ci.debian.net/data/packages/unstable/amd64/m/meson/latest-autopkgtest/log.gz

Jussi also mentioned it.  Perhaps it's related to the recent upload of 
fpga-icestorm?


Scott

Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

[Paul Gevers]

Dear all,

The visible progress on this bug report stopped several days ago. I'd
like to try an get it a bit further. I'm expecting frustration on all
sides, but let's try to work together to fix the current situation. In
case you aren't aware, the fact that gcc-9 hasn't migrated to testing in
the last couple of weeks is starting to impact quite some uploads and
transitions (search for "gcc-9 (not considered)" in
https://release.debian.org/britney/update_excuses.html)

Rene, I really appreciate the fact that libreoffice has an extensive
test suite. But just to get options on the table can you please tell us
how severe this particular failure is? In other words, how much is this
telling you about libreoffice? I think the failure is "just" that you
can't compile a test that used to be able to compile. And you suspect
that the libreoffice test may not be the only code that breaks.

Matthias, did you have time to look into the issue? Have you discovered
anything that is worth knowing already? If not, do you intent to work on
this soon. I noticed you uploaded a new version that doesn't address
this RC bug, for the reason I mentioned above, could you please refrain
from uploading new versions unless critical issues that aren't present
in testing are fixed in those uploads until a version of gcc-9 migrates?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#934386: wxScrolled flickers when the horizontal scrollbar is active and GTK3 is used

[Olly Betts]

Control: tags -1 +unreproducible

On Sat, Aug 10, 2019 at 04:51:10PM +0200, Gunter Königsmann wrote:
> Upstream bug report: https://trac.wxwidgets.org/ticket/18462. The
> problem is reproducible by the maintainer of wxWidgets.

The upstream ticket has been in state "infoneeded_new" for more than 3
weeks requesting you explain how to reproduce this in the "scroll"
sample - so far without response.  Tagging this "unreproducible" which
roughly matches the upstream status, and because neither Scott nor
myself seem to be able to reproduce this based on the information you've
so far provided.

Cheers,
Olly

Bug#943437: src:meson: Please update/remove libwxgtk3.0-dev build-dependency

[Olly Betts]

On Mon, Oct 28, 2019 at 07:53:24AM +0100, Martin Pitt wrote:
> Olly Betts [2019-10-27 11:52 +1300]:
> > However, then the build fails for me running tests using ccache - the
> > problem is that $HOME is /sbuild-nonexistent under sbuild, which
> > doesn't exist, and cache tries to create its cache under $HOME/.ccache
> > by default.
> 
> I don't have that, but I also have failing tests.

I think this is #935817 - if so it's not tests using ccache that are the
problem, but that meson automatically tries to use ccache if it's
installed, plus mk-sbuild seems to install ccache in chroots.

(That seems a mis-feature to me - the usual ways to use ccache are to
either something like `CC="ccache gcc"`, or to add /usr/lib/ccache to
your PATH ahead of /usr/bin, which both require a concious extra action,
but I think that's a good thing - it's surprising for building some
software to create a persistent hidden directory under your home
directory potentially using a lot of diskspace just because the package
happens to use meson for its build system and you're on a multi-user
system which happens to have ccache installed).

It seems brittle for a build to fail because an extra package is
installed, especially one like ccache which might reasonably have
been added to a chroot to speed up builds.

> > [2/3] /usr/bin/arachne-pnr -q -d 1k -p '../test cases/fpga/1
> > simple/spin.pcf' spin.blif -o spin.asc
> > FAILED: spin.asc 
> > /usr/bin/arachne-pnr -q -d 1k -p '../test cases/fpga/1 simple/spin.pcf'
> > spin.blif -o spin.asc
> > spin.blif:50: fatal error: invalid formal-actual
> > ninja: build stopped: subcommand failed.
> 
> For me, fpga also fails, but the failure looks different:

I also see that eatmydata seems to cause problems (#917501), which again
is something that might reasonably be in use.  I've been running my
package builds under it for the best part of a decade (including many
NMUs) and this is the first issue I've hit.

I tried temporarily disabling that, but meson still fails to build.

Cheers,
Olly

Bug#895661: bugs.debian.org: Add X-Debbugs-CC automatically on initial reports with Tags: security

[Salvatore Bonaccorso]

Hi,

On Sat, Apr 14, 2018 at 09:51:00AM +0200, Salvatore Bonaccorso wrote:
> Package: bugs.debian.org
> Severity: wishlist
> 
> Hi
> 
> [Please Cc team@security.d.o for futher discussion/followup questions]
> 
> If one uses reportbug to fill bugs, which are tagged with security
> tag, reportbug adds a X-Debbugs-CC to the security team as
> team@security.d.o.
> 
> If one submits though a bug via regular mail, adding Tags: security,
> the security team does not get notified via mail on this this report
> directly.
> 
> We would like to see that the security team alias gets any bug filled
> with Tags: security initially. It's not needed to get any conversation
> of security tagged bugs if the alias is not explicitly cc'ed.
> 
> As an example, https://bugs.debian.org/895658 was filled via
> submit@bugs.d.o filling out the pseudo headers, including security
> tag, but the security team did not got a X-Debbugs-CC.
> 
> Thanks for considering implementing the change,

Any chance this could be implemented? I guess "patch welcome" (but to
be honest, this is currently out of reachability for me).

Regards,
Salvatore

Bug#943734: vinagre: Vinagre RDP-session still overlays desktop on Alt+F4

[Henning]

Package: vinagre
Version: 3.22.0-6
Severity: important

Dear Maintainer,

   * What led up to the situation?
Starting a RDP-session to a Windows 10 Professional desktop, doing whatever you
want, then press Alt+F4.

   * What was the outcome of this action?
vinagre-process finishes (at least it is not listed anymore with ps -A in
another terminal). However, the screen content of the rdp session stays in
front of everything on the gnome3-desktop, thus it is not possible to see other
windows or anything. However, it is still possible to activate the menu in the
upper right bar and logoff / reboot. Other shortcuts like Windows-key for the
Activity-Button do not work.

   * What outcome did you expect instead?
Alt+F4 is send to the virtual machine or the screen content of the rdp session
disappears when the process finishes.

The bug is reproducible on all my machines running debian stable. Thus, if you
need additional information please contact me.

Kind regards,
Henning



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

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 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 vinagre depends on:
ii  dconf-gsettings-backend [gsettings-ba  0.30.1-2
ii  libavahi-common3   0.7-4+b1
ii  libavahi-gobject0  0.7-4+b1
ii  libavahi-ui-gtk3-0 0.7-4+b1
ii  libc6  2.28-10
ii  libcairo2  1.16.0-4
ii  libfreerdp2-2  2.0.0~git20190204.1.2693389a+dfsg1-1
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libglib2.0-0   2.58.3-2+deb10u1
ii  libgtk-3-0 3.24.5-1
ii  libgtk-vnc-2.0-0   0.9.0-1.1
ii  libsecret-1-0  0.18.7-1
ii  libspice-client-glib-2.0-8 0.35-2
ii  libspice-client-gtk-3.0-5  0.35-2
ii  libvte-2.91-0  0.54.2-2
ii  libxml22.9.4+dfsg1-7+b3

vinagre recommends no packages.

vinagre suggests no packages.

-- no debconf information

Bug#943473:

[Michael Hudson-Doyle]

The issue is that the autodep8 tests are run for all supported versions of
Python, but odil does not build its extensions for all supported versions
of Python. And one of the reasons it does not (not build-depending on
python3-all-dev) causes odil to not be on the list of packages that needs
to be rebuilt when a supported version of Python3 is added or removed. The
attached patch fixes that, and (in a fairly unpleasant way) fixes a failure
to run the tests for the non-default Python with the correct Python
interpreter.
diff -Nru odil-0.10.0/debian/changelog odil-0.10.0/debian/changelog
--- odil-0.10.0/debian/changelog	2019-01-15 06:42:21.0 +1300
+++ odil-0.10.0/debian/changelog	2019-10-25 09:29:22.0 +1300
@@ -1,3 +1,11 @@
+odil (0.10.0-3ubuntu1) focal; urgency=medium
+
+  * Build-Depend on python3-all-dev so that Python 3.8 extensions are built.
+  * d/rules: Fix py3versions invocation, actually run tests for non-default
+Python with that Python. 
+
+ -- Michael Hudson-Doyle   Fri, 25 Oct 2019 09:29:22 +1300
+
 odil (0.10.0-3) unstable; urgency=medium
 
   [ Julien Lamy ]
diff -Nru odil-0.10.0/debian/control odil-0.10.0/debian/control
--- odil-0.10.0/debian/control	2019-01-15 06:42:21.0 +1300
+++ odil-0.10.0/debian/control	2019-10-25 09:29:22.0 +1300
@@ -1,5 +1,6 @@
 Source: odil
-Maintainer: Debian Med Packaging Team 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Debian Med Packaging Team 
 Uploaders: Julien Lamy 
 Section: science
 Testsuite: autopkgtest-pkg-python
@@ -27,7 +28,7 @@
chrpath,
dcmtk,
python-dev,
-   python3-dev,
+   python3-all-dev,
python-nose,
python3-nose
 Build-Depends-Indep: doxygen,
diff -Nru odil-0.10.0/debian/helpers/nosetests3 odil-0.10.0/debian/helpers/nosetests3
--- odil-0.10.0/debian/helpers/nosetests3	1970-01-01 12:00:00.0 +1200
+++ odil-0.10.0/debian/helpers/nosetests3	2019-10-25 09:29:22.0 +1300
@@ -0,0 +1,2 @@
+#!/bin/sh
+exec /usr/bin/python${Python} /usr/bin/nosetests3 "$@"
diff -Nru odil-0.10.0/debian/rules odil-0.10.0/debian/rules
--- odil-0.10.0/debian/rules	2019-01-15 06:42:21.0 +1300
+++ odil-0.10.0/debian/rules	2019-10-25 09:29:22.0 +1300
@@ -7,7 +7,7 @@
 
 # Find all Python versions
 PYTHON2=$(shell pyversions -vrd)
-PYTHON3=$(shell py3versions -vrd)
+PYTHON3=$(shell py3versions -vs)
 ALLPY=$(PYTHON2) $(PYTHON3)
 
 %:
@@ -64,13 +64,14 @@
 override_dh_auto_test-arch-py: override_dh_auto_test-arch-nopy
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 	set -e; \
+	export Python; \
 	for Python in $(ALLPY); do \
 	  echo "=== Testing for Python $${Python} ==="; \
 	  ln -s build-py$${Python} build; \
 	  ln -sr ./build/wrappers/python ./build/odil; \
 	  ln -sr ./wrappers/python/*.py ./build/odil; \
 	  cd build && \
-	../tests/run --no-network \
+	PATH=$(CURDIR)/debian/helpers:$$PATH ../tests/run --no-network \
 	  --nose nosetests$$(dpkg --compare-versions $${Python} ge 3 && echo "3") \
 	  -E ".*"; \
 	  cd ..; \

Bug#943732: pandas: test failures on non-Intel

[Rebecca N. Palmer]

Package: python3-pandas
Version: 0.25.2+dfsg-1
Severity: serious
Control: notfound -1 0.23.3+dfsg-8

(Filed as RC to make sure I don't forget about these: actual severity to 
be decided.)


- Several datetime-related failures on arm* and mips64el.

- Several convert-to-records failures on s390x and ppc64.  (These may be 
a non-bug, as some of the tests involve explicit endianness.)


The above are temporarily skipped by v025_test_failures.patch.

- Crash on mipsel.

Not skipping this as I want to know if it's reproducible or random.

Bug#943733: RFP: golang-bombardier -- Fast cross-platform HTTP benchmarking tool written in Go

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: golang-bombardier
  Version : 1.2.4
  Upstream Author : Максим Федосеев
* URL : https://github.com/codesenberg/bombardier
* License : MIT/X
  Programming Lang: Golang
  Description : Fast cross-platform HTTP benchmarking tool written in Go

bombardier is a HTTP(S) benchmarking tool. It is written in Go
programming language and uses excellent fasthttp instead of Go's
default http library, because of its lightning fast performance.

With bombardier v1.1 and higher you can now use net/http client if you
need to test HTTP/2.x services or want to use a more RFC-compliant
HTTP client.



There are many HTTP benchmarking tools in Debian, but many suffer from
significant bitrot. Tools like `siege` or `ab` (part fo apache2-utils)
do not support HTTP/2, for example. Both of those also suffer from
significant performance limitations when compared to bombardier. A
simple benchmark of the three, for example, shows bombardier performs
much better on a minimalist Hetzner virtual machine (CX11):

Siege:

root@cache-02:~# siege
** SIEGE 4.0.4
** Preparing 100 concurrent users for battle.
The server is now under siege...
Lifting the server siege...
Transactions:  28895 hits
Availability: 100.00 %
Elapsed time: 119.73 secs
Data transferred: 285.18 MB
Response time:  0.40 secs
Transaction rate: 241.33 trans/sec
Throughput: 2.38 MB/sec
Concurrency:   96.77
Successful transactions:   28895
Failed transactions:   0
Longest transaction:1.26
Shortest transaction:   0.05

Load went to about 2 (`Load average: 1.65 0.80 0.36` after test), with
one CPU constantly busy and the other at about 50%, memory usage was
low (~800M).

ab:

# ab -c 100 -n 1000 https://blog.torproject.org/
[...]
Server Software:ATS/8.0.2
Server Hostname:blog.torproject.org
Server Port:443
SSL/TLS Protocol:   TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,4096,256
Server Temp Key:X25519 253 bits
TLS Server Name:blog.torproject.org

Document Path:  /
Document Length:53320 bytes

Concurrency Level:  100
Time taken for tests:   4.010 seconds
Complete requests:  1000
Failed requests:0
Total transferred:  54421000 bytes
HTML transferred:   5332 bytes
Requests per second:249.37 [#/sec] (mean)
Time per request:   401.013 [ms] (mean)
Time per request:   4.010 [ms] (mean, across all concurrent requests)
Transfer rate:  13252.82 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:   23  254 150.0303 549
Processing:14  119  89.3122 361
Waiting:5  105  89.7105 356
Total: 37  373 214.9464 738

Percentage of the requests served within a certain time (ms)
  50%464
  66%515
  75%549
  80%566
  90%600
  95%633
  98%659
  99%675
 100%738 (longest request)

Bombardier results are much better and pretty much max out the gigabit
connexion:

$ ./go/bin/bombardier --duration=2m --latencies https://blog.torproject.org/
Bombarding https://blog.torproject.org:443/ for 2m0s using 125 connection(s)
[=] 
2m0s
Done!
StatisticsAvg  StdevMax
  Reqs/sec  2021.18 572.505462.41
  Latency   62.82ms22.98ms  1.62s
  Latency Distribution
 50%60.43ms
 75%69.43ms
 90%80.59ms
 95%91.31ms
 99%   156.62ms
  HTTP codes:
1xx - 0, 2xx - 238797, 3xx - 0, 4xx - 0, 5xx - 0
others - 0
  Throughput:   103.73MB/s

It might be because it supports doing HTTP/2 requests and, indeed, the
`Throughput` drops down to `14MB/s` when we use the `--http1` flag,
along with rates closer to ab:

anarcat@cache-02:~$ ./go/bin/bombardier --duration=2m --latencies 
https://blog.torproject.org/ --http1
Bombarding https://blog.torproject.org:443/ for 2m0s using 125 connection(s)
[=] 
2m0s
Done!
StatisticsAvg  StdevMax
  Reqs/sec  1320.90 200.041820.33
  Latency   96.15ms21.39ms   671.40ms
  Latency Distribution
 50%92.86ms
 75%   104.60ms
 90%   118.41ms
 95%   128.01ms
 99%   160.40ms
  HTTP codes:
1xx - 0, 2xx - 156265, 3xx - 0, 4xx - 0, 5xx - 0
others - 0
  Throughput:14.49MB/s

So I think 

Bug#943356: no login in vm

[jnqnfe]

update: I was playing with display settings a found that the wrong
graphics controller has been set for some time. I was incorrectly using
`VBoxVBA` which exhibits the problem after the Gnome 3.34 update.
Switching to the correct setting of `VMSVGA` resolves the problem.

Since `VBoxVBA` according to the help documentation appears to be for
Windows systems, this can just be closed.

Bug#942235: dask: autopkgtest needs update for new version of pytest

[Rebecca N. Palmer]

Assuming we're talking about

https://salsa.debian.org/python-team/modules/dask/blob/experimental/debian/patches/use-local-intersphinx.patch

I think the actual problem is on the numpy line: it adds the local 
inventory but doesn't remove the online one, so the tuple is too long. 
(I haven't actually tried this.)

Bug#943465: fwupd is wrongly marked Multi-Arch: foreign

[Mario.Limonciello]

> On Mon, Oct 28, 2019 at 02:46:03PM +, mario.limoncie...@dell.com wrote:
> > I guess by this argument it really should be made into a Depends not
> > a Recommends not because fwupd internally needs it to work but to ensure
> > those architecture constraints get met effectively.
> 
> Recommends work no different from depends when it comes to the
> architecture constraint.
> 
> > Part of the reason to make it Recommends is that it only is needed for 4
> architectures.
> > I'm not sure if setting architecture specific dependencies is valid syntax, 
> > but if so
> > this updated changeset should accomplish the goal.
> 
> Yes, this syntax does work. The architecture qualification is resolved
> at build time and the resulting binary packages will have the dependency
> exactly for those architectures that need it.

Thanks for your confirmation.

> 
> >
> https://github.com/fwupd/fwupd/commit/88623a90fae36b61093c84198acfdba6b
> ce3e533

Steve, what do you think of this?  Since it's going to need to be a NEW binary 
package
I suspect you'll need to sponsor it for me if we agree to go this route.

> 
> This looks sane to me. Keep in mind that you also need to upload
> fwupd-*-signed.

That part gets handled by some backend service when the new template packages 
are made.

Bug#943456: m2r: maintain in python group?

[Joseph Herlant]

Hi Jonas,

I noticed that your ITP mentioned that you plan to maintain m2r in the
Debian group.
Any chance you could put it in the Python module group instead?
https://salsa.debian.org/python-team/modules

Thanks,
Joseph

Bug#727005: switch python bindings to python3

[Boruch Baum]

Thanks for clearing that up for me, Torsten. Sorry for creating any confusion.

On 2019-10-27 19:35, Torsten Landschoff wrote:
> Actually, SWIG supports Python 3 for quite some time: Support was
> introduced in SWIG 1.3.37
>
> Source: https://github.com/swig/swig/blob/master/RELEASENOTES#L260
>
> AFAICT, only some Python 3.8 specific changes are missing in SWIG 3.
>
> > Version 4 of swig does seem to support python3, using a new command-line
> > option `-py3`.
>
> This option is only for type annocation support.
>
> See http://swig.org/Doc3.0/SWIGDocumentation.html#Python_nn74
>

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Bug#936792: kicad: Python2 removal in sid/bullseye

[Carsten Schoenert]

Hello Andreas,

Am 28.10.19 um 15:31 schrieb Andreas Henriksson:

It seems the kicad package has already (mostly) been switched over
to python3. The only python2 related things I could spot is the
libpython-stdlib build-dependency. This seems to be something lingering
from a long time ago which maybe just isn't relevant anymore.

I tried to find the original reason it was introduced and in
debian/changelog entry for 4.0.2+dfsg1-3 I found the following
pretty cryptic message:

   * added a build-dependency on libpython-stdlib, which should not harm
 for most architectures, and might be necessary on a few ones.

Maybe this should be switched over to libpython3-stdlib now that
everything else uses python3, but I also wouldn't be surprised if
it should just be dropped because the cryptic description kind of
smells like a bogus excuse to me.

Could kicad maintainers please comment on what you think?


I'm back from the miniDebConf Vaumarcus just right now. :)

For a long time I was now able to work also on various other parts of 
the packaging of KiCad while the mDC. So I can answer your question 
hopefully.


I also don't now why George has added this dependency and it was 
probably really not needed and I will simply just remove it.


The src:kicad package has a dependency on python3-all since January 2019 
which is pulling in python3.7 (currently). This then is depending on 
libpython3.7-dev so this library is installed and pulled anyway.


Removing libpython-dev will as far I see remove the only direct 
dependency on Python2. But there are more indirect dependencies on 
Python2 e.g by dblatex and asciidoc.


--
Regards
Carsten Schoenert

Bug#943731: gimp: New upstream release (2.10.14)

[Michael Schumacher]

Package: gimp
Version: 2.10.8-2+b1
Severity: important

Dear Maintainer,

a new release of the stable branch of GIMP has been made: 2.10.14.

We're currently doing some final polishing to the release announcement - when
finished, it will be available at:
https://www.gimp.org/news/2019/10/28/gimp-2-10-14-released/

The source code is available at
https://download.gimp.org/pub/gimp/v2.10/gimp-2.10.14.tar.bz2

Corresponding git tag is GIMP_2_10_14


Regards,
Michael



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

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

Versions of packages gimp depends on:
ii  gimp-data2.10.8-2
ii  libaa1   1.4p5-46+b1
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.8-2
ii  libc62.29-2
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.10.1-2
ii  libgcc1  1:9.2.1-14
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-1
ii  libgegl-0.4-00.4.16-1
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.8-2+b1
ii  libglib2.0-0 2.62.2-1
ii  libgs9   9.50~dfsg-2
ii  libgtk2.0-0  2.24.32-4
ii  libgudev-1.0-0   233-1
ii  libharfbuzz0b2.6.2-1
ii  libheif1 1.5.1-1+b1
ii  libilmbase24 2.3.0-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-4
ii  liblzma5 5.2.4-1+b1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2.1+b1
ii  libopenexr24 2.3.0-6
ii  libopenjp2-7 2.3.1-1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpangoft2-1.0-01.42.4-7
ii  libpng16-16  1.6.37-1
ii  libpoppler-glib8 0.71.0-6
ii  librsvg2-2   2.44.15-1
ii  libstdc++6   9.2.1-14
ii  libtiff5 4.0.10+git191003-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libwmf0.2-7  0.2.8.4-15
ii  libx11-6 2:1.6.8-1
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages gimp recommends:
ii  ghostscript  9.50~dfsg-2

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
ii  gimp-python   2.10.8-2+b1
ii  gvfs-backends 1.42.1-1
ii  libasound21.1.8-2

-- no debconf information

Bug#943730: RFS: cowsay/3.03+dfsg2-7 [ITA] -- configurable talking cow

[James McDonald]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: cowsay
  Version : 3.03+dfsg2-7
  Upstream Author : Tony Monroe 
* URL : 
https://web.archive.org/web/20120527202447/http://www.nog.net/~tony/warez/cowsay.shtml
* License : COWSAY
* Vcs : https://salsa.debian.org/debian/cowsay
  Section : games

It builds those binary packages:

 cowsay - configurable talking cow
 cowsay-off - configurable talking cow (offensive cows)

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/c/cowsay/cowsay_3.03+dfsg2-7.dsc

Changes since the last upload:
  * New maintainer (closes: #910035)
  * Fix lintian warning about spelling of 'balloons' in patch
  * Add fox cow (closes: #888229)
  * Bump Standards-Version to 4.4.1
  * Bump debhelper compat to 12

Regards,

--
James McDonald

Bug#943515: [External] Bug#943515: linux-image-5.2.0-3-amd64: Cannot resume from suspend

[Anton Bobov]

Hi Mark,

Thank you to point me in the right direction, I have solved my problem by
changing BIOS security configuration.

I have the security chip settings:
- Security Chip Selection = Intel PTT
- Security Chip = Enabled

I enabled Discrete TPM and now 5.2 kernel suspend and resume properly.

I also found this logs with Intel PTT:

tpm tpm0: Operation Timed out
tpm tpm0: Operation Timed out
tpm_crb: probe of MSFT0101:00 failed with error -62

The system does not have a network connection after suspend (can't ping), but
then I press Fn+ESC it toggle Fn led on and off (in normal condition no led are
on and Fn+ESC resume system).

-- 
Cheers,
Anton

Bug#943504: firefox-esr: Firefox Wayland crashes at startup

[Alain Ducharme]

Confirmed: Firefox 68.2.0esr-1~deb10u1 Wayland mode DBUS bug
Firefox does not start with MOZ_ENABLE_WAYLAND=1 (or old GDK_BACKEND=wayland)
Works with --no-remote, but once open can't open URLs from other applications.

MOZ_ENABLE_WAYLAND=1 firefox-esr --no-remote # temp. partial workaround

Related upstream bug to consider (along with Benoît Laniel's fix):
https://bugzilla.mozilla.org/show_bug.cgi?id=1551664

Thanks

Bug#933964: milkytracker: CVE-2019-14464 CVE-2019-14496 CVE-2019-14497

[James Cowgill]

Hi,

On 28/10/2019 12:29, Utkarsh Gupta wrote:
> Hi James,
> 
> On Tue, Oct 22, 2019 at 10:36 PM James Cowgill  > wrote:
> 
> Hi!
> 
> On 22/10/2019 15:03, Utkarsh Gupta wrote:
> > Hey,
> >
> > I have prepared an NMU for Sid.
> > I'd be happy to upload if you are busy to do so.
> > Given that it is fixed for oldoldstable already, I plan on
> uploading it
> > in a couple of days :)
> >
> > Please let me know if I shouldn't or something.
> 
> Do you have a patch for this NMU (or even better - a git branch against
> the repo in Salsa)?
> 
> 
> Here's the link to the Salsa repo:
> https://salsa.debian.org/utkarsh2102-guest/milkytracker
> Let me know if there's anything else you want me to do?
> 
> I could perhaps upload and create a MR for the same as well :)

Thanks. I've uploaded it (with some minor metadata changes and some more
changelog entries for all the other stuff in git pending upload).

James



signature.asc
Description: OpenPGP digital signature

Bug#943714: Acknowledgement (ruby-gettext: apt-listbugs fails during upgrade process with error emited by ruby-gettext)

[Félix Sipma]

Weird, this time I was able to "apt upgrade" without any error
message... I did not change anything related to locale or apt.

-- 
Félix


signature.asc
Description: PGP signature

Bug#943729: lvcreate -Z y does not imply -W y contrary to manual ?

[Ian Jackson]

Package: lvm2
Version: 2.02.168-2

I have encountered a situation where:

2019-10-28 16:45:09 Z executing ssh ... root@172.16.144.40 lvcreate -Z y -L 
1M -n debianhvm.guest.osstest-disk italia0-vg 
WARNING: dos signature detected on /dev/italia0-vg/debianhvm.guest.osstest-disk 
at offset 510. Wipe it? [y/n]: ^C

But:

2019-10-28 16:47:33 Z executing ssh ... root@172.16.144.40 lvcreate -W y -L 
1M -n debianhvm.guest.osstest-disk italia0-vg 
  Logical volume "debianhvm.guest.osstest-disk" created.

The documentation says

  If this option is not specified, then by default -W |
  --wipesignatures y is assumed each time the zeroing is done (-Z |
  --zero y).  This default behaviour can be controlled by
  allocation/wipe_signatures_when_zeroing_new_lvs setting found in
  lvm.conf(5).

grep wip /etc/lvm/lvm.conf yields some comments and also
use_blkid_wiping = 1
wipe_signatures_when_zeroing_new_lvs = 1
(from the default config supplied with the package).

I don't know if it's the documentation or the implementation that is
wrong.  The workaround appears to be to specify -W y explicitly.

Thanks,
Ian.

Bug#943668: Getting "Can't update Chromium" notifications

[Sean McGuire]

Also getting these notifications.

Chromium 76.0.3809.100 built on Debian 10.0, running on Debian 10.1

These are very bad since we're using chromium for digital displays 
showing fullscreen slideshows on TV screens throughout the system, 
running on unattended machines with no mouse or keyboard access.


This notification makes chromium unusable in this situation.

Bug#943465: fwupd is wrongly marked Multi-Arch: foreign

[Mario.Limonciello]

> -Original Message-
> From: Helmut Grohne 
> Sent: Saturday, October 26, 2019 1:16 AM
> To: Steve McIntyre
> Cc: 943...@bugs.debian.org; debian-cr...@lists.debian.org
> Subject: Bug#943465: fwupd is wrongly marked Multi-Arch: foreign
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi Steve,
> 
> On Fri, Oct 25, 2019 at 10:55:30PM +0100, Steve McIntyre wrote:
> > >So I see two possible routes here:
> > > 1. Remove M-A:foreign. (Nobody likes that)
> > > 2. a. Move the efi packages to a separate non-M-A:foreign package.
> > >b. Have fwupd depend on that new package.
> > >c. Rename the fwupd dependency of fwupd-armhf-signed to that new
> > >   package.
> >
> > Ummm, I don't think I follow your logic here at all. The normal system
> > pieces of the fwupd package (i.e. the bits that are executed by the
> > running Linux system need to match the arch you're running (to be
> > useful). But to be able to work on a normal system, the underlying EFI
> > binaries *must* match the hardware that's running (otherwise the EFI
> > firmware won't be able to use them at all). *However*, in some
> > circumstances (like building a live image) we want to allow
> > installation of all versions of the fwupd EFI binaries.
> 
> I think I follow your requirements.
> 
> > I think this particular situation is not well-described at all by M-A!
> 
> Unfortunately, I very much concur with this. I (and others) tried hard
> to describe M-A, but we always run into a roadblock: M-A must talk about
> "interfaces" of a package and "interfaces" are not well-described at all
> by Debian. In other words: In order to describe M-A, we must describe
> what "interface of a package" means. Essentially it means "not
> everything a package ships is part of its interface, but sometimes it is
> an implementation detail".
> 
> So here we were first thinking "the *.efi files are not part of the
> interface, so M-A:foreign is fine". Then I noticed that they're used by
> the sign package and thus I concluded that "oh they art part of the
> interface and M-A:foreign is thus wrong". Now we have a choice between
> removing M-A:foreign and changing interfaces (i.e. moving files to
> different packages).
> 
> > Maybe we could do something like:
> >
> >  * fwupd (non-M-A) - bits in /usr/{s,}bin, must have the right arch
> >installed
> >  * (we could possibly split out some of the common data into a
> >M-A:foreign fwupd-data package)
> >  * fwupd-efi (M-A:same) for each architecture
> 
> I don't see why removing M-A:foreign (or splitting a fwupd-data package)
> from fwupd would be required. All I said was that the *.efi files must
> not reside in a M-A:foreign package.
> 
> > but I don't see how to ensure that the *right* fwupd-efi package is
> > installed for a system that wants to run it...
> 
> Let me try to explain this in terms of interfaces. Suppose we keep the
> fwupd-efi (or fwupd-unsigned as it was previously called) package, have
> it contain the *.efi binaries and be M-A:same. Now we keep fwupd
> M-A:foreign. What does this do to multiarch?
> 
> The package building that uses the *.efi files must not build depend on
> fwupd for that matter, because we say that the *.efi files are not part
> of the interface "fwupd". They're still used internally by fwupd.
> Instead you build depend on fwupd-efi (or fwupd-unsigned as it was
> called in the patch). All is well here.
> 
> Now fwupd can depend on fwupd-efi. Given that dependencies always ensure
> same-arch constraints (unless M-A:foreign on the dependee, :any or
> :native is involved), fwupd will always get the fwupd-efi instance of
> the same architecture as itself. The M-A:foreign will practically ensure
> that the native fwupd is installed. The latest patch doesn't have that
> dependency, but turned it into a recommendation instead. Like
> dependencies, these are also preserving the architecture constraint by
> default.
> 

I guess by this argument it really should be made into a Depends not
a Recommends not because fwupd internally needs it to work but to ensure
those architecture constraints get met effectively.

Part of the reason to make it Recommends is that it only is needed for 4 
architectures.
I'm not sure if setting architecture specific dependencies is valid syntax, but 
if so
this updated changeset should accomplish the goal.

https://github.com/fwupd/fwupd/commit/88623a90fae36b61093c84198acfdba6bce3e533

> Does this help you, Steve? I don't feel like I've explained it
> particularly well. I've Cced d-cross@l.d.o now. Please keep them in the
> loop so maybe Guillem or Josch can do a better job at explaining this.
> Please bear with us and don't give up.
> 
> Helmut

Bug#939571: Fails to import

[Jameson Graef Rollins]

On Tue, 15 Oct 2019 13:02:44 +0200 Carlos Pascual  wrote:
> Just adding that I checked and 0.10.0-1 is not affected.
> 
> Note this bug is affecting the to build the taurus-pyqtgraph package:
> 
> https://salsa.debian.org/science-team/taurus-pyqtgraph/-/jobs/362247

It's very peculiar that the upstream version supposedly didn't change
but yet this failure is definitely due to an upstream import problem.
Is the packaging applying some new patch that breaks things?

Is there any progress on fixing this issue?

jamie.

Bug#943728: policycoreutils-dev: do not depend on binutils

[Christian Göttsche]

Package: policycoreutils-dev
Version: 2.9-2

Please do not depend on binutils.
I do not think this is a hard dependency.

Bug#811180: etckeeper: diff for NMU version 1.18.10-1.1

[Antoine Beaupré]

On 2019-10-28 14:09:06, Mattia Rizzolo wrote:
> Control: tags 811180 + patch
> Control: tags 811180 + pending
> Control: tags 921447 + patch
> Control: tags 928177 + patch
> Control: tags 928177 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for etckeeper (versioned as 1.18.10-1.1) and
> uploaded it to DELAYED/7. Please feel free to tell me if I
> should delay it longer.

Thanks!

This looks fine, go ahead and directly upload if you wish.

I really need to open a repo on salsa for this... :/

a.

-- 
We will create a civilization of the Mind in Cyberspace. May it be more
humane and fair than the world your governments have made before.
- John Perry Barlow, 1996
A Declaration of Independence of Cyberspace

Bug#943465: fwupd is wrongly marked Multi-Arch: foreign

[Helmut Grohne]

On Mon, Oct 28, 2019 at 02:46:03PM +, mario.limoncie...@dell.com wrote:
> I guess by this argument it really should be made into a Depends not
> a Recommends not because fwupd internally needs it to work but to ensure
> those architecture constraints get met effectively.

Recommends work no different from depends when it comes to the
architecture constraint.

> Part of the reason to make it Recommends is that it only is needed for 4 
> architectures.
> I'm not sure if setting architecture specific dependencies is valid syntax, 
> but if so
> this updated changeset should accomplish the goal.

Yes, this syntax does work. The architecture qualification is resolved
at build time and the resulting binary packages will have the dependency
exactly for those architectures that need it.

> https://github.com/fwupd/fwupd/commit/88623a90fae36b61093c84198acfdba6bce3e533

This looks sane to me. Keep in mind that you also need to upload
fwupd-*-signed.

Helmut

Bug#367515: Bug#749991: debian-installer: Wrong kernel in debian-installer package

[Ben Hutchings]

On Mon, 2019-10-28 at 15:56 +0100, Cyril Brulebois wrote:
> Philipp Wollschlegel  (2019-10-28):
> > On 28.10.19 15:11, Ben Hutchings wrote:
> > > On Sun, 2019-10-27 at 20:18 +0100, Holger Wansing wrote:
> > > > Bugreport against kernel version mismatch, when using outdated or 
> > > > broken 
> > > > netboot images:
> > 
> > This isn't a package / message  problem, this is a process problem.
> > 
> > The netboot image is not built at the same time as the rest of the
> > distribution. I.e. the kernel in the main distro changes and the netboot
> > image still uses the old one.
> > 
> > Even when using a direct url to the netboot image, the netboot image
> > will fail, using the same package mirror, the netboot image came from.
> 
> That's not true for stable or oldstable. Also, we ship netboot images in
> packages, use that and be happy?
> 
> If users are tracking testing or unstable, well, yes; those
> distributions are WIP.

I think that's reasonable for unstable, but this really shouldn't
happen in testing (and I didn't realise it did).

Ben.

> But the script you quoted seems to be about buster, so using d-i-n-i
> packages should be a no-brainer.
> 
>   https://tracker.debian.org/pkg/debian-installer-netboot-images
> 
> 
> Cheers,
-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.




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

Bug#943639: grisbi: text unreadable when GTK theme is Adwaita-Dark

[Ludovic Rousseau]

Le 28/10/2019 à 13:31, Roberto C. Sánchez a écrit :

On Sun, Oct 27, 2019 at 06:30:08PM +0100, Ludovic Rousseau wrote:

Le 27/10/2019 à 14:07, Roberto C. Sanchez a écrit :

Package: grisbi
Version: 1.2.2-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

When I changed my GTK theme to Adwaita-Dark much of the UI text became
unreadable.  It appears that some UI elements are specified for
particular colors while others are left with default values.  This
resulted in things like white text on white background, which was
impossible to read.

I may try to fix this myself, but I am not sure when I may find time.


I can reproduce the problem.
Screen copy attached.

I have no idea how to fix it. I reported the issue upstream in 
https://www.grisbi.org/bugsreports/view.php?id=1980

If you know how to fix it please share your knowledge. I may try to fix it 
myself.


I don't know how to fix it, as I've never developed anything for GTK.
That said, it seems like a good learning opportunity, so I may make an
attempt when I can find some time.


Nothing is better than your own motivation to fix a bug :-)

Feel free to ask for help on the Grisbi developer list at 
http://listes.grisbi.org/mailman/listinfo/devel
or access the upstream project on github at https://github.com/grisbi/grisbi

Bye

--
 Dr. Ludovic Rousseau

Bug#943515: [External] Bug#943515: linux-image-5.2.0-3-amd64: Cannot resume from suspend

[Mark Pearson]

> On Sat, Oct 26, 2019 at 7:28 PM Ben Hutchings 
> wrote:
> > I have the same model and can't reproduce this.
> >
> > Does this still happen if you remove the acpi_call module?
> 
> Yes, I removed acpi_call module and can't resume from suspend.
> 
> I also done clean testing installation, with only main packages and standard
> system utilities, no configuration at all.
> Just boot and sudo systemctl suspend, and can't resume.
> 
> --
> Cheers,
> Anton

Hi Anton,

We tried here at Lenovo (using the same 5.2.17 testing stream) and weren't able 
to reproduce either I'm afraid. Let me know if you are able to narrow it down 
to something in particular. 

We recently debugged a suspend-and-resume issue on the P1 Gen2 using hybrid 
graphics mode and in that case it was a link training issue in the i915 driver 
caused by a timeout being too short. It only happened on a system with an OLED 
screen and was 'introduced' 4.19.3 as that was when eDP link re-training was 
enabled (it is a timeout setting in the BIOS that is the problem, not the 
kernel code itself, but the code change triggered the issue). In that 
particular case on resume everything was working fine except the screen was 
blank (so you could ssh in to the system succesfully). We've only seen that 
issue on P1G2 so it's really unlikely it's the same thing your seeing - but 
just in case it's helpful.

Thanks
Mark

Bug#927027: dcfldd: split=1000 fails on i386, armhf

[Eriberto Mota]

Control: forwarded 927027
https://github.com/resurrecting-open-source-projects/dcfldd

Em dom, 14 de abr de 2019 às 14:57, Bernhard Übelacker
 escreveu:
> Dear Maintainer,
> I tried to have a look at this crash and I think it is related to
> the large file support, which is defined in dcfldd.h, line 27 and 28.
>
> Unfortunately this file gets not included first in split.c and
> therefore off_t gets defined without large file support.
> Therefore the size of struct split_t in split.c and output.c
> is different and therefore the fmt is a null pointer.

Hi Steve and Berhard,

Sorry for my long delay. I implemented Berhard's changes in new
upstream repo (created by me)[1]. I will release the 1.5 version soon.
Note that I am not a C programmer. Feel free to join to the project.
dcfldd is a very nice/useful program and it needs to be resurrected.

Regards,

Eriberto

[1] https://github.com/resurrecting-open-source-projects/dcfldd

Bug#943727: chkrootkit: cron.daily exits with status 1 when `chkrootkit $RUN_DAILY_OPTS` produces no output

[Guilhem Moulin]

Package: chkrootkit
Version: 0.52-3
Severity: normal
File: /etc/cron.daily/chkrootkit
Tags: patch

Dear Maintainer,

As of Buster, chkrootkit's cron.daily script contains the following line [0]

eval $CHKROOTKIT $RUN_DAILY_OPTS | egrep -v -f "${IGNORE_FILE}" > 
$LOG_DIR/log.today.raw 2>&1

egrep(1) exits with status 1 when it does not select any line (because
the left hand-side of the pipe produces no output, or because each
output line was matching a pattern from $IGNORE_FILE).

Since the script is run under `set -e`, it causes the entire cronjob to
fail.  Adding a trailing ‘|| true’ fixes this (though one might argue
it's changing the semantics if $IGNORE_FILE is not a readable file.).

Cheers,
-- 
Guilhem.

[0] 
https://salsa.debian.org/pkg-security-team/chkrootkit/blob/debian/0.52-3/debian/cron.daily#L25
--- a/etc/cron.daily/chkrootkit
+++ b/etc/cron.daily/chkrootkit
@@ -22,7 +22,7 @@
 
 if [ "$RUN_DAILY" = "true" ]; then
 if [ "$DIFF_MODE" = "true" ]; then
-eval $CHKROOTKIT $RUN_DAILY_OPTS | egrep -v -f "${IGNORE_FILE}" > $LOG_DIR/log.today.raw 2>&1
+eval $CHKROOTKIT $RUN_DAILY_OPTS | { egrep -v -f "${IGNORE_FILE}" || true; } > $LOG_DIR/log.today.raw 2>&1
 # the sed expression replaces the messages about /sbin/dhclient3 /usr/sbin/dhcpd3
 # with a message that is the same whatever order eth0 and eth1 were scanned
 sed -r -e 's,eth(0|1)(:[0-9])?: PACKET SNIFFER\((/sbin/dhclient|/usr/sbin/dhcpd)\[[0-9]+\]\),eth\[0|1\]: PACKET SNIFFER\([dhclient|dhcpd]{PID}\),' \


signature.asc
Description: PGP signature

Bug#943551: trace-cmd in debian is very old compared to upstream

[Sudip Mukherjee]

Thanks Seth for the reply.

On Mon, Oct 28, 2019 at 2:14 PM Seth Forshee  wrote:
>
> On Sat, Oct 26, 2019 at 10:31:52AM +0100, Sudip Mukherjee wrote:
> > Package: trace-cmd
> > Version: 2.6.1-0.1
> > Severity: important
> >
> > The trace-cmd package in debian seems to be very old. The upstream
> > available version is v2.8.3 and the version used in debian is v2.5.3.
> > There had been major improvements in trace-cmd and kernelshark recently.
> >
> > I can help in updating it if the ubuntu kernel team is busy.
>
> Yes, I had been keeping it up to date for some time, but it's not really
> something I have time for anymore. If you or someone else is interested
> in taking over the package, please feel free.

I am willing to take over the package. But not sure what the process
is for that.
In any case, I will continue to build the package and upload to
mentors in few days.


-- 
Regards
Sudip

Bug#943726: ITP: golang-github-ssgelm-cookiejarparser -- A Go library that parses a curl (netscape) cookiejar file into a Go http.CookieJar

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-ssgelm-cookiejarparser
  Version : 1.0.0-1
  Upstream Author : Stephen Gelman 
* URL : https://github.com/ssgelm/cookiejarparser
* License : Expat
  Programming Lang: Go
  Description : A Go library that parses a curl (netscape) cookiejar file 
into a Go http.CookieJar

 cookiejarparser cookiejarparser is a Go library that parses a curl
 (netscape) cookiejar file into a Go http.CookieJar.

This is a new dependency for git-lfs

Bug#936927: libtorrent-rasterbar: Python2 removal in sid/bullseye

[Andreas Henriksson]

Hello,

On Fri, Aug 30, 2019 at 07:24:29AM +, Matthias Klose wrote:
> Package: src:libtorrent-rasterbar
> Version: 1.1.13-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.
[...]

At first glance it seems like this package is affected simply
because it builds python2 bindings (alongside python3 bindings).

The python-libtorrent and python-libtorrent-dbg packages have no reverse
dependencies and it seems like this could simply be fixed by dropping
those packages, the python2 build-dependencies and the python2 machinery
in debian/rules.

Things are however not so simple. Once python2 is gone, the package no
longer builds:

dh_auto_clean: Please use the third-party "pybuild" build system instead of 
python-distutils
dh_auto_clean: This feature will be removed in compat 12.
Can't exec "pyversions": No such file or directory at
/usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 124.
dh_auto_clean: failed to run pyversions

I assume the next step needed would be to convert from distutils to
setuptools.

Maybe there are other hidden gotchas after that as well.

Hope this helps anyway.

Regards,
Andreas Henriksson

Bug#943725: calibre: Error when connecting Kobo

[Remi Vanicat]

Package: calibre
Version: 4.2.0+dfsg-1
Severity: normal

When connecting my kobo to the version of calibre in exerimental I've
the following error:

ERREUR : Erreur: Erreur pendant la communication avec le périphérique

'<' not supported between instances of 'NoneType' and 'NoneType'

Traceback (most recent call last):
  File "/usr/lib/calibre/calibre/gui2/device.py", line 90, in run
self.result = self.func(*self.args, **self.kwargs)
  File "/usr/lib/calibre/calibre/gui2/device.py", line 513, in _books
mainlist = self.device.books(oncard=None, end_session=False)
  File "/usr/lib/calibre/calibre/devices/kobo/driver.py", line 1974, in books
for idx in sorted(itervalues(bl_cache), reverse=True):
TypeError: '<' not supported between instances of 'NoneType' and 'NoneType'


Thanks.

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

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

Versions of packages calibre depends on:
ii  calibre-bin  4.2.0+dfsg-1
ii  fonts-liberation 1:1.07.4-10
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b2
ii  libjpeg-turbo-progs  1:1.5.2-2+b1
ii  libjs-coffeescript   1.12.8~dfsg-4
ii  libjs-mathjax2.7.4+dfsg-1
ii  optipng  0.7.7-1+b1
ii  poppler-utils0.71.0-6
ii  python3  3.7.5-1
ii  python3-apsw 3.29.0-r1-1
ii  python3-bs4  4.8.0-2
ii  python3-chardet  3.0.4-4
ii  python3-cherrypy38.9.1-5
ii  python3-css-parser   1.0.4-1
ii  python3-cssselect1.1.0-1
ii  python3-cssutils 1.0.2-2
ii  python3-dateutil 2.7.3-3
ii  python3-dbus 1.2.12-1
ii  python3-feedparser   5.2.1-1
ii  python3-html2text2019.8.11-1
ii  python3-html5-parser 0.4.8-1
ii  python3-html5lib 1.0.1-1
ii  python3-lxml 4.4.1-1
ii  python3-markdown 3.1.1-2
ii  python3-mechanize1:0.4.3-2
ii  python3-msgpack  0.5.6-2
ii  python3-netifaces0.10.4-1+b1
ii  python3-pil  6.2.1-1
ii  python3-pkg-resources41.4.0-1
ii  python3-pyparsing2.4.2-1
ii  python3-pyqt55.12.3+dfsg-3
ii  python3-pyqt5.qtsvg  5.12.3+dfsg-3
ii  python3-pyqt5.qtwebengine5.12.1-4+b1
ii  python3-regex0.1.20190207-1+b1
ii  python3-routes   2.4.1-1
ii  xdg-utils1.1.3-1

Versions of packages calibre recommends:
ii  python3-dnspython  1.16.0-1

Versions of packages calibre suggests:
pn  python3-unrardll  

-- no debconf information

-- 
Rémi Vanicat

Bug#943724: lintian: internal error in Lintian::files::empty_package::_set_is_dummy

[Christian Göttsche]

Package: lintian
Version: 2.30.0

While working on the logrotate package, lintian errored out:

$ lintian ../build-area/logrotate_3.15.1-2_amd64.changes
W: logrotate source: orig-tarball-missing-upstream-signature
logrotate_3.15.1.orig.tar.xz
W: logrotate source: spelling-error-in-patch-description
debian/patches/0010-testsuite-remove-explicit-group-and-other-write-perm.patch
genrated generated
Usage: Lintian::files::empty_package::_set_is_dummy(self, newvalue) at
/usr/share/lintian/checks/files/empty-package.pm line 42.
internal error: cannot run files check on package
binary:logrotate-dbgsym/3.15.1-2/amd64
warning: skipping check of binary:logrotate-dbgsym/3.15.1-2/amd64
Usage: Lintian::files::empty_package::_set_is_dummy(self, newvalue) at
/usr/share/lintian/checks/files/empty-package.pm line 42.
internal error: cannot run files check on package
binary:logrotate/3.15.1-2/amd64
warning: skipping check of binary:logrotate/3.15.1-2/amd64

Bug#943393: closed by Matthias Klose (Bug#943393: fixed in gcc-9-cross 14)

[Matthias Klose]

On 28.10.19 14:56, Thorsten Glaser wrote:

On Sun, 27 Oct 2019, Debian Bug Tracking System wrote:


#943393: gcc-9-cross: FTBFS: libatomic.so.1, needed by ./libgnat-9.so, not found

It has been closed by Matthias Klose .



   * Link libgnatvsn against libatomic.


This bug was filed against gcc-9-cross-ports.


Doesn’t seem to help as gcc-9-cross-ports (11) with
gcc-9-source (9.2.1-15) still FTBFS the build in both
arch:all and arch:any variants:


yes, I can read build logs.


/usr/hppa-linux-gnu/bin/ld: cannot find -latomic
collect2: error: ld returned 1 exit status
libtool: install: error: relink `libgnatvsn.la' with the above command before 
installing it

(Or the hppa libatomic.so is just missing.)


If you want to help, then please do. But stating the obvious doesn't add any 
value.

Bug#943723: texlive-extra-utils: JRE is not a dependency even though some programs (e.g. arara) need it

[Aras Ergus]

Package: texlive-extra-utils
Version: 2019.20190930-3
Severity: normal



If texlive-extra-utils is installed on a system which doesn't have
a Java runtime environment, some programs in it don't work, e.g.
> arara --version
yields
> /usr/bin/arara: line 9: java: command not found

This affects at least one other program, namely texosquery.

Installing a JRE (e.g. the package default-jre-headless) solves
this issue.

Is it intentional that no JRE is listed as a dependency, a
recommended package or a suggested package?


-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 1201 Oct 28 16:04 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Feb 28  2019 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Sep 30 02:59 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Sep 30 02:59 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Oct 28 15:44 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Sep 30 02:59 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Sep 30 02:59 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 2763 Oct 28 16:04 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Feb 28  2019 mktex.cnf
-rw-r--r-- 1 root root 475 Oct 28 15:44 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

Kernel: Linux 4.19.71-1.pvops.qubes.x86_64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US.UTF-8 (charmap=locale: Cannot set LC_MESSAGES to default 
locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages texlive-extra-utils depends on:
ii  libunicode-linebreak-perl  0.0.20190101-1
ii  python 2.7.16-1
ii  tex-common 6.11
ii  texlive-base   2019.20190930-1
ii  texlive-binaries   2019.20190605.51237-3
ii  texlive-latex-base 2019.20190930-1

Versions of packages texlive-extra-utils recommends:
ii  ghostscript9.27~dfsg-2+deb10u2
ii  libfile-homedir-perl   1.004-1
ii  liblog-log4perl-perl   1.49-1
ii  libyaml-tiny-perl  1.73-1
ii  ruby   1:2.5.1
ii  texlive-latex-recommended  2019.20190930-1

Versions of packages texlive-extra-utils suggests:
pn  chktex  
pn  dvidvi  
pn  dvipng  
pn  fragmaster  
pn  lacheck 
pn  latexdiff   
pn  latexmk 
pn  purifyeps   
pn  xindy   

Versions of packages tex-common depends on:

Bug#943722: RFP: ciasdis -- a reverse engineering assembler

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Albert van der Horst 

-- Forwarded message -
From: Albert van der Horst 
Date: Mon, 28 Oct 2019 at 16:05
Subject: No Intent To Package : ciasdis a reverse engineering assembler.
To: Debian Mentors 


 From "control"

The package ciasdis contains an i86 assembler-disassembler
  combination that allows to reassemble to a byte-for-byte
  same binary. This is useful for modifying programs where
  the source was lost, analysing viruses, etc. and general
  curiosity. Knowledge about a binary can be build up
  automatically, using scripts, or interactively and can be
  stored for continued use in .cul files.
  .
"

Release 2.0.0 sports a large cleanup, notably it can be compiled on
newer 64 bits Forth compilers.

One of the examples is reversing a linux elf32 program, with
a crawler that extracts labels from the binary itself (not
from a section with debugging labels) and detects hundreds
of boundaries between text code and 32 bits data.

I have no intent to package it myself. However if anybody thinks
this package is valuable enough to do it, I will lend full
  cooperation.
As mentionned in the release notes
 make install
will basically generate a directory tree such as present in a
.deb file. Let's say I've done some prepratory work.

Groetjes Albert
--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst



-- 
Cheers,
  Andrej

Bug#943388: Fixed

[Bálint Réczey]

Control: notfound -1 1.11.2


Yvan Masson  ezt írta (időpont: 2019.
okt. 28., H, 14:57):
>
> Hi,
>
> It was a wrong configuration on my side (see upstream bug report), the
> issue is fixed.
>
> Regards,
> Yvan
>

Bug#942126: gvfs-fuse: /run/user/ID/gvfs/ empty after upgrade

[Raphael Hertzog]

Control: severity -1 serious

Hi,

On Tue, 22 Oct 2019, Cesare Leonardi wrote:
> Ok, I confirm that replacing fuse with fuse3, as reported by Bert, make
> gvfs-fuse works as expected, with /run/user/ID/gvfs/ populated again.
> So please, consider to tighten gvfs-fuse dependencies on fuse3.

I was hit by this issue as well and installing fuse3 resolved the problem.
Given the simple fix and the fact that it's a clear regression I'm bumping
the severity of the bug.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#943721: postgresql-11 (and others): please synchronise alternatives with reality (e.g. pg_test_fsync missing)

[Thorsten Glaser]

Package: postgresql-11
Version: 11.5-3sid2
Severity: wishlist

I found pg_test_fsync via
https://www.ashnik.com/tips-for-postgres-from-a-postgres-insider/
and while the manpage is exposed via alternatives, the binary itself
isn’t, so we now have a manpage without PATH-reachable binary.

As the manpage is managed using alternatives (likely a slave of the
default PostgreSQL version), the binary itself could also be that.

Please double-check that everything shipped is available sensibly
via alternatives, for every PostgreSQL version.

Thanks!


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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages postgresql-11 depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  libc6  2.29-2
ii  libelogind0 [libsystemd0]  241.3-1+debian1
ii  libgssapi-krb5-2   1.17-6
ii  libicu63   63.2-2
ii  libldap-2.4-2  2.4.48+dfsg-1+b2
ii  libpam0g   1.3.1-5
ii  libpq5 12.0-1+b1
ii  libselinux12.9-2+b2
ii  libssl1.1  1.1.1d-2
ii  libuuid1   2.34-0.1
ii  libxml22.9.4+dfsg1-7+b3tarent1
ii  libxslt1.1 1.1.32-2.1
ii  locales2.29-2
ii  locales-all2.29-2
ii  postgresql-client-11   11.5-3sid2
ii  postgresql-common  207
ii  ssl-cert   1.0.39
ii  tzdata 2019c-3
ii  zlib1g 1:1.2.11.dfsg-1+b1

Versions of packages postgresql-11 recommends:
pn  sysstat  

postgresql-11 suggests no packages.

-- debconf information:
  postgresql-11/postrm_purge_data: true

Bug#941817: llvm-toolchain-9: FTBFS on x32

[Thorsten Glaser]

retitle 941817 llvm-toolchain-9: FTBFS on x32
reassign 941817 src:llvm-toolchain-9
found 941817 1:9.0.0-2
thanks

OK, let’s try to get this fixed in llvm-toolchain-9 and hope
that we both manage it and can bump the defaults for x32 once
working. Please note that llvm-toolchain-9 uses GCC 8 instead
of the default compiler for building still, which might be a
problem eventually.

The patch rebased is attached; I’m currently building the pak‐
kage locally and don’t know yet whether it is complete.

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.

**diff -Nru llvm-toolchain-9-9.0.0/debian/changelog 
llvm-toolchain-9-9.0.0/debian/changelog
--- llvm-toolchain-9-9.0.0/debian/changelog 2019-10-20 17:27:50.0 
+0200
+++ llvm-toolchain-9-9.0.0/debian/changelog 2019-10-28 15:18:43.0 
+0100
@@ -1,3 +1,11 @@
+llvm-toolchain-9 (1:9.0.0-2+x32.1) unreleased; urgency=high
+
+  * Non-maintainer upload.
+  * Add back cbmuser’s patch to fix include and library paths on x32
+to fix the build (Closes: #941817)
+
+ -- Thorsten Glaser   Mon, 28 Oct 2019 15:18:43 +0100
+
 llvm-toolchain-9 (1:9.0.0-2) unstable; urgency=medium
 
   * polly, openmp & lldb aren't enabled for every platform
diff -Nru llvm-toolchain-9-9.0.0/debian/patches/series 
llvm-toolchain-9-9.0.0/debian/patches/series
--- llvm-toolchain-9-9.0.0/debian/patches/series2019-10-20 
17:27:50.0 +0200
+++ llvm-toolchain-9-9.0.0/debian/patches/series2019-10-28 
15:15:40.0 +0100
@@ -19,6 +19,7 @@
 clang-tidy-run-bin.diff
 0001-tools-clang-cmake-resolve-symlinks-in-ClangConfig.cmake.patch
 debug-jit-path.diff
+x32-fix-driver-search-paths.diff
 
 # commented because of bug 903709
 #force-gcc-header-obj.diff
diff -Nru 
llvm-toolchain-9-9.0.0/debian/patches/x32-fix-driver-search-paths.diff 
llvm-toolchain-9-9.0.0/debian/patches/x32-fix-driver-search-paths.diff
--- llvm-toolchain-9-9.0.0/debian/patches/x32-fix-driver-search-paths.diff  
1970-01-01 01:00:00.0 +0100
+++ llvm-toolchain-9-9.0.0/debian/patches/x32-fix-driver-search-paths.diff  
2019-10-28 15:16:35.0 +0100
@@ -0,0 +1,80 @@
+Description: Fix missing include and library paths on x32
+Author: John Paul Adrian Glaubitz 
+Forwarded: https://reviews.llvm.org/D52050
+Last-Update: 2019-10-28
+
+--- a/clang/lib/Driver/ToolChains/Gnu.cpp
 b/clang/lib/Driver/ToolChains/Gnu.cpp
+@@ -1956,7 +1956,10 @@ void Generic_GCC::GCCInstallationDetecto
+   "x86_64-manbo-linux-gnu", "x86_64-linux-gnu",
+   "x86_64-slackware-linux", "x86_64-unknown-linux",
+   "x86_64-amazon-linux","x86_64-linux-android"};
+-  static const char *const X32LibDirs[] = {"/libx32"};
++  static const char *const X32LibDirs[] = {"/libx32", "/lib"};
++  static const char *const X32Triples[] = {
++  "x86_64-linux-gnux32","x86_64-unknown-linux-gnux32",
++  "x86_64-pc-linux-gnux32"};
+   static const char *const X86LibDirs[] = {"/lib32", "/lib"};
+   static const char *const X86Triples[] = {
+   "i686-linux-gnu",   "i686-pc-linux-gnu", "i486-linux-gnu",
+@@ -2173,14 +2176,16 @@ void Generic_GCC::GCCInstallationDetecto
+ TripleAliases.append(begin(AVRTriples), end(AVRTriples));
+ break;
+   case llvm::Triple::x86_64:
+-LibDirs.append(begin(X86_64LibDirs), end(X86_64LibDirs));
+-TripleAliases.append(begin(X86_64Triples), end(X86_64Triples));
+ // x32 is always available when x86_64 is available, so adding it as
+ // secondary arch with x86_64 triples
+ if (TargetTriple.getEnvironment() == llvm::Triple::GNUX32) {
+-  BiarchLibDirs.append(begin(X32LibDirs), end(X32LibDirs));
++  LibDirs.append(begin(X32LibDirs), end(X32LibDirs));
++  TripleAliases.append(begin(X32Triples), end(X32Triples));
++  BiarchLibDirs.append(begin(X86_64LibDirs), end(X86_64LibDirs));
+   BiarchTripleAliases.append(begin(X86_64Triples), end(X86_64Triples));
+ } else {
++  LibDirs.append(begin(X86_64LibDirs), end(X86_64LibDirs));
++  TripleAliases.append(begin(X86_64Triples), end(X86_64Triples));
+   BiarchLibDirs.append(begin(X86LibDirs), end(X86LibDirs));
+   BiarchTripleAliases.append(begin(X86Triples), end(X86Triples));
+ }
+--- a/clang/lib/Driver/ToolChains/Linux.cpp
 b/clang/lib/Driver/ToolChains/Linux.cpp
+@@ -88,10 +88,13 @@ static std::string getMultiarchTriple(co
+   case llvm::Triple::x86_64:
+ if (IsAndroid)
+   return "x86_64-linux-android";
+-// We don't want this for x32, otherwise it will match x86_64 libs
+-

Bug#931818: Please close this bug

[Jeffrey E. Hundstad]

Hello,

Please close this bug.  I don't see anyone else that's having the same
issue.  I now have a working cups installation myself.

I removed all the cups packages and associated unique support packages. 
I then followed:
https://wiki.debian.org/SystemPrinting

This instructed me to:
apt install task-print-server

This solved my problem and printing is working fine.

Sorry for the noise.

-- 
Jeffrey Hundstad




signature.asc
Description: OpenPGP digital signature

Bug#943720: RFP: onefetch -- Git repository summary on your terminal

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: onefetch
  Version : 1.6.5
  Upstream Author : Ossama Hjaji 
* URL : https://github.com/o2sh/onefetch
* License : MIT/X
  Programming Lang: Rust
  Description : Git repository summary on your terminal

Onefetch is a command line tool that displays information about your
Git project directly on your terminal. Onefetch supports almost 50
different programming languages. If your language of choice isn't
supported: Open up an issue and support will be added.



I maintain a similar tool called "pepper" but that tool hasn't seen
any activist in 4 years. In comparison, onefetch seems much simpler
and focused, but I haven't tried it yet, it being Rust...

Bug#367515: Bug#749991: debian-installer: Wrong kernel in debian-installer package

[Cyril Brulebois]

Philipp Wollschlegel  (2019-10-28):
> On 28.10.19 15:11, Ben Hutchings wrote:
> > On Sun, 2019-10-27 at 20:18 +0100, Holger Wansing wrote:
> >> Bugreport against kernel version mismatch, when using outdated or broken 
> >> netboot images:
> 
> This isn't a package / message  problem, this is a process problem.
> 
> The netboot image is not built at the same time as the rest of the
> distribution. I.e. the kernel in the main distro changes and the netboot
> image still uses the old one.
> 
> Even when using a direct url to the netboot image, the netboot image
> will fail, using the same package mirror, the netboot image came from.

That's not true for stable or oldstable. Also, we ship netboot images in
packages, use that and be happy?

If users are tracking testing or unstable, well, yes; those
distributions are WIP.

But the script you quoted seems to be about buster, so using d-i-n-i
packages should be a no-brainer.

  https://tracker.debian.org/pkg/debian-installer-netboot-images


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#943719: cgoban FTCBFS: ./configure thinks it cannot cross

[Helmut Grohne]

Source: cgoban
Version: 1.9.14-18
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

cgoban fails to cross build from source, because its configure.in checks
for cross building and deliberately fails in that case. It does that,
because earlier versions of AC_CHECK_SIZEOF did not work for cross
building, but nowadays that just works. We should simply discard the
code special casing cross compilation here to make it work. Please
consider applying the attached patch.

Helmut
--- cgoban-1.9.14.orig/configure.in
+++ cgoban-1.9.14/configure.in
@@ -189,10 +189,10 @@
 fi
 WMS_CHECK_H_ERRNO
 WMS_CHECK_SOCKETS
-if test "$cross_compiling" = "yes" ; then
+AC_CHECK_SIZEOF(short)
+if test "x$ac_cv_sizeof_short" '=' x0 ; then
   echo "* IMPORTANT *"
-  echo "*** It looks like either you are cross compiling, or configure cannot"
-  echo "***   figure out how to run your C compiler."
+  echo "*** configure cannot figure out how to run your C compiler."
   echo "*** If you are cross compiling, then configure cannot detect the "
   echo "***   size of various types and the endian style of your machine.  "
   echo "***   You will have to edit the file obj-${SYSTEM_TYPE}/configure.h "
@@ -201,26 +201,12 @@
   echo "***   for instructions on how to tell ./configure how to run your"
   echo "***   C compiler."
   echo "*"
-else
-  AC_CHECK_SIZEOF(short)
-  if test "x$ac_cv_sizeof_short" '=' x0 ; then
-echo "* IMPORTANT *"
-echo "*** configure cannot figure out how to run your C compiler."
-echo "*** If you are cross compiling, then configure cannot detect the "
-echo "***   size of various types and the endian style of your machine.  "
-echo "***   You will have to edit the file obj-${SYSTEM_TYPE}/configure.h "
-echo "***   by hand."
-echo "*** If you are NOT cross compiling, then please see the README file"
-echo "***   for instructions on how to tell ./configure how to run your"
-echo "***   C compiler."
-echo "*"
-exit 1
-  fi
-  AC_CHECK_SIZEOF(int)
-  AC_CHECK_SIZEOF(long)
-  AC_CHECK_SIZEOF(long long)
-  AC_C_BIGENDIAN
+  exit 1
 fi
+AC_CHECK_SIZEOF(int)
+AC_CHECK_SIZEOF(long)
+AC_CHECK_SIZEOF(long long)
+AC_C_BIGENDIAN
 AC_CHECK_FUNCS(strerror getdtablesize memmove strcasecmp)
 AC_RETSIGTYPE
 AC_PATH_XTRA

Bug#367515: Bug#749991: debian-installer: Wrong kernel in debian-installer package

[Philipp Wollschlegel]

On 28.10.19 15:11, Ben Hutchings wrote:
> On Sun, 2019-10-27 at 20:18 +0100, Holger Wansing wrote:
>> Bugreport against kernel version mismatch, when using outdated or broken 
>> netboot images:

This isn't a package / message  problem, this is a process problem.

The netboot image is not built at the same time as the rest of the
distribution. I.e. the kernel in the main distro changes and the netboot
image still uses the old one.

Even when using a direct url to the netboot image, the netboot image
will fail, using the same package mirror, the netboot image came from.

The CI system that builds the kernel packages needs to (re-)build the
netboot images at the same time.

Here is a shell script that i use for deploying machines with libvirt
and virt-install: (at the moment it works, but after a release its
likley to fail.)

#!/bin/bash

QSTRING="qemu:///system"
if [ -z "${1}" ]; then
  BOXNAME="base-debian-10.sigkill.noexit"
  CACHEMODE=unsafe
else
  HOSTNAME=$(echo $1 | cut -f1 -d.)
  DOMAIN=$(echo $1 | cut -f2- -d.)
  BOXNAME="${HOSTNAME}.${DOMAIN}"
  CACHEMODE=default
fi

if [ -z "${2}" ]; then
  SUITE=${2}
else
  SUITE=stable
fi

virsh --connect $QSTRING list --all | grep $BOXNAME
if [ "$?" == 0 ]; then
  virsh --connect $QSTRING destroy $BOXNAME
  virsh --connect $QSTRING undefine $BOXNAME --remove-all-storage
fi

virt-install \
  --connect $QSTRING \
  --memory 1024 \
  --vcpus 2 \
  --cpu host \
  --disk size=10,pool=vmlandscape,bus=virtio,cache=$CACHEMODE \
  --net network=vmlandscape,model=virtio \
  --os-variant debian8 \
  --os-type linux \
  --name "$BOXNAME" \
  --noautoconsole \
  --console pty,target_type=serial \
  --location
'http://ftp.debian.org/debian/dists/buster/main/installer-amd64/' \
  --extra-args "console=tty0,ttyS0,115200n8 serial auto language=en
country=CH locale=en_GB.UTF-8 keymap=us hostname=$HOSTNAME
domain=$DOMAIN net.ifnames=0 mirror/http/hostname=ftp.debian.org"

Regards,
 - Philipp Wollschlegel

-- 
Adfinis SyGroup AG
Philipp Wollschlegel

Be Smart. Think Open Source.
http://www.adfinis-sygroup.ch

Bug#943348: open-iscsi: Ask for initiator name during install

[Ritesh Raj Sarraf]

Control: reassign -1 debian-installer

On Wed, 2019-10-23 at 13:47 -0400, Christopher David Howie wrote:
> (I am not sure if this is the correct package to report this to, or
> if
> there is a separate package for the debian-installer component. 
> Please
> reassign as appropriate.)
> 

I believe all bugs for the installer go to the debian-installer
package.

> In the Debian installer, while editing partitions, one has a chance
> to
> connect to iSCSI targets.  However, nowhere does the installer ask
> for
> the iSCSI initiator name during this process.  Some targets require a
> specific initiator name to be used (to avoid initiators discovering
> devices that aren't relevant to them) and currently, using those
> targets
> during installation requires switching to a secondary VT and manually
> editing files.
> 

Interesting. I recollect discoveries were done explicitly by the
initiator. Thus, you mention the target that you want to negotiate to.

But that was years ago. I haven't been on top of the iSCSI stuff
lately.

> It would be helpful for the installer to ask if a specific initiator
> name is required, and then configure both the installer environment
> and
> the target system to have that name.

I agree it could be a nice feature to have.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#943718: reportbug-gtk is reporting that up-to-date software is out-of-date

[Jason L. Quinn]

Package: reportbug-gtk
Version: 7.5.3~deb10u1
Severity: important

Dear Maintainer,

Reportbug (at least when using the GUI) is warning software is out-of-date even
when it's not. For instance, even filing this report, I got a pop-up dialogue
saying:

=
Your version (7.5.3~deb10u1) of reportbug appears to be out of date.
The following newer releases(s) are available in the Debian archive:
   testing: 7.5.3
   unstable: 7.5.3
Please try to verify if the bug you are about to report is already
addressed by these releases. Do you still want to file a report
=

(While it's up, notice the missing question mark. Please fix that too.)

As you can see, I HAVE the latest version. It does the same thing for
the latest version of Firefox too where it warned that my version
68.2.0esr-1~deb10u1 is out-of-date and unstable has 68.2.0esr-1.

It seems like it might be the "deb10u1" patch extensions causing the trouble in
whatever comparison algorithm used.

Anyway, this is an IMPORTANT bug, not just normal. It's literally discouraging
users from sending feedback and thus adversely affects the whole project.



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

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

Versions of packages reportbug-gtk depends on:
ii  gir1.2-gtk-3.0 3.24.5-1
ii  gir1.2-vte-2.910.54.2-2
ii  python3-gi 3.30.4-1
ii  python3-gi-cairo   3.30.4-1
ii  python3-gtkspellcheck  4.0.5-1
ii  reportbug  7.5.3~deb10u1

reportbug-gtk recommends no packages.

reportbug-gtk suggests no packages.

-- no debconf information

Bug#943717: RFS: python-ebooklib/0.17.1-1 [ITA] -- Python 3 E-book library for handling EPUB2/EPUB3/Kindle formats

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-ebooklib"

* Package name ?? : python-ebooklib
?? Version ?? ??  : 0.17.1-1
?? Upstream Author  : Aleksandar Erkalovi?? 
* URL ?? ?? ??  : https://github.com/aerkalov/ebooklib
* License ?? ??  : AGPL-3
* Vcs ?? ?? ??  : None
?? Section?? ?? ?? ?? : python

It builds those binary packages:

python3-ebooklib - Python 3 E-book library for handling 
EPUB2/EPUB3/Kindle formats


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


https://mentors.debian.net/package/python-ebooklib

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

dget -x 
https://mentors.debian.net/debian/pool/main/p/python-ebooklib/python-ebooklib_0.17.1-1.dsc


Changes since the last upload:

* New maintainer closes: #942371
* New upstream release.
* Change homepage in d/control.
* Updated description in d/control.
* Updated to Standards-Version 4.4.1.
* Use debhelper-compat instead of d/compat
* Update debhelper-compat to (=12).
* Use 'Python3 -m sphinx' instead of sphinx-build for building docs.
* Remove Vcs-Git and Vcs-Browser since these were out-of-date.
* Remove unnecessary X-Python-Version field in d/control.
* rules-requires-root: no
* Remove 0001-fix_unicode_error.patch, error has been addressed upstream.
* Remove SUFFIX=~ds since this no longer applies.
* Remove d/repack* since these were no longer needed.
* d/watch update to version 4 and simplified the process.
* Remove 'get-orig-source' in d/rules.
* Use secure copyright file specification in URI.
* Changed CHANGES.TXT to CHANGES.txt in d/python3-ebooklib.docs.
* Added ${sphinxdoc:Depends} for binary in d/control.

Regards,
H??vard

Bug#936792: kicad: Python2 removal in sid/bullseye

[Andreas Henriksson]

On Fri, Aug 30, 2019 at 07:22:04AM +, Matthias Klose wrote:
> Package: src:kicad
> Version: 5.1.4+dfsg1-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
[...]

It seems the kicad package has already (mostly) been switched over
to python3. The only python2 related things I could spot is the
libpython-stdlib build-dependency. This seems to be something lingering
from a long time ago which maybe just isn't relevant anymore.

I tried to find the original reason it was introduced and in
debian/changelog entry for 4.0.2+dfsg1-3 I found the following
pretty cryptic message:

  * added a build-dependency on libpython-stdlib, which should not harm
for most architectures, and might be necessary on a few ones.

Maybe this should be switched over to libpython3-stdlib now that
everything else uses python3, but I also wouldn't be surprised if
it should just be dropped because the cryptic description kind of
smells like a bogus excuse to me.

Could kicad maintainers please comment on what you think?

Regards,
Andreas Henriksson

Bug#943471: khard: please make the build reproducible

[Félix Sipma]

On 2019-10-28 14:19+, Chris Lamb wrote:
> No problem. I've forwarded this upstream here:
> 
>  https://github.com/scheibler/khard/pull/233
> 
> As part of this I noticed that the patch I previously attached was a
> little bit garbled so it won't apply completely cleanly... but I think
> after the above PR is merged and released you will just need to do:
> 
>--- a/debian/rules 2019-10-25 09:18:54.208690284 +0100
>--- b/debian/rules 2019-10-25 09:33:48.499676643 +0100
>@@ -8,5 +8,9 @@
>   make man
>   dh_auto_build
> 
>+override_dh_auto_clean:
>+  dh_auto_clean
>+  rm -f khard/version.py
>+  
> 
> … but you may need to add `tar-ignore = "*/version.py"` to debian/
> source/options too, I am not quite sure right now.
> 
> Hope that helps.
> 
> Best wishes,

OK, I'll keep this in mind.

Thanks again,

-- 
Félix


signature.asc
Description: PGP signature

Bug#943716: systemd: generates a directory name with the /etc/machine-id value, which is confidential

[Vincent Lefevre]

Package: systemd
Version: 242-7
Severity: important
Tags: security

systemd generates a directory name under /var/log/journal with
the /etc/machine-id value, which is confidential according to
the machine-id(5) man page:

  This ID uniquely identifies the host. It should be considered
  "confidential", and must not be exposed in untrusted environments, in
  particular on the network. If a stable unique identifier that is tied
  to the machine is needed for some application, the machine ID or any
  part of it must not be used directly. Instead the machine ID should be
  hashed with a cryptographic, keyed hash function, using a fixed,
  application-specific key. That way the ID will be properly unique, and
  derived in a constant way from the machine ID but there will be no way
  to retrieve the original machine ID from the application-specific one.
  The sd_id128_get_machine_app_specific(3) API provides an implementation
  of such an algorithm.

This directory name is not directly exposed on the network, but most
users do not know where it comes from and that it is confidential,
so that it may end up on the net, e.g. in debugging exchanges and
when asking for help. An example:

  https://forum.ubuntu-fr.org/viewtopic.php?pid=21992288#p21992288

As a consequence, the machine-id is also present in journalctl output,
which may also end up on the net.

BTW, the fact that this ID is available in a file, in particular
word-readable, instead of an API to generate a hash, is a bad idea.

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-5
ii  libapparmor1 2.13.3-5+b1
ii  libaudit11:2.8.5-2
ii  libblkid12.34-0.1
ii  libc62.29-2
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.2.1-1
ii  libgcrypt20  1.8.5-3
ii  libgnutls30  3.6.9-5
ii  libgpg-error01.36-7
ii  libidn2-02.2.0-2
ii  libip4tc21.8.3-2
ii  libkmod2 26-3
ii  liblz4-1 1.9.1-2
ii  liblzma5 5.2.4-1+b1
ii  libmount12.34-0.1
ii  libpam0g 1.3.1-5
ii  libpcre2-8-0 10.32-5+b1
ii  libseccomp2  2.4.1-2
ii  libselinux1  2.9-2+b2
ii  libsystemd0  242-7
ii  mount2.34-0.1
ii  util-linux   2.34-0.1

Versions of packages systemd recommends:
ii  dbus1.12.16-2
ii  libpam-systemd  242-7

Versions of packages systemd suggests:
ii  policykit-10.105-26
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.135
ii  udev 242-7

-- Configuration Files:
/etc/systemd/journald.conf changed:
[Journal]
Storage=persistent

/etc/systemd/system.conf changed:
[Manager]
DefaultTimeoutStopSec=20s


-- no debconf information

Bug#943347: open-iscsi: md-raid layers are not probed when deciding what sessions to stop during shutdown

[Ritesh Raj Sarraf]

Contorl: severity -1 wishlist

On Wed, 2019-10-23 at 13:34 -0400, Christopher David Howie wrote:
> Package: open-iscsi
> Version: 2.0.874-7.1
> 
> I've created a VM to test the feasibility of a particular
> configuration
> and wound up running into a case that open-iscsi does not consider
> during shutdown: if an iSCSI session provides a device that is used
> as
> part of an md-raid device, then the open-iscsi shutdown scripts will
> not
> notice this and terminate the iSCSI session anyway.  This causes the
> iSCSI device to be kicked from the raid device.  On boot, because the
> device was kicked out, it will not be re-added
> automatically.  ("mdadm
> $MD_DEVICE --re-add missing" fixes this, but must be run by hand.)
> 
> The current workaround I am using is to set
> ISCSI_ROOT_KEEP_ALL_SESSIONS_AT_SHUTDOWN=1 in /etc/default/open-
> iscsi.
> 

These are some of the use cases for which this functionality was added.

> It would be nice if open-iscsi looked through md-raid layers and
> avoided
> stopping sessions that provide a device used by _any_ active md-raid
> device, as not doing so requires manually re-adding the iSCSI device
> to
> the array next time it is assembled.
> 

I have never done sw raid in all my years of interaction with
computers. At Big HW Vendor labs, it was mostly HW RAID.

The teardown of Linux (Stackable) Storage Layers is complicated and as
such, uncommon features like SW RAID got left out.

I'm willing to review and add this feature if someone can come up with
an implementation to integrate to what we have cooked so far.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#943471: khard: please make the build reproducible

[Chris Lamb]

forwarded 943471 https://github.com/scheibler/khard/pull/233
thanks

Félix Sipma wrote:

> Thanks for the report and the attached patch. Would you want to file a
> pull request to upstream directly?

No problem. I've forwarded this upstream here:

  https://github.com/scheibler/khard/pull/233

As part of this I noticed that the patch I previously attached was a
little bit garbled so it won't apply completely cleanly... but I think
after the above PR is merged and released you will just need to do:

--- a/debian/rules  2019-10-25 09:18:54.208690284 +0100
--- b/debian/rules  2019-10-25 09:33:48.499676643 +0100
@@ -8,5 +8,9 @@
make man
dh_auto_build
 
+override_dh_auto_clean:
+   dh_auto_clean
+   rm -f khard/version.py
+   

… but you may need to add `tar-ignore = "*/version.py"` to debian/
source/options too, I am not quite sure right now.

Hope that helps.


Best wishes,

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

Bug#943551: trace-cmd in debian is very old compared to upstream

[Seth Forshee]

On Sat, Oct 26, 2019 at 10:31:52AM +0100, Sudip Mukherjee wrote:
> Package: trace-cmd
> Version: 2.6.1-0.1
> Severity: important
> 
> The trace-cmd package in debian seems to be very old. The upstream
> available version is v2.8.3 and the version used in debian is v2.5.3.
> There had been major improvements in trace-cmd and kernelshark recently.
> 
> I can help in updating it if the ubuntu kernel team is busy.

Yes, I had been keeping it up to date for some time, but it's not really
something I have time for anymore. If you or someone else is interested
in taking over the package, please feel free.

Thanks,
Seth