Bug#968030: e17: FTBFS during combined arch+indep build

2020-08-06 Thread Ross Vandegrift
On Fri, Aug 07, 2020 at 01:17:29AM +0200, Andreas Beckmann wrote:
> e17/experimental FTBFS during a combined binary arch+indep build (i.e. the
> default dpkg-buildpackage mode), while it succeeds during separate arch and
> indep builds (dpkg-buildpackage -B, dpkg-buildpackage -A; as done by the
> buildds). I know no other package having such a failure mode ;-)

Hah, I swear I finally had all combinations working- but looks like I just
moved the bump in the rug around.  At least I got a totally unique failure out
for my time! :)

Ross



Bug#962193: libargs_6.2.2-1_amd64.changes REJECTED

2020-08-06 Thread Thorsten Alteholz

Hi Andreas,

please explain more verbose how catch.hpp is generated and what sources are 
needed.

Thanks!
 Thorsten
 



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.


___
Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

Bug#966816: lvm2: Patch to fix the problem

2020-08-06 Thread Asher Gordon
Package: lvm2
Version: 2.03.09-2
Followup-For: Bug #966816

Dear Maintainer,

I noticed this bug as well, when I was upgrading lvm2. Here is a patch
to fix the problem:
diff --git a/scripts/blk_availability_systemd_red_hat.service.in b/scripts/blk_availability_systemd_red_hat.service.in
index c556e1c8d..c83f76a08 100644
--- a/scripts/blk_availability_systemd_red_hat.service.in
+++ b/scripts/blk_availability_systemd_red_hat.service.in
@@ -7,7 +7,7 @@ Conflicts=shutdown.target
 
 [Service]
 Type=oneshot
-ExecStart=@bindir@/true
+ExecStart=/bin/true
 ExecStop=@SBINDIR@/blkdeactivate -u -l wholevg -m disablequeueing -r wait
 RemainAfterExit=yes
 
This could also be fixed by fully expanding $bindir in configure like
$SBINDIR and some other variables, but the path to 'true' is independent
on $bindir anyway, so I think using /bin/true is a better
solution. (Also, I'm not even sure that $bindir _is_ /bin.)

It seems that this problem was present for quite a while, so I'm not
sure why I didn't notice it before.

Thanks,
Asher

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

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

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.171-2
ii  dmsetup   2:1.02.171-2
ii  init-system-helpers   1.58
ii  libaio1   0.3.112-8
ii  libblkid1 2.36-2
ii  libc6 2.31-2
ii  libdevmapper-event1.02.1  2:1.02.171-2
ii  libreadline5  5.2+dfsg-3+b13
ii  libselinux1   3.1-2
ii  libsystemd0   246-2
ii  libudev1  246-2
ii  lsb-base  11.1.0

Versions of packages lvm2 recommends:
ii  thin-provisioning-tools  0.8.5-4

lvm2 suggests no packages.

-- no debconf information

-- 
By necessity, by proclivity, and by delight, we all quote.  In fact, it is as
difficult to appropriate the thoughts of others as it is to invent.
-- R. Emerson
-- Quoted from a fortune cookie program
(whose author claims, "Actually, stealing IS easier.")
[to which I reply, "You think it's easy for me to
misconstrue all these misquotations?!?"  Ed.]
   
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.

GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68


signature.asc
Description: PGP signature


Bug#968033: RM: wicd -- ROM; Version in unstable depends on Python 2.x, Python3 version only in experimental so far

2020-08-06 Thread Axel Beckert
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: w...@packages.debian.org

Please remove wicd from Debian Unstable (and only Unstable). The
version in Debian Unstable depends on Python 2.x and it doesn't look
as if upstream gets the Python 3 port in shape for unstable very soon.

The plan is that those who also have Debian Experimental in their
sources.list might be prompted to update to the incomplete Python 3
port in Debian Experimental instead of staying with the Python 2.x
version and blocking the Python 2 removal on their installations.

I will bring back wicd into Debian Unstable once the Python 3 port is
in an appropriate state.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5



Bug#816958: ITP: broadcom-facetimehd -- dkms source for the Broadcom 1570 PCIe camera

2020-08-06 Thread You-Sheng Yang
retitle 816958 ITP: facetimehd-dkms -- dkms source for the Broadcom 1570 PCIe 
camera
owner 816958 !
thanks

I would like to package this. It has been available at 
https://gitlab.com/vicamo/facetimehd-dkms for some time.

You-Sheng Yang



signature.asc
Description: OpenPGP digital signature


Bug#929692: ITP: backport-iwlwifi-dkms -- iwlwifi driver backport in DKMS format

2020-08-06 Thread You-Sheng Yang
retitle 929692 ITP: backport-iwlwifi-dkms -- iwlwifi driver backport in DKMS 
format
thanks



signature.asc
Description: OpenPGP digital signature


Bug#968032: RFP: librespeed-cli -- A command line interface for testing Internet bandwidth using LibreSpeed backends

2020-08-06 Thread Vipul
Package: wnpp
Severity: wishlist

* Package name: librespeed-cli
  Version : 1.0.7
  Upstream Author : Federico Dossena 
* URL : https://github.com/librespeed/speedtest-cli
* License : LGPL-3.0
  Programming Lang: Go
  Description : A command line interface for testing Internet bandwidth 
using LibreSpeed backends

librespeed-cli is a free and open source implemention to test Internet
bandwith directly from terminal. Unlike speedtest.net, librespeed
backends are also free and open source, which is currently available in
PHP[1] and Go[2] implementation; also it doesn't have miles-long privacy
policy[3].

[1]: https://github.com/librespeed/speedtest
[2]: https://github.com/librespeed/speedtest-go
[3]: https://www.speedtest.net/about/privacy



Bug#968029: ITP: prometheus-exporter-exporter -- simple reverse proxy to other Prometheus exporters

2020-08-06 Thread Johan Fleury
Package: wnpp
Severity: wishlist
Owner: Johan Fleury 
X-Debbugs-Cc: debian-de...@lists.debian.org, jfle...@arcaik.net

* Package name: prometheus-exporter-exporter
  Version : 0.4.0-1
  Upstream Author : Tristan Colgate-McFarlane 
* URL : https://github.com/QubitProducts/exporter_exporter
* License : Apache-2.0
  Programming Lang: Golang
  Description : simple reverse proxy to other Prometheus exporters

prometheus-exporter-exporter is intended as a single binary alternative to
nginx/apache for use in environments where opening multiple TCP ports to all
servers might be difficult (technically or politically).



Bug#968031: take-vector-screenshot: crash (SIGSEGV) under GNOME Wayland

2020-08-06 Thread Paul Wise
Package: gtk-vector-screenshot
Version: 0.3.2.1-2+b1
Severity: normal
File: /usr/bin/take-vector-screenshot
Usertags: crash wayland

When I try to take a screenshot under GNOME Wayland I get a crash.
Other programs like xkill that query the pointer seem to work.

$ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' -ex 
'thread apply all bt full' --args take-vector-screenshot
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x70516700 (LWP 679312)]
[New Thread 0x7fffefd15700 (LWP 679313)]
[New Thread 0x7fffef46e700 (LWP 679314)]
[New Thread 0x7fffeec44700 (LWP 679315)]

(take-vector-screenshot:679270): GLib-GObject-WARNING **: 08:59:24.716: The 
property GtkSettings:gtk-button-images is deprecated and shouldn't be used 
anymore. It will be removed in a future version.
Gdk-Message: 08:59:24.854: Window 0x55a96270 is a temporary window without 
parent, application will not be able to position it on screen.

(take-vector-screenshot:679270): Gdk-WARNING **: 08:59:33.365: Window 
0x55a96270 is already mapped at the time of grabbing. gdk_seat_grab() 
should be used to simultanously grab input and show this popup. You may find 
oddities ahead.

Thread 1 "take-vector-scr" received signal SIGSEGV, Segmentation fault.
0x in ?? ()
#0  0x in  ()
#1  0x770b02a0 in XQueryPointer (dpy=0x55776810, w=1374389535210, 
root=0x7fffd098, child=0x7fffd090, root_x=0x7fffd088, 
root_y=0x7fffd088, win_x=0x7fffd088, win_y=0x7fffd088, 
mask=0x7fffd08c) at ../../src/QuPntr.c:46
#2  0x5a10 in pdfscreenshot_window_selected 
(grab_window=grab_window@entry=0x557b07e0 [GtkWindow], event=, button=) at take-vector-screenshot.c:52
#7  0x77313edf in  (instance=instance@entry=0x557b07e0, signal_id=, detail=detail@entry=0) at ../../../gobject/gsignal.c:3554
#3  0x77bc60fb in _gtk_marshal_BOOLEAN__BOXED 
(closure=closure@entry=0x559c7b80, 
return_value=return_value@entry=0x7fffd2e0, 
n_param_values=n_param_values@entry=2, 
param_values=param_values@entry=0x7fffd340, 
invocation_hint=invocation_hint@entry=0x7fffd2c0, 
marshal_data=marshal_data@entry=0x0) at gtkmarshalers.c:83
#4  0x772f4fd2 in g_closure_invoke (closure=0x559c7b80, 
return_value=0x7fffd2e0, n_param_values=2, param_values=0x7fffd340, 
invocation_hint=0x7fffd2c0) at ../../../gobject/gclosure.c:810
#5  0x77308784 in signal_emit_unlocked_R (node=, 
detail=detail@entry=0, instance=instance@entry=0x557b07e0, 
emission_return=emission_return@entry=0x7fffd460, 
instance_and_params=instance_and_params@entry=0x7fffd340) at 
../../../gobject/gsignal.c:3742
#6  0x77313078 in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7fffd510) at ../../../gobject/gsignal.c:3508
#8  0x77b71f12 in gtk_widget_event_internal (event=0x55a660d0, 
widget=0x557b07e0 [GtkWindow]) at ../../../../gtk/gtkwidget.c:7808
#9  gtk_widget_event_internal (widget=0x557b07e0 [GtkWindow], 
event=0x55a660d0) at ../../../../gtk/gtkwidget.c:7677
#10 0x77a31c98 in propagate_event_up (topmost=, 
event=, widget=0x557b07e0 [GtkWindow]) at 
../../../../gtk/gtkmain.c:2597
#11 propagate_event (widget=, event=0x55a660d0, 
captured=, topmost=0x0) at ../../../../gtk/gtkmain.c:2700
#12 0x77a33e5b in gtk_main_do_event (event=0x55a660d0) at 
../../../../gtk/gtkmain.c:1920
#13 gtk_main_do_event (event=) at ../../../../gtk/gtkmain.c:1690
#14 0x7772f815 in _gdk_event_emit (event=event@entry=0x55a660d0) at 
../../../../gdk/gdkevents.c:73
#15 0x7778c872 in gdk_event_source_dispatch (base=, 
callback=, data=) at 
../../../../../gdk/wayland/gdkeventsource.c:124
#16 0x7720b5fd in g_main_dispatch (context=0x55783c20) at 
../../../glib/gmain.c:3309
#17 g_main_context_dispatch (context=context@entry=0x55783c20) at 
../../../glib/gmain.c:3974
#18 0x7720b880 in g_main_context_iterate (context=0x55783c20, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/gmain.c:4047
#19 0x7720bb53 in g_main_loop_run (loop=0x55a6eaf0) at 
../../../glib/gmain.c:4241
#20 0x77a32e85 in gtk_main () at ../../../../gtk/gtkmain.c:1328
#21 0x584a in main (argc=, argv=) at 
take-vector-screenshot.c:176
#0  0x in  ()
#1  0x770b02a0 in XQueryPointer (dpy=0x55776810, w=1374389535210, 
root=0x7fffd098, child=0x7fffd090, root_x=0x7fffd088, 
root_y=0x7fffd088, win_x=0x7fffd088, win_y=0x7fffd088, 
mask=0x7fffd08c) at ../../src/QuPntr.c:46
rep = {type = 0 '\000', sameScreen = 0 '\000', sequenceNumber = 16920, 
length = 0, root = 0, child = 0, rootX = 31616, rootY = 21916, winX = 21845, 
winY = 0, mask = 39902, pad1 = 63266, pad = 32767}

Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way

2020-08-06 Thread gregor herrmann
On Thu, 06 Aug 2020 17:09:13 +0200, Dominique Dumont wrote:

> On jeudi 6 août 2020 16:56:17 CEST you wrote:
> > I figured. How about depending on debian-policy and using the
> > information in its changelog?
> Actually, I could use rmadison to get the latest version of debian-policy 
> without installing this package (like rmadison is used to get the version of 
> packages in unstable and older releases)

Right, except that this also doesn't work at build time.
But if we skip the test phase that would be ok.

What I'm wondering is:
- depending on debian-policy would be another dependency, and the debian-policy
  only installs files to /usr/share/doc which is not guaranteed to
  exist; and there's also no easily parsable file there;
- will lintian continue to ship
  /usr/share/lintian/data/standards-version/release-dates ? Then we
  could still parse it ourselves without the Lintian perl modules;
- even if lintian ships the perl modules in a private path, it would
  be possible to use it; if this makes sense depends on the reason
  why lintian moves the files, which I haven't fully understood yet
  (my impression is more that this has to do with lintian internales
  like tests that with the question if the modules should be uses by
  others).

But yeah, maybe just using rmadison or whatever other online method
to get the lates S-V is easier than to rely on lintian.


Cheers,
gregor

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


signature.asc
Description: Digital Signature


Bug#960640: bash-completion: dh_bash-completion needs to record installed files for dh_missing

2020-08-06 Thread Gabriel F. T. Gomes
Hi, Andreas,

I need help to reproduce this bug.

On 15 May 2020, Andreas Beckmann wrote:

>with dh_missing defaulting to --fail-missing in compat level 13,
>dh_bash-completion needs to log the files it has installed s.t.
>dh_missing does not wrongly report
>  dh_missing: error: missing files, aborting

Have you seen this message during the build of some package? Could you
share the package name?

I followed Anthony's suggestion and tried a couple of packages, for
instance: mpc and apt-file, but none of them caused the behavior you
describe. Not after switching to debhelper 13, not even after adding
--fail-missing to an override of dh_missing.

Perhaps I'm doing something wrong, but knowing what packages cause this
could help me narrow the search (or my errors) down.

Cheers,
Gabriel



Bug#881075: Update

2020-08-06 Thread Rodolphe Pelloux-Prayer

Sorry for the very long delay on this issue.

I've just push a new version to 
https://mentors.debian.net/package/dfu-programmer/


FYI, the git repo is now on salsa : 
https://salsa.debian.org/ropp-guest/dfu-programmer.



Rodolphe

Le 06/08/2020 à 18:39, Ryan Pavlik a écrit :

I'd be willing to look into updating this package, as long as the
maintainer has no objection. It would be helpful if the git repo of
packaging were available (see https://bugs.debian.org/928335 ), though
failing that I could just use dgit.

Ryan




Bug#957355: ifplugd: ftbfs with GCC-10

2020-08-06 Thread Luis Paulo Linares
Control: tags -1 + patch

Hi,

the attached patch fixes the FTBFS with GCC 10.

Regards,
-- 
Luis Paulo (lpfll)
diff -Nru ifplugd-0.28/debian/patches/09_fix-ftbfs-with-gcc10.patch ifplugd-0.28/debian/patches/09_fix-ftbfs-with-gcc10.patch
--- ifplugd-0.28/debian/patches/09_fix-ftbfs-with-gcc10.patch	1969-12-31 21:00:00.0 -0300
+++ ifplugd-0.28/debian/patches/09_fix-ftbfs-with-gcc10.patch	2020-08-06 19:46:15.0 -0300
@@ -0,0 +1,17 @@
+Description: Fix FTBFS with GCC 10.
+Author: Luis Paulo Linares 
+Bug-Debian: https://bugs.debian.org/957355
+
+--- ifplugd-0.28.orig/src/interface.h
 ifplugd-0.28/src/interface.h
+@@ -24,8 +24,8 @@
+ /* From  */
+ #define ETH_ALEN 6
+ 
+-int interface_auto_up;
+-int interface_do_message;
++extern int interface_auto_up;
++extern int interface_do_message;
+ 
+ typedef enum { IFSTATUS_UP, IFSTATUS_DOWN, IFSTATUS_ERR } interface_status_t;
+ 
diff -Nru ifplugd-0.28/debian/patches/series ifplugd-0.28/debian/patches/series
--- ifplugd-0.28/debian/patches/series	2018-06-23 07:22:26.0 -0300
+++ ifplugd-0.28/debian/patches/series	2020-08-06 19:46:15.0 -0300
@@ -6,3 +6,4 @@
 06_509015_better_delays.patch
 07_add_fractional_delays.patch
 08_allow_ipv4_less.patch
+09_fix-ftbfs-with-gcc10.patch


Bug#968021: RFS: dfu-programmer/0.7.2-1 -- device firmware update (DFU) based USB programmer for Atmel chips

2020-08-06 Thread Rodolphe Pelloux-Prayer

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dfu-programmer":

* Package name : dfu-programmer
Version : 0.7.2-1
Upstream Author : [fill in name and email of upstream]
* URL : https://dfu-programmer.github.io/
* License : GPL-2+
* Vcs : https://salsa.debian.org/ropp-guest/dfu-programmer
Section : electronics

It builds those binary packages:

dfu-programmer - device firmware update (DFU) based USB programmer for 
Atmel chips


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


https://mentors.debian.net/package/dfu-programmer/

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dfu-programmer/dfu-programmer_0.7.2-1.dsc


Changes since the last upload:

dfu-programmer (0.7.2-1) unstable; urgency=low
.
* New Upstream version 0.7.2
* debian/control:
- bump standards version to 4.5.0
- update Vcs fields.
* debian/patches/:
- refresh update_configure.
- refresh escape_minus_sign_in_manpage.
* Use gbp pq for patches.
* Add gbp.conf
* Update compat
* Use https for copyright-format (insecure-copyright-format-uri).

Regards,



Bug#966822: systemd: user-runtime-dir service crashes the kernel under SELinux

2020-08-06 Thread bauen1
Hi,

I've already reported this bug in the kernel audit system upstream, see 
https://lore.kernel.org/linux-audit/20200723200041.7yinlklts47pz...@madcap2.tricolour.ca/T/#t
 for details.

A revert (8ac68dc455d9d18241d44b96800d73229029ed34) of the commit that caused 
this regression in 5.7 is already in 5.7.13 
(https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.7.13) 

This bug should be reassigned to the kernel package.



Bug#968017: RFS: spacenavd/0.7.1-1 [RC] -- daemon for using 3D input devices from 3Dconnexion

2020-08-06 Thread Rodolphe Pelloux-Prayer

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "spacenavd":

* Package name : spacenavd
Version : 0.7.1-1
Upstream Author : [fill in name and email of upstream]
* URL : http://spacenav.sourceforge.net
* License : GPL-3.0+, BSD-3-clause and GPL-3.0+
* Vcs : https://salsa.debian.org/ropp-guest/spacenavd
Section : utils

It builds those binary packages:

spacenavd - daemon for using 3D input devices from 3Dconnexion

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/s/spacenavd/spacenavd_0.7.1-1.dsc


Changes since the last upload:

spacenavd (0.7.1-1) unstable; urgency=medium
.
* Make the build reproducible (Thanks Reiner Herrmann). Closes: #843097.
* Update Standards-Version to 3.9.8.
* Add missing lsb-base dependency.
* New upstream version 0.7.1. (Closes: #959833)
* Upgrade patches for 0.7.1 release.
* Remove dh-systemd dependency. (Closes: #958617)
* Update docs and compat files.
* Bump standards version to 4.5.0.
* Move Vcs-* fields to point salsa page.
* Add documentation field to systemd service file
* Use https for copyright-format (insecure-copyright-format-uri).
* Prepare 0.7.1-1 for release.

Regards,



Bug#968030: e17: FTBFS during combined arch+indep build

2020-08-06 Thread Andreas Beckmann
Source: e17
Version: 0.24.2-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

e17/experimental FTBFS during a combined binary arch+indep build (i.e. the
default dpkg-buildpackage mode), while it succeeds during separate arch and
indep builds (dpkg-buildpackage -B, dpkg-buildpackage -A; as done by the
buildds). I know no other package having such a failure mode ;-)

   debian/rules execute_before_dh_install-indep
make[1]: Entering directory '/build/e17-0.24.2'
rm -f debian/tmp/usr/share/enlightenment/COPYING
gzip -9n debian/tmp/usr/share/enlightenment/doc/*.txt
gzip: debian/tmp/usr/share/enlightenment/doc/*.txt: No such file or directory
make[1]: *** [debian/rules:30: execute_before_dh_install-indep] Error 1
make[1]: Leaving directory '/build/e17-0.24.2'
make: *** [debian/rules:11: binary] Error 2



Andreas


e17_0.24.2-3.log.gz
Description: application/gzip


Bug#963868: linux-image-amd64: 5.7.6 crash

2020-08-06 Thread Christian Göttsche
Control: tags -1 fixed-upstream

Fixed in 5.7.13

ee27c88788b88c9c1c75e3a9ce580c79c2dba009 ("drm/amd/display: Clear
dm_state for fast updates")



Bug#954189: Upload approval for acmetool 0.2 in buster-backports

2020-08-06 Thread Ralph Giles
Hi,

I wanted to request approval from the maintainer team to upload the
acmetool 0.2.1-2 package currently in testing/unstable to buster-
backports.

The version currently in buster (0.0.63) only supports the deprecated
ACME v1 protocol, which no longer works for new registrations, and will
stop working even for renewals in 2021. As such, the package isn't
usable for deploying new sites on buster installs.

The 0.2.1 package from unstable works fine on buster, providing ACME v2
support, and also fixes issues with the systemd unit file provided by
the package.

I think having the newer package available in backports would be a
better situation for users.

Thanks for your time an effort supporting letsencrypt,

Ralph


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


Bug#965077: MySQL database with "SQLAUthTypes Backend" doesn't work anymore in buster

2020-08-06 Thread Hilmar Preuße
Control: tags 965077 + pending

On 8/6/20 4:20 PM, Andreas Trottmann wrote:
> Am 23.07.20 um 21:28 schrieb Hilmar Preuße:

Hi,

>> Addendum: meanwhile proftp 1.3.7a has been released. I built a package
>> and uploaded to unstable. You may get the packages from the official
>> page.
>> Your (adapted) patch is contained in the source package but not
>> activated. You need to rebuild for testing.
> 
> Thank you very much! I can confirm that it works when built with the patch.
> 
Thanks for calling back, the patch will be in next upload. Tag pending.

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature


Bug#608124: Hyvää päivää,

2020-08-06 Thread Alliance Funding Bvba
Hyvää päivää,

Olen Orlando Lawrence, talousjohtaja hyvin tunnustettu luotonanto yritys 
tunnetaan Alliance Funding Bvba. Onko sinulla huono luotto tai olet tarvitsevat 
lainaa maksaa laskuja? Voit ottaa meihin yhteyttä, meidän korko on 2% korko 
vuodessa.

Täytä alla oleva lomake, jos olet kiinnostunut saamaan lainaa.

Koko nimi: 
Sukupuoli: 
Tarvittava määrä:
Kesto:
Ymmärrätkö englantia?

Terveisin
Orlando Lawrence



Bug#968015: resolvconf-pull-resolved.service fails with systemd 246-2

2020-08-06 Thread Juuso Alasuutari
I was also hit by this bug. The rate of logspam caused by the failure
message was so intense that my laptop's SATA SSD was filling up at hundreds
of MiB per minute. The I/O flood made everything slow down; login barely
worked, bash-completion tabbing took 5-10 s, and figuring out which
process(es) to kill before space runs out was a race against time that I
nearly lost.

It's been a long time since I last experienced a bug that demanded a
similarly urgent and decisive user response as this. In my opinion this is
a serious one.


Bug#957841: squidguard: diff for NMU version 1.6.0-1.1

2020-08-06 Thread Sudip Mukherjee
Control: tags 957841 + patch
Control: tags 957841 + pending

Dear maintainer,

I've prepared an NMU for squidguard (versioned as 1.6.0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru squidguard-1.6.0/debian/changelog squidguard-1.6.0/debian/changelog
--- squidguard-1.6.0/debian/changelog   2019-02-02 17:13:22.0 +
+++ squidguard-1.6.0/debian/changelog   2020-08-06 22:42:00.0 +0100
@@ -1,3 +1,10 @@
+squidguard (1.6.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957841)
+
+ -- Sudip Mukherjee   Thu, 06 Aug 2020 22:42:00 
+0100
+
 squidguard (1.6.0-1) unstable; urgency=medium
 
   * New upstream release with many fixes and updates (see CHANGELOG).
diff -Nru squidguard-1.6.0/debian/patches/fix_ftbfs.patch 
squidguard-1.6.0/debian/patches/fix_ftbfs.patch
--- squidguard-1.6.0/debian/patches/fix_ftbfs.patch 1970-01-01 
01:00:00.0 +0100
+++ squidguard-1.6.0/debian/patches/fix_ftbfs.patch 2020-08-06 
22:41:24.0 +0100
@@ -0,0 +1,50 @@
+Description: Fix ftbfs with GCC-10
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/957841
+Forwarded: no
+
+---
+
+--- squidguard-1.6.0.orig/src/main.c.in
 squidguard-1.6.0/src/main.c.in
+@@ -71,6 +71,8 @@ int sgtime = 0;
+ char *globalLogDir = NULL;
+ int globalSyslog = 0;
+ 
++char *progname;
++int lineno;
+ 
+ #if __STDC__
+ int main(intargc,
+--- squidguard-1.6.0.orig/src/sg.h.in
 squidguard-1.6.0/src/sg.h.in
+@@ -115,7 +115,7 @@ int tolower();
+ #define REDIRECT_PERMANENT   "301:"
+ #define REDIRECT_TEMPORARILY "302:"
+ 
+-char *progname;
++extern char *progname;
+ 
+ struct LogFileStat {
+   char *name;
+@@ -337,7 +337,7 @@ struct AclDest {
+   struct AclDest *next;
+ };
+ 
+-int lineno;
++extern int lineno;
+ 
+ char   *sgParseRedirect   __P((char *, struct SquidInfo *, struct Acl *, 
struct AclDest *));
+ char   *sgAclAccess __P((struct Source *, struct Acl *, struct SquidInfo *));
+--- squidguard-1.6.0.orig/src/sg.y.in
 squidguard-1.6.0/src/sg.y.in
+@@ -35,7 +35,7 @@ extern int globalSyslog;
+ 
+ #include "sgEx.h"
+ 
+-FILE *yyin, *yyout;
++extern FILE *yyin, *yyout;
+ char *configFile;
+ 
+ int numTimeElements;
diff -Nru squidguard-1.6.0/debian/patches/series 
squidguard-1.6.0/debian/patches/series
--- squidguard-1.6.0/debian/patches/series  2019-02-02 17:13:22.0 
+
+++ squidguard-1.6.0/debian/patches/series  2020-08-06 22:39:49.0 
+0100
@@ -1 +1 @@
-
+fix_ftbfs.patch



Bug#964926: systemd: systemctl show prints "Failed to parse bus message: Invalid argument" before output

2020-08-06 Thread Michael Biebl
Control: user pkg-systemd-maintain...@lists.alioth.debian.org
Control: usertag -1 + buster-backport

Am 06.08.20 um 14:25 schrieb Marc Haber:
> On Tue, Jul 14, 2020 at 09:13:15PM +0100, Hugh Cole-Baker wrote:
>> It turns out this is just caused by running a 5.8-rc kernel with systemd
>> compiled against linux-libc-dev 5.7, there's a new capability cap_bpf
>> that systemctl fails to display since it's not in linux/capability.h.
>>
>> The same issue is described here, with a link to the upstream fix:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1853736
> 
> Thanks for the accurate description. This also happens when a stable
> system is running a 5.8 release kernel. Can this fix possibly be applied
> in stable as well?

I'll add this to the list of things to consider for the next stable upload.




signature.asc
Description: OpenPGP digital signature


Bug#960074: libmupdf-dev: mistake pkg-config file path

2020-08-06 Thread Bastian Germann
On Sat, 09 May 2020 12:08:09 +0900 madosuki
 wrote:> I would expect pkg-config path is
dynamic change from architecture.
> However currently output path is 
> "/usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/mupdf.pc". 

dh-exec is not run. This can be fixed by:
chmod +x debian/libmupdf-dev.install



Bug#885265: [py3] some fixes to get chirpw running with python3, Fixes #7431

2020-08-06 Thread Christoph Berg
Re: Arturo Borrero Gonzalez
> I tested chirp from the upstream mercurial repository (py3 branch) today in
> Debian testing bullseye, and I got it working with python3 with the attached 
> patch.

Hi Arturo,

thanks for picking this up. I had done some python3 hacking on chirp
earlier this year, but apparently never pushed the changes anywhere
since they weren't working.

> I was able to download the image from a baofeng UV-5RA, modify it and the 
> upload
> it again.

I confirm that my UV-5R works now as well. Cool.

Fwiw, I've tried to submit changes to the tracker on danplanet for
about half a dozen times and it always failed, so no idea where to
send my patches. If this mail gets through, the python3 patches are
there:

https://salsa.debian.org/debian-hamradio-team/chirp/-/tree/master/debian/patches

py3-print: print foo => print(foo) changes
py3-except: except Exception, e => except Exception as e changes
py3-fixes: the (small) rest

Only the UV-5R module is tested, there are many other issues remaining
in the other modules, but this is a start.

Thanks,
Christoph



Bug#968027: dino-im: FTBFS: error: [...]/xmpp-vala/src/glib_fixes.vapi not found

2020-08-06 Thread Andreas Beckmann
Source: dino-im
Version: 0.1.0+20200623.717d0b7-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

dino-im/experimental FTBFS on all architectures:
https://buildd.debian.org/status/package.php?p=dino-im=experimental

   dh_auto_build -a -O--buildsystem=cmake\+ninja
cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j4 -v
[1/642] cd /<>/obj-x86_64-linux-gnu/xmpp-vala && echo -e 
"gdk-pixbuf-2.0\ngee-0.8\ngio-2.0\nglib-2.0\ngobject-2.0\nicu-uc\n" > 
/<>/obj-x86_64-linux-gnu/exports/xmpp-vala.deps
[2/642] cd /<>/obj-x86_64-linux-gnu/qlite && echo -e 
"gee-0.8\nglib-2.0\ngobject-2.0\nsqlite3\n" > 
/<>/obj-x86_64-linux-gnu/exports/qlite.deps
[3/642] cd /<>/obj-x86_64-linux-gnu/libdino && echo -e 
"gdk-pixbuf-2.0\ngee-0.8\nglib-2.0\ngmodule-2.0\ngobject-2.0\nxmpp-vala\nqlite" 
> /<>/obj-x86_64-linux-gnu/exports/dino.deps
[4/642] cd /<>/obj-x86_64-linux-gnu/libdino && cp 
/<>/libdino/src/dino_i18n.h 
/<>/obj-x86_64-linux-gnu/exports/dino_i18n.h
[5/642] cd /<>/obj-x86_64-linux-gnu/xmpp-vala && /usr/bin/valac 
--color=always -C 
--header=/<>/obj-x86_64-linux-gnu/exports/xmpp-vala.h 
--internal-header=/<>/obj-x86_64-linux-gnu/exports/xmpp-vala_internal.h
 --vapi=/<>/obj-x86_64-linux-gnu/exports/xmpp-vala.vapi 
--internal-vapi=/<>/obj-x86_64-linux-gnu/exports/xmpp-vala_internal.vapi
 -b /<>/xmpp-vala -d 
/<>/obj-x86_64-linux-gnu/xmpp-vala --pkg=gdk-pixbuf-2.0 
--pkg=gee-0.8 --pkg=gio-2.0 --pkg=glib-2.0 --pkg=gobject-2.0 --pkg=icu-uc 
--define=ALPN_SUPPORT --vapidir=/<>/xmpp-vala/vapi -g 
--target-glib=2.38 /<>/xmpp-vala/src/core/namespace_state.vala 
/<>/xmpp-vala/src/core/stanza_attribute.vala 
/<>/xmpp-vala/src/core/stanza_node.vala 
/<>/xmpp-vala/src/core/stanza_reader.vala 
/<>/xmpp-vala/src/core/stanza_writer.vala 
/<>/xmpp-vala/src/core/xmpp_log.vala 
/<>/xmpp-vala/src/core/xmpp_stream.vala 
/<>/xmpp-vala/src/module/bind.vala 
/<>/xmpp-vala/src/module/bookmarks_provider.vala 
/<>/xmpp-vala/src/module/conference.vala 
/<>/xmpp-vala/src/module/iq/module.vala 
/<>/xmpp-vala/src/module/iq/stanza.vala 
/<>/xmpp-vala/src/module/jid.vala 
/<>/xmpp-vala/src/module/message/module.vala 
/<>/xmpp-vala/src/module/message/stanza.vala 
/<>/xmpp-vala/src/module/presence/flag.vala 
/<>/xmpp-vala/src/module/presence/module.vala 
/<>/xmpp-vala/src/module/presence/stanza.vala 
/<>/xmpp-vala/src/module/roster/flag.vala 
/<>/xmpp-vala/src/module/roster/item.vala 
/<>/xmpp-vala/src/module/roster/module.vala 
/<>/xmpp-vala/src/module/roster/versioning_module.vala 
/<>/xmpp-vala/src/module/sasl.vala 
/<>/xmpp-vala/src/module/session.vala 
/<>/xmpp-vala/src/module/stanza.vala 
/<>/xmpp-vala/src/module/stanza_error.vala 
/<>/xmpp-vala/src/module/stream_error.vala 
/<>/xmpp-vala/src/module/tls.vala 
/<>/xmpp-vala/src/module/util.vala 
/<>/xmpp-vala/src/module/xep/0048_bookmarks.vala 
/<>/xmpp-vala/src/module/xep/0048_conference.vala 
/<>/xmpp-vala/src/module/xep/0402_bookmarks2.vala 
/<>/xmpp-vala/src/module/xep/0004_data_forms.vala 
/<>/xmpp-vala/src/module/xep/0030_service_discovery/flag.vala 
/<>/xmpp-vala/src/module/xep/0030_service_discovery/identity.vala 
/<>/xmpp-vala/src/module/xep/0030_service_discovery/info_result.vala
 /<>/xmpp-vala/src/module/xep/0030_service_discovery/item.vala 
/<>/xmpp-vala/src/module/xep/0030_service_discovery/items_result.vala
 /<>/xmpp-vala/src/module/xep/0030_service_discovery/module.vala 
/<>/xmpp-vala/src/module/xep/0045_muc/flag.vala 
/<>/xmpp-vala/src/module/xep/0045_muc/module.vala 
/<>/xmpp-vala/src/module/xep/0045_muc/status_code.vala 
/<>/xmpp-vala/src/module/xep/0047_in_band_bytestreams.vala 
/<>/xmpp-vala/src/module/xep/0049_private_xml_storage.vala 
/<>/xmpp-vala/src/module/xep/0054_vcard/module.vala 
/<>/xmpp-vala/src/module/xep/0060_pubsub.vala 
/<>/xmpp-vala/src/module/xep/0065_socks5_bytestreams.vala 
/<>/xmpp-vala/src/module/xep/0066_out_of_band_data.vala 
/<>/xmpp-vala/src/module/xep/0077_in_band_registration.vala 
/<>/xmpp-vala/src/module/xep/0082_date_time_profiles.vala 
/<>/xmpp-vala/src/module/xep/0084_user_avatars.vala 
/<>/xmpp-vala/src/module/xep/0085_chat_state_notifications.vala 
/<>/xmpp-vala/src/module/xep/0115_entitiy_capabilities.vala 
/<>/xmpp-vala/src/module/xep/0166_jingle.vala 
/<>/xmpp-vala/src/module/xep/0184_message_delivery_receipts.vala 
/<>/xmpp-vala/src/module/xep/0191_blocking_command.vala 
/<>/xmpp-vala/src/module/xep/0198_stream_management.vala 
/<>/xmpp-vala/src/module/xep/0199_ping.vala 
/<>/xmpp-vala/src/module/xep/0203_delayed_delivery.vala 
/<>/xmpp-vala/src/module/xep/0234_jingle_file_transfer.vala 
/<>/xmpp-vala/src/module/xep/0260_jingle_socks5_bytestreams.vala 
/<>/xmpp-vala/src/module/xep/0261_jingle_in_band_bytestreams.vala 
/<>/xmpp-vala/src/module/xep/0280_message_carbons.vala 
/<>/xmpp-vala/src/module/xep/0308_last_message_correction.vala 
/<>/xmpp-vala/src/module/xep/0313_message_archive_management.vala 
/<>/xmpp-vala/src/module/xep/0333_chat_markers.vala 

Bug#968026: Depends need to be updated for the new libhinawa

2020-08-06 Thread Sebastien Bacher
Package: hinawa-utils
Version: 0.2.0-2

python3-hinawa-utils depends on gir1.2-hinawa-2.0 but the gir version
changed to 3.0 in the recent update
https://packages.qa.debian.org/libh/libhinawa/news/20200713T110020Z.html

Which means the package is not installable anymore



Bug#968025: iproute2: Cannot delete xfrm policy if `mark` is not preseent

2020-08-06 Thread bernardo
Package: iproute2
Version: 5.5.0-1ubuntu1
Severity: normal

Dear Maintainer,

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

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

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


-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.76-linuxkit (SMP w/4 CPU cores)
Kernel taint flags: TAINT_RANDSTRUCT
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages iproute2 depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  libbsd00.10.0-1
ii  libc6  2.31-0ubuntu9
ii  libcap21:2.32-1
ii  libcap2-bin1:2.32-1
ii  libdb5.3   5.3.28+dfsg1-0.6ubuntu2
ii  libelf10.176-1.1build1
ii  libmnl01.0.4-2
ii  libselinux13.0-1build2
ii  libxtables12   1.8.4-3ubuntu2

Versions of packages iproute2 recommends:
ii  libatm1  1:2.5.1-4

Versions of packages iproute2 suggests:
pn  iproute2-doc  

-- debconf information excluded



Bug#968024: netpbm-free: Unversioned Python removal in sid/bullseye

2020-08-06 Thread Andreas Beckmann
Source: netpbm-free
Version: 2:10.78.05-0.1
Severity: serious
User: debian-pyt...@lists.debian.org
Usertags: py2unversioned

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

We will keep some Python2 package as discussed in
https://lists.debian.org/debian-python/2020/07/msg00039.html
but removing the unversioned python packages python-minimal, python,
python-dev, python-dbg, python-doc.

Your package either build-depends, depends on one of those packages.
Please either convert these packages to Python3, or if that is not
possible, replaces the dependencies on the unversioned Python
packages with one of the python2 dependencies (python2, python2-dev,
python2-dbg, python2-doc).

Please check for dependencies, build dependencies AND autopkg tests.

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.



Bug#967997: rdiff-backup: maintainer address invalid

2020-08-06 Thread Otto Kekäläinen
While researching this I only found packages that list the old group email:

Maintainer: Python Applications Packaging Team

- 
https://salsa.debian.org/python-team/applications/nitrotool/-/blob/master/debian/control
- 
https://salsa.debian.org/python-team/applications/terminator/-/blob/debian/master/debian/control
- 
https://salsa.debian.org/python-team/applications/protonvpn-cli/-/blob/debian/master/debian/control
- 
https://salsa.debian.org/python-team/applications/pyflakes/-/blob/debian/master/debian/control
- 
https://salsa.debian.org/python-team/applications/gnome-authenticator/-/blob/debian/master/debian/control

This package does not list any group mailing list at all:
- 
https://salsa.debian.org/python-team/applications/commit-helper/-/blob/master/debian/control

I am not sure what to do here. Maybe just remove myself as uploader
and make myself the maintainer alone, but that is kind of semantically
wrong, since this is team maintained.



-- 
- Otto



Bug#968023: munin: Unversioned Python removal in sid/bullseye

2020-08-06 Thread Andreas Beckmann
Source: munin
Version: 2.999.14-1
Severity: serious
User: debian-pyt...@lists.debian.org
Usertags: py2unversioned

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

We will keep some Python2 package as discussed in
https://lists.debian.org/debian-python/2020/07/msg00039.html
but removing the unversioned python packages python-minimal, python,
python-dev, python-dbg, python-doc.

Your package either build-depends, depends on one of those packages.
Please either convert these packages to Python3, or if that is not
possible, replaces the dependencies on the unversioned Python
packages with one of the python2 dependencies (python2, python2-dev,
python2-dbg, python2-doc).

Please check for dependencies, build dependencies AND autopkg tests.

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.



Bug#966822: systemd: user-runtime-dir service crashes the kernel under SELinux

2020-08-06 Thread Michael Biebl
Control: reassign -1 src:linux
Control: found -1 5.7.10-1

Am 06.08.20 um 21:43 schrieb bauen1:
> Hi,
> 
> I've already reported this bug in the kernel audit system upstream, see 
> https://lore.kernel.org/linux-audit/20200723200041.7yinlklts47pz...@madcap2.tricolour.ca/T/#t
>  for details.
> 
> A revert (8ac68dc455d9d18241d44b96800d73229029ed34) of the commit that caused 
> this regression in 5.7 is already in 5.7.13 
> (https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.7.13) 
> 
> This bug should be reassigned to the kernel package.
> 

Thanks for this valuable information.

Reassigning accordingly and marking the current version in sid/bullseye
as affected.

Regards,
Michael



Bug#968022: sequitur-g2p: Unversioned Python removal in sid/bullseye

2020-08-06 Thread Andreas Beckmann
Source: sequitur-g2p
Version: 0+r1668.r3-1
Severity: serious
User: debian-pyt...@lists.debian.org
Usertags: py2unversioned

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

We will keep some Python2 package as discussed in
https://lists.debian.org/debian-python/2020/07/msg00039.html
but removing the unversioned python packages python-minimal, python,
python-dev, python-dbg, python-doc.

Your package either build-depends, depends on one of those packages.
Please either convert these packages to Python3, or if that is not
possible, replaces the dependencies on the unversioned Python
packages with one of the python2 dependencies (python2, python2-dev,
python2-dbg, python2-doc).

Please check for dependencies, build dependencies AND autopkg tests.

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.



Bug#968020: RM: lttv -- ROM; Dead upstream

2020-08-06 Thread Michael Jeanson
Package: ftp.debian.org
Severity: normal

Hi ftp-master,

Please remove src:lttv, it is unmaintained upstream, the last release
was in 2013. It's usefulness is very limited as it can't reliably open
traces produced with any currently maintained LTTng version.

Thanks,

Michael



Bug#959387: [Re] paraview-dev: missing cmake vtk modules in the dev package, cannot use

2020-08-06 Thread Jakob Meng
Found another problem with the ParaView source package in Debian Sid.
The Salsa GitLab Repo of ParaView has Git LFS Pointers, e.g. [1]. The
source tarball paraview_5.7.0.orig.tar.xz [2] that has been uploaded to
Debian Sid does not have the binary files but the raw Git LFS pointers
instead! For example, file
VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/tornado.vec in the source tarball is:

version https://git-lfs.github.com/spec/v1
oid sha256:dca8105bf888e67a9fe476a563d69ac708925aec519814fb520c6057e5ca0a1f
size 1327116

[1]
https://salsa.debian.org/science-team/paraview/-/tree/master/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data

[2]
http://deb.debian.org/debian/pool/main/p/paraview/paraview_5.7.0.orig.tar.xz




signature.asc
Description: OpenPGP digital signature


Bug#968019: enhanceio: Unversioned Python removal in sid/bullseye

2020-08-06 Thread Andreas Beckmann
Source: enhanceio
Version: 0+git20190417.5815670-1
Severity: serious
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2unversioned

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

We will keep some Python2 package as discussed in
https://lists.debian.org/debian-python/2020/07/msg00039.html
but removing the unversioned python packages python-minimal, python,
python-dev, python-dbg, python-doc.

Your package either build-depends, depends on one of those packages.
Please either convert these packages to Python3, or if that is not
possible, replaces the dependencies on the unversioned Python
packages with one of the python2 dependencies (python2, python2-dev,
python2-dbg, python2-doc).

Please check for dependencies, build dependencies AND autopkg tests.

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.



Bug#943302: zsnapd: Python2 removal in sid/bullseye

2020-08-06 Thread Andreas Beckmann
Followup-For: Bug #943302
Control: severity -1 serious

The unversioned python package is gone, making zsnapd B-D uninstallable.

Andreas



Bug#944148: RM: apachedex -- ROM; popcon=8

2020-08-06 Thread Andreas Beckmann
Control: clone -1 -2
Control: reopen -2
Control: retitle -2 RM: apachedex/experimental -- RoM; popcon=8

On Tue, 05 Nov 2019 14:16:08 +0900 Arnaud Fontaine  wrote:
> Considering the very low popcon and that I don't have time to maintain it
> anymore, I think it is better to remove this package from the archive. I

Removal from sid has happenend some time ago.
I assume the same removal reasons hold for the package in experimental
and have cloned the bug accordingly.


Andreas

PS: apachedex/experimental FTBFS since the removal of the unversioned
python package



Bug#964637: [Pkg-javascript-devel] Bug#964637: node-rollup: FTBFS: dh_auto_build: error: cd ./. && sh -ex debian/nodejs/./build returned exit code 1

2020-08-06 Thread Xavier
Le 06/08/2020 à 20:51, Xavier a écrit :
> Control: reassign -1 node-typescript-types
> 
> FTBFS is due to @types/node which was upgraded to version 14.0.14 while
> we run nodejs 12

It's time to move @types/node from src:typescript-types to src:nodejs



Bug#957360: RFS: Bug#957360: insighttoolkit4: ftbfs with GCC-10

2020-08-06 Thread Étienne Mollier
Control: tag -1 pending

Good day,

This night's build of insighttoolkit 4.13.3 in the clean chroot
went through, and test suite validated without particular
issues.  I pushed the part of my work fixing #957360 on Salsa:

https://salsa.debian.org/med-team/insighttoolkit

As is, it may not be lintian clean, but I only managed to start
a gbp run only a few moments ago, so will have the .dsc to
scan against tomorrow.

If someone else attempts a run with git buildpackage, note the
external data fetched by debian/rules get-orig-source, which
need to be put into an appropriate archive .orig-data.tar.gz;
something specific to format 3.0 (quilt) if I understood
correctly dpkg-source(1).  I'm not comfortable with this format,
so haven't marked the release as ready for upload yet, by fear
of having screwed the branch named "upstream", but maybe it is.

Kind Regards,
-- 
Étienne Mollier 
Old rsa/3072: 5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
New rsa/4096: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, please excuse my verbosity.


signature.asc
Description: PGP signature


Bug#964637: node-rollup: FTBFS: dh_auto_build: error: cd ./. && sh -ex debian/nodejs/./build returned exit code 1

2020-08-06 Thread Xavier
Control: reassign -1 node-typescript-types

FTBFS is due to @types/node which was upgraded to version 14.0.14 while
we run nodejs 12



Bug#968016: ITP: sudoku-solver -- sudoku puzzles solver

2020-08-06 Thread Fabio Augusto De Muzio Tobich
Package: wnpp
Severity: wishlist
Owner: Fabio Augusto De Muzio Tobich 
X-Debbugs-Cc: debian-de...@lists.debian.org, ftob...@gmail.com

* Package name: sudoku-solver
  Version : 1.0.0
  Upstream Author : DanSoft 
* URL : https://bitbucket.org/admsasha/sudoku-solver
* License : GPL3+
  Programming Lang: C++
  Description : sudoku puzzles solver

Sudoku solver that contains several logical resolution methods, as well as
brute force selection.



Bug#967546: udev: missing /dev/stdin etc.

2020-08-06 Thread Harald Jenny
Dear Jakub,

I experience the same problem, maybe the systemd maintainers could add
some lines to the init script to create the missing symlinks again?

Kind regards
Harald Jenny



Bug#960120: different error during build

2020-08-06 Thread Paolo Greppi
With this build:
https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/915568#L2420

I get a different error while building:
[17:58:12] Starting 'build'...
2420[17:58:13] Error: [BABEL] 
/builds/js-team/node-yarnpkg/debian/output/node-yarnpkg-1.22.4/src/api.js: 
Cannot find module 'babel-plugin-transform-strict-mode'

?

Paolo



Bug#968014: systemd 246 postinst script should restart systemd-logind.service

2020-08-06 Thread Michael Biebl
Am 06.08.20 um 19:41 schrieb Zygmunt Krynicki:
>> Unfortunately logind can't be restarted safely. Xorg (and Wayland) still
>> don't handle that properly and crash.
>> If you want to pursue getting those fixed, this would be very much
>> welcome. Otherwise I can't really do anything about that in systemd.
> 
> I see, this is quite unfortunate.
> 
> Could the postinst script refer the current set of blocking issues?
> 
> Could the postinst script restart logind if neither X nor wayland is 
> employed? 

I'm uncertain how to safely detect this. This would need someone testing
the various desktop environments / Xorg / Wayland compositors / display
managers *and* keep that list up to date.

In my configuration it is really affecting CI systems that are all headless.

I guess in your case you can simply automate the restart of logind on
systemd upgrades.




signature.asc
Description: OpenPGP digital signature


Bug#968015: resolvconf-pull-resolved.service fails with systemd 246-2

2020-08-06 Thread Thomas Mühlbacher
Package: resolvconf
Version: 1.82

Since `systemd` version 246-2, systems using `systemd-resolved` fail to
reach the `default.target` if `resolvconf` is also installed.

Steps to reproduce the error in a sysroot (`less` and `bash-completion`
are just for comfort in debugging/reading logs):

```shell
# debootstrap --variant minbase sid sid
# systemd-nspawn --directory sid
# apt update
# apt install resolvconf systemd less bash-completion
# systemctl enable systemd-networkd
# systemctl enable systemd-resolved
# exit
# systemd-nspawn --directory sid --boot
```

With the last command `init` will try to start
`resolvconf-pull-resolved.service` endlessly and not reach the
`default.target`. At this point, you may no longer be able to read
`systemd-nspawn`'s info in your terminal so keep in mind:

> Press ^] three times within 1s to kill container.

The error messages:

```
...
[FAILED] Failed to start resolvconf-pull-resolved.service.
See 'systemctl status resolvconf-pull-resolved.service' for details.
[FAILED] Failed to start resolvconf-pull-resolved.service.
See 'systemctl status resolvconf-pull-resolved.service' for details.
[FAILED] Failed to start resolvconf-pull-resolved.service.
See 'systemctl status resolvconf-pull-resolved.service' for details.
[FAILED] Failed to start resolvconf-pull-resolved.service.
See 'systemctl status resolvconf-pull-resolved.service' for details.
[FAILED] Failed to start resolvconf-pull-resolved.service.
See 'systemctl status resolvconf-pull-resolved.service' for details.
[FAILED] Failed to start resolvconf-pull-resolved.service.
See 'systemctl status resolvconf-pull-resolved.service' for details.
...
```

This also happens on physical machines, leaving some of mine unbootable
currently. :(

Unfortunately I am not completely sure why the service fails as I am not
familiar enough with it.

This is my first Debian bug report so I hope I did it correctly. Should
this bug somehow tag the Debian systemd team as well, since technically
an update to the `systemd` package introduced it?

A solution may be to just not install `resolvconf` but it's in the
`Recommends` of a lot of other packages so it will be installed on many
systems that might use `resolved`, which is already a part of the
`systemd` package.

Cheers,
Thomas Mühlbacher



Bug#968014: systemd 246 postinst script should restart systemd-logind.service

2020-08-06 Thread Zygmunt Krynicki
> Unfortunately logind can't be restarted safely. Xorg (and Wayland) still
> don't handle that properly and crash.
> If you want to pursue getting those fixed, this would be very much
> welcome. Otherwise I can't really do anything about that in systemd.

I see, this is quite unfortunate.

Could the postinst script refer the current set of blocking issues?

Could the postinst script restart logind if neither X nor wayland is employed? 
In my configuration it is really affecting CI systems that are all headless.

Best regards
ZK



Bug#968014: systemd 246 postinst script should restart systemd-logind.service

2020-08-06 Thread Michael Biebl
Control: forcemerge 919509 -1

Am 06.08.20 um 19:35 schrieb Zygmunt Krynicki:
> Package: systemd
> Version: 246-2
> 
> Updating systemd to 246-2 leaves systemd-logind.service from 245-* which 
> breaks certain operations. 
> 
> One such example is, (assuming user foo): loginctl enable-linger foo. Without 
> restarting systemd-logind.service this command fails with the following error:
> 
> Aug 06 17:08:06 aug061652-827018 systemd-user-runtime-dir[28557]: Failed to 
> acquire number of inodes for runtime directory: Unknown interface 
> org.freedesktop.login1.Manager or property RuntimeDirectoryInodesMax.
> 
> Looking at the systemd.postinst script I can see that systemd-logind is not 
> restarted on purpose, referencing upstream systemd bug 
> https://github.com/systemd/systemd/issues/1163. This bug is closed now so I 
> suspect the proper action is to simply restart systemd-logind.service. I've 
> attached a crude patch with that change.
> 

Duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919509
btw. Merging accordingly.

Regarding,
Michael



signature.asc
Description: OpenPGP digital signature


Bug#966519: RM: pysal -- ROM; Unmaintained

2020-08-06 Thread Sebastiaan Couwenberg
Control: tags -1 - moreinfo

On 8/6/20 7:23 PM, Sean Whitton wrote:
> On Thu 30 Jul 2020 at 05:51AM +02, Bas Couwenberg wrote:
>> Please remove pysal from the archive,
>> it is unmaintained and has a low popcon score.
> 
> popcon is not low and there are no open bugs?

11 votes is low.

No one has stepped up to package the many projects PySAL upstream has
split into, so it should be removed instead of remaining stuck at an
outdated version indefinitely.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



signature.asc
Description: OpenPGP digital signature


Bug#968014: systemd 246 postinst script should restart systemd-logind.service

2020-08-06 Thread Michael Biebl
Am 06.08.20 um 19:35 schrieb Zygmunt Krynicki:
> Package: systemd
> Version: 246-2
> 
> Updating systemd to 246-2 leaves systemd-logind.service from 245-* which 
> breaks certain operations. 
> 
> One such example is, (assuming user foo): loginctl enable-linger foo. Without 
> restarting systemd-logind.service this command fails with the following error:
> 
> Aug 06 17:08:06 aug061652-827018 systemd-user-runtime-dir[28557]: Failed to 
> acquire number of inodes for runtime directory: Unknown interface 
> org.freedesktop.login1.Manager or property RuntimeDirectoryInodesMax.
> 
> Looking at the systemd.postinst script I can see that systemd-logind is not 
> restarted on purpose, referencing upstream systemd bug 
> https://github.com/systemd/systemd/issues/1163. This bug is closed now so I 
> suspect the proper action is to simply restart systemd-logind.service. I've 
> attached a crude patch with that change.
> 

Unfortunately logind can't be restarted safely. Xorg (and Wayland) still
don't handle that properly and crash.
If you want to pursue getting those fixed, this would be very much
welcome. Otherwise I can't really do anything about that in systemd.

Regards,
Michael




signature.asc
Description: OpenPGP digital signature


Bug#968014: systemd 246 postinst script should restart systemd-logind.service

2020-08-06 Thread Zygmunt Krynicki
Package: systemd
Version: 246-2

Updating systemd to 246-2 leaves systemd-logind.service from 245-* which breaks 
certain operations. 

One such example is, (assuming user foo): loginctl enable-linger foo. Without 
restarting systemd-logind.service this command fails with the following error:

Aug 06 17:08:06 aug061652-827018 systemd-user-runtime-dir[28557]: Failed to 
acquire number of inodes for runtime directory: Unknown interface 
org.freedesktop.login1.Manager or property RuntimeDirectoryInodesMax.

Looking at the systemd.postinst script I can see that systemd-logind is not 
restarted on purpose, referencing upstream systemd bug 
https://github.com/systemd/systemd/issues/1163. This bug is closed now so I 
suspect the proper action is to simply restart systemd-logind.service. I've 
attached a crude patch with that change.
--- /var/lib/dpkg/info/systemd.postinst	2020-08-03 09:46:27.0 +0200
+++ systemd.postinst	2020-08-06 19:33:31.845505560 +0200
@@ -114,8 +114,7 @@
 
 if [ -n "$2" ]; then
 _systemctl daemon-reexec || true
-# don't restart logind; this can be done again once this gets implemented:
-# https://github.com/systemd/systemd/issues/1163
+_systemctl try-restart systemd-logind.service || true
 _systemctl try-restart systemd-networkd.service || true
 _systemctl try-restart systemd-resolved.service || true
 _systemctl try-restart systemd-journald.service || true


Bug#920555: xmobar: compile flag with_alsa to support Volume command

2020-08-06 Thread rharwood
Package: xmobar
Version: 0.33-1
Followup-For: Bug #920555

Users looking for a non-polling solution to ALSA volume may be able to adapt
my script for it:

#!/usr/bin/python3

import re
import subprocess
import sys

r = re.compile(r"\[(\d+)%\].*\[(on|off)\]$")

args = "stdbuf -oL alsactl monitor".split()
p = subprocess.Popen(args, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
while True:
data = subprocess.check_output(["amixer", "get", "Master"])
vline = data.rsplit(b"\n", 2)[-2].decode("utf-8")

m = r.search(vline)
assert(m)
vol = m.group(1)
onoff = m.group(2)
muted = "%" if onoff == "on" else "M"

sys.stdout.write(f"({vol}{muted})\n")
sys.stdout.flush()

p.stdout.readline() # type: ignore

Thanks,
--Robbie



Bug#967053: RM: pynifti -- RoQA; Replaced by nibabel, Python 2

2020-08-06 Thread Sean Whitton
Hello,

On Mon 03 Aug 2020 at 07:07PM +02, Moritz Muehlenhoff wrote:

> Package: ftp.debian.org
> Severity: normal
>
> Please remove pynifti. It depends on Python 2 and has been replaced
> by nibabel. Acked by the maintainers in #937490.

Looks like I already removed it last month!

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#966598: RM: sgabios -- RoQA; swallowed by the only user (qemu)

2020-08-06 Thread Sean Whitton
control: tag -1 + moreinfo

Hello,

On Fri 31 Jul 2020 at 11:34AM +03, Michael Tokarev wrote:

> Package: ftp.debian.org
> Severity: normal
>
> Package sgabios provides a variant of x86 BIOS/firmware. It was
> only used by qemu system emulation in Debian. The upstream development
> stopped many years ago, and now it is maintained within the only its
> user, qemu, and is built from qemu sources too (qemu-system-data
> package, /usr/share/qemu/sgabios.bin). Package sgabios is not useful
> by its own.
>
> While it does not really hurt, I guess, to keep this package in the
> archive, I also don't see a reason for that.
>
> sgabios has rather high numbers on the popcon data.  This is because
> it's been suggested by qemu for quite some time.
>
> Also this package is in Depends: of libguestfs0. This is okay, since
> qemu-system-data provides sgabios (and conflicts with it), so the
> dependency is satisfied by qemu-system-data which is a required
> dependency of qemu-system-x86 anyway. I filed a bugreport for
> libguestfs0 to remove the explicit dependency on sgabios, which
> is #966596 , but it is completely optional due to this Provides.

Please remove the moreinfo tag when this rdep is gone.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#966519: RM: pysal -- ROM; Unmaintained

2020-08-06 Thread Sean Whitton
control: tag -1 + moreinfo

Hello,

On Thu 30 Jul 2020 at 05:51AM +02, Bas Couwenberg wrote:

> Package: ftp.debian.org
> Severity: normal
> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
>
> Please remove pysal from the archive,
> it is unmaintained and has a low popcon score.

popcon is not low and there are no open bugs?

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#885265: [py3] some fixes to get chirpw running with python3, Fixes #7431

2020-08-06 Thread Arturo Borrero Gonzalez
Hi there!

I tested chirp from the upstream mercurial repository (py3 branch) today in
Debian testing bullseye, and I got it working with python3 with the attached 
patch.

I was able to download the image from a baofeng UV-5RA, modify it and the upload
it again.

Please, consider merging the attached patch. If the patch requires any mangling
please do so yourself, I'm on vacations and I don't plan to follow-up on this.

regards.
# HG changeset patch
# User Arturo Borrero Gonzalez 
# Date 1596733882 -7200
#  Thu Aug 06 19:11:22 2020 +0200
# Branch py3
# Node ID 16906193cd4089786be642ce0af684a72e29cae9
# Parent  68534f20c1418ae8e4cc09f3ff468d0375ba843a
[py3] some fixes to get chirpw running with python3, Fixes #7431

This patch contains a couple of small changes to get chirpw running with
python3.

Signed-off-by: Arturo Borrero Gonzalez 

diff -r 68534f20c141 -r 16906193cd40 chirp/drivers/uv5r.py
--- a/chirp/drivers/uv5r.py	Thu Feb 13 16:35:52 2020 -0800
+++ b/chirp/drivers/uv5r.py	Thu Aug 06 19:11:22 2020 +0200
@@ -587,7 +587,7 @@
 data += _read_block(radio, i, 0x40, False)
 
 if append_model:
-data += radio.MODEL.ljust(8)
+data += bytes(radio.MODEL.ljust(8), 'utf-8')
 
 LOG.debug("done.")
 return memmap.MemoryMapBytes(data)
diff -r 68534f20c141 -r 16906193cd40 chirp/drivers/vx6.py
--- a/chirp/drivers/vx6.py	Thu Feb 13 16:35:52 2020 -0800
+++ b/chirp/drivers/vx6.py	Thu Aug 06 19:11:22 2020 +0200
@@ -871,5 +871,5 @@
 elif setting == "password":
 newval = self._encode_chars(newval, 4)
 setattr(_settings, setting, newval)
-except Exception, e:
+except:
 raise
diff -r 68534f20c141 -r 16906193cd40 chirp/ui/mainapp.py
--- a/chirp/ui/mainapp.py	Thu Feb 13 16:35:52 2020 -0800
+++ b/chirp/ui/mainapp.py	Thu Aug 06 19:11:22 2020 +0200
@@ -1137,7 +1137,7 @@
 
 query = "http://chirp.danplanet.com/query/rb/1.0/app_direct; \
 "?loc=%s=%s=%s" % (loc, band, dist)
-print query
+print(query)
 
 # Do this in case the import process is going to take a while
 # to make sure we process events leading up to this


Bug#968012: sjaakii: variant "judkins" has incomplete FEN, does not load properly in XBoard

2020-08-06 Thread ydirson
Package: sjaakii
Version: 1.4.1-2
Tags: patch
X-Debbugs-CC: Evert Glebbeek 

This change is necessary to avoid undefined behaviour from XBoard (which in this
cases ignores the last rook, leading to wrong initial position)

--- /tmp/variants.txt   2020-08-06 19:07:29.331235206 +0200
+++ /usr/share/games/sjaakii/variants.txt   2020-08-06 19:08:05.711475456 
+0200
@@ -1052,7 +1052,7 @@
 ##
 Variant: Judkins' Shogi (6x6)
 Board: 6x6
-FEN: "rbnsgk/5p/6/6/P5/KGSNBR"
+FEN: "rbnsgk/5p/6/6/P5/KGSNBR w 0 1"
 XBoard pieces: "PNBR.S...G..+Kpnbr.s...g..+k"
 XBoard parent: "shogi"
 Zone: white_promotion = a5,b5,c5,d5,e5,f5,a6,b6,c6,d6,e6,f6



Bug#968013: swi-prolog: time bomb in swi-prolog-test, and failing autopkgtest

2020-08-06 Thread Julien Cristau
Package: swi-prolog
Severity: serious
X-Debbugs-Cc: jcris...@debian.org

Hi,

swi-prolog autopkgtests are currently failing:
https://ci.debian.net/data/autopkgtest/testing/amd64/s/swi-prolog/6535300/log.gz

>From what I can tell, there's a step in the build process to generate
test certs, which are then shipped in the swi-prolog-test package.
Among those files is rootCA-crl.pem which is valid for 30 days, so
running the tests more than 30 days after the package was built fails.
I guess the certs should be generated as part of the test procedure
instead.

Cheers,
Julien



Bug#968010: Aw: Bug#968010: Acknowledgement (dma: SEGFAULT when configuration file can't be read (permission denied))

2020-08-06 Thread Ulrich Wegener
Hello,
 
as a little follow-up:
 
Changing util.c as per 
https://github.com/corecode/dma/commit/9fa38db89b3813394ea07dd852f9270109dcbdb4 
(i.e. adding 
#include 
#include 
)

fixes this problem:

/usr/local/sbin$ ./dma
dma: can not open config `/etc/dma/dma.conf': Permission denied


Best regards
 

Gesendet: Donnerstag, 06. August 2020 um 18:21 Uhr
Von: "Debian Bug Tracking System" 
An: "Ulrich Wegener" 
Betreff: Bug#968010: Acknowledgement (dma: SEGFAULT when configuration file 
can't be read (permission denied))
Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 968010: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968010[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968010].

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
Arno Töll 

If you wish to submit further information on this problem, please
send it to 968...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

--
968010: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968010[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968010]
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#965282: wpasupplicant: fails to create /var/run/wpa_supplicant control interface in Debian 10

2020-08-06 Thread APT Gatuno MX

close 965282
thanks

The bug is not in Debian packaging, so I'm closing this bug.

--
Atte. Félix Arreola
«Sin firma GPG»



Bug#968009: Warn that there is no point of installing this package if using systemd

2020-08-06 Thread 積丹尼 Dan Jacobson
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967906#10
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967906#32
seem to indicate one doesn't need both packages.

I'm guessing that all Debian systems that have been around for 10 years
will probably have both packages installed.

But the newest Debian systems won't.

Can I safely remove resolvconf?



Bug#881075: Update

2020-08-06 Thread Ryan Pavlik
I'd be willing to look into updating this package, as long as the
maintainer has no objection. It would be helpful if the git repo of
packaging were available (see https://bugs.debian.org/928335 ), though
failing that I could just use dgit.

Ryan



Bug#968011: lintian: Stop shipping modules in system path

2020-08-06 Thread Felix Lechner
Package: lintian
Severity: normal
Control: block -1 by 968000

Hi,

Some modules were kept in Perl's system path because they are used by
libconfig-model-dpkg-perl. A bug with some suggestions was filed in
Bug#968000. The Perl packaging team is working hard to resolve the
other bug, which blocks this one.

The affected Lintian modules are presently shipped in two locations.
This is a reminder to remove the duplicate files. The line
'lib/Lintian usr/share/perl5' should then be dropped from
d/lintian.install.

Aside from the other bug, more information may be available in commits
818b3aad and 0df1a8ed.

Kind regards
Felix Lechner



Bug#968009: Warn that there is no point of installing this package if using systemd

2020-08-06 Thread Andrej Shadura
Control: tag -1 moreinfo

Hi,

On Thu, 6 Aug 2020, at 17:57, 積丹尼 Dan Jacobson wrote:
> Package: resolvconf
> Version: 1.82
> 
> Apparently there is no point in installing this package if one has
> systemd installed(?) So at least the package Description should warn so.

Sorry, I don't understand the point you're trying to make. I use both systemd 
and resolving and I'm not aware of any issues.

-- 
Cheers,
  Andrej



Bug#966416: RM: argyll -- ROM; RC-buggy; abandoned upstream

2020-08-06 Thread Sean Whitton
control: tag -1 + moreinfo

Hello Jörg,

On Tue 28 Jul 2020 at 12:10PM +02, Jörg Frings-Fürst wrote:

> argyll is RC-buggy with no responce from upstream since
> more then 6 month.

Would you mind confirming that the latest upstream release, which isn't
packaged, doesn't build with gcc-10 either?

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#968010: dma: SEGFAULT when configuration file can't be read (permission denied)

2020-08-06 Thread Ulrich Wegener
Package: dma
Version: 0.11-1+deb10u1
Severity: normal

Dear Maintainer,
   * What led up to the situation?

Consider the following situation:
ls -l /etc/dma
total 8
-rw-r- 1 root mail  186 Jul 29  2019 auth.conf
-rw-r- 1 root root 2445 Aug  5 23:09 dma.conf

/etc/dma/dma.conf is not readable by dma which runs under group mail (setgid). 
(This was intitially caused by moving a backup file into place without checking 
the permissions)

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

Invoke dma as non-root-user (e.g. some cronjob):
dma -t
or
sendmail -t

the -t argument is optional, it crashes without it as well.

   * What was the outcome of this action?

SEGFAULT: (below is a backtrace after rebuilding the package to keep the debug 
symbols)

$ which dma
/usr/sbin/dma
$ gdb dma
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from dma...done.
(gdb) run -t
Starting program: /usr/sbin/dma -t
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
65  ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
(gdb) bt
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
#1  0x7fcdcde919ef in _IO_vfprintf_internal (s=0x7fff03cf01c0, 
format=0x55e7adb58bd0 "%s: %s: %s\n", ap=0x7fff03cf2880)
at vfprintf.c:1638
#2  0x7fcdcde92866 in buffered_vfprintf (s=s@entry=0x7fcdcdffc680 
<_IO_2_1_stderr_>,
format=format@entry=0x55e7adb58bd0 "%s: %s: %s\n", 
args=args@entry=0x7fff03cf2880) at vfprintf.c:2322
#3  0x7fcdcde8feb2 in _IO_vfprintf_internal (s=0x7fcdcdffc680 
<_IO_2_1_stderr_>, format=0x55e7adb58bd0 "%s: %s: %s\n",
ap=ap@entry=0x7fff03cf2880) at vfprintf.c:1296
#4  0x7fcdcde98534 in __fprintf (stream=, format=) at fprintf.c:32
#5  0x55e7adb558e2 in errlog (exitcode=66, fmt=0x55e7adb5772f "can not open 
config `%s'") at util.c:155
#6  0x55e7adb4e7f8 in parse_conf (config_path=0x55e7adb57d8f 
"/etc/dma/dma.conf") at conf.c:162
#7  0x55e7adb506dc in main (argc=0, argv=0x7fff03cf3598) at dma.c:575

   * What outcome did you expect instead?

A clean exit. DMA built by source ( 
https://github.com/corecode/dma/archive/v0.13.tar.gz ) cleanly exits in the 
same situation:

/usr/local/sbin/dma
dma: can not open config `/etc/dma/dma.conf': Permission denied

-- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-10-cloud-amd64 (SMP w/1 CPU core)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dma depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libssl1.1  1.1.1d-0+deb10u3
ii  ucf3.0038+nmu1
dma recommends no packages.
dma suggests no packages.
-- Configuration Files:
/etc/dma/auth.conf [Errno 13] Permission denied: '/etc/dma/auth.conf'
-- debconf information:
* dma/mailname: instance-1.us-central1-a.c.orbital-bee-258421.internal
* dma/relayhost:



Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way

2020-08-06 Thread Felix Lechner
Hi Dominique,

On Thu, Aug 6, 2020 at 8:10 AM Dominique Dumont  wrote:
>
> Please wait until the next release of libconfig-model-dpkg-perl.

No rush, please. We will keep shipping the modules until you close
this bug. Thank you!

Kind regards
Felix Lechner



Bug#967970: redis-server crashes with jemalloc error if activedefrag is enabled

2020-08-06 Thread Matthew Hall
On Thu, Aug 06, 2020 at 03:00:06PM -, Chris Lamb wrote:
> Thanks for the heads-up; I don't subscribe to Redis bugs filed against
> Ubuntu. So, for completeness, I can "reproduce" this in Debian:

Thanks for confirming, I was able to get the same behavior when I tried it on 
your latest Debian source package, hence why I felt reasonably comfortable it 
applied to both distributions.

> I use the term "reproduce" in square quotes here because I am not
> entirely sure why you are surprised by this error -- we deliberately
> do not use the bundled version of jemalloc in Debian so we can use the
>  system one as per the general policy about avoiding embedded code
> copies.

I am curious: where did I say I was surprised by the behavior? I've used 
Debian (or Ubuntu derivatives) since about 1997 and I am aware of and strongly 
support the general policy.

But at the same time, I wanted to be sure the community was made aware of it 
if they were setting up the service and expected the feature to work, and 
advise that at least a base config file comment about it could be a good idea 
if everybody decides not to fix it.

> The only solutions would appear to be either (a) revert to using the
> bundled jemalloc version (which would require a stronger case at this
> point), or (b) ask upstream to merge this fragmentation support into
> upstream jemalloc.

I think this analysis is probably correct, depending on the estimated 
importance of the feature.

If you could provide some advice, of the right way to temporarily disable the 
USE_SYSTEM_JEMALLOC patch, for building a one-off Debian package of the 
redis-server where defrag would be able to operate, probably that's good 
enough so that somebody would see it in the public historical record if they 
run into this later.

> What am I missing here? I might be missing something ...

I think you got it right.

> I don't completely understand your remarks about the JEMALLOC_FRAG_HINT 
> define.

Sorry, I was pretty tired when I wrote it, as I found it late in a 16 hour day 
of coding something else which had redis-server as a dependency, and took a 
break to debug it and report it in an effort to give back to the community at 
least a little bit, after I found it was apparently not seen before online in 
my search engine results.

> Indeed, the code that surrounds it in zmalloc.h appears to
> perfectly describe the trade-off being made:
> 
>  73 /* We can enable the Redis defrag capabilities only if we are using 
> Jemalloc
>  74  * and the version used is our special version modified for Redis having
>  75  * the ability to return per-allocation fragmentation hints. */
>  76 #if defined(USE_JEMALLOC) && defined(JEMALLOC_FRAG_HINT)
>  77 #define HAVE_DEFRAG
>  78 #endif

True, but that's a good few layers deep, so I was trying to give it a bit more 
exposure for the next user, whoever that might be.

Thanks for your prompt reply and analysis, and for maintaining the package.

Matthew.



Bug#964446: sane-airscan stuck in NEW

2020-08-06 Thread Didier 'OdyX' Raboud
Le mercredi, 5 août 2020, 14.02:12 h CEST Alexander Pevzner a écrit :
> Hi Till, OdyX, Zdenek,
> 
> I've just created the new 0.99.12 release, and I highly recommend to
> upgrade existent packaging.

https://salsa.debian.org/printing-team/sane-airscan/-/commit/
182f0f4da433bcb0b21c39cfefb30270eb0b4fd7

Uploaded 0.99.12 to unstable, hence to NEW.

Cheers,
OdyX

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


Bug#968009: Warn that there is no point of installing this package if using systemd

2020-08-06 Thread 積丹尼 Dan Jacobson
Package: resolvconf
Version: 1.82

Apparently there is no point in installing this package if one has
systemd installed(?) So at least the package Description should warn so.



Bug#967226: Clarification

2020-08-06 Thread Chris Lamb
Vasyl,

> Then I can happily trigger the rebuild & salsa push without doing
> additional overrides?

Sure. Or rather: you should always be able to push to 'your' salsa
repositories to trigger a rebuild there. (That is entirely disconnected
from FTP-master autorejects.)


Regards,

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



Bug#967226: Clarification

2020-08-06 Thread Vasyl Gello
Hi Chris!

Thanks for clarification!
Then I can happily trigger the rebuild & salsa push without doing additional 
overrides?
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

signature.asc
Description: PGP signature


Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way

2020-08-06 Thread Dominique Dumont
On jeudi 6 août 2020 16:56:17 CEST you wrote:
> I figured. How about depending on debian-policy and using the
> information in its changelog?

Actually, I could use rmadison to get the latest version of debian-policy 
without installing this package (like rmadison is used to get the version of 
packages in unstable and older releases)



Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way

2020-08-06 Thread Dominique Dumont
On jeudi 6 août 2020 16:11:22 CEST you wrote:
> Unless you advise otherwise, Lintian will stop shipping the modules in
> the system path in the next release.

Please wait until the next release of libconfig-model-dpkg-perl.

All the best



Bug#967953: ifupdown2

2020-08-06 Thread Julien Fortin
Hi Christoph,


On Thu, Aug 6, 2020 at 12:27 PM Christoph Egger  wrote:
>
> Hi
>
> > We are now looking for a new debian sponsor to upload our latest
> > version to the debian repository.
>
> I guess I can help there for now but better don't rely on me for long-term
> sponsoring. What exactly would you want uploaded? Do you have the package
> somewhere? or github HEAD?

It would be awesome if you could help us out with this new release
(https://packages.debian.org/sid/ifupdown2).
We want to upload ifupdown2 3.0: it adds python3 support, new features
and fixes a bunch of bugs

The package is available on github, master branch:
http://github.com/CumulusNetworks/ifupdown2/

git clone https://github.com/CumulusNetworks/ifupdown2.git -b master

git tag 3.0.0-1

ifupdown2 (3.0.0-1) unstable; urgency=medium

   * New: python3 support
   * New: attribute alias support
   * New: bridge-always-up attribute
   * New: set bridge mtu with policy default
   * New: ES bond with "es-sys-mac" attribute
   * New: vxlan attribute: vxlan-mcastgrp-map
   * New: support for "veth-peer-name" attribute
   * New: dhcp policy: dhclient_retry_on_failure
   * New: support for marking interfaces as mgmt interfaces
   * New: bridge-vlan-vni-map attribute (single vxlan device)
   * New: dhcp: skipping dhcp configuration if link-down yes
   * New: vrf-slave: keep vlan down if lower device has "link-down yes"
   * New: vxlan: support for vxlan-svcnodeip6 and vxlan-mcastgrp6 (fixes #43)
   * New: support for add ovs-ports-condone-regex attribute (openvswitch)
   * Fix: dry-run exceptions
   * Fix: bond enslavement ordering
   * Fix: process MTU before addrgen
   * Fix: set bridge MTU after bridge creation
   * Fix: ifquery-running: incorrect displayed data
   * Fix: tunnel configuration compatibility with ifupdown1
   * Fix: start-networking script is back to handle mgmt & hotplug cases
   * Fix: devices matching with ".{0,13}\-v" could get removed by ifreload
   * Fix: mstpctl: check mstpctl-stp and bridge-stp and fix bridge cache update
   * Removing python-argcomplete dependency

 -- Julien Fortin   Tue, 04 Aug 2020 23:42:42 +0200

Let me know if that's all good and can proceed with the upload.

Best regards
Julien

>
> Christoph



Bug#967226: Clarification

2020-08-06 Thread Chris Lamb
Vasyl,

> Just wanted to ask if this behaviour prevents the acception of new 
> packages by FTP team's lintian check pass.

According to:

  https://ftp-master.debian.org/static/lintian.tags

... the "redundant-globbing-patterns" tag is not an autoreject-able
tag. So, no, there no need to wait.


Regards,

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



Bug#967970: redis-server crashes with jemalloc error if activedefrag is enabled

2020-08-06 Thread Chris Lamb
tags 967970 + moreinfo
thanks

Hi Matthew,

> I also filed this here. The error received and the reason why are different on
> Ubuntu and Debian, so the solution might be similar or it might be different.
> So, I am just trying to be complete / comprehensive.

Thanks for the heads-up; I don't subscribe to Redis bugs filed against
Ubuntu. So, for completeness, I can "reproduce" this in Debian:

Aug 06 12:42:10 tinycat systemd[1]: Starting Advanced key-value store...
Aug 06 12:42:10 tinycat redis-server[2682431]: *** FATAL CONFIG FILE ERROR 
(Redis 6.0.6) ***
Aug 06 12:42:10 tinycat redis-server[2682431]: Reading the configuration file, 
at line 1783
Aug 06 12:42:10 tinycat redis-server[2682431]: >>> 'activedefrag yes'
Aug 06 12:42:10 tinycat redis-server[2682431]: Active defragmentation cannot be 
enabled: it requires a Redis server compiled with a modified Jemalloc like the 
one shipped by default with the Redis source distribution
Aug 06 12:42:10 tinycat systemd[1]: redis-server.service: Control process 
exited, code=exited, status=1/FAILURE

I use the term "reproduce" in square quotes here because I am not
entirely sure why you are surprised by this error -- we deliberately
do not use the bundled version of jemalloc in Debian so we can use the
 system one as per the general policy about avoiding embedded code
copies.

The only solutions would appear to be either (a) revert to using the
bundled jemalloc version (which would require a stronger case at this
point), or (b) ask upstream to merge this fragmentation support into
upstream jemalloc.

What am I missing here? I might be missing something as I don't
completely understand your remarks about the JEMALLOC_FRAG_HINT
define. Indeed, the code that surrounds it in zmalloc.h appears to
perfectly describe the trade-off being made:

 73 /* We can enable the Redis defrag capabilities only if we are using Jemalloc
 74  * and the version used is our special version modified for Redis having
 75  * the ability to return per-allocation fragmentation hints. */
 76 #if defined(USE_JEMALLOC) && defined(JEMALLOC_FRAG_HINT)
 77 #define HAVE_DEFRAG
 78 #endif


Regards,

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



Bug#963737: ilias...@debian.org

2020-08-06 Thread Ilias Tsitsimpis
On Thu, Aug 06, 2020 at 11:42AM, peter green wrote:
> hi, highlighting-kate was just removed from testing at your request, but
> carettah still build-depends on it in both testing and
> unstable.
> 
> Should I go ahead and file a rc bug against carettah

Good catch. I open an RC bug against carettah (#968008).

Thanks,

-- 
Ilias



Bug#968008: carettah: Removal notice: unmaintained

2020-08-06 Thread Ilias Tsitsimpis
Package: carettah
Version: 0.5.1-2
Severity: grave
Justification: renders package unusable

This package appears to be unmaintained (last upstream upload in 2016).
It depends on deprecated software (gtk2 #967282 and highlighting-kate
#963737), is not part of Stackage and has no rev dependencies.

Unless someone fixes the above, I intend to remove it from Debian.

-- 
Ilias



Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way

2020-08-06 Thread Felix Lechner
Hi gregor,

On Thu, Aug 6, 2020 at 7:28 AM gregor herrmann  wrote:
>
> having the
> version in a file was the big advantage of using the lintian data.

I figured. How about depending on debian-policy and using the
information in its changelog?

Kind regards
Felix Lechner



Bug#967966: ITP: collectd-graph-panel -- web-based graphing app for collectd statistics

2020-08-06 Thread Alexandre Rossi
Hi,

> Package: wnpp
> Severity: wishlist
> Owner: Joseph Nahmias 
> 
> * Package name: collectd-graph-panel
>   Version : 1
>   Upstream Author : Pim van den Berg 
> * URL : http://pommi.nethuis.nl/category/cgp/
> * License : GPL3
>   Programming Lang: PHP
>   Description : web-based graphing app for collectd statistics
> 
>  Collectd Graph Panel (CGP) is a graphical web-based front-end for
>  visualizing RRD collected by collectd, written in the PHP language.

The author seems[1] to have migrated to grafana now, so maybe this won't be
maintained upstream.

[1] https://cloud-infra.engineer/collectd-influxdb-grafana-with-downsampling/

Alex



Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way

2020-08-06 Thread gregor herrmann
On Thu, 06 Aug 2020 15:43:02 +0200, Dominique Dumont wrote:

> > Attached is a script that extracts the release dates from the policy
> > changelog. It uses the network. The data will always be current.
> 
> If the source of information is Salsa, I'd rather use gitlab API to extract 
> the latest policy version from the tags with something like:
> 
> mojo get -r https://salsa.debian.org/api/v4/projects/234/repository/tags \
>   /0/name | perl -n -E '/(\d+\.\d+\.\d+)/; say $1;'

The problem I see here is that dynamically fetching the policy
version can't work during package builds / for tests; having the
version in a file was the big advantage of using the lintian data.

But yeah, at runtime it should be ok.

Cheers,
gregor

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


signature.asc
Description: Digital Signature


Bug#965077: MySQL database with "SQLAUthTypes Backend" doesn't work anymore in buster

2020-08-06 Thread Andreas Trottmann

Am 23.07.20 um 21:28 schrieb Hilmar Preuße:


Addendum: meanwhile proftp 1.3.7a has been released. I built a package
and uploaded to unstable. You may get the packages from the official page.
Your (adapted) patch is contained in the source package but not
activated. You need to rebuild for testing.


Thank you very much! I can confirm that it works when built with the patch.


Kind regards

--
Andreas Trottmann
CTO
Werft22 AG

T +41 56 210 91 32
F +41 56 210 91 34
M +41 79 229 88 55
andreas.trottm...@werft22.com

Stadtbachstrasse 63
CH‑5400 Baden / Schweiz
www.werft22.com



Bug#957074: cdrkit: ftbfs with GCC-10

2020-08-06 Thread Sebastien Bacher
Fedora has a patch for gcc-10

https://src.fedoraproject.org/rpms/cdrkit/blob/master/f/cdrkit-1.1.11-gcc10.patch



Bug#968006: RM: magithub -- ROM; abandoned upstream; superseded by magit-forge

2020-08-06 Thread Matteo F. Vescovi
Package: ftp.debian.org
Severity: normal

As stated on its git repository[1], the code has mostly migrated and
merged in magit-forge[2], which is now in experimental suite for testing
purposes and will probably be uploaded to unstable within this weekend.

Thus, this package has lost its meaning for being part of the Debian
archives and should be removed asap.

Cheers.


[1] https://github.com/vermiculus/magithub
[2] https://github.com/magit/forge

-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature


Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way

2020-08-06 Thread Felix Lechner
Hi Dominique,

On Thu, Aug 6, 2020 at 6:43 AM Dominique Dumont  wrote:
>
> Does that sound reasonable ?

First of all, thanks for your swift reply!

I have no preference how the package gets the information. I suggested
a solution only in order to appear helpful. Thanks for addressing it
so promptly.

Unless you advise otherwise, Lintian will stop shipping the modules in
the system path in the next release.

As a side note, it seems the changelog date could differ from the tag
date, but that is a question for the policy editors.

Kind regards
Felix Lechner



Bug#963396: jimfs: FTBFS: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project jimfs: Compilation failure

2020-08-06 Thread Thorsten Glaser
On Thu, 6 Aug 2020, Andreas Tille wrote:

> [ERROR] 
> /build/jimfs-1.1/jimfs/src/main/java/com/google/common/jimfs/PathService.java:[290,30]
>  error:  is not abstract and 
> does not override abstract method test(Object) in Predicate

Change apply to test in line 292 (or let the IDE convert it to lambda).

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



Bug#968004: Should Build-depends on tzdata

2020-08-06 Thread Sebastien Bacher
Le 06/08/2020 à 15:31, David Bremner a écrit :
> It would be better to add the test only dependency with . If
> you do respin the patch, please add Closes, now that the bug exists.

Thanks,  that makes sense, new patch attached

diff -Nru ledger-3.2.1/debian/changelog ledger-3.2.1/debian/changelog
--- ledger-3.2.1/debian/changelog	2020-08-05 12:46:45.0 +0200
+++ ledger-3.2.1/debian/changelog	2020-08-06 15:01:32.0 +0200
@@ -1,3 +1,11 @@
+ledger (3.2.1-3) unstable; urgency=medium
+
+  * debian/control: 
+- Build-Depends on tzdata , it's needed for the tests
+  (Closes: #968004)
+
+ -- Sebastien Bacher   Thu, 06 Aug 2020 15:01:32 +0200
+
 ledger (3.2.1-2) unstable; urgency=medium
 
   * Bug fix: "Unversioned Python removal in sid/bullseye", thanks to
diff -Nru ledger-3.2.1/debian/control ledger-3.2.1/debian/control
--- ledger-3.2.1/debian/control	2020-08-05 12:46:45.0 +0200
+++ ledger-3.2.1/debian/control	2020-08-06 15:01:32.0 +0200
@@ -8,7 +8,7 @@
 	libboost-date-time-dev, libboost-filesystem-dev,
 	libboost-iostreams-dev, libboost-serialization-dev,
 	libboost-test-dev, man2html-base, python3-dev, texinfo, texlive,
-	libutfcpp-dev, libboost-python-dev, dh-python
+	libutfcpp-dev, libboost-python-dev, dh-python, tzdata 
 Standards-Version: 4.4.1
 Homepage: http://ledger-cli.org
 Vcs-Git: https://salsa.debian.org/debian/ledger.git


Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way

2020-08-06 Thread Dominique Dumont
On jeudi 6 août 2020 14:26:13 CEST you wrote:
> Your package is the only known consumer of Lintian's internal Perl
> modules. We would like to stop shipping our modules in the Perl system
> path. 

ok.

> Your package loads a default Lintian profile [1] and uses the
> Lintian::Data mechanism to get the policy release dates from
> data/standard-version/release-dates [2]. 

Actually, only the latest policy number is used by cme (currently 4.5.0)

> It may be tempting to use a
> simpler parser, but please consider that the information actually
> originates somewhere else.

I don't really understand your point there, but it may not matter much (see 
below)

> Attached is a script that extracts the release dates from the policy
> changelog. It uses the network. The data will always be current.

If the source of information is Salsa, I'd rather use gitlab API to extract 
the latest policy version from the tags with something like:

mojo get -r https://salsa.debian.org/api/v4/projects/234/repository/tags \
  /0/name | perl -n -E '/(\d+\.\d+\.\d+)/; say $1;'

Since the data returned by gitlab is JSON, parsing is not much of an issue.

Does that sound reasonable ?

All the best



Bug#967655: nitrokey-app: depends on deprecated GTK 2

2020-08-06 Thread Szczepan Zalega | Nitrokey
On 8/5/20 6:12 PM, John Scott wrote:
> libgtk2.0-dev is in the Build-Depends:
> Build-Depends: bash-completion, cmake (>= 3.1.0), debhelper (>= 12~), 
> *libgtk2.0-dev*, libnotify-dev, libusb-1.0-0-dev, udev, qt5-qmake, qtbase5-
> dev, qttools5-dev, libqt5svg5-dev, qtchooser, libhidapi-dev, libnitrokey-dev 
> (>= 3.5)
> 
I believe this one could be safely removed. Thank you for checking that!

Best regards,
Szczepan

-- 
Szczepan Zalega
Senior Software Developer

Nitrokey GmbH
https://www.nitrokey.com

Email: szcze...@nitrokey.com
Nickname: szszszsz

Rheinstr. 10 C, 14513 Teltow, Germany
CEO / Geschäftsführer: Jan Suhr
Register: AG Potsdam, HRB 32882 P
VAT ID / USt-IdNr.: DE300136599



Bug#962036: quodlibet: Ending a call in Microsoft Teams causes Quod Libet to start playing music.

2020-08-06 Thread Matthew Wakeling

On Tue, 2 Jun 2020, Martin wrote:

Note, that this happens with other software, too, e.g. linphone.
I assume, that most soft phones send (DBus?) signals when one
takes or ends a call. Quodlibet pauses and resumes accordingly,
which is nice. However, it should probably not resume
automatically when being paused manually.


After a little investigation, it appears that this functionality is 
performed by the module-role-cork module of pulseaudio, so commenting out 
the line "load-module module-role-cork" in /etc/pulse/default.pa fixes the 
issue.


That is, when I start a video call, quodlibet no longer pauses, and when I 
finish a video call, quodlibet no longer unpauses.


I would be happy if quod libet were to pause when a video call starts, but 
I am not happy for it to unpause when it finishes. However, there doesn't 
seem to be any documentation or configuration options for 
module-role-cork.


I'm happy for this to be "fixed" in quodlibet, or reassigned to the 
pulseaudio package.


Matthew

--
And the lexer will say "Oh look, there's a null string. Oooh, there's 
another. And another.", and will fall over spectacularly when it realises

there are actually rather a lot.
   - Computer Science Lecturer (edited)



Bug#968005: gimp: install the application well, it did not give any error but when executing it gave a serious error

2020-08-06 Thread Jorge Fernandez
Package: gimp
Version: 2.10.8-2
Severity: important


install the application through the normal software manager without errors,
when executing it gave me a serious error and I could not execute it, try to
uninstall it and reinstall it but I generate the same error



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

Kernel: Linux 4.19.0-10-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_VE.UTF-8, LC_CTYPE=es_VE.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_VE.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
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.6-9.2~deb10u1
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u1
ii  libgcc1  1:8.3.0-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgegl-0.4-00.4.12-2
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.8-2
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgs9   9.27~dfsg-2+deb10u3
ii  libgtk2.0-0  2.24.32-3
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b2.3.1-1
ii  libheif1 1.3.2-2~deb10u1
ii  libilmbase23 2.2.1-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  liblzma5 5.2.4-1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2.1
ii  libopenexr23 2.2.1-4.1
ii  libopenjp2-7 2.3.0-2+deb10u1
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpangoft2-1.0-01.42.4-8~deb10u1
ii  libpng16-16  1.6.36-6
ii  libpoppler-glib8 0.71.0-5
ii  librsvg2-2   2.44.10-2.1
ii  libstdc++6   8.3.0-6
ii  libtiff5 4.1.0+git191117-2~deb10u1
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libwmf0.2-7  0.2.8.4-14
ii  libx11-6 2:1.6.7-1
ii  libxcursor1  1:1.1.15-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+deb10u1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages gimp recommends:
ii  ghostscript  9.27~dfsg-2+deb10u3

Versions of packages gimp suggests:
pn  gimp-data-extras  
ii  gimp-help-es [gimp-help]  2.8.2-1
pn  gimp-python   
ii  gvfs-backends 1.38.1-5
ii  libasound21.1.8-1

-- no debconf information
```
GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 
8.2.0-13' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-8 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new 
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx 
--enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch 
--disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-13) 

using GEGL version 0.4.12 (compiled against version 0.4.12)
using GLib version 2.65.0 (compiled against version 2.58.1)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.0)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Violación de segmento

Stack trace:
```

# Stack traces obtained from PID 2557 - Thread 2557 #

[New LWP 2559]
[New LWP 2560]
[New LWP 2561]
[New LWP 2562]
[New LWP 2563]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Bug#968004: Should Build-depends on tzdata

2020-08-06 Thread David Bremner
Sebastien Bacher  writes:

> - libutfcpp-dev, libboost-python-dev, dh-python
> + libutfcpp-dev, libboost-python-dev, dh-python, tzdata
>  Standards-Version: 4.4.1
>  Homepage: http://ledger-cli.org
>  Vcs-Git: https://salsa.debian.org/debian/ledger.git

It would be better to add the test only dependency with . If
you do respin the patch, please add Closes, now that the bug exists.

d



Bug#968004: Should Build-depends on tzdata

2020-08-06 Thread Sebastien Bacher
Package: ledger
Version: 3.2.1-2
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Trying to build on a machine without tzdata the build fail on a test
error [1]

1057 fails with

  -(("/<>/test/regress/1057.test" 1 (21308 60112 0) nil
"www.amazon.fr"
  +(("/<>/test/regress/1057.test" 1 (21308 42112 0) nil
"www.amazon.fr"

The issue has been reported and fixed upstream there
https://github.com/ledger/ledger/commit/d967c348

Even if tzdata is installed by default on the builders it still makes
sense to have in the Build-Depends


Thanks,

[1]
https://launchpadlibrarian.net/492137498/buildlog_ubuntu-groovy-riscv64.ledger_3.2.1-2_BUILDING.txt.gz

diff -Nru ledger-3.2.1/debian/changelog ledger-3.2.1/debian/changelog
--- ledger-3.2.1/debian/changelog	2020-08-05 12:46:45.0 +0200
+++ ledger-3.2.1/debian/changelog	2020-08-06 15:01:32.0 +0200
@@ -1,3 +1,9 @@
+ledger (3.2.1-3) unstable; urgency=medium
+
+  * debian/control: Build-Depends on tzdata, it's needed for the tests
+
+ -- Sebastien Bacher   Thu, 06 Aug 2020 15:01:32 +0200
+
 ledger (3.2.1-2) unstable; urgency=medium
 
   * Bug fix: "Unversioned Python removal in sid/bullseye", thanks to
diff -Nru ledger-3.2.1/debian/control ledger-3.2.1/debian/control
--- ledger-3.2.1/debian/control	2020-08-05 12:46:45.0 +0200
+++ ledger-3.2.1/debian/control	2020-08-06 15:01:32.0 +0200
@@ -8,7 +8,7 @@
 	libboost-date-time-dev, libboost-filesystem-dev,
 	libboost-iostreams-dev, libboost-serialization-dev,
 	libboost-test-dev, man2html-base, python3-dev, texinfo, texlive,
-	libutfcpp-dev, libboost-python-dev, dh-python
+	libutfcpp-dev, libboost-python-dev, dh-python, tzdata
 Standards-Version: 4.4.1
 Homepage: http://ledger-cli.org
 Vcs-Git: https://salsa.debian.org/debian/ledger.git


Bug#968003: lintian: bad name for duplicate-globbing-patterns and redundant-globbing-patterns

2020-08-06 Thread Raphaël Hertzog
Package: lintian
Version: 2.87.0
Severity: normal
User: de...@kali.org
Usertags: origin-kali

I was hit with those errors (reproducible with commit
cd6b90a5295aa5a171a1ac9c3c51590f568ca075 in the openvas-scanner git
repository):

E: openvas-scanner source: duplicate-globbing-patterns 
tools/greenbone-nvt-sync.in in lines 12 12
E: openvas-scanner source: redundant-globbing-patterns 
[tools/greenbone-nvt-sync.in tools/greenbone-nvt-sync.in] for 
tools/greenbone-nvt-sync.in

I have multiple issues:

1/ it's not clear that the problem is in the copyright file, I first
looked up tools/greenbone-nvt-sync.in to look what was on line 12
please rename to
{duplicate,redundant}-globbing-patterns-in-debian-copyright for example.

2/ why do I have the same line number twice in the first error?

3/ minor, but ideally we would only report one of the two errors when it
applies to the same file...

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

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

Versions of packages lintian depends on:
ii  binutils  2.35-1
ii  bzip2 1.0.8-4
ii  diffstat  1.63-1
ii  dpkg  1.20.5
ii  dpkg-dev  1.20.5
ii  file  1:5.38-5
ii  gettext   0.19.8.1-10
ii  gpg   2.2.20-1
ii  intltool-debian   0.35.0+20060710.5
ii  libapt-pkg-perl   0.1.36+b3
ii  libarchive-zip-perl   1.68-1
ii  libcapture-tiny-perl  0.48-1
ii  libclass-xsaccessor-perl  1.19-3+b5
ii  libclone-perl 0.45-1
ii  libconfig-tiny-perl   2.24-1
ii  libcpanel-json-xs-perl4.19-1
ii  libdata-dpath-perl0.58-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdevel-size-perl0.83-1+b1
ii  libdpkg-perl  1.20.5
ii  libemail-address-xs-perl  1.04-1+b2
ii  libfile-basedir-perl  0.08-1
ii  libfile-find-rule-perl0.34-1
ii  libfont-ttf-perl  1.06-1
ii  libhtml-parser-perl   3.72-5
ii  libio-async-loop-epoll-perl   0.21-1
ii  libio-async-perl  0.77-3
ii  libipc-run3-perl  0.048-2
ii  libjson-maybexs-perl  1.004002-1
ii  liblist-compare-perl  0.53-1
ii  liblist-moreutils-perl0.416-1+b5
ii  liblist-utilsby-perl  0.11-1
ii  libmoo-perl   2.004000-1
ii  libmoox-aliases-perl  0.001006-1
ii  libnamespace-clean-perl   0.27-1
ii  libpath-tiny-perl 0.114-1
ii  libperlio-gzip-perl   0.19-1+b6
ii  libsereal-decoder-perl4.017+ds-1
ii  libsereal-encoder-perl4.017+ds-1
ii  libtext-levenshteinxs-perl0.03-4+b7
ii  libtext-xslate-perl   3.5.8-1
ii  libtime-duration-perl 1.21-1
ii  libtime-moment-perl   0.44-1+b2
ii  libtimedate-perl  2.3300-1
ii  libtry-tiny-perl  0.30-1
ii  libtype-tiny-perl 1.010002-1
ii  libunicode-utf8-perl  0.62-1+b1
ii  liburi-perl   1.76-2
ii  libxml-libxml-perl2.0134+dfsg-2
ii  libxml-writer-perl0.625-1
ii  libyaml-libyaml-perl  0.82+repack-1
ii  lzip  1.21-7
ii  man-db2.9.3-2
ii  patchutils0.4.2-1
ii  perl [libdigest-sha-perl] 5.30.3-4
ii  t1utils   1.41-4
ii  xz-utils  5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information



Bug#852746:

2020-08-06 Thread Lukáš Durďák
Hi, I am unsure which bug report is correct for this as there is similar
one #898033 and #954849 but I could confirm the problem is back since
approximately May 2020 up to today:
It could be basically any program using opencl, I've picked the clinfo as
an example:

$ clinfo
: CommandLine Error: Option 'polly' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

$ sudo apt remove mesa-opencl-icd
... package mesa-opencl-icd removed...

$ dpkg -l | grep opencl
ii  intel-opencl-icd  20.13.16352-1
 amd64Intel graphics compute runtime for OpenCL
ii  libopencl-clang10 10.0.0-2
amd64thin wrapper for clang
ii  libopencl1-amdgpu-pro:amd64   20.20-1098277
 amd64AMD OpenCL ICD Loader library
rc  mesa-opencl-icd:amd64 20.1.4-1
amd64free implementation of the OpenCL API -- ICD runtime
ii  ocl-icd-libopencl1:amd64  2.2.12-4
amd64Generic OpenCL ICD Loader
ii  ocl-icd-opencl-dev:amd64  2.2.12-4
amd64OpenCL development files
ii  opencl-c-headers  3.0~2020.05.12-g5cc337c-1
 all  OpenCL (Open Computing Language) C header files
ii  opencl-clhpp-headers  2.2.0~~2.0.11+git9-g0192662-1
 all  C++ headers for OpenCL development
ii  opencl-headers3.0~2020.05.12-g5cc337c-1
 all  OpenCL (Open Computing Language) header files
ii  opencl-orca-amdgpu-pro-icd:amd64  20.20-1098277
 amd64non-free AMD OpenCL ICD Loaders

$ clinfo
Number of platforms   1
  Platform Name   AMD Accelerated Parallel
Processing
  Platform Vendor Advanced Micro Devices,
Inc.
  Platform VersionOpenCL 2.1 AMD-APP
(3110.6)
  Platform ProfileFULL_PROFILE
  Platform Extensions cl_khr_icd
cl_amd_event_callback cl_amd_offline_devices
  Platform Host timer resolution  1ns
  Platform Extensions function suffix AMD

  Platform Name   AMD Accelerated Parallel
Processing


BR//L.D.


Bug#967991: glirc, build-depends on package which is not in testing

2020-08-06 Thread peter green

notfound 967991 2.35-1
found 967991 2.32-1
close 967991 2.35-1
thanks

On 06/08/2020 13:20, Clint Adams wrote:

On Thu, Aug 06, 2020 at 11:20:00AM +0100, peter green wrote:

glirc can no longer be built in testing because haskell-regex-tdfa is no longer
present in testing. Ilias Tsitsimpis has filed a bug report against the package
saying he intends to remove it and asked the release team to remove it from
testing ( https://lists.debian.org/debian-haskell/2020/08/msg2.html ) .
which the release team did.


That list appears to have haskell-regex-tdfa-text, not haskell-regex-tdfa?


Apologies, I clearly mixed up haskell-regex-tdfa and haskell-regex-tdfa-text
it seems I also missed that there were different versions of glirc
in testing and unstable.

It seems that testing's version of glirc build-depends on binary package's
built from haskell-regex-tdfa-text, but unstable's version does not.

Updating the bug metadata accordingly



Bug#936146: archivemail - Python 3 porting

2020-08-06 Thread Martin Steigerwald
Hi!

I used this frequently enough to be hesitant to let apt dist-upgrade 
remove it on my system currently.

But I understand it may not make sense to port it as its hard and 
upstream is not active anymore.

Is there an alternative in Debian repository?

Best,
-- 
Martin



Bug#968002: Missing ssl certificates

2020-08-06 Thread Pim Kartner
Package: ca-certificates
Version: 20200601~deb10u1

Some certificates seem to be missing in 20200601~deb10u1. The following
command works in version 20190110 but stopped working in 20200601~deb10u1 .

curl https://static.gc.apple.com/public-key/3rd-party-auth-prod-19824d.cer

This gives the output:

curl: (60) SSL certificate problem: unable to get issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.


  1   2   >