Bug#924401: #924401 base-files fails postinst when base-passwd is unpacked

2021-02-21 Thread Tim Woodall

Hi,

A. /etc/passwd is part of base-passwd's interface and base-files is
   right in relying on it working at all times. Then base-passwd is rc
   buggy for violating a policy must. Fixing this violation is
   technically impossible.


I seem to have hit this same issue independently.

Could you explain why "Fixing this violation is technically impossible"

As far as I can see, making base-passwd not essential, only required,
and then making passwd and base-files pre-depend on base-passwd the
system seems to bootstrap /etc/passed and /etc/group OK.

That also seems to conform to the debian policy. The oddity is that
base-files and passwd only actually need to depend on base-passwd, not
pre-depend on it as they only use /etc/passwd and /etc/group in the
postinst scripts but the debian policy doesn't seem to consider this
case.

(There are also issues with mawk preventing bootstrap but again I think
this is due to some missing pre-depends (or depends) as explicitly
configuring mawk first before anything else, even base-passwd resolves
this. But I haven't analysed exactly what is going wrong yet in that
case)

Regards,

Tim.



Bug#983251: passwd is missing dependencies

2021-02-21 Thread Tim Woodall

On Sun, 21 Feb 2021, Chris Hofstaedtler wrote:


* Tim Woodall  [210221 15:28]:

I am unsure how debootstrap avoids the first problem - It could just be
down to luck that debootstrap configures base-passwd before passwd. grep
is Priority: required and Essential: yes so it could be argued that it
should be unpacked before attempting to configure passwd and so this
dependency is not required.


That is exactly the case. Both grep and base-passwd are Essential:
yes, so they _must_ function already (even when not configured yet).

Adding them to Depends: could be argued to be a bug.



Hi Chris,

As per my other message I think there is a bug, but it's not in this
package. However if there is a bug it's possibly in the wording of the
debian policy on essential packages which is somewhat vague about
bootstraping a virgin system.

I've now inspected debootstrap and it handles this case by having an
explicit ordering on how it configures the first seven packages
independent of any explicit or implicit dependencies.

So go ahead and close this bug rather than reassign it to base-passwd.
I've taken the discussion to debian-devel.

Regards,

Tim.



Bug#983086: [Pkg-zfsonlinux-devel] Bug#983086: zfsutils-linux: TRIM crashes SSD drives

2021-02-21 Thread Aron Xu
Hi,

On Fri, Feb 19, 2021 at 4:45 PM Xavier  wrote:
>
> Package: zfsutils-linux
> Version: 0.8.6-1~bpo10+1
> Severity: important
>
> Dear Maintainer,
>
> The recently added cron "TRIM the first Sunday of every month" makes some SSD 
> drives crash.
>
> The problem appears on reasonnably busy and otherwise stable servers:
>* with about 100 containers,
>* each on a separate zvol, ext4 mounted with discard option,
>* on a 6 identical drives raidz2.
>
> The issue has been observed on these drives:
>* Micron_5100_MTFDDAK960TCB
>* Samsung_SSD_850_EVO_1TB
>* Samsung_SSD_860_EVO_1TB
>

I'm particularly interested in the protocol used by these disks, I
suspect all of them are equipped with SATA 2.x/3.0?

Prior to SATA 3.1, TRIM command is considered blocking (non-queued)
and this might be the root cause of crashing your workload in a busy
environment. In other words, actively trimming on SATA 2.x/3.0 disks
could be considered harmful to the operational status of heavy
workloads even though the disks are enterprise graded with superfluous
IOPS capacity.

> When affected (it not always the case), the systems could not complete the 
> cancelling of the trim with:
> # zpool trim -c pool
> Testing trim on one drive only, and reducing the rate to as low as 50, 
> did not help.
>
> A reset seems the only solution, followed by a zpool trim -c after reboot.
>
> It would be wise to deactivate that cron by default, or at least to provide 
> some kind of convenient way to do so, like an option in /etc/default/zfs.
>

Thanks for this advice and we'll have a look on how to get something
landed for bullseye and buster-bpo.

Regards,
Aron



Bug#981253: actually, make that: document minimum and maximum values of all options

2021-02-21 Thread Martin-Éric Racine
ma 22. helmik. 2021 klo 1.33 Santiago Garcia Mantinan
(ma...@debian.org) kirjoitti:
>
> > Document the minimum and maximum values of all options, and tell which
> > value is the strongest for each.
>
> This will take a lot of time, and I don't know if this is worth the effort.
[...]
> I'll try to gather info for all this, but looks like it will be time
> consuming and that the kernel guys may change it again :-(

One way to do this would be to revise the man page exactly once at
every Debian release, at the start of the soft freeze i.e. once the
kernel version is decided, and to have a section where it says
something like:

--
BUGS

The above options, values and meanings are correct as of Linux kernel
5.10, and may have changed since the previous major Linux kernel
release. This might indeed mean that changes in the way the Linux
kernel handles bridges have altered the way existing options are
interpreted. Whenever in doubt, consult older versions of this manual
page and compare their contents.
--

This way, the manual page would at least be correct for the Debian
release it comes with.

Martin-Éric



Bug#948876: fontforge: Segmentation fault, making kodi FTBFS

2021-02-21 Thread Hideki Yamane
control: severity -1 important
control: retitle -1 fontforge: memory leak issue

Hi,

> fontforge: Segmentation fault, making kodi FTBFS

 fontforge has still memory leak issues that are able to detect with
 sanitize DEB_BUILD_OPTION in debian/rules, however, kodi build can
 be without fontforge's segmentation fault now. So, downgrade severity
 and retitle it.



-- 
Hideki Yamane 



Bug#982984: Mirror blocked due to repeated errors

2021-02-21 Thread Michael Tokarev

22.02.2021 02:43, Eduard Bloch wrote:


I hope I have identified all root causes for the problems in Russel's
original report, some were specific to evdns (best reproduced in
Michael's setup) which are IMHO bugs in libevent (worth another
bug report there when I have more evidence) and some could be attributed
to a file descriptor introduced in version 3.6 and some are caused by
incorrect (and actually obsolete) algorithms on cache item handling.


btw, did you try my (trivial) event lib and udns? :) I wrote the event
lib after trying to use libevent many years ago and finding it is somewhat
huge and illogical.. :)


https://www.unix-ag.uni-kl.de/~bloch/acng/snap3.6.1/ . If this is still


Nope, this one does not fail anymore, it works as it should.

Thanks,

/mjt



Bug#982944: rename.ul was arbitrarily removed from util-linux citing non-existent policy

2021-02-21 Thread Lucas Sandery
I wrote about this over at 
http://forums.debian.net/viewtopic.php?f=19=148938


Similar bug #966468 has been closed as WONTFIX by the same maintainer 
who removed it, without comment, and seemingly without any oversight.


I can understand the argument about excluding it from update 
alternatives, I don't necessarily agree but at least there was a 
workaround. However, It's removal, is illogical. It was already suffixed 
to avoid conflicts, people are using it. Can a maintainer please provide 
a very good reason for this removal, or just put it back?


Thanks,
Lucas.



Bug#982579: DMesg output of BananaPi M3

2021-02-21 Thread Bernhard
Hello Maks

Here, the DMesg output for BananaPi M3:

> [   11.957171] brcmfmac mmc2:0001:1: firmware: failed to load 
> brcm/brcmfmac43430-sdio.sinovoip,bpi-m3.txt (-2)
> [   11.967106] firmware_class: See https://wiki.debian.org/Firmware for 
> information about missing firmware
> [   11.977035] brcmfmac mmc2:0001:1: firmware: failed to load 
> brcm/brcmfmac43430-sdio.txt (-2)
> [   12.994756] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 
> 0x50

Best regards and thank you for your support.
Bernhard



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


Bug#983295: libpam-modules: pam_mkhomedir is disabled for noninteractive sessions (e.g. samba)

2021-02-21 Thread Sam Hartman
> "Lars" == Lars Kruse  writes:
Lars> I am inclined to think, that enabling "mkhomedir" for
Lars> non-interactive sessions as part of the "mkhomedir"
Lars> configuration shipped by the pam package would not hurt its
Lars> users.  But maybe I am overlooking something ovious?

It might tend to create home directories on mail servers and web servers
in cases where they are really not wanted.  In your case I'd either
modify /etc/pam.d/common-session-noninteractive or /etc/pam.d/samba.
Creating a new separate profile you install in /usr/share/pam-configs
also seems reasonable.



Bug#983242: wine-development recent upgrade (5.6-1?) broke levelator.exe

2021-02-21 Thread Antoine Le Gonidec

On Sun, 21 Feb 2021 14:22:19 +0100 Alex Andreotti  
wrote:

I been using a script to level wav files for more than a year without problems, 
until few day ago, I guess it was the upgrade to version 5.6-1 but I'm not sure


In bug #983117 there is a series of commands showing how to downgrade to 
wine-development 5.5-9:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983117#5

Following it would allow you to check is your issue happens with 5.5-9 too, or 
if actually started happening with 5.6-1.

Here is a copy for convenience (all commands as root):

cat > /etc/apt/sources.list.d/snapshot-20201026T024334Z.list << EOF
# wine-development 5.5-9
# cf. https://snapshot.debian.org/package/wine-development/5.5-9/
deb [check-valid-until=no] 
https://snapshot.debian.org/archive/debian/20201026T024334Z/ sid main
EOF
apt update
apt install 
{libwine-development:{amd64,i386},wine32-development:i386,wine64-development,wine-development}=5.5-9



OpenPGP_signature
Description: OpenPGP digital signature


Bug#971713: NMU in delayed/5

2021-02-21 Thread Benda Xu
Hi Matthew,

Matthew Vernon  writes:

> I've taken Trek's patches and incorporated them into an NMU which I've
> pushed to delayed/5.
>
> We may still want to get the new version into bullseye once Jesse
> publishes it, but at least this way the fix for this bug will be in.
>
> I hope that's OK!

Thank you so much for taking care of it.  Hope it will get through soon.

Yours,
Benda



Bug#979865: m2crypto FTBFS on IPV6-only buildds

2021-02-21 Thread Sandro Tosi
> > it would be easier to enforce to have all buildds configured equally so
> > the package does not fail on a random buildd.
>
> I *guess* that's not trivial as I think it depends on the network their in.

OTOH it's not ideal to have machines that are supposed to be similar,
being different enough to cause build failure (due to their
configuration, not due to resource constraint).

> m2crypto needs another upload anyways. Without a proper IPv6 solution
> for the tests, can the failing network tests please be disabled in the
> next upload?

given the 29 failures are all part of test_ssl.py (and make up more
than half of the tests in it) i'm going to skip that file entirely. i
would argue that testing SSL is important for this package, so this
solution is very suboptimal.

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



Bug#983298: unblock: ocserv/1.1.2-2

2021-02-21 Thread Aron Xu
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

Dear release team,

This is a pre-approval request that please unblock package ocserv/1.1.2-2, which
is a version with cherry picked upstream bug fixes.

unblock ocserv/1.1.2-2


Regards,
Aron
diff -Nru ocserv-1.1.2/debian/changelog ocserv-1.1.2/debian/changelog
--- ocserv-1.1.2/debian/changelog   2020-12-17 18:38:57.0 +0800
+++ ocserv-1.1.2/debian/changelog   2021-02-22 11:37:07.0 +0800
@@ -1,3 +1,9 @@
+ocserv (1.1.2-2) unstable; urgency=medium
+
+  * d/patches: cherry-pick upstream post 1.1.2 bug fixes
+
+ -- Aron Xu   Mon, 22 Feb 2021 11:37:07 +0800
+
 ocserv (1.1.2-1) unstable; urgency=medium
 
   * New upstream version 1.1.2
diff -Nru 
ocserv-1.1.2/debian/patches/0009-update_auth_time_stats-cast-operations-to-avoid-over.patch
 
ocserv-1.1.2/debian/patches/0009-update_auth_time_stats-cast-operations-to-avoid-over.patch
--- 
ocserv-1.1.2/debian/patches/0009-update_auth_time_stats-cast-operations-to-avoid-over.patch
 1970-01-01 08:00:00.0 +0800
+++ 
ocserv-1.1.2/debian/patches/0009-update_auth_time_stats-cast-operations-to-avoid-over.patch
 2021-02-22 11:33:03.0 +0800
@@ -0,0 +1,27 @@
+From e035221030f8fdfbb38483889631916fef9d9798 Mon Sep 17 00:00:00 2001
+From: Nikos Mavrogiannopoulos 
+Date: Wed, 9 Dec 2020 15:05:24 +0100
+Subject: [PATCH 09/36] update_auth_time_stats: cast operations to avoid
+ overflows
+
+Signed-off-by: Nikos Mavrogiannopoulos 
+---
+ src/sec-mod-auth.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/sec-mod-auth.c b/src/sec-mod-auth.c
+index c769643c..b4b2f3fd 100644
+--- a/src/sec-mod-auth.c
 b/src/sec-mod-auth.c
+@@ -131,7 +131,7 @@ static void update_auth_time_stats(sec_mod_st * sec, 
time_t secs)
+ 
+   if (secs > sec->max_auth_time)
+   sec->max_auth_time = secs;
+-  sec->avg_auth_time = 
(sec->avg_auth_time*(sec->total_authentications-1)+secs) / 
sec->total_authentications;
++  sec->avg_auth_time = 
((uint64_t)sec->avg_auth_time*((uint64_t)(sec->total_authentications-1))+secs) 
/ (uint64_t)sec->total_authentications;
+ }
+ 
+ static
+-- 
+2.20.1
+
diff -Nru 
ocserv-1.1.2/debian/patches/0020-ocserv-worker-renamed-loop-to-worker_loop.patch
 
ocserv-1.1.2/debian/patches/0020-ocserv-worker-renamed-loop-to-worker_loop.patch
--- 
ocserv-1.1.2/debian/patches/0020-ocserv-worker-renamed-loop-to-worker_loop.patch
1970-01-01 08:00:00.0 +0800
+++ 
ocserv-1.1.2/debian/patches/0020-ocserv-worker-renamed-loop-to-worker_loop.patch
2021-02-22 11:35:22.0 +0800
@@ -0,0 +1,131 @@
+From 47c6638286a694b4d278e01b278f64f9368b3e1a Mon Sep 17 00:00:00 2001
+From: Nikos Mavrogiannopoulos 
+Date: Sat, 12 Dec 2020 22:41:50 +0100
+Subject: [PATCH 20/36] ocserv-worker: renamed loop to worker_loop
+
+This avoids warnings and static analyzers complains about
+the libev functions hiding the global 'loop' variable
+
+Signed-off-by: Nikos Mavrogiannopoulos 
+---
+ src/worker-vpn.c | 34 +-
+ 1 file changed, 17 insertions(+), 17 deletions(-)
+
+Index: ocserv/src/worker-vpn.c
+===
+--- ocserv.orig/src/worker-vpn.c
 ocserv/src/worker-vpn.c
+@@ -95,7 +95,7 @@ struct worker_st *global_ws = NULL;
+ static int terminate = 0;
+ static int terminate_reason = REASON_SERVER_DISCONNECT;
+ 
+-static struct ev_loop *loop = NULL;
++static struct ev_loop *worker_loop = NULL;
+ ev_io command_watcher;
+ ev_io tls_watcher;
+ ev_io tun_watcher;
+@@ -433,8 +433,8 @@ static int setup_dtls_connection(struct
+   dtls->dtls_session = session;
+   ev_init(>io, dtls_watcher_cb);
+   ev_io_set(>io, dtls->dtls_tptr.fd, EV_READ);
+-  ev_io_start(loop, >io);
+-  ev_invoke(loop, >io, EV_READ);
++  ev_io_start(worker_loop, >io);
++  ev_invoke(worker_loop, >io, EV_READ);
+ 
+   return 0;
+  fail:
+@@ -2609,7 +2609,7 @@ static int test_for_tcp_health_probe(str
+ 
+ static void syserr_cb (const char *msg)
+ {
+-  struct worker_st * ws = ev_userdata(loop);
++  struct worker_st * ws = ev_userdata(worker_loop);
+   int err = errno;
+ 
+   oclog(ws, LOG_ERR, "libev fatal error: %s / %s", msg, strerror(err));
+@@ -2637,7 +2637,7 @@ static void cstp_send_terminate(struct w
+ 
+ static void command_watcher_cb (EV_P_ ev_io *w, int revents)
+ {
+-  struct worker_st *ws = ev_userdata(loop);
++  struct worker_st *ws = ev_userdata(worker_loop);
+ 
+   int ret = handle_commands_from_main(ws);
+   if (ret == ERR_NO_CMD_FD) {
+@@ -2723,7 +2723,7 @@ static void invoke_dtls_if_needed(struct
+   if ((dtls->udp_state > UP_WAIT_FD) && 
+   (dtls->dtls_session != NULL) &&
+   (gnutls_record_check_pending(dtls->dtls_session))) {
+-  ev_invoke(loop, >io, EV_READ);
++  ev_invoke(worker_loop, >io, EV_READ);
+   }
+ }
+ 
+@@ -2757,9 

Bug#980068: cmake: Please update to version 3.19.3 before bullseye freeze

2021-02-21 Thread ciel
Dear Debian cmake maintainers,

Now I saw libboost 1.74 is migrated to testing (bullseye). boost 1.74
is not compatible with cmake 3.18.
As a released version, I do need cmake 3.19 (or later).

ciel.



Bug#983297: Substitute "mktemp" with "mkstemp"

2021-02-21 Thread Bjarni Ingi Gislason
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 1da3e089210539ef445e6b32a393b9870f967df9 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Mon, 22 Feb 2021 02:04:32 +
>Subject: [PATCH] Substitute "mktemp" with "mkstemp"

  Substitute "mktemp" with "mkstemp" in files "nntp.c" and
"contrib/recmail.c" as "mktemp" is unsafe,
see "man 3 mktemp".

Signed-off-by: Bjarni Ingi Gislason 
---
 contrib/recmail.c | 4 ++--
 nntp.c| 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/contrib/recmail.c b/contrib/recmail.c
index 78670d9..25e5f45 100644
--- a/contrib/recmail.c
+++ b/contrib/recmail.c
@@ -48,7 +48,7 @@
 extern char *getlogin();
 extern char *getenv();
 extern char *malloc();
-extern char *mktemp();
+extern char *mkstemp();
 extern struct passwd *getpwnam();
 void get_host_name();
 
@@ -89,7 +89,7 @@ char **argv;
 /*  FIX  this could be much better */
*tolist++ = MAILER;
*tolist++ = "-f";
-   *tolist++ = mktemp(strcpy(mail_spool, mail_template));
+   *tolist++ = mkstemp(strcpy(mail_spool, mail_template));
*tolist = pbuff;
 
if ((sfd = fopen(mail_spool, "w")) == NULL){
diff --git a/nntp.c b/nntp.c
index 0ba296f..c1bee4c 100644
--- a/nntp.c
+++ b/nntp.c
@@ -120,7 +120,7 @@ int nntp_debug = 0;
 extern char*home_directory;
 extern int  silent;
 
-extern char*mktemp();
+extern char*mkstemp();
 
 static FILE*nntp_in = NULL;/* fp for reading from server */
 static FILE*nntp_out = NULL;/* fp for writing to server */
@@ -996,7 +996,7 @@ nntp_get_active(void)
 if (!is_connected && connect_server() < 0)
return -1;
 
-new_name = mktemp(relative(db_directory, ".actXX"));
+new_name = mkstemp(relative(db_directory, ".actXX"));
 
 switch (n = ask_server("LIST")) {
case OK_GROUPS:
@@ -1053,7 +1053,7 @@ nntp_get_newsgroups(void)
 FILE   *new;
 int n;
 
-new_name = mktemp(relative(tmp_directory, "nngrXX"));
+new_name = mkstemp(relative(tmp_directory, "nngrXX"));
 new = open_file(new_name, OPEN_CREATE_RW | OPEN_UNLINK);
 if (new == NULL)
return NULL;
-- 
2.30.0



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason



Bug#983296: db.c: define some variables for subroutine "readactfile"

2021-02-21 Thread Bjarni Ingi Gislason
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 73ee09c5ef39c6ad89a07f3a284b89734bbe517f Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Mon, 22 Feb 2021 01:26:45 +
>Subject: [PATCH] db.c: define some variables for subroutine "readactfile"

  Define the followiing variables in the subroutine "readactfile":

char   *source;
extern char*nntp_server;
static FILE*f_user = NULL;
extern int  nntp_debug;

Signed-off-by: Bjarni Ingi Gislason 
---
 db.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/db.c b/db.c
index 99c2695..51ac2e6 100644
--- a/db.c
+++ b/db.c
@@ -1017,6 +1017,10 @@ readactfile(void)
 int i;
 FILE   *actfp;
 stlist_t   *sthead, *stp = NULL;
+char   *source;
+extern char*nntp_server;
+static FILE*f_user = NULL;
+extern int  nntp_debug;
 extern int  keep_active_file;
 
 if (actlist != NULL)
-- 
2.30.0


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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason



Bug#983295: libpam-modules: pam_mkhomedir is disabled for noninteractive sessions (e.g. samba)

2021-02-21 Thread Lars Kruse
Package: libpam-modules
Version: 1.4.0-4
Severity: normal

Dear Maintainer,


= Description of the use-case =

I am using pam_mkhomedir on a file server (samba).
Users are managed via LDAP (configured in smbd).

The home directories of users are supposed to be created, as soon as the
user accesses the corresponding personal share via samba.

This works well, if `pam_mkhomedir` is enabled in "common-session" and
"common-session-noninteractive".
Additionally "obey pam restrictions = yes" needs to be specified in
/etc/samba/smbd.conf.


= Description of the issue =

In theory, this works well together with the configuration distributed
in the pam package.  But one missing piece is missing, since
/usr/share/pam-configs/mkhomedir contains the following line:

  Session-Interactive-Only: yes

I am not sure, whether this line is necessary.
For my specific use-case I need to remove this line in order to
allow users to create their home directory via samba (non-interactively).


# Description of local workarounds =

In order to prevent my local modification from being overridden during
package upgrades, I decided to create an adjusted copy of
/usr/share/pam-configs/mkhomedir in that directory.  Now I can select
this custom module via "pam-auth-update" (and disable the original
"mkhomedir").
This approach is obviously not good, since I changed the content of
/usr/share/pam-configs (instead of some file below /etc).

An alternative approach would be to change
/etc/pam.d/common-session-noninteractive and tell "pam-auth-update" to
stop managing the files below /etc/pam.d/.  This is obviously not
desirable.


I am inclined to think, that enabling "mkhomedir" for non-interactive
sessions as part of the "mkhomedir" configuration shipped by the pam
package would not hurt its users.
But maybe I am overlooking something ovious?

Thank you for your time!

Cheers,
Lars



Bug#983294: nvme storage device disappears after random time of usage

2021-02-21 Thread Pelzi
Subject: linux-image-4.19.0-14-amd64: nvme storage device disappears after 
random time of usage
Package: src:linux
Version: 4.19.171-2
Severity: normal

Dear Maintainer,

using a certain NVME storage device "ADATA XPG SX6000 Lite 128 GB, SSD"
leads after some time to a controller down error message,
after which the /dev/nvme* devices are vanished. Any mounted file system or 
swap space on
such a device will only report i/o errors after that, easily making the machine 
unusable.

The device is not absolutely unusable. E.g. it never showed a problem writing 
an UEFI partition
to it, then booting from it. It is possible to trigger the problem quite 
reproducably by
constantly writing random bytes to an mounted ext4 file system on one the 
device's partition:

# while true;do file=$(mktemp -p /mnt/test_nvm);\
dd bs=10240 if=/dev/urandom of=${file};echo $file filled;rm $file;done

After some hours, the following entries will appear in kernel.log:

Feb 21 21:14:43 server kernel: [1624409.093271] nvme nvme0: controller is down; 
will reset: CSTS=0x, PCI_STATUS=0x10
Feb 21 21:14:43 server kernel: [1624409.145284] nvme :03:00.0: enabling 
device ( -> 0002)
Feb 21 21:14:43 server kernel: [1624409.145457] nvme nvme0: Removing after 
probe failure status: -19

...and the device will be gone.

Obviously, I expect the storage device not to vanish during operation.

The kernel log given below starts with the reboot after such a situation, i.e. 
does not contain the error message itself, nevertheless
might give helpful hints on the machine’s details.

-- Package-specific info:
** Version:
Linux version 4.19.0-14-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.171-2 (2021-01-30)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-14-amd64 root=/dev/mapper/CachedVG-lv_root ro 
quiet nvme_core.default_ps_max_latency_us=550 nomodeset

** Not tainted

** Kernel log:
[9.514267] systemd[1]: Listening on LVM2 poll daemon socket.
[9.514375] systemd[1]: Reached target System Time Synchronized.
[9.959671] lp: driver loaded but no devices found
[9.974087] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro
[9.996685] ppdev: user-space parallel port driver
[   10.088993] loop: module loaded
[   10.712098] input: Power Button as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1
[   10.712111] ACPI: Power Button [PWRB]
[   10.768385] idma64 idma64.0: Found Intel integrated DMA 64-bit
[   10.771850] input: PC Speaker as /devices/platform/pcspkr/input/input2
[   10.785212] EFI Variables Facility v0.08 2004-May-17
[   10.788785] idma64 idma64.1: Found Intel integrated DMA 64-bit
[   10.809649] idma64 idma64.2: Found Intel integrated DMA 64-bit
[   10.828678] idma64 idma64.3: Found Intel integrated DMA 64-bit
[   10.848828] idma64 idma64.4: Found Intel integrated DMA 64-bit
[   10.868490] idma64 idma64.5: Found Intel integrated DMA 64-bit
[   10.888526] idma64 idma64.6: Found Intel integrated DMA 64-bit
[   10.898088] sd 2:0:0:0: Attached scsi generic sg0 type 0
[   10.898131] sd 3:0:0:0: Attached scsi generic sg1 type 0
[   10.908518] idma64 idma64.7: Found Intel integrated DMA 64-bit
[   10.926527] pstore: Using compression: deflate
[   10.926539] pstore: Registered efi as persistent store backend
[   10.928651] idma64 idma64.8: Found Intel integrated DMA 64-bit
[   10.948528] idma64 idma64.9: Found Intel integrated DMA 64-bit
[   10.963294] RAPL PMU: API unit is 2^-32 Joules, 4 fixed counters, 655360 ms 
ovfl timer
[   10.963296] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[   10.963297] RAPL PMU: hw unit of domain package 2^-14 Joules
[   10.963298] RAPL PMU: hw unit of domain dram 2^-14 Joules
[   10.963298] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
[   10.966117] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   10.968618] idma64 idma64.10: Found Intel integrated DMA 64-bit
[   11.088462] Intel(R) Wireless WiFi driver for Linux
[   11.088464] Copyright(c) 2003- 2015 Intel Corporation
[   11.088575] iwlwifi :05:00.0: enabling device ( -> 0002)
[   11.125442] input: MSI WMI hotkeys as /devices/virtual/input/input3
[   11.287781] iwlwifi :05:00.0: firmware: direct-loading firmware 
iwlwifi-3168-29.ucode
[   11.288156] iwlwifi :05:00.0: loaded firmware version 29.1044073957.0 
op_mode iwlmvm
[   11.304417] Bluetooth: Core ver 2.22
[   11.304451] NET: Registered protocol family 31
[   11.304452] Bluetooth: HCI device and connection manager initialized
[   11.304457] Bluetooth: HCI socket layer initialized
[   11.304459] Bluetooth: L2CAP socket layer initialized
[   11.304467] Bluetooth: SCO socket layer initialized
[   11.375918] audit: type=1326 audit(1613951009.927:2): auid=4294967295 uid=0 
gid=0 ses=4294967295 subj==unconfined pid=415 comm="libinput-device" 
exe="/lib/udev/libinput-device-group" sig=31 arch=4003 syscall=45 compat=1 
ip=0xf7f6ec37 code=0x0
[   11.375923] audit: type=1326 

Bug#983291: [Pkg-fonts-devel] Bug#983291: fonts-noto-core: Excessive fonts bundles in fonts-noto-core make desired font selection painful

2021-02-21 Thread Jonas Smedegaard
Hi Dan,

Quoting Dan Dascalescu (2021-02-22 00:42:28)
> The issue is that the fonts-noto-core package bundles together a very 
> large number (over 190[1]) of exotic fonts. While the aim of covering 
> all Unicode scripts (65+) means the package covers our bases for 
> individual users on every locale imaginable, it also presents a 
> challenge for font selectors in applications, and for *all* users 
> using them.

I agree that it makes sense to split the Noto fonts into more packages.


> My proposal is simple: split the package in at least two components 
> that can be installed and removed independently. From what I can see 
> in the package manifest, the following fonts might have general 
> applicability:
> 
> Noto Sans
> Noto Sans Linear {A,B}
> Noto Sans Display
> Noto Sans Math
> Noto Sans Symbols
> Noto Sans Symbols2
> Noto Serif
> 
> These would comprise one package. For simplicity, the other package 
> can contain all other 180+ fonts.

I would prefer to relieve the pain also for _all_ users, however.

Probably makes sense to group by writing system¹ since they are commonly 
tied to cultural groups.  I imagine that it is more common e.g. for 
users in South India to need other South Indian scripts (and maybe North 
Indian scripts as well), than it is for them to need Canadian Syllabics.


¹ https://en.wikipedia.org/wiki/Writing_system


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature


Bug#983293: autopkgtest: testbed difference between lxc and qemu affecting mmdebstrap

2021-02-21 Thread Ryutaroh Matsumoto
Package: autopkgtest
Version: 5.16
Severity: important
Tags: bullseye sid

Dear Maintainer,

I report yet another testbed difference between lxc and qemu,
affecting mmdebstrap 0.7.5-1 testsuite. My testbeds were
prepared by  debci setup -f -a amd64 -s bullseye -b ...

On lxc testbed, the testsuite always return 
testsuiteSKIP exit status 77 and marked as skippable
while on qemu it always return
testsuiteFAIL non-zero exit status 1

testsuite-stderr on qemu ends as:
+ capsh --drop=cap_sys_admin -- -c exec "$@" exec mmdebstrap --mode=root 
--variant=apt testing /tmp/debian-chroot http://127.0.0.1/debian
E: root mode requires mount which requires CAP_SYS_ADMIN
+ ret=25
+ [ 25 = 0 ]
+ rm -r /tmp/debian-chroot
rm: cannot remove '/tmp/debian-chroot': No such file or directory
test.sh failed

In addition to the above, the newest test result of mmdebstrap 0.7.5-1 on 
ci.debian.net is "PASS",
which is different from both of the above.

I am unsure if this is a duplicate of #983197 or #983186.
Test logs are attached.

Best regards, Ryutaroh Matsumoto

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

Kernel: Linux 5.9.16-preempt (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages autopkgtest depends on:
ii  apt-utils   2.1.20
ii  libdpkg-perl1.20.7.1
ii  procps  2:3.3.16-5
ii  python3 3.9.1-1
ii  python3-debian  0.1.39

Versions of packages autopkgtest recommends:
ii  autodep8  0.24

Versions of packages autopkgtest suggests:
ii  lxc   1:4.0.6-1
pn  lxd   
ii  ovmf  2020.11-2
ii  qemu-efi-aarch64  2020.11-2
ii  qemu-efi-arm  2020.11-2
ii  qemu-system   1:5.2+dfsg-3
ii  qemu-utils1:5.2+dfsg-3
pn  schroot   
ii  vmdb2 0.22-1

-- no debconf information


mmdebstrap-autopkgtest-log.tar.xz
Description: application/xz


Bug#980607: [PATCH] netcfg: FTBFS: test/test_inet_mton.c:12:15: error: too many arguments for format [-Werror=format-extra-args]

2021-02-21 Thread John Paul Adrian Glaubitz



> On Feb 22, 2021, at 12:24 AM, Francisco Vilmar Cardoso Ruviaro 
>  wrote:
> 
> Hello everyone,
> 
> I would like to help with this,
> I reviewed the patches (thanks Dennis) and created an MR at
> https://salsa.debian.org/installer-team/netcfg/-/merge_requests/5.
> 
> As Bart said, the patches solve the FTBFS.
> 
> I intend to make a delayed NMU in 7 days.

That shouldn’t be necessary as Holger is usually very quick working on d-i 
issues.

If Holger isn’t available, I can merge the patch and upload the updated package.

Adrian


Bug#983292: nn: add "active_directory" to "global.h" and "variable.c"

2021-02-21 Thread Bjarni Ingi Gislason
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From d0ae4064ab527fcf17f762a2e8960981e870d7c9 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sun, 21 Feb 2021 23:54:23 +
>Subject: [PATCH] add "active_directory" to files "global.h" and "variable.c"

  global.h: Declare the variable "active_directory".

  variable.c: define the string "active-directory" in the array
"variables[]".

Signed-off-by: Bjarni Ingi Gislason 
---
 global.h   | 2 +-
 variable.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/global.h b/global.h
index cd7d24e..8fe3682 100644
--- a/global.h
+++ b/global.h
@@ -95,7 +95,7 @@ typedef int (*fct_type) ();
  */
 
 extern char
-   *nn_directory, *lib_directory, version_id[];
+   *active_directory, *nn_directory, *lib_directory, version_id[];
 
 extern int  use_nntp;  /* 1 iff we are using nntp */
 
diff --git a/variable.c b/variable.c
index 68cc1f0..2dceaad 100644
--- a/variable.c
+++ b/variable.c
@@ -199,6 +199,7 @@ static struct variable_defs {
 char  **var_addr;
 }   variables[] = {
 
+{"active-directory", STR 2, (char **) _directory},
 {"also-full-digest", BOOL 0, (char **) _full_digest},
 {"also-subgroups", BOOL INIT 0, (char **) _subgroups},
 {"append-signature-mail", BOOL 0, (char **) _sig_mail},
-- 
2.30.0



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason



Bug#954118: munin-plugins-core: apt_all is all broken

2021-02-21 Thread devel
Hello Cyril,


On Mon, 30 Mar 2020 20:34:41 +0200 Cyril Brulebois  wrote:
> Beware, starting with bullseye (Debian 11, currently in “testing” mode),
> the security suite will be named -updates rather than
> /updates.

Thanks for the hint. This is now handled properly since Munin 2.0.65.


> I'll see what happens in the upcoming days/weeks; I already anticipate
> that I'll have to tweak the limits for some suites: “apt-get
> dist-upgrade” would only upgrade packages from the “-backports”
> suite *if they are currently installed from there*, while it seems the
> new apt_all plugin reports all packages that could be upgraded there,
> even if the current version is that of the base … I can expand
> with some example if you'd like.
> 
> 
> FWIW: That's the usual behaviour for suites configured with:
> 
> NotAutomatic: yes
> ButAutomaticUpgrades: yes
> 
> which is the case for *-backports suites (experimental is a little
> different).

Maybe you could take a look at the current state of your apt_all tracking?

I would be glad to fix remaining details for Bullseye, if possible.

Thank you!

Cheers,
Lars



Bug#983290: Acknowledgement (worklog: summary prints 0.0 even when no work done)

2021-02-21 Thread Jon Daley
I see that this bug was introduced when adding code that I requested 
previously, so it must have just had a patch applied incorrectly or 
something, so I'm now more confident that my patch exactly fixes the issue 
- I was previously trying to figure out if you were trying to change 
behavior.  :)



P.S. thanks for taking over the package - I see the other stuff you've 
fixed, it's great to have someone else working on it!




--
Jon Daley
http://jon.limedaley.com
~~
You can fool too many of the people too much of the time.
-- James Thurber



Bug#983291: fonts-noto-core: Excessive fonts bundles in fonts-noto-core make desired font selection painful

2021-02-21 Thread Dan Dascalescu
Package: fonts-noto-core
Version: 20200323-1build1~ubuntu20.04.1
Severity: important

After gathering feedback from several distros and user forums,
I would like to make a suggestion for the fonts-noto package that I
believe will save a significant amount of time for the vast majority of
users, and will provide backwards compatibility with the status quo.

The issue is that the fonts-noto-core package bundles together a very
large number (over 190[1]) of exotic fonts. While the aim of covering
all Unicode scripts (65+) means the package covers our bases for
individual users on every locale imaginable, it also presents a
challenge for font selectors in applications, and for *all* users using
them.

Some applications freeze while trying to render so many fonts.[2]

But more importantly, a typical user is likely to only use *one* of these
language fonts, if any (Ubuntu Desktop statistics show that the majority
of users use the English locale.[3]) Every time a user needs to select
a font, the font selector is cluttered by ~190 fonts they do not need.[4]
Even only 5 seconds wasted scrolling through this list of unnecessary
fonts, and only 1 font selection per day, amounts to several tens of
thousands of person-hours wasted each day, when scaled to the entire
user base.[5]

Uninstalling the fonts is commonly requested[6], but far from trivial[7],
or even impossible[8].

My proposal is simple: split the package in at least two components
that can be installed and removed independently. From what I can see
in the package manifest, the following fonts might have general
applicability:

Noto Sans
Noto Sans Linear {A,B}
Noto Sans Display
Noto Sans Math
Noto Sans Symbols
Noto Sans Symbols2
Noto Serif

These would comprise one package. For simplicity, the other package can
contain all other 180+ fonts. One of them might be useful for users
in certain locales, two for a few bilingual/multilingual users who might
need more than one script, and more than two, only for very specialized
cases (language researchers?).

The meta package can still pull in all dependencies, but this will allow
the vast majority of users to easily uninstall the fonts they don't need.

Note that while I am a software engineer, I am not familiar with
Linux development, so please excuse any potential naivete when it
comes to the arcane details of Debian packaging. I do believe that,
conceptually, the solution I've proposed above makes sense, and I trust
that the ingenuity of Debian maintainers will make its implementation
possible.


[1]: https://packages.debian.org/sid/fonts-noto-core
[2]: https://bugs.launchpad.net/pinta/+bug/1916373
[3]: https://ubuntu.com/desktop/statistics
[4]:
https://askubuntu.com/questions/1140030/how-to-disable-unused-asiatic-fonts
[5]:
https://web.archive.org/web/20170717075850/https://insights.ubuntu.com/about/
[6]: https://askubuntu.com/questions/820746/remove-unused-fonts
[7]:
https://askubuntu.com/questions/214950/how-can-i-remove-fonts-that-i-never-use-from-libreoffice-and-linux-in-general
[8]: https://bugs.kde.org/show_bug.cgi?id=433215


-- Package-specific info:
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version   Architecture Description
+++-==-=--=
ii  fontconfig 2.13.1-2ubuntu3   amd64generic font
configuration library - support binaries
ii  libfreetype6:amd64 2.10.1-2ubuntu0.1 amd64FreeType 2 font
engine, shared library files
ii  libxft2:amd64  2.3.3-0ubuntu1amd64FreeType-based font
drawing library for X

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

-- no debconf information


Bug#982984: Mirror blocked due to repeated errors

2021-02-21 Thread Eduard Bloch
Hallo,
* Eduard Bloch [Sun, Feb 21 2021, 10:59:14AM]:

> > same issue here since upgrade to apt-cacher-ng 3.6-1. Packages apparmor-
> > profiles or apparmor-profiles-extra are not installed.
>
> Ok, so I think we have some kind of strange libevent bug here. Could
> someone please run:
>
> strace -s 4000 -o log.strace -f /usr/lib/apt-cacher-ng/acngtool curl 
> http://www.debian.org

Okay guys, thank you very much for the contributed traces and other
remarks, this helped to track down about two and half real or potential
bugs.

I hope I have identified all root causes for the problems in Russel's
original report, some were specific to evdns (best reproduced in
Michael's setup) which are IMHO bugs in libevent (worth another
bug report there when I have more evidence) and some could be attributed
to a file descriptor introduced in version 3.6 and some are caused by
incorrect (and actually obsolete) algorithms on cache item handling.
I might also have found a reason for hanging acngtool cronjobs along the
way (another bug report). Check
https://salsa.debian.org/blade/apt-cacher-ng/-/commits/upstream/sid if
you want to see the longer story.

If you don't mind, I would kindly ask you to test a snapshot of that,
built locally from debian/sid branch ("fakeroot debian/rules binary") or
check the snapshot builds for amd64 at
https://www.unix-ag.uni-kl.de/~bloch/acng/snap3.6.1/ . If this is still
failing, it would be good to have a similar strace log but attaching to
the daemon process, like:
strace -s 4000 -o log.strace -f -p $(pidof apt-cacher-ng)
and then rerunning the failing operation. It might also make sense to
make another run after taking a break on client activity for 30s or more
in order to trigger the specific behavior leading to this bug.

It would be good to receive some feedback by Wednesday, then I am
planing to approach the release team (expecting the "usual" messy
discussion).

Best regards,
Eduard.



Bug#981253: actually, make that: document minimum and maximum values of all options

2021-02-21 Thread Santiago Garcia Mantinan
> Document the minimum and maximum values of all options, and tell which
> value is the strongest for each.

This will take a lot of time, and I don't know if this is worth the effort.

I'm going to try to go over all of this, as it seems that documentation is
wrong, the kernel guys have changed things around and doc doesn't match
kernel, for example, you asked for portprio... I had to read the kernel code
to know what was happening, right now as of 5.10 this would be...

br_stp_if.c:#define BR_MAX_PORT_PRIORITY ((u16)~0 >> BR_PORT_BITS)
br_private.h:#define BR_PORT_BITS   10

This means that it is set to an unsigned int of 16 bits which is the
complent of 0, which means it is  in binary or  in hexa,
shifted right 10 bits, which makes it 11 or 63 in decimal, so... right
now the values go from 0 to 63.

It looks like by default...
p->priority = 0x8000 >> BR_PORT_BITS;
which would be... 0x20 or 32 in decimal.

And testing shows lower is higher priority.

I'll try to gather info for all this, but looks like it will be time
consuming and that the kernel guys may change it again :-(

Regards...
-- 
Manty/BestiaTester -> http://manty.net



Bug#983290: worklog: summary prints 0.0 even when no work done

2021-02-21 Thread Jon Daley
Package: worklog
Version: 2.1
Severity: minor
Tags: patch

worklog.c: In function ‘exit_handler’:
worklog.c:365:7: warning: ‘seconds’ may be used uninitialized in this function 
[-Wmaybe-uninitialized]
 if(!seconds)

Because seconds is unitialized, the summary always prints incorrectly, always 
printing out the last project even if that wasn't touched, and not printing 
anything else.

The following patch fixes the bug.

364a365
>   seconds=(double) project->time;
367d367
<   seconds=(double) project->time;




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

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

Versions of packages worklog depends on:
ii  libc62.28-10
ii  libncurses6  6.1+20181013-2+deb10u2
ii  libtinfo66.1+20181013-2+deb10u2

worklog recommends no packages.

worklog suggests no packages.

-- no debconf information


Bug#983289: ITP: traefik -- The Cloud Native Application Proxy

2021-02-21 Thread Aloïs Micard

Package: wnpp
Severity: wishlist
Owner: Aloïs Micard 

* Package name: traefik
  Version : 2.4.3-1
  Upstream Author : Traefik Labs
* URL : https://github.com/traefik/traefik
* License : Expat
  Programming Lang: Go
  Description : The Cloud Native Application Proxy

 Traefik is a modern HTTP reverse proxy and load balancer that makes
 deploying microservices easy. Traefik integrates with existing
 infrastructure components such as Docker/Swarm/Kubernetes, etc...

Cheers!

--
Aloïs Micard (creekorful) 

GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2



Bug#980607: [PATCH] netcfg: FTBFS: test/test_inet_mton.c:12:15: error: too many arguments for format [-Werror=format-extra-args]

2021-02-21 Thread Francisco Vilmar Cardoso Ruviaro
Hello everyone,

I would like to help with this,
I reviewed the patches (thanks Dennis) and created an MR at
https://salsa.debian.org/installer-team/netcfg/-/merge_requests/5.

As Bart said, the patches solve the FTBFS.

I intend to make a delayed NMU in 7 days.

Regards,
-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00



OpenPGP_signature
Description: OpenPGP digital signature


Bug#971713: sysstat: init or systemd file has overlapping runlevels

2021-02-21 Thread Matthew Vernon

On 21/02/2021 22:30, Vincent Lefevre wrote:

On 2021-02-21 14:06:20 -0400, Jesse Smith wrote:

A new version of SysV init and innserv have been published today. The
new version of insserv (1.23.0) fixes the above issue. It can be
downloaded from here: http://download.savannah.nongnu.org/releases/sysvinit/


There is a new version of initscripts in unstable, and this is now
much worse, as I get many identical warning messages:


I don't think the new initscripts can be relevantly responsible - the 
change from -5 shouldn't have affected any of this; likewise the insserv 
package I uploaded was to the delayed queue, so isn't in unstable yet.


Regards,

Matthew



Bug#983288: db.c: add subroutine "readpartactfile"

2021-02-21 Thread Bjarni Ingi Gislason
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From c8c65bbca53fba5acac88955bb15b47cb66e1b19 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sun, 21 Feb 2021 19:15:05 +
>Subject: [PATCH] db.c: add subroutine "readpartactfile"

Signed-off-by: Bjarni Ingi Gislason 
---
 db.c | 120 +++
 1 file changed, 120 insertions(+)

diff --git a/db.c b/db.c
index 4278dda..99c2695 100644
--- a/db.c
+++ b/db.c
@@ -44,6 +44,7 @@ static void db_init_group(group_header * gh, int num);
 static void db_init_active(group_header * gh);
 static void readtimfile(void);
 static void readactfile(void);
+static void readpartactfile(void);
 static void
 db_fixup_cross_postings(data_header * dhp,
data_dynamic_data * ddp,
@@ -1112,6 +1113,125 @@ readactfile(void)
 
 }
 
+
+static void
+readpartactfile(void)
+{
+char*cp;
+charactline[512];
+charnewsrcline[256];
+int count = 0;
+int i, n;
+FILE   *actfp;
+stlist_t   *sthead, *stp = NULL;
+int get_group_line(const char *, char *, size_t);
+extern char*newsrc_file;
+static FILE*f_user = NULL;
+extern int  nntp_debug;
+
+if (actlist != NULL)
+   return;
+
+if (newsrc_file == NULL)
+   newsrc_file = home_relative(".newsrc");
+
+actfp = fopen(newsrc_file, "r");
+
+if (actfp == NULL) {
+   nn_exitmsg(1, "could not open .newsrc file %s\n", newsrc_file);
+}
+
+/*
+ * Snarf all of active up in first pass.  This gives us a count of the
+ * groups we can use for internal tables.
+ */
+sthead = NULL;
+gotoxy(0, 3);
+tprintf("Reading active file for groups in %s ... ", newsrc_file);
+fflush(stdout);
+strcpy(actline, "GROUP ");
+
+if (nntp_debug) {
+   if (f_user == NULL) {
+/*f_user = open_file(relative(nn_directory, 
"partial_active_file"), OPEN_CREATE);*/
+f_user = open_file(relative(active_directory, 
"partial_active_file"), OPEN_CREATE);
+   if (f_user == NULL) {
+   msg("Could not open file in the %s directoy for writing the 
active file\n", nn_directory);
+   }
+   }
+}
+while (fgets(newsrcline, sizeof newsrcline, actfp))
+
+{
+/* Get the group name from the .newsrc file and the data with the GROUP
+   nntp command.  Data in actline should be the same as from the "LIST"
+   command group: last first p
+*/
+   if ((cp = strchr(newsrcline, ':')) == NULL)
+   continue;
+   *cp = NUL;
+   n = get_group_line(newsrcline, actline, sizeof actline);
+
+   if (n != OK_GROUP) {
+   msg("newsrc-group %s is not on server", newsrcline);
+   continue;
+   }
+   if (nntp_debug  && (f_user != NULL))
+   fprintf(f_user, "%s\n", actline);
+
+/* tprintf("%s\n", actline);
+   nn_exitmsg(1, "Testing ask_server\n");
+*/
+   stlist_t   *stnew = (stlist_t *) strkeep(actline, 
sizeof(stlisthdr_t), POOL_ACT);
+   if (stnew == NULL) {
+   nn_exitmsg(1, "Out of memory for active file (at line %d)\n", count 
+ 1);
+   }
+   if (sthead != NULL) {
+   stp->n.next = stnew;
+   stp = stnew;
+   } else {
+   sthead = stnew;
+   stp = sthead;
+   }
+   count++;
+}
+stp->n.next = NULL;
+
+if (!use_nntp)
+   (void) fclose(actfp);
+
+actlist = (char **) calloc(count + 1, sizeof(char *));
+grplist = (char **) calloc(count + 1, sizeof(char *));
+if (grplist == NULL) {
+   nn_exitmsg(1, "can't create active or group list (%d entries)\n",
+  count + 1);
+}
+
+/*
+ * Second pass (in core): Put active lines and group names into string
+ * arrays.
+ */
+
+for (i = 0, stp = sthead; stp && i < count; stp = stp->n.next, i++) {
+   char   *p = strchr(stp->str, ' ');
+
+   if (p == NULL)
+   actlist[i] = NULL;
+   else {
+   *p++ = NUL;
+   actlist[i] = p;
+   }
+   grplist[i] = strkeep(stp->str, 0, POOL_GRP);
+}
+tprintf("done.  %d groups.\n\n", count);
+actlist[count] = NULL;
+grplist[count] = NULL;
+
+/* init the master struct */
+clearobj(, sizeof(master), 1);
+master.number_of_groups = count;
+}
+
 #endif /* NOV */
 
 
-- 
2.30.0



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason



Bug#983239: libbio-db-ncbihelper-perl: (autopkg)test failures when network is available

2021-02-21 Thread Aaron M. Ucko
Étienne Mollier writes:

> I have been looking in the issue below in the package
> libbio-db-ncbihelper-perl.  If I understood correctly, the main
> point of the package is to rely on resources made available on
> the Internet.

I'm not sure I've been personally involved with this package, but that's
my understanding as well.

> a perhaps magic index to refer to human genome, but maybe it is
> a "well known index".)

Per [1], taxonomic ID *numbers* are stable in general, but the
associated *names* occasionally change to reflect improved
understandings of the underlying science.  AFAICT from [2] (as linked
from [3]), this change is correct and legitimate; moreover, it looks
like 'Actinobacteria' should now appear in $n->common_names, if anyone
wants to verify that.

[1] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7408187/
[2] 
https://www.microbiologyresearch.org/content/journal/ijsem/10.1099/ijsem.0.003920
[3] 
https://www.ncbi.nlm.nih.gov/Taxonomy/Browser/wwwtax.cgi?mode=Info=1760=3=f=1=1

> In any case, I though upstream would be interested, so I took
> the liberty to open an issue in their VCS.

Thanks!

gregor herrmann  writes:

> I still think that NO_NETWORK_TESTING=1 should be set in debian/rules
> to make sure there's no internet access attempted during the build,
> as that is a policy violation.

Right, we're just discussing what to do about the autopkgtest.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Bug#983287: bugs.debian.org: Onboard NIC running at 10 Mbps vs 1000 Mbps

2021-02-21 Thread Jake
Package: bugs.debian.org
Severity: normal

Duplication steps:

* Assemble a network with 1000 Mb/s capabilities. (switch, router, etc).
* Obtain a Lenovo Thinkpad T480s or T490. These devices are equiped with a 1000
Mb/s NIC.

* Install debian 10 (stable / latest) on said device.

* Plug in a CAT6 /a ethernet cable from the switch to the onboard NIC.

Expected result: NIC autonegotiates as 1000 Mb/s.

Actual result: NIC autonegotiates as 10 Mb/s.

Other notes:

Unplugging the cable and plugging it back in quickly (under 2 seconds)
successfully results in the NIC running at 1000 Mbps.

Connecting via a Thunderbolt dock with 1000 Mb/s port works successfully every
time.

Please note that this post does a much better job of explaining the issue,
although it was for Fedora v 30 on a Lenovo Thinkpad T480s.

https://bugzilla.redhat.com/show_bug.cgi?id=1627816



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

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



Bug#983286: rsyslog stops writing logs until restarted

2021-02-21 Thread Rob N
Package: rsyslog
Version: 8.1901.0-1
Severity: important
Tags: upstream patch

Dear Maintainer,

In high-volume situations, omfile with asyncWriting enabled can stop
writing to output files and remain stuck there until rsyslog is
restarted.

I have seen this twice in the last couple of months on my buster hosts.

Upstream bug report: https://github.com/rsyslog/rsyslog/issues/1701

Upstream fix: https://github.com/rsyslog/rsyslog/pull/2794

This patch was released in upstream v8.2012, and so is likely also fixed
in Debian's rsyslog 8.2012.0-1 (testing) and 8.2102.0-2 (unstable). I
suggest a backported patch for the next stable point release and/or an
updated package on buster-backports would be nice for those who don't
have the ability to patch and build their own packages.

Thanks!
Rob N.


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

Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages rsyslog depends on:
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-10
ii  libestr0 0.1.10-2.1
ii  libfastjson4 0.99.8-2
ii  liblognorm5  2.0.5-1
ii  libsystemd0  241-7~deb10u6
ii  libuuid1 2.33.1-0.1
ii  lsb-base 10.2019051400
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages rsyslog recommends:
ii  logrotate  3.14.0-4

Versions of packages rsyslog suggests:
pn  rsyslog-doc
ii  rsyslog-gnutls 8.1901.0-1
pn  rsyslog-gssapi 
pn  rsyslog-mongodb
pn  rsyslog-mysql | rsyslog-pgsql  
pn  rsyslog-relp   

-- Configuration Files:
/etc/logrotate.d/rsyslog changed [not included]
/etc/rsyslog.conf changed [not included]

-- no debconf information



Bug#983284: dbab: Requires internet connection in postinst

2021-02-21 Thread Tong Sun
Control: close -1
thanks

As we've already discussed, the situation has already been covered by
the script, e.g.,

https://github.com/suntong/dbab/blob/123c1bf3cfedd3872f1e87203258401e0ea92a46/bin/dbab-get-list#L21-L25

and You've confirmed that with "喔那这个挺好的,应该没问题了"

Thanks for helping, for this and all other issues that I had.

Cheers

On Sun, Feb 21, 2021 at 5:21 PM Boyuan Yang  wrote:
>
> Package: dbab
> Version: 15.01-1
> Severity: normal
>
> Package dbab will use curl to download artifects in postinst script. If
> the curl connection fails, the postinst script will directly fail,
> leaving the package unconfigured.
>
> Please consider making the whole process more robust and handle the
> condition where curl fails.
>
> Thanks,
> Boyuan Yang



Bug#971713: sysstat: init or systemd file has overlapping runlevels

2021-02-21 Thread Vincent Lefevre
On 2021-02-21 14:06:20 -0400, Jesse Smith wrote:
> A new version of SysV init and innserv have been published today. The
> new version of insserv (1.23.0) fixes the above issue. It can be
> downloaded from here: http://download.savannah.nongnu.org/releases/sysvinit/

There is a new version of initscripts in unstable, and this is now
much worse, as I get many identical warning messages:

[...]
Setting up initscripts (2.96-6) ...
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.

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



Bug#983285: openrc: /etc/init.d/cgroups has no LSB headers

2021-02-21 Thread Adam Borowski
Package: openrc
Version: 0.42-2
Severity: normal

Even though openrc doesn't require LSB headers here, insserv loudly
repeatedly complains, making some dpkg operations produce multiple
screenfuls of:

insserv: warning: script 'cgroups' missing LSB tags
insserv: Default-Start undefined, assuming empty start runlevel(s) for script 
`cgroups'
insserv: Default-Stop  undefined, assuming empty stop runlevel(s) for script 
`cgroups'
insserv: warning: script 'cgroups' missing LSB tags
insserv: Default-Start undefined, assuming empty start runlevel(s) for script 
`cgroups'
insserv: Default-Stop  undefined, assuming empty stop runlevel(s) for script 
`cgroups'
insserv: warning: script 'cgroups' missing LSB tags
insserv: Default-Start undefined, assuming empty start runlevel(s) for script 
`cgroups'
insserv: Default-Stop  undefined, assuming empty stop runlevel(s) for script 
`cgroups'

Adding even dummy headers would make insserv happy.


Meow!
-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.0-3-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages openrc depends on:
ii  insserv  1.21.0-1
ii  libaudit11:3.0-2
ii  libc62.31-9
ii  libeinfo10.42-2
ii  libpam0g 1.4.0-4
ii  librc1   0.42-2
ii  libselinux1  3.1-3

openrc recommends no packages.

Versions of packages openrc suggests:
pn  policycoreutils  
ii  sysvinit-core2.96-6

-- no debconf information



Bug#983239: libbio-db-ncbihelper-perl: (autopkg)test failures when network is available

2021-02-21 Thread gregor herrmann
On Sun, 21 Feb 2021 22:23:20 +0100, Étienne Mollier wrote:

> As the purpose of the package is to fetch resources on the web,
> I did something better described by the following commit[1].
> 
> [1] 
> https://salsa.debian.org/med-team/libbio-db-ncbihelper-perl/-/commit/bde35697e319417ae17367d51aaa868c43e1715d
> 
> It looked to me like the most sensible thing to do, since the
> entire set of tests part of smoke are otherwise skipped.

I see your point, and in the end it's a matter of taste, I guess; or
a choice between two bad options:
- skipping tests and missing bugs
- enabling tests and having to deal with failures because of internet
  problems, server problems, changes in returned data etc.

Having seen too much of the latter, I prefer the former but as I
said, that's not the only option :)


I still think that NO_NETWORK_TESTING=1 should be set in debian/rules
to make sure there's no internet access attempted during the build,
as that is a policy violation.

(Sorry if that's already the case for _this_ package, I might confuse
the 3 libbio.*-perl packages I looked at today and which all have a
similar situation.)

As a side note to the autopkg-tests: The "heavy" tests don't exists,
that was just an idea when we started with the framework, so you can
remove the last paragraph.


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: Peter, Paul and Mary: Leaving On A Jet Plane


signature.asc
Description: Digital Signature


Bug#965291:

2021-02-21 Thread J. Smith
I was unable to reproduce this.

If it still happens with Emacs 27.1, I encourage you to report it to the Emacs 
developers with M-x report-emacs-bug. They will need:

1) A complete, minimal example that shows the problem (eg lists exactly which 
version of helm and its dependencies you installed).

2) The output of addr2line, as per 
https://www.gnu.org/software/emacs/manual/html_node/emacs/Crashing.html



Bug#983284: dbab: Requires internet connection in postinst

2021-02-21 Thread Boyuan Yang
Package: dbab
Version: 15.01-1
Severity: normal

Package dbab will use curl to download artifects in postinst script. If
the curl connection fails, the postinst script will directly fail,
leaving the package unconfigured.

Please consider making the whole process more robust and handle the
condition where curl fails.

Thanks,
Boyuan Yang


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


Bug#904333: Bug904333

2021-02-21 Thread J. Smith
I was unable to reproduce this.
If it still happens with Emacs 27.1, I encourage you to report it to the Emacs 
developers with M-x report-emacs-bug.



Bug#983283: cpl-plugin-uves: demote sphinx dependency to B-

2021-02-21 Thread Helmut Grohne
Source: cpl-plugin-uves
Version: 6.1.3+dfsg-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

cpl-plugin-uves cannot be cross built from source, because its sphinx
dependency is not satisfiable. Since the documentation is already split
to an arch:all package and the documentation is only built during an
arch-only build, all that needs doing is restricting the usage of the
shpinxdoc addon to the indep part. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru cpl-plugin-uves-6.1.3+dfsg/debian/changelog 
cpl-plugin-uves-6.1.3+dfsg/debian/changelog
--- cpl-plugin-uves-6.1.3+dfsg/debian/changelog 2020-07-02 09:39:10.0 
+0200
+++ cpl-plugin-uves-6.1.3+dfsg/debian/changelog 2021-02-21 22:30:39.0 
+0100
@@ -1,3 +1,10 @@
+cpl-plugin-uves (6.1.3+dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Request sphinxdoc addon via B-D-I. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 21 Feb 2021 22:30:39 +0100
+
 cpl-plugin-uves (6.1.3+dfsg-2) unstable; urgency=low
 
   * Increase tolerance in hdrl_fpn_tests
diff --minimal -Nru cpl-plugin-uves-6.1.3+dfsg/debian/control 
cpl-plugin-uves-6.1.3+dfsg/debian/control
--- cpl-plugin-uves-6.1.3+dfsg/debian/control   2020-07-02 08:47:01.0 
+0200
+++ cpl-plugin-uves-6.1.3+dfsg/debian/control   2021-02-21 22:28:04.0 
+0100
@@ -11,7 +11,8 @@
python3,
python3-astropy,
python3-cpl,
-   python3-sphinx
+Build-Depends-Indep: dh-sequence-sphinxdoc,
+ python3-sphinx
 Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/debian-astro-team/cpl-plugin-uves
 Vcs-Git: https://salsa.debian.org/debian-astro-team/cpl-plugin-uves.git
diff --minimal -Nru cpl-plugin-uves-6.1.3+dfsg/debian/rules 
cpl-plugin-uves-6.1.3+dfsg/debian/rules
--- cpl-plugin-uves-6.1.3+dfsg/debian/rules 2020-07-02 08:43:17.0 
+0200
+++ cpl-plugin-uves-6.1.3+dfsg/debian/rules 2021-02-21 22:27:51.0 
+0100
@@ -11,7 +11,7 @@
sh ./debian/repackage.sh
 
 %:
-   dh  $@ --with sphinxdoc
+   dh  $@
 
 debian_files:
if [ -d calib/cal ] ; then \
@@ -40,11 +40,6 @@
sphinx-build sphinx sphinx/html
dh_installdocs
 
-override_dh_sphinxdoc:
-   if [ -d sphinx ] ; then \
-   dh_sphinxdoc ; \
-   fi
-
 override_dh_clean:
dh_clean
rm -rf debian/${DEB_SOURCE}.install \


Bug#983282: cpl-plugin-giraf: demote sphinx dependency to B-D-I

2021-02-21 Thread Helmut Grohne
Source: cpl-plugin-giraf
Version: 2.16.7+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

cpl-plugin-giraf cannot be cross built from source, because its sphinx
dependency is not satisfiable. Since the documentation is already split
to an arch:all package and the documentation is only built during an
arch-only build, all that needs doing is restricting the usage of the
shpinxdoc addon to the indep part. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru cpl-plugin-giraf-2.16.7+dfsg/debian/changelog 
cpl-plugin-giraf-2.16.7+dfsg/debian/changelog
--- cpl-plugin-giraf-2.16.7+dfsg/debian/changelog   2020-06-29 
10:20:20.0 +0200
+++ cpl-plugin-giraf-2.16.7+dfsg/debian/changelog   2021-02-21 
20:26:46.0 +0100
@@ -1,3 +1,10 @@
+cpl-plugin-giraf (2.16.7+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Request sphinxdoc addon via B-D-I.
+
+ -- Helmut Grohne   Sun, 21 Feb 2021 20:26:46 +0100
+
 cpl-plugin-giraf (2.16.7+dfsg-1) unstable; urgency=low
 
   * New upstream version 2.16.7+dfsg
diff --minimal -Nru cpl-plugin-giraf-2.16.7+dfsg/debian/control 
cpl-plugin-giraf-2.16.7+dfsg/debian/control
--- cpl-plugin-giraf-2.16.7+dfsg/debian/control 2020-06-29 10:19:53.0 
+0200
+++ cpl-plugin-giraf-2.16.7+dfsg/debian/control 2021-02-21 20:25:25.0 
+0100
@@ -8,7 +8,8 @@
python3,
python3-astropy,
python3-cpl,
-   python3-sphinx
+Build-Depends-Indep: dh-sequence-sphinxdoc,
+ python3-sphinx
 Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/debian-astro-team/cpl-plugin-giraf
 Vcs-Git: https://salsa.debian.org/debian-astro-team/cpl-plugin-giraf.git
diff --minimal -Nru cpl-plugin-giraf-2.16.7+dfsg/debian/rules 
cpl-plugin-giraf-2.16.7+dfsg/debian/rules
--- cpl-plugin-giraf-2.16.7+dfsg/debian/rules   2020-06-29 10:19:53.0 
+0200
+++ cpl-plugin-giraf-2.16.7+dfsg/debian/rules   2021-02-21 20:25:11.0 
+0100
@@ -11,7 +11,7 @@
sh ./debian/repackage.sh
 
 %:
-   dh  $@ --with sphinxdoc
+   dh  $@
 
 debian_files:
if [ -d calib/cal ] ; then \
@@ -40,11 +40,6 @@
sphinx-build sphinx sphinx/html
dh_installdocs
 
-override_dh_sphinxdoc:
-   if [ -d sphinx ] ; then \
-   dh_sphinxdoc ; \
-   fi
-
 override_dh_clean:
dh_clean
rm -rf debian/${DEB_SOURCE}.install \


Bug#983281: cpl-plugin-vimos: demote sphinx dependency to B-D-I

2021-02-21 Thread Helmut Grohne
Source: cpl-plugin-vimos
Version: 4.1.1+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

cpl-plugin-vimos cannot be cross built from source, because its sphinx
dependency is not satisfiable. Since the documentation is already split
to an arch:all package and the documentation is only built during an
arch-only build, all that needs doing is restricting the usage of the
shpinxdoc addon to the indep part. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru cpl-plugin-vimos-4.1.1+dfsg/debian/changelog 
cpl-plugin-vimos-4.1.1+dfsg/debian/changelog
--- cpl-plugin-vimos-4.1.1+dfsg/debian/changelog2020-11-19 
13:51:18.0 +0100
+++ cpl-plugin-vimos-4.1.1+dfsg/debian/changelog2021-02-21 
22:30:22.0 +0100
@@ -1,3 +1,10 @@
+cpl-plugin-vimos (4.1.1+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Request sphinxdoc addon via B-D-I. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 21 Feb 2021 22:30:22 +0100
+
 cpl-plugin-vimos (4.1.1+dfsg-1) unstable; urgency=medium
 
   * New upstream version 4.1.1+dfsg
diff --minimal -Nru cpl-plugin-vimos-4.1.1+dfsg/debian/control 
cpl-plugin-vimos-4.1.1+dfsg/debian/control
--- cpl-plugin-vimos-4.1.1+dfsg/debian/control  2020-07-02 08:24:29.0 
+0200
+++ cpl-plugin-vimos-4.1.1+dfsg/debian/control  2021-02-21 22:30:07.0 
+0100
@@ -10,7 +10,8 @@
python3,
python3-astropy,
python3-cpl,
-   python3-sphinx
+Build-Depends-Indep: dh-sequence-sphinxdoc,
+ python3-sphinx
 Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/debian-astro-team/cpl-plugin-vimos
 Vcs-Git: https://salsa.debian.org/debian-astro-team/cpl-plugin-vimos.git
diff --minimal -Nru cpl-plugin-vimos-4.1.1+dfsg/debian/rules 
cpl-plugin-vimos-4.1.1+dfsg/debian/rules
--- cpl-plugin-vimos-4.1.1+dfsg/debian/rules2020-11-19 13:51:18.0 
+0100
+++ cpl-plugin-vimos-4.1.1+dfsg/debian/rules2021-02-21 22:29:53.0 
+0100
@@ -11,7 +11,7 @@
sh ./debian/repackage.sh
 
 %:
-   dh  $@ --with sphinxdoc
+   dh  $@
 
 debian_files:
if [ -d calib/cal ] ; then \
@@ -40,11 +40,6 @@
sphinx-build sphinx sphinx/html
dh_installdocs
 
-override_dh_sphinxdoc:
-   if [ -d sphinx ] ; then \
-   dh_sphinxdoc ; \
-   fi
-
 override_dh_clean:
dh_clean
rm -rf debian/${DEB_SOURCE}.install \


Bug#983280: cpl-plugin-xshoo: demote sphinx dependency to B-D-I

2021-02-21 Thread Helmut Grohne
Source: cpl-plugin-xshoo
Version: 3.5.0+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

cpl-plugin-xshoo cannot be cross built from source, because its sphinx
dependency is not satisfiable. Since the documentation is already split
to an arch:all package and the documentation is only built during an
arch-only build, all that needs doing is restricting the usage of the
shpinxdoc addon to the indep part. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru cpl-plugin-xshoo-3.5.0+dfsg/debian/changelog 
cpl-plugin-xshoo-3.5.0+dfsg/debian/changelog
--- cpl-plugin-xshoo-3.5.0+dfsg/debian/changelog2020-07-01 
09:03:17.0 +0200
+++ cpl-plugin-xshoo-3.5.0+dfsg/debian/changelog2021-02-21 
22:34:11.0 +0100
@@ -1,3 +1,10 @@
+cpl-plugin-xshoo (3.5.0+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Request sphinxdoc addon via B-D-I. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 21 Feb 2021 22:34:11 +0100
+
 cpl-plugin-xshoo (3.5.0+dfsg-1) unstable; urgency=low
 
   * New upstream version 3.5.0+dfsg. Rediff patches
diff --minimal -Nru cpl-plugin-xshoo-3.5.0+dfsg/debian/control 
cpl-plugin-xshoo-3.5.0+dfsg/debian/control
--- cpl-plugin-xshoo-3.5.0+dfsg/debian/control  2020-07-01 09:02:38.0 
+0200
+++ cpl-plugin-xshoo-3.5.0+dfsg/debian/control  2021-02-21 22:34:09.0 
+0100
@@ -9,7 +9,8 @@
python3,
python3-astropy,
python3-cpl,
-   python3-sphinx
+Build-Depends-Indep: dh-sequence-sphinxdoc,
+ python3-sphinx
 Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/debian-astro-team/cpl-plugin-xshoo
 Vcs-Git: https://salsa.debian.org/debian-astro-team/cpl-plugin-xshoo.git
diff --minimal -Nru cpl-plugin-xshoo-3.5.0+dfsg/debian/rules 
cpl-plugin-xshoo-3.5.0+dfsg/debian/rules
--- cpl-plugin-xshoo-3.5.0+dfsg/debian/rules2020-07-01 09:02:38.0 
+0200
+++ cpl-plugin-xshoo-3.5.0+dfsg/debian/rules2021-02-21 22:33:57.0 
+0100
@@ -11,7 +11,7 @@
sh ./debian/repackage.sh
 
 %:
-   dh  $@ --with sphinxdoc
+   dh  $@
 
 debian_files:
if [ -d calib/cal ] ; then \
@@ -40,11 +40,6 @@
sphinx-build sphinx sphinx/html
dh_installdocs
 
-override_dh_sphinxdoc:
-   if [ -d sphinx ] ; then \
-   dh_sphinxdoc ; \
-   fi
-
 override_dh_clean:
dh_clean
rm -rf debian/${DEB_SOURCE}.install \


Bug#983279: cpl-plugin-naco: demote sphinx dependency to B-D-I

2021-02-21 Thread Helmut Grohne
Source: cpl-plugin-naco
Version: 4.4.9+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

cpl-plugin-naco cannot be cross built from source, because its sphinx
dependency is not satisfiable. Since the documentation is already split
to an arch:all package and the documentation is only built during an
arch-only build, all that needs doing is restricting the usage of the
shpinxdoc addon to the indep part. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru cpl-plugin-naco-4.4.9+dfsg/debian/changelog 
cpl-plugin-naco-4.4.9+dfsg/debian/changelog
--- cpl-plugin-naco-4.4.9+dfsg/debian/changelog 2020-06-30 10:25:31.0 
+0200
+++ cpl-plugin-naco-4.4.9+dfsg/debian/changelog 2021-02-21 22:28:13.0 
+0100
@@ -1,3 +1,10 @@
+cpl-plugin-naco (4.4.9+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Request sphinxdoc addon via B-D-I. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 21 Feb 2021 22:28:13 +0100
+
 cpl-plugin-naco (4.4.9+dfsg-1) unstable; urgency=low
 
   * New upstream version 4.4.9+dfsg
diff --minimal -Nru cpl-plugin-naco-4.4.9+dfsg/debian/control 
cpl-plugin-naco-4.4.9+dfsg/debian/control
--- cpl-plugin-naco-4.4.9+dfsg/debian/control   2020-06-30 10:25:20.0 
+0200
+++ cpl-plugin-naco-4.4.9+dfsg/debian/control   2021-02-21 22:26:10.0 
+0100
@@ -9,7 +9,8 @@
python3,
python3-astropy,
python3-cpl,
-   python3-sphinx
+Build-Depends-Indep: dh-sequence-sphinxdoc,
+ python3-sphinx
 Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/debian-astro-team/cpl-plugin-naco
 Vcs-Git: https://salsa.debian.org/debian-astro-team/cpl-plugin-naco.git
diff --minimal -Nru cpl-plugin-naco-4.4.9+dfsg/debian/rules 
cpl-plugin-naco-4.4.9+dfsg/debian/rules
--- cpl-plugin-naco-4.4.9+dfsg/debian/rules 2020-06-30 10:25:20.0 
+0200
+++ cpl-plugin-naco-4.4.9+dfsg/debian/rules 2021-02-21 22:25:57.0 
+0100
@@ -11,7 +11,7 @@
sh ./debian/repackage.sh
 
 %:
-   dh  $@ --with sphinxdoc
+   dh  $@
 
 debian_files:
if [ -d calib/cal ] ; then \
@@ -40,11 +40,6 @@
sphinx-build sphinx sphinx/html
dh_installdocs
 
-override_dh_sphinxdoc:
-   if [ -d sphinx ] ; then \
-   dh_sphinxdoc ; \
-   fi
-
 override_dh_clean:
dh_clean
rm -rf debian/${DEB_SOURCE}.install \


Bug#983278: cpl-plugin-amber: demote sphinx dependency to B-D-I

2021-02-21 Thread Helmut Grohne
Source: cpl-plugin-amber
Version: 4.4.0+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

cpl-plugin-amber cannot be cross built from source, because its sphinx
dependency is not satisfiable. Since the documentation is already split
to an arch:all package and the documentation is only built during an
arch-only build, all that needs doing is restricting the usage of the
shpinxdoc addon to the indep part. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru cpl-plugin-amber-4.4.0+dfsg/debian/changelog 
cpl-plugin-amber-4.4.0+dfsg/debian/changelog
--- cpl-plugin-amber-4.4.0+dfsg/debian/changelog2020-07-01 
08:36:18.0 +0200
+++ cpl-plugin-amber-4.4.0+dfsg/debian/changelog2021-02-21 
12:50:08.0 +0100
@@ -1,3 +1,10 @@
+cpl-plugin-amber (4.4.0+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Request sphinxdoc addon via B-D-I.
+
+ -- Helmut Grohne   Sun, 21 Feb 2021 12:50:08 +0100
+
 cpl-plugin-amber (4.4.0+dfsg-1) unstable; urgency=low
 
   * New upstream version 4.4.0+dfsg
diff --minimal -Nru cpl-plugin-amber-4.4.0+dfsg/debian/control 
cpl-plugin-amber-4.4.0+dfsg/debian/control
--- cpl-plugin-amber-4.4.0+dfsg/debian/control  2020-07-01 08:35:13.0 
+0200
+++ cpl-plugin-amber-4.4.0+dfsg/debian/control  2021-02-21 12:50:08.0 
+0100
@@ -10,7 +10,8 @@
python3,
python3-astropy,
python3-cpl,
-   python3-sphinx
+Build-Depends-Indep: dh-sequence-sphinxdoc,
+ python3-sphinx
 Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/debian-astro-team/cpl-plugin-amber
 Vcs-Git: https://salsa.debian.org/debian-astro-team/cpl-plugin-amber.git
diff --minimal -Nru cpl-plugin-amber-4.4.0+dfsg/debian/rules 
cpl-plugin-amber-4.4.0+dfsg/debian/rules
--- cpl-plugin-amber-4.4.0+dfsg/debian/rules2020-07-01 08:35:13.0 
+0200
+++ cpl-plugin-amber-4.4.0+dfsg/debian/rules2021-02-21 12:50:07.0 
+0100
@@ -11,7 +11,7 @@
sh ./debian/repackage.sh
 
 %:
-   dh  $@ --with sphinxdoc
+   dh  $@
 
 debian_files:
if [ -d calib/cal ] ; then \
@@ -40,11 +40,6 @@
sphinx-build sphinx sphinx/html
dh_installdocs
 
-override_dh_sphinxdoc:
-   if [ -d sphinx ] ; then \
-   dh_sphinxdoc ; \
-   fi
-
 override_dh_clean:
dh_clean
rm -rf debian/${DEB_SOURCE}.install \


Bug#983277: cpl-plugin-muse: demote sphinx dependency to B-D-I

2021-02-21 Thread Helmut Grohne
Source: cpl-plugin-muse
Version: 2.8.3+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

cpl-plugin-muse cannot be cross built from source, because its sphinx
dependency is not satisfiable. Since the documentation is already split
to an arch:all package and the documentation is only built during an
arch-only build, all that needs doing is restricting the usage of the
shpinxdoc addon to the indep part. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru cpl-plugin-muse-2.8.3+dfsg/debian/changelog 
cpl-plugin-muse-2.8.3+dfsg/debian/changelog
--- cpl-plugin-muse-2.8.3+dfsg/debian/changelog 2020-06-29 10:06:35.0 
+0200
+++ cpl-plugin-muse-2.8.3+dfsg/debian/changelog 2021-02-21 22:25:23.0 
+0100
@@ -1,3 +1,10 @@
+cpl-plugin-muse (2.8.3+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Request sphinxdoc addon via B-D-I. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 21 Feb 2021 22:25:23 +0100
+
 cpl-plugin-muse (2.8.3+dfsg-1) unstable; urgency=low
 
   * New upstream version 2.8.3+dfsg
diff --minimal -Nru cpl-plugin-muse-2.8.3+dfsg/debian/control 
cpl-plugin-muse-2.8.3+dfsg/debian/control
--- cpl-plugin-muse-2.8.3+dfsg/debian/control   2020-06-29 10:06:35.0 
+0200
+++ cpl-plugin-muse-2.8.3+dfsg/debian/control   2021-02-21 22:25:21.0 
+0100
@@ -8,7 +8,8 @@
python3,
python3-astropy,
python3-cpl,
-   python3-sphinx
+Build-Depends-Indep: dh-sequence-sphinxdoc,
+ python3-sphinx
 Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/debian-astro-team/cpl-plugin-muse
 Vcs-Git: https://salsa.debian.org/debian-astro-team/cpl-plugin-muse.git
diff --minimal -Nru cpl-plugin-muse-2.8.3+dfsg/debian/rules 
cpl-plugin-muse-2.8.3+dfsg/debian/rules
--- cpl-plugin-muse-2.8.3+dfsg/debian/rules 2020-06-29 10:06:35.0 
+0200
+++ cpl-plugin-muse-2.8.3+dfsg/debian/rules 2021-02-21 22:25:07.0 
+0100
@@ -11,7 +11,7 @@
sh ./debian/repackage.sh
 
 %:
-   dh  $@ --with sphinxdoc
+   dh  $@
 
 debian_files:
if [ -d calib/cal ] ; then \
@@ -40,11 +40,6 @@
sphinx-build sphinx sphinx/html
dh_installdocs
 
-override_dh_sphinxdoc:
-   if [ -d sphinx ] ; then \
-   dh_sphinxdoc ; \
-   fi
-
 override_dh_clean:
dh_clean
rm -rf debian/${DEB_SOURCE}.install \


Bug#983276: cpl-plugin-fors: demote sphinx dependency to B-D-I

2021-02-21 Thread Helmut Grohne
Source: cpl-plugin-fors
Version: 5.5.6+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

cpl-plugin-fors cannot be cross built from source, because its sphinx
dependency is not satisfiable. Since the documentation is already split
to an arch:all package and the documentation is only built during an
arch-only build, all that needs doing is restricting the usage of the
shpinxdoc addon to the indep part. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru cpl-plugin-fors-5.5.6+dfsg/debian/changelog 
cpl-plugin-fors-5.5.6+dfsg/debian/changelog
--- cpl-plugin-fors-5.5.6+dfsg/debian/changelog 2020-10-15 16:17:22.0 
+0200
+++ cpl-plugin-fors-5.5.6+dfsg/debian/changelog 2021-02-21 20:23:38.0 
+0100
@@ -1,3 +1,10 @@
+cpl-plugin-fors (5.5.6+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Request sphinxdoc addon via B-D-I. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 21 Feb 2021 20:23:38 +0100
+
 cpl-plugin-fors (5.5.6+dfsg-1) unstable; urgency=medium
 
   * New upstream version 5.5.6+dfsg. Rediff patches
diff --minimal -Nru cpl-plugin-fors-5.5.6+dfsg/debian/control 
cpl-plugin-fors-5.5.6+dfsg/debian/control
--- cpl-plugin-fors-5.5.6+dfsg/debian/control   2020-10-15 16:17:17.0 
+0200
+++ cpl-plugin-fors-5.5.6+dfsg/debian/control   2021-02-21 20:23:37.0 
+0100
@@ -10,7 +10,8 @@
python3,
python3-astropy,
python3-cpl,
-   python3-sphinx
+Build-Depends-Indep: dh-sequence-sphinxdoc,
+ python3-sphinx
 Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/debian-astro-team/cpl-plugin-fors
 Vcs-Git: https://salsa.debian.org/debian-astro-team/cpl-plugin-fors.git
diff --minimal -Nru cpl-plugin-fors-5.5.6+dfsg/debian/rules 
cpl-plugin-fors-5.5.6+dfsg/debian/rules
--- cpl-plugin-fors-5.5.6+dfsg/debian/rules 2020-06-30 10:34:21.0 
+0200
+++ cpl-plugin-fors-5.5.6+dfsg/debian/rules 2021-02-21 20:23:21.0 
+0100
@@ -11,7 +11,7 @@
sh ./debian/repackage.sh
 
 %:
-   dh  $@ --with sphinxdoc
+   dh  $@
 
 debian_files:
if [ -d calib/cal ] ; then \
@@ -40,11 +40,6 @@
sphinx-build sphinx sphinx/html
dh_installdocs
 
-override_dh_sphinxdoc:
-   if [ -d sphinx ] ; then \
-   dh_sphinxdoc ; \
-   fi
-
 override_dh_clean:
dh_clean
rm -rf debian/${DEB_SOURCE}.install \


Bug#983275: cpl-plugin-hawki: demote sphinx dependency to B-D-I

2021-02-21 Thread Helmut Grohne
Source: cpl-plugin-hawki
Version: 2.4.8+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

cpl-plugin-hawki cannot be cross built from source, because its sphinx
dependency is not satisfiable. Since the documentation is already split
to an arch:all package and the documentation is only built during an
arch-only build, all that needs doing is restricting the usage of the
shpinxdoc addon to the indep part. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru cpl-plugin-hawki-2.4.8+dfsg/debian/changelog 
cpl-plugin-hawki-2.4.8+dfsg/debian/changelog
--- cpl-plugin-hawki-2.4.8+dfsg/debian/changelog2020-06-30 
10:09:16.0 +0200
+++ cpl-plugin-hawki-2.4.8+dfsg/debian/changelog2021-02-21 
20:34:20.0 +0100
@@ -1,3 +1,10 @@
+cpl-plugin-hawki (2.4.8+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Request sphinxdoc addon via B-D-I. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 21 Feb 2021 20:34:20 +0100
+
 cpl-plugin-hawki (2.4.8+dfsg-1) unstable; urgency=low
 
   [ Debian Janitor ]
diff --minimal -Nru cpl-plugin-hawki-2.4.8+dfsg/debian/control 
cpl-plugin-hawki-2.4.8+dfsg/debian/control
--- cpl-plugin-hawki-2.4.8+dfsg/debian/control  2020-06-30 10:08:50.0 
+0200
+++ cpl-plugin-hawki-2.4.8+dfsg/debian/control  2021-02-21 20:34:19.0 
+0100
@@ -10,7 +10,8 @@
python3,
python3-astropy,
python3-cpl,
-   python3-sphinx
+Build-Depends-Indep: dh-sequence-sphinxdoc,
+ python3-sphinx
 Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/debian-astro-team/cpl-plugin-hawki
 Vcs-Git: https://salsa.debian.org/debian-astro-team/cpl-plugin-hawki.git
diff --minimal -Nru cpl-plugin-hawki-2.4.8+dfsg/debian/rules 
cpl-plugin-hawki-2.4.8+dfsg/debian/rules
--- cpl-plugin-hawki-2.4.8+dfsg/debian/rules2020-06-30 10:08:50.0 
+0200
+++ cpl-plugin-hawki-2.4.8+dfsg/debian/rules2021-02-21 20:30:04.0 
+0100
@@ -8,7 +8,7 @@
 PIPELINE ?= $(shell echo '$(DEB_SOURCE)' | sed -e 's/cpl-plugin-//')
 
 %:
-   dh  $@ --with sphinxdoc
+   dh  $@
 
 debian_files:
if [ -d calib/cal ] ; then \
@@ -37,11 +37,6 @@
sphinx-build sphinx sphinx/html
dh_installdocs
 
-override_dh_sphinxdoc:
-   if [ -d sphinx ] ; then \
-   dh_sphinxdoc ; \
-   fi
-
 override_dh_clean:
dh_clean
rm -rf debian/${DEB_SOURCE}.install \


Bug#983274: cpl-plugin-visir: demote sphinx dependency to B-D-I

2021-02-21 Thread Helmut Grohne
Source: cpl-plugin-visir
Version: 4.3.10+dfsg-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

cpl-plugin-visir cannot be cross built from source, because its sphinx
dependency is not satisfiable. Since the documentation is already split
to an arch:all package and the documentation is only built during an
arch-only build, all that needs doing is restricting the usage of the
shpinxdoc addon to the indep part. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru cpl-plugin-visir-4.3.10+dfsg/debian/changelog 
cpl-plugin-visir-4.3.10+dfsg/debian/changelog
--- cpl-plugin-visir-4.3.10+dfsg/debian/changelog   2020-08-02 
16:41:42.0 +0200
+++ cpl-plugin-visir-4.3.10+dfsg/debian/changelog   2021-02-21 
22:32:29.0 +0100
@@ -1,3 +1,10 @@
+cpl-plugin-visir (4.3.10+dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Request sphinxdoc addon via B-D-I. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 21 Feb 2021 22:32:29 +0100
+
 cpl-plugin-visir (4.3.10+dfsg-2) unstable; urgency=medium
 
   * Don't build swarp convenience copy. Closes: #957105
diff --minimal -Nru cpl-plugin-visir-4.3.10+dfsg/debian/control 
cpl-plugin-visir-4.3.10+dfsg/debian/control
--- cpl-plugin-visir-4.3.10+dfsg/debian/control 2020-08-02 16:41:42.0 
+0200
+++ cpl-plugin-visir-4.3.10+dfsg/debian/control 2021-02-21 22:32:27.0 
+0100
@@ -8,7 +8,8 @@
python3,
python3-astropy,
python3-cpl,
-   python3-sphinx
+Build-Depends-Indep: dh-sequence-sphinxdoc,
+ python3-sphinx
 Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/debian-astro-team/cpl-plugin-visir
 Vcs-Git: https://salsa.debian.org/debian-astro-team/cpl-plugin-visir.git
diff --minimal -Nru cpl-plugin-visir-4.3.10+dfsg/debian/rules 
cpl-plugin-visir-4.3.10+dfsg/debian/rules
--- cpl-plugin-visir-4.3.10+dfsg/debian/rules   2020-08-02 16:38:57.0 
+0200
+++ cpl-plugin-visir-4.3.10+dfsg/debian/rules   2021-02-21 22:32:14.0 
+0100
@@ -11,7 +11,7 @@
sh ./debian/repackage.sh
 
 %:
-   dh  $@ --with sphinxdoc
+   dh  $@
 
 debian_files:
if [ -d calib/cal ] ; then \
@@ -40,11 +40,6 @@
sphinx-build sphinx sphinx/html
dh_installdocs
 
-override_dh_sphinxdoc:
-   if [ -d sphinx ] ; then \
-   dh_sphinxdoc ; \
-   fi
-
 override_dh_clean:
dh_clean
rm -rf debian/${DEB_SOURCE}.install \


Bug#983273: jellyfish: Homepage: needs updating

2021-02-21 Thread Adrian Bunk
Source: jellyfish
Version: 2.3.0-8
Severity: minor

Homepage: points to a server hosting tarballs for src:jellyfish1,
https://github.com/gmarcais/Jellyfish looks like the correct one.



Bug#794920:

2021-02-21 Thread J. Smith
This report was forwarded to https://sourceforge.net/p/docutils/bugs/283/, 
where it received the comment:
"Indeed this feature isn't implemented yet and probably won't be anytime soon."

Is there any value in keeping the Debian bug report open, or can it be closed?



Bug#983239: libbio-db-ncbihelper-perl: (autopkg)test failures when network is available

2021-02-21 Thread Étienne Mollier
Control: tag -1 upstream
Control: forwarded -1 https://github.com/bioperl/Bio-DB-NCBIHelper/issues/6

Hi Aaron,

I have been looking in the issue below in the package
libbio-db-ncbihelper-perl.  If I understood correctly, the main
point of the package is to rely on resources made available on
the Internet.

On Sun, 21 Feb 2021 14:05:39 +0100 gregor herrmann  wrote:
> not ok 44
> 
> #   Failed test at t/Taxonomy.t line 102.
> #  got: 'Actinomycetia'
> # expected: 'Actinobacteria'

For reference, I see along those lines:

101 ok $n = $db->get_Taxonomy_Node('1760');
102 is $n->scientific_name, 'Actinobacteria';

I would think the test 44 in t/Taxonomy.t is fooled following an
update in the resource the package fetches on the Internet
(https://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi if I
trust the package description).  Hence I would be tempted to
think the kind of bacteria is not necessarily that important,
but that a character string could be fetched.  But I'm not at
all a specialist of the field so prefer referring to your expert
view.  (and I am also concerned that the previous tests rely on
a perhaps magic index to refer to human genome, but maybe it is
a "well known index".)

In any case, I though upstream would be interested, so I took
the liberty to open an issue in their VCS[0].

[0] https://github.com/bioperl/Bio-DB-NCBIHelper/issues/6


Gregor, Many Thanks for having spotted this in the first place!

As the purpose of the package is to fetch resources on the web,
I did something better described by the following commit[1].

[1] 
https://salsa.debian.org/med-team/libbio-db-ncbihelper-perl/-/commit/bde35697e319417ae17367d51aaa868c43e1715d

It looked to me like the most sensible thing to do, since the
entire set of tests part of smoke are otherwise skipped.
I am not sure if there were more simple ways to approach that.
I am concerned that all test are skipped and considered valid.
Here is what I see if I smoke-env NO_NETWORK_TESTING=1:

autopkgtest [18:43:55]: test autodep8-perl-build-deps: 
/usr/share/pkg-perl-autopkgtest/runner build-deps
autopkgtest [18:43:55]: test autodep8-perl-build-deps: 
[---
t/EntrezGene.t . skipped: NO_NETWORK_TESTING
t/GenBank.t  skipped: NO_NETWORK_TESTING
t/GenPept.t  skipped: NO_NETWORK_TESTING
t/Query-Genbank.t .. skipped: NO_NETWORK_TESTING
t/RefSeq.t . skipped: NO_NETWORK_TESTING
t/Taxonomy.t ... skipped: NO_NETWORK_TESTING
Files=6, Tests=0,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.07 cusr  
0.00 csys =  0.09 CPU)
Result: NOTESTS
autopkgtest [18:43:55]: test autodep8-perl-build-deps: 
---]
autopkgtest [18:43:55]: test autodep8-perl-build-deps:  - - - - - - - - 
- - results - - - - - - - - - -
autodep8-perl-build-deps PASS

I'm sorry, I'm not sure that was that much of a Low Hanging
Fruit, but that might do for this month's session hopefully.  :)

Thanks for your thoughts,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/8, please excuse my verbosity.


signature.asc
Description: PGP signature


Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2

2021-02-21 Thread Lucas Nussbaum
Hi,

I tried again to build the version of the package that was failing
(3.1.6+ds-10) and it built *successfully* in an environment similar to
the one I used for the initial test (except it was updated to the
current state of unstable).

In the failed build log, there was:
Making check in tests
make[2]: Entering directory '/<>/tests'
make  check-local
make[3]: Entering directory '/<>/tests'
./unittest ./firehol ./fireqos ./link-balancer ./update-ipsets ./vnetbuild
unshare: unshare failed: Operation not permitted
make[3]: *** [Makefile:588: check-local] Error 1
make[3]: Leaving directory '/<>/tests'
make[2]: *** [Makefile:471: check-am] Error 2
make[2]: Leaving directory '/<>/tests'
make[1]: *** [Makefile:447: check-recursive] Error 1
make[1]: Leaving directory '/<>'
dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2
make: *** [debian/rules:8: binary] Error 25

In the successful log, there's:
Making check in tests
make[2]: Entering directory '/<>/tests'
make  check-local
make[3]: Entering directory '/<>/tests'
echo "Unprivileged user namespaces not enabled - not running tests"
Unprivileged user namespaces not enabled - not running tests
make[3]: Leaving directory '/<>/tests'
make[2]: Leaving directory '/<>/tests'
make[2]: Entering directory '/<>'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/<>'
make[1]: Leaving directory '/<>'

I don't understand why, in the failing build, the userns were detected
as being enabled. It might be that another package (built previously)
was enabling them during build (or during installation of one of its
build-depends). But I find that surprising, given all builds are
performed as an unprivileged user...

In any case, I can confirm that setting
/proc/sys/kernel/unprivileged_userns_clone to 1 makes the failure
reproducible (still on a 4.19 kernel). And 3.1.7+ds-1 is also affected.

Lucas



Bug#913978: bug 913978: gnome-control-center is not accessible with Orca screenreader

2021-02-21 Thread Samuel Thibault
Hello,

Paul Gevers, le sam. 06 févr. 2021 10:10:33 +0100, a ecrit:
> On Thu, 16 May 2019 20:15:20 +0200 Paul Gevers  wrote:
> > On Sat, 27 Apr 2019 13:16:05 -0700 Tassia Camoes Araujo
> >  wrote:
> > > From what I could understand, it is unlikely this will be fixed before
> > > Buster release. So how should we proceed about his bug?
> > > Even if a backport can possibly be provided later, would it be possible
> > > to just document the keystrokes "workaround" mentioned by Jeremy Bicha
> > > in the package shipped with Buster?
> > > It might be a big difference for users in need of this accessibility
> > > feature.
> > 
> > Although I rather have the bug fixed (who doesn't) I think documenting
> > is the least that can be done. @a11y team, anybody willing to update the
> > Wiki? I'll make sure the release notes have something.
> 
> One release further. Can somebody, e.g. from the Debian Accessibility
> Team, please at least check if this is still an issue? If not, we can
> close the bug, if so, we can document it *again* [1] as I'm not
> expecting it to get fixed in these last months if it's not fixed already.

I had a look, it looks like it is exactly in the same state as before:
having to press right arrow twice, having to use control-f then esc to
get back to the panel list (not able to select a result element with the
keyboard). So the same text would be needed.

Samuel



Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2

2021-02-21 Thread Dennis Filder
On Sun, Feb 21, 2021 at 07:32:19PM +0100, Paul Gevers wrote:

> On 21-02-2021 14:02, Jerome BENOIT wrote:
> > please consider to tag #982719 as bullseye-ignore
> > given that the issue is not a package issue but
> > it seems rather related to an chroot issue.
>
> A fresh upload from mere hours ago built successfully on our buildd
> infrastructure with
> Kernel: Linux 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30)
> amd64 (x86_64)

No, it didn't.  On that buildd server kernel.unprivileged_userns_clone
must have been 0 which effectively disables the test suite as can be
seen in the build log[1]:

...
Making check in tests
make[2]: Entering directory '/<>/tests'
make  check-local
make[3]: Entering directory '/<>/tests'
echo "Unprivileged user namespaces not enabled - not running tests"
Unprivileged user namespaces not enabled - not running tests
make[3]: Leaving directory '/<>/tests'
make[2]: Leaving directory '/<>/tests'
make[2]: Entering directory '/<>'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/<>'
make[1]: Leaving directory '/<>'
...

The buildd admins need to decide if they want
kernel.unprivileged_userns_clone to always be 1 or 0 before every
build (or is it upon the package to specify that?).  Otherwise this
will introduce breakage randomly as the setting gets toggled.

> Does that mean this bug is not yet fully understood? (Or did I miss
> details, I didn't read the bug in *full* detail.)

It's understood alright.  The gist is that the test suite relies on a
rather new system call named unshare(2) which cannot be used in a
chroot environment when called with CLONE_NEWUSER -- at least that's
what the manpage says.  (I expect this issue to affect more packages
in the future since unshare allows for convenient unit testing of
network and firewall code without mockups).  I read about an sbuild
backend that uses unshare instead of schroot which could help, but the
manpage called it "experimental".  All this somewhat makes this an
issue with the buildd environment itself, thus raising the question of
how this bug should be handled.  By disabling the test suite and
reuploading, or through a bullseye-ignore?  The latter would have the
advantage of keeping this on the table for when others run into this.

Regards,
Dennis.

1: 
https://buildd.debian.org/status/fetch.php?pkg=firehol=all=3.1.7%2Bds-1=1613917812=1



Bug#980592: [Pkg-clamav-devel] Bug#980592: clamav: diff for NMU version 0.103.0+dfsg-3.1

2021-02-21 Thread Sebastian Ramacher
On 2021-02-21 20:47:11 +0100, Sebastian Andrzej Siewior wrote:
> On 2021-02-21 16:07:37 [+0100], Sebastian Ramacher wrote:
> > Control: tags 980592 + pending
> > 
> > Dear maintainer,
> > 
> > I've prepared an NMU for clamav (versioned as 0.103.0+dfsg-3.1) and
> > uploaded it to DELAYED/2. Please feel free to tell me if I
> > should delay it longer.
> 
> I clearly missed that part that it affects current testing. I saved it
> internally as Bullseye+1. I also planned to upload 0.103.1 which didn't
> happend.
> Anyway. Feel free to NMU it right away if you want to and I try upload
> 103.1 this week or next…

Thanks, rescheduled to DELAYED/0

Cheers

> 
> > Cheers
> > -- 
> > Sebastian Ramacher
> 
> Sebastian

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#982135: ITP: bearssl -- BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C

2021-02-21 Thread Thaddeus H. Black
> I need sponsor.

Have you got your sponsor?


signature.asc
Description: PGP signature


Bug#983272: libfakeroot passes uninitialized bytes to msgsnd

2021-02-21 Thread Bálint Réczey
Package: fakeroot
Version: 1.24-1
Severity: minor

$ mkdir foo
$ fakeroot valgrind rm -r foo
==428772== Memcheck, a memory error detector
==428772== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==428772== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==428772== Command: rm -r foo
==428772==
==428772== Syscall param msgsnd(msgp->mtext) points to uninitialised byte(s)
==428772==at 0x49ABF4A: msgsnd (msgsnd.c:27)
==428772==by 0x4852E6B: send_fakem (in
/usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so)
==428772==by 0x4852EFC: send_get_fakem (in
/usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so)
==428772==by 0x4852FDD: ??? (in
/usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so)
==428772==by 0x48507B5: __lxstat (in
/usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so)
==428772==by 0x10EA35: lstat (stat.h:462)
==428772==by 0x10EA35: get_root_dev_ino (root-dev-ino.c:32)
==428772==by 0x10AD88: main (rm.c:346)
==428772==  Address 0x1ffefff79c is on thread 1's stack
==428772==
==428772== Syscall param msgsnd(msgp->mtext) points to uninitialised byte(s)
==428772==at 0x49ABF4A: msgsnd (msgsnd.c:27)
==428772==by 0x4852E6B: send_fakem (in
/usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so)
==428772==by 0x48530CA: send_stat64 (in
/usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so)
==428772==by 0x485146F: unlinkat (in
/usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so)
==428772==by 0x10B403: excise (remove.c:370)
==428772==by 0x10BF6D: rm_fts (remove.c:508)
==428772==by 0x10BF6D: rm (remove.c:607)
==428772==by 0x10AC93: main (rm.c:370)
==428772==  Address 0x1ffefff59c is on thread 1's stack
==428772==  in frame #2, created by send_stat64 (???:)
==428772==
==428772==
==428772== HEAP SUMMARY:
==428772== in use at exit: 0 bytes in 0 blocks
==428772==   total heap usage: 87 allocs, 87 frees, 57,596 bytes allocated
==428772==
==428772== All heap blocks were freed -- no leaks are possible
==428772==
==428772== Use --track-origins=yes to see where uninitialised values come from
==428772== For lists of detected and suppressed errors, rerun with: -s
==428772== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 0 from 0)



Bug#983203: [Pkg-utopia-maintainers] Bug#983203: [firewalld] error - invalid ipset sshguard4

2021-02-21 Thread Lyndon Brown
On Sun, 2021-02-21 at 20:01 +0100, Michael Biebl wrote:
> Unfortunately I have no idea what sshguard is.
> Is that another firewall?

I expect you've found out yourself by now, but fwiw, sshguard adds
brute-force protection to ssh. It analyses log files for signs of brute
force attempts and updates firewall rules to block connections as
appropriate.

> Does it install iptables / nftables rules (which might clash with 
> firewalld).

The latest package version uses the nftables backend. Setup when using
firewalld involves adding a couple of rich-rules as below. I do not
know what sshguard specifically does internally to make things work,
but some part of this setup, presumably with the switch to nftables, is
clearly broken.

> What exactly do you mean with "sshguard config"?

The sshguard firewalld config is described in [1] & [2], and is
essentially this:
1. # firewall-cmd --zone=zone-name --permanent --add-rich-rule="rule source 
ipset=sshguard4 drop"
2. # firewall-cmd --zone=zone-name --permanent --add-rich-rule="rule source 
ipset=sshguard6 drop"

[1]:
https://manpages.debian.org/testing/sshguard/sshguard-setup.7.en.html
[2]: https://wiki.archlinux.org/index.php/Sshguard

On Sun, 2021-02-21 at 20:10 +0100, Michael Biebl wrote:
> After looking at the package description, I think this is a sshguard
> issue.

Ok, fair enough :)

> Looking at the git log of sshguard, maybe upgrading to a newer
> sshguard 
> version helps.
> It has commits like
>  
> https://bitbucket.org/sshguard/sshguard/commits/5927e696a8f0bc323f66d1edcce1365a70972320
> which look related.

Indeed that does look very much related and I agree that it would be
good to test a newer version of sshguard with those changes to see if
that resolves it. I was too exhausted yesterday to think about looking
at sshguard developments; sorry about that.



Bug#975650: blhc: reports false positives for missing flags

2021-02-21 Thread Olek Wojnar
Hello Simon and other interested parties,

On Sat, 28 Nov 2020 12:28:16 +0100 Simon Ruderich 
wrote:
>
> is the problem because blhc requires a space after each flag. I
> know this handling is not perfect but parsing arbitrary shell
> commands is difficult.

I have run into this exact issue with bazel-bootstrap builds. [1] I love
what blhc does so I'd rather not disable it due to these false positives,
but I also like for the Salsa CI to let me know when a recent commit has
caused a problem, and constant test failures mask that.

Would it be possible to change the regex so that it will also accept a " or
a ' next to the spaces surrounding the flag? That way all of the three
following would be considered valid:
-D_FORTIFY_SOURCE=2
'-D_FORTIFY_SOURCE=2'
"-D_FORTIFY_SOURCE=2"

If you think it could cause problems to implement that as default behavior,
is it something that could be implemented as an option? Something along
the lines of `blhc --accept-quoted` perhaps?

Thanks for your work on this package, it's a very useful indicator of
regressions or other coding issues!


-Olek

[1] https://salsa.debian.org/bazel-team/bazel-bootstrap/-/jobs/1452282


Bug#983233: New autopkgtest shouldn’t trigger a regression

2021-02-21 Thread David Prévot

Le 21/02/2021 à 16:02, Paul Gevers a écrit :

Control: tags -1 moreinfo

Hi David,

On 21-02-2021 12:53, David Prévot wrote:

I recently added an autopkgtest to a package, and the autopkgtest failed
on all suites. I’m surprised to see that failure considered as a
regression (#983211)

[…]

We realize that `regression` doesn't quite cover how we use it
[…] we consider
failing tests in testing RC [1]. Hence, allowing a package with a
failing test to migrate to testing would immediately make it RC buggy,
hence we block it. `regression` doesn't fully cover it, we read it as
"there wasn't an RC bug in testing, and now there will be, hence
regression" but it's a bit stretched.

Do you have a suggestion to use there instead (a word, not a sentence)?


Maybe “failing test” since you used it twice to describe the actual 
issue (but that’s two words) or even simply (test) “failure”?


The current policy makes it almost worth to remove autopkgtest in order 
to avoid what you call “regression”. Yet, such removal would check all 
boxes of what is called “regression” according to some some online 
[dict]ionary: “a return to a previous and less advanced or worse state, 
condition, or way of behaving”.


  dict: https://dictionary.cambridge.org/dictionary/english/regression

Regards

David



Bug#820790: ldapvi: sorts entries alphabetically which can break specific modifications where the order of the definitions is important

2021-02-21 Thread Ralf Becker
This bug causes editing of a schema definition to fail.

The error message reads:
```
ldap_modify: Other (e.g., implementation specific) error (80)
additional info: olcObjectClasses: ObjectClass not found: "idmPerson"
Error at: cn={8}yyy,cn=schema,cn=config
```

The reason for this is the sorting of the values.

## Example

This definition is only correct in exactly this order,
because `idmStudent` builds on `idmPerson`:
```
olcObjectClasses: {3}( 1.3.6.1.4.1..1 NAME 'idmPerson'
SUP top AUXILIARY MUST ( uid $ givenName ) )
...
olcObjectClasses: {11}( 1.3.6.1.4.1..2 NAME 'idmStudent'
SUP idmPerson AUXILIARY MAY ( mtr ) )
```

Sorting turns it into:
```
olcObjectClasses: {11}( 1.3.6.1.4.1..2 NAME 'idmStudent'
SUP idmPerson AUXILIARY MAY ( mtr ) )
...
olcObjectClasses: {3}( 1.3.6.1.4.1..1 NAME 'idmPerson'
SUP top AUXILIARY MUST ( uid $ givenName ) )
```

And that then leads to described error.


## Conclusion:

There seems to be no valid reason why the values are sorted.
Attribute values should be taken in *exactly* the order
in which they are entered in `vi`.


## Patch:

This patch ensures that reordering no longer takes place and
fixes the problem in the case shown above.

```
diff --git a/ldapvi/diff.c b/ldapvi/diff.c
index e2787a3..42de566 100644
--- a/ldapvi/diff.c
+++ b/ldapvi/diff.c
@@ -29,8 +29,8 @@ compare_ptr_arrays(GPtrArray *a, GPtrArray *b,
int i = 0;
int j = 0;
 
-   qsort(a->pdata, a->len, sizeof(void *), cmp);
-   qsort(b->pdata, b->len, sizeof(void *), cmp);
+// qsort(a->pdata, a->len, sizeof(void *), cmp);
+// qsort(b->pdata, b->len, sizeof(void *), cmp);
 
while (i < a->len && j < b->len) {
void *ax = g_ptr_array_index(a, i);

```



Bug#983270: u-boot: CVE-2021-27097

2021-02-21 Thread Salvatore Bonaccorso
Source: u-boot
Version: 2021.01+dfsg-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for u-boot.

CVE-2021-27097[0]:
| The boot loader in Das U-Boot before 2021.04-rc2 mishandles a modified
| FIT.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-27097
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27097

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#983269: u-boot: CVE-2021-27138

2021-02-21 Thread Salvatore Bonaccorso
Source: u-boot
Version: 2021.01+dfsg-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for u-boot.

CVE-2021-27138[0]:
| The boot loader in Das U-Boot before 2021.04-rc2 mishandles use of
| unit addresses in a FIT.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-27138
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27138

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#983267: steghide: CVE-2021-27211

2021-02-21 Thread Salvatore Bonaccorso
Source: steghide
Version: 0.5.1-15
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 0.5.1-13

Hi,

The following vulnerability was published for steghide.

CVE-2021-27211[0]:
| steghide 0.5.1 relies on a certain 32-bit seed value, which makes it
| easier for attackers to detect hidden data.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-27211
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27211

Regards,
Salvatore



Bug#983268: RFS: posterazor/1.5.1-10 -- splits an image across multiple pages for assembly into a poster

2021-02-21 Thread Marcelo Soares Mota
Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: motasmarc...@gmail.com

Dear mentors,

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

 * Package name: posterazor
   Version : 1.5.1-10
   Upstream Author : Alessandro Portale 
 * URL : https://posterazor.sourceforge.io/
 * License : GPL-3+, MIT, LGPL-2+, BSD-3-Clause
 * Vcs : https://salsa.debian.org/debian/posterazor
   Section : graphics

It builds those binary packages:

  posterazor - splits an image across multiple pages for assembly into a poster

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/posterazor/posterazor_1.5.1-10.dsc

Changes since the last upload:

 posterazor (1.5.1-10) unstable; urgency=medium
 .
   * Uploaded to unstable.

Regards,
-- 
  Marcelo S Mota



Bug#983266: src:os-autoinst: fails to migrate to testing for too long: unresolved RC bug

2021-02-21 Thread Paul Gevers
Source: os-autoinst
Version: 4.5.1527308405.8b586d5-4.2
Severity: serious
Control: close -1 4.6.1604525166.912dfbd-0.2
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 977990

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:os-autoinst
has been trying to migrate for 60 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=os-autoinst




OpenPGP_signature
Description: OpenPGP digital signature


Bug#983233: New autopkgtest shouldn’t trigger a regression

2021-02-21 Thread Paul Gevers
Control: tags -1 moreinfo

Hi David,

On 21-02-2021 12:53, David Prévot wrote:
> I recently added an autopkgtest to a package, and the autopkgtest failed
> on all suites. I’m surprised to see that failure considered as a
> regression (#983211), so I believe there is a mistake somewhere (maybe
> that’s just me not getting what “regression” means, if so that might
> deserve being documented).

We realize that `regression` doesn't quite cover how we use it in
Debian, but this part was taken over from Ubuntu. In Debian, we consider
failing tests in testing RC [1]. Hence, allowing a package with a
failing test to migrate to testing would immediately make it RC buggy,
hence we block it. `regression` doesn't fully cover it, we read it as
"there wasn't an RC bug in testing, and now there will be, hence
regression" but it's a bit stretched.

Do you have a suggestion to use there instead (a word, not a sentence)?

Paul

[1] https://release.debian.org/bullseye/rc_policy.txt



OpenPGP_signature
Description: OpenPGP digital signature


Bug#980592: [Pkg-clamav-devel] Bug#980592: clamav: diff for NMU version 0.103.0+dfsg-3.1

2021-02-21 Thread Sebastian Andrzej Siewior
On 2021-02-21 16:07:37 [+0100], Sebastian Ramacher wrote:
> Control: tags 980592 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for clamav (versioned as 0.103.0+dfsg-3.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

I clearly missed that part that it affects current testing. I saved it
internally as Bullseye+1. I also planned to upload 0.103.1 which didn't
happend.
Anyway. Feel free to NMU it right away if you want to and I try upload
103.1 this week or next…

> Cheers
> -- 
> Sebastian Ramacher

Sebastian



Bug#983265: vorta: autopkgtest regression on armhf: test times out

2021-02-21 Thread Paul Gevers
Source: vorta
Version: 0.7.3-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression timeout

Dear maintainer(s),

With a recent upload of vorta the autopkgtest of vorta fails in testing
on armhf when that autopkgtest is run with the binary packages of vorta
from unstable. It passes when run with only packages from testing. In
tabular form:

   passfail
vorta  from testing0.7.3-1
all others from testingfrom testing

I copied some of the output at the bottom of this report, but as it
times out (after 2 hours and 47 minutes, where it used to take only
around 2 minutes) in autopkgtest, you can only get the last successfully
output log.

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

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=vorta

https://ci.debian.net/data/autopkgtest/testing/armhf/v/vorta/10584291/log.gz

autopkgtest [12:51:05]: test unittests: [---
=== Testing with python3.9 ===
= test session starts
==
platform linux -- Python 3.9.1+, pytest-6.0.2, py-1.10.0, pluggy-0.13.0
PyQt5 5.15.2 -- Qt runtime 5.15.2 -- Qt compiled 5.15.2
rootdir: /tmp/autopkgtest-lxc.htw3i14l/downtmp/autopkgtest_tmp/vorta
plugins: qt-3.2.2, forked-1.3.0, mock-1.10.4
collected 54 items

tests/test_archives.py ..
 [ 33%]
tests/test_borg.py .
 [ 35%]
tests/test_lock.py ..
 [ 38%]
tests/test_misc.py s
 [ 40%]
tests/test_notifications.py .
 [ 42%]
tests/test_profile.py ..
 [ 46%]
tests/test_repo.py s.
 [ 57%]
tests/test_schedule.py .
 [ 59%]
tests/test_scheduler.py .
 [ 61%]
tests/test_source.py .autopkgtest [15:37:45]: ERROR: timed out on
command "su -s /bin/bash debci -c set -e; export USER=`id -nu`; .
/etc/profile >/dev/null 2>&1 || true;  . ~/.profile >/dev/null 2>&1 ||
true; buildtree="/tmp/autopkgtest-lxc.htw3i14l/downtmp/build.hDA/src";
mkdir -p -m 1777 --
"/tmp/autopkgtest-lxc.htw3i14l/downtmp/unittests-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.htw3i14l/downtmp/unittests-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.htw3i14l/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.htw3i14l/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=32; unset
LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY
LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; chmod
+x
/tmp/autopkgtest-lxc.htw3i14l/downtmp/build.hDA/src/debian/tests/unittests;
touch /tmp/autopkgtest-lxc.htw3i14l/downtmp/unittests-stdout
/tmp/autopkgtest-lxc.htw3i14l/downtmp/unittests-stderr;
/tmp/autopkgtest-lxc.htw3i14l/downtmp/build.hDA/src/debian/tests/unittests
2> >(tee -a /tmp/autopkgtest-lxc.htw3i14l/downtmp/unittests-stderr >&2)
> >(tee -a /tmp/autopkgtest-lxc.htw3i14l/downtmp/unittests-stdout);"
(kind: test)
autopkgtest [15:37:46]: test unittests: ---]



OpenPGP_signature
Description: OpenPGP digital signature


Bug#983203: [Pkg-utopia-maintainers] Bug#983203: [firewalld] error - invalid ipset sshguard4

2021-02-21 Thread Michael Biebl

Control: reassign -1 sshguard

Am 21.02.21 um 20:01 schrieb Michael Biebl:

Control: tags -1 + moreinfo

Am 21.02.21 um 03:14 schrieb Lyndon Brown:

Package: firewalld
Version: 0.9.3-2
Severity: important

I'm experiencing problems on a Sid system with firewalld and sshguard 
- firewalld does

not seem happy with the sshguard config for some reason.



Unfortunately I have no idea what sshguard is.
Is that another firewall?
Does it install iptables / nftables rules (which might clash with 
firewalld).

What exactly do you mean with "sshguard config"?


After looking at the package description, I think this is a sshguard issue.
Looking at the git log of sshguard, maybe upgrading to a newer sshguard 
version helps.

It has commits like
https://bitbucket.org/sshguard/sshguard/commits/5927e696a8f0bc323f66d1edcce1365a70972320
which look related.

Dear sshguard maintainer, if you think this is a genuine firewalld bug, 
please reassign back.


Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature


Bug#978678: Acknowledgement (gnome-calendar: segfault when clicking certain buttons)

2021-02-21 Thread Znoteer
The crashes haven't happened for a couple of weeks now (maybe something got
upgraded?), so I guess this is bug report is now pointless.

Thanks,

-- 
Znoteer
znot...@mailbox.org



Bug#983203: [Pkg-utopia-maintainers] Bug#983203: [firewalld] error - invalid ipset sshguard4

2021-02-21 Thread Michael Biebl

Control: tags -1 + moreinfo

Am 21.02.21 um 03:14 schrieb Lyndon Brown:

Package: firewalld
Version: 0.9.3-2
Severity: important

I'm experiencing problems on a Sid system with firewalld and sshguard - 
firewalld does
not seem happy with the sshguard config for some reason.



Unfortunately I have no idea what sshguard is.
Is that another firewall?
Does it install iptables / nftables rules (which might clash with 
firewalld).

What exactly do you mean with "sshguard config"?



OpenPGP_signature
Description: OpenPGP digital signature


Bug#983264: troffcvt: FTBFS with binutils 2.36

2021-02-21 Thread Logan Rosen
Package: troffcvt
Version: 1.04-25
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Hi,

troffcvt FTBFS with binutils 2.36 (currently in experimental). The reason is
that the WRPRC module tries to use the -l flag to ar by default, which
doesn't do anything in binutils <2.36 and starts having a function in
2.36, one that is different from the one that the WRPRC config script is
intending to use.

In Ubuntu, the attached patch was applied to achieve the following:

  * patches/WRPRC-2.11.diff: Change ar command to use cq instead of clq to fix
compatibility with binutils 2.36.

Thanks for considering the patch.

Logan
diff -u troffcvt-1.04/patches/WRPRC-2.11.diff 
troffcvt-1.04/patches/WRPRC-2.11.diff
--- troffcvt-1.04/patches/WRPRC-2.11.diff
+++ troffcvt-1.04/patches/WRPRC-2.11.diff
@@ -1,7 +1,15 @@
-diff -Nurp tmp/WRPRC-2.11/config/Imake.params WRPRC-2.11/config/Imake.params
 tmp/WRPRC-2.11/config/Imake.params 1997-05-23 22:19:11.0 +0100
-+++ WRPRC-2.11/config/Imake.params 2007-08-19 08:09:51.0 +0100
-@@ -583,16 +583,16 @@
+diff -u WRPRC-2.11/config/Imake.params WRPRC-2.11/config/Imake.params
+--- WRPRC-2.11/config/Imake.params 2007-08-19 08:09:51.0 +0100
 WRPRC-2.11/config/Imake.params 2021-02-21 13:34:03.108767338 -0500
+@@ -331,7 +331,3 @@
+ #ifndef ArCmd
+-#if SystemV4
+ #define ArCmd ar cq
+-#else
+-#define ArCmd ar clq
+-#endif
+ #endif
+@@ -583,16 +579,16 @@
   */
  
  #ifndef InstProgFlags
@@ -22,7 +30,7 @@
  #endif
  #ifndef InstScriptFlags
  #define InstScriptFlags $(INSTCOPY) $(INSTOWNER) $(INSTGROUP) 
$(INSTSCRIPTMODE)
-diff -Nurp tmp/WRPRC-2.11/config/linux.cf WRPRC-2.11/config/linux.cf
+unchanged:
 --- tmp/WRPRC-2.11/config/linux.cf Wed Dec 31 19:00:00 1969
 +++ WRPRC-2.11/config/linux.cf Mon Nov 10 22:25:15 1997
 @@ -0,0 +1,94 @@
@@ -120,7 +128,7 @@
 +#ifndef SpoolRootDir
 +#define SpoolRootDir /var/spool
 +#endif
-diff -Nurp tmp/WRPRC-2.11/config/site.def WRPRC-2.11/config/site.def
+unchanged:
 --- tmp/WRPRC-2.11/config/site.def Fri May 23 17:19:11 1997
 +++ WRPRC-2.11/config/site.def Mon Nov 10 23:13:08 1997
 @@ -55,26 +55,24 @@ XCOMM site:  Primate Center 89/12/22
@@ -155,8 +163,9 @@
  #endif
  
  /* document preparation preferences */
-diff -Nurp tmp/WRPRC-2.11/config/linux.p-cf WRPRC-2.11/config/linux.p-cf
+unchanged:
 --- tmp/WRPRC-2.11/config/linux.p-cf   Wed Dec 31 19:00:00 1969
 +++ WRPRC-2.11/config/linux.p-cf   Mon Nov 10 22:25:15 1997
 @@ -0,0 +1,1 @@
 +
+


Bug#983248: guix: possible missing dependency daemonize

2021-02-21 Thread florine forine
Package: guix
Version: 1.2.0-3
Severity: normal

After installing guix and trying to start the daemon with
> service guix start

I get the following error-message

/etc/init.d/guix-daemon: line 35: daemonize: command not found

After installing daemonize and try again
> service guix start

I get File "/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon" is
not executable.

Also after installation there is no group "guixbuild" (see guix user manual
§2.41)

-- System Information:
Debian Release: bullseye/sid
Architecture: amd64 (x86_64)

Init: sysvinit (via /sbin/init)

Versions of packages guix depends on:
ii  guile-2.2   2.2.7+1-5.4
ii  guile-2.2-libs  2.2.7+1-5.4
ii  guile-gcrypt0.3.0-3
ii  guile-git   0.4.0-3
ii  guile-gnutls3.7.0-5
ii  guile-json  4.3.2-2
ii  guile-lzlib 0.0.2-2
ii  guile-sqlite3   0.1.3-2
ii  guile-ssh   0.13.1-3
ii  guile-zlib  0.0.1-3
ii  libbz2-1.0  1.0.8-4
ii  libc6   2.31-9
ii  libgcc-s1   10.2.1-6
ii  libgcrypt20 1.8.7-2
ii  libsqlite3-03.34.1-1
ii  libssh-dev  0.9.5-1
ii  libstdc++6  10.2.1-6
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages guix recommends:
pn  nscd 
pn  systemd  

guix suggests no packages.

-- no debconf information

-- 


signature.asc
Description: PGP signature


Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2

2021-02-21 Thread Paul Gevers
Hi,

On 21-02-2021 14:02, Jerome BENOIT wrote:
> please consider to tag #982719 as bullseye-ignore
> given that the issue is not a package issue but
> it seems rather related to an chroot issue.

A fresh upload from mere hours ago built successfully on our buildd
infrastructure with
Kernel: Linux 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30)
amd64 (x86_64)

Does that mean this bug is not yet fully understood? (Or did I miss
details, I didn't read the bug in *full* detail.)

Paul



OpenPGP_signature
Description: OpenPGP digital signature


Bug#983263: 3.21.2 should not migrate automatically (yet)

2021-02-21 Thread Didier 'OdyX' Raboud
Source: hplip
Version: 3.21.2+dfsg0-1
Severity: serious

As hplip maintainer, I'm hereby making sure that hplip 3.21.2 doesn't migrate
automatically to bullseye. It was uploaded by mistake to unstable, but two
alternatives exist:
- A) Revert to 3.20.11, because the changes are too disruptive;
- B) Allow 3.21.2 in bullseye, because the increased hardware support is worth
 it.

Let's give the autobuilders, autopkgtest runners and Debian sid users some
time in this soft freeze, to see whether there are important regressions
tilting this balance towards A).

OdyX



Bug#973004: dpkg-sig: outdated digest format

2021-02-21 Thread Daniel Kahn Gillmor
On Tue 2020-10-27 07:52:16 +0100, Konstantinos Dalamagkidis wrote:
> currently dpkg-sig uses MD5/SHA1 for the digest. Both are insufficient
> for integrity protection and according to the Debian Wiki SHA-1 is being
> phased out.

This is really not acceptable.  It's 2021, we've known that both MD5 and
SHA-1 are inappropriate to use for applications where poor
collision-resistance is a risk.

Cryptographic verification of software packages *definitely* falls into
this category.  As far as i can tell (the documentation i could find is
rather sparse), there is no other purpose for dpkg-sig.

So I think its dependence on weak digests makes dpkg-sig entirely unfit
for purpose.  It should be removed from debian until/unless it is
improved to use modern cryptographic primitives.

 --dkg


signature.asc
Description: PGP signature


Bug#971713: sysstat: init or systemd file has overlapping runlevels

2021-02-21 Thread Jesse Smith
On 2021-02-19 4:38 a.m., Matthew Vernon wrote:
> On 15/12/2020 21:34, Jesse Smith wrote:
>> On 2020-12-15 5:04 p.m., Trek wrote:
>>> On Tue, 15 Dec 2020 12:45:40 -0400
>>> Jesse Smith  wrote:
>>>
 I gave the patch a test run and, while I like what it does in theory,
 in practise I'm running into trouble with it. When I use the attached
 patch and then run "make check" in the insserv source directory,
 inssrev segfaults after about eight tests. I haven't had a chance yet
 to hunt down what is causing the problem, but I'm guessing a variable
 is getting used before it is given a value/initialized.
>>> well, moving the Start_Stop_Overlap call broke the assumption that
>>> start_levels and stop_levels are never undefined, so this additional
>>> patch should fix the regression
>>>
>>> make check now passes all 240 tests
>>>
>>> thanks for the review and happy hacking! :)
>>
>> Thank you for the updated patch. I have confirmed it works here and
>> passes all checks. I've committed the change for the upcoming 1.23.0
>> branch of insserv. People are welcome to test it out and, when the next
>> version gets published, this fix (and update to the manual page) will be
>> included.
>
> Are you in a position to publish this version? insserv still has this
> grave severity bug open against it, which it'd be good to resolve ASAP
> before insserv gets pulled from testing...


A new version of SysV init and innserv have been published today. The
new version of insserv (1.23.0) fixes the above issue. It can be
downloaded from here: http://download.savannah.nongnu.org/releases/sysvinit/

- Jesse



Bug#983248: guix: changes needed to work with sysvinit

2021-02-21 Thread Vagrant Cascadian
Control: retitle 983248 guix: changes needed to work with sysvinit

On 2021-02-20, florine forine wrote:
> After installing guix and trying to start the daemon with
> > service guix start
>
> I get the following error-message
>
> /etc/init.d/guix-daemon: line 35: daemonize: command not found
>
> After installing daemonize and try again
> > service guix start

The daemonize binary is only needed when using something other than
systemd. I guess "systemd-sysv | daemonize" might be worth adding to
recommends.


> I get File "/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon" is
> not executable.

The init script definitely needs to be patched to use
/usr/bin/guix-daemon, and possibly changes to the locale settings
(e.g. GUIX_LOCPATH and the hard-coded en_US.UTF-8 locale).


> Also after installation there is no group "guixbuild" (see guix user manual
> §2.41)

Similarly, could add "systemd-sysv | opensysusers" to recommends to
handle this.


Another approach instead of recommends would be to add a README.Debian
explaining how to set up when systemd is not installed.


Would very much appreciate tested patches!


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#983208: lynx: embeds path to various binaries that differ with usrmerge

2021-02-21 Thread Vagrant Cascadian
On 2021-02-21, Andreas Metzler wrote:
> On 2021-02-21 Vagrant Cascadian  wrote:
>> The paths to various binaries are embedded in /usr/bin/lynx, which
>> differs on a usrmerge vs. non-usrmerge system.
...
>> Patch attached which passes variables to configure to use the
>> non-usrmerge locations, as usrmerge installations typically have
>> compatibility symlinks, but not vice-versa.
>
>> This does not resolve all reproducibility issues (e.g. when /bin/sh
>> points to bash), but should reduce some of the noise when comparing the
>> differences.
> [...]
>
> Hello,
>
> Reluctantly applied.

Thanks for applying.


> I don't get the point of trying to do reproducible builds on systems
> that differ significantly (usrmerge or not), it feels like make-work.

I get that, for sure.

The current reproducible builds test infrastructure is geared towards
finding issues so that we can fix them; some of the issues may seem to
be nuanced corner-cases.

In the case of usrmerge, both usrmerge and non-usrmerge systems exist in
the wild; having fewer variables that affect the build makes it
significantly easier to reproduce a build and more resilient. Bugs
triggered by building in a usrmerge environment have actually resulted
in functionally broken packages in several cases, too, so it does seem
to me important to find them early.


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#971713: NMU in delayed/5

2021-02-21 Thread Matthew Vernon

Hi,

I've taken Trek's patches and incorporated them into an NMU which I've 
pushed to delayed/5.


We may still want to get the new version into bullseye once Jesse 
publishes it, but at least this way the fix for this bug will be in.


I hope that's OK!

Regards,

Matthew
diff --git a/debian/changelog b/debian/changelog
index 9b6450e..ab9811c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+insserv (1.21.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Apply patches from Trek to only check LSB headers for overlapping
+run-levels and document Default-{Start,Stop} more clearly
+(Closes: #971713)
+
+ -- Matthew Vernon   Sun, 21 Feb 2021 17:13:07 +
+
 insserv (1.21.0-1) unstable; urgency=medium
 
   * New upstream release
diff --git a/debian/patches/patches-from-trek-closes-971713.patch b/debian/patches/patches-from-trek-closes-971713.patch
new file mode 100644
index 000..99d78f9
--- /dev/null
+++ b/debian/patches/patches-from-trek-closes-971713.patch
@@ -0,0 +1,76 @@
+From: Matthew Vernon 
+Date: Sun, 21 Feb 2021 17:07:48 +
+X-Dgit-Generated: 1.21.0-1.1 25129a77868f74aca504d43faf9d2bfe375468dc
+Subject: Patches from Trek (Closes: #971713)
+
+Only check LSB headers for overlapping runlevels (so you don't get an
+error if the admin has adjusted runlevels), and also document
+Default-Start and Default-Stop more clearly.
+
+---
+
+--- insserv-1.21.0.orig/insserv.8.in
 insserv-1.21.0/insserv.8.in
+@@ -97,6 +97,11 @@ execute insserv directly unless you know
+ may render your boot system inoperable.
+ .B update\-rc.d
+ is the recommended interface for managing init scripts.
++.PP
++The
++.B Default\-Start
++keyword declares on which runlevels the script must be started. An empty
++value means the script will never be started.
+ @@BEGIN_SUSE@@
+ Please note, that the
+ .B Default\-Stop
+@@ -104,6 +109,10 @@ are ignored in SuSE Linux, because the S
+ uses a differential link scheme (see
+ .IR init.d (7)).
+ @@ELSE_SUSE@@
++The same applies for its counterpart
++.B Default\-Stop
++with the only difference that the script is stopped.
++.PP
+ Please be aware that the line
+ .sp 1
+ .in +1l
+--- insserv-1.21.0.orig/insserv.c
 insserv-1.21.0/insserv.c
+@@ -2737,6 +2737,8 @@ boolean Start_Stop_Overlap(char *start_l
+int string_index = 0;
+char *found;
+ 
++   if (!start_levels || !stop_levels) return false;
++
+while (start_levels[string_index])   /* go to end of string */
+{
+if (start_levels[string_index] != ' ') /* skip spaces */
+@@ -3573,6 +3575,14 @@ int main (int argc, char *argv[])
+ 		if (script_inf.stop_after && script_inf.stop_after != empty) {
+ 			reversereq(service, REQ_SHLD|REQ_KILL, script_inf.stop_after);
+ 		}
++
++overlap = Start_Stop_Overlap(script_inf.default_start, script_inf.default_stop);
++if (overlap)
++{
++warn("Script `%s' has overlapping Default-Start and Default-Stop runlevels (%s) and (%s). This should be fixed.\n",
++  d->d_name, script_inf.default_start, script_inf.default_stop);
++}
++
+ 		/*
+ 		 * Use information from symbolic link structure to
+ 		 * check if all services are around for this script.
+@@ -3739,13 +3749,6 @@ int main (int argc, char *argv[])
+ 	}
+ #endif /* not SUSE */
+ 
+-overlap = Start_Stop_Overlap(script_inf.default_start, script_inf.default_stop);
+-if (overlap)
+-{
+-warn("Script %s has overlapping Default-Start and Default-Stop runlevels (%s) and (%s). This should be fixed.\n",
+-  d->d_name, script_inf.default_start, script_inf.default_stop);
+-}
+-
+ 	if (isarg && !defaults && !del) {
+ 	if (argr[curr_argc]) {
+ 		char * ptr = argr[curr_argc];
diff --git a/debian/patches/series b/debian/patches/series
index e28fa8f..13ebfb3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,4 @@
 warn_in_ignore_mode.patch
 0004-Fix-spurious-warnings-about-unknown-virtual-dependen.patch
 0005-Fix-spelling-error-in-manpage.patch
+patches-from-trek-closes-971713.patch
diff --git a/insserv.8.in b/insserv.8.in
index 9008b5f..a370deb 100644
--- a/insserv.8.in
+++ b/insserv.8.in
@@ -97,6 +97,11 @@ execute insserv directly unless you know exactly what you're doing, doing so
 may render your boot system inoperable.
 .B update\-rc.d
 is the recommended interface for managing init scripts.
+.PP
+The
+.B Default\-Start
+keyword declares on which runlevels the script must be started. An empty
+value means the script will never be started.
 @@BEGIN_SUSE@@
 Please note, that the
 .B Default\-Stop
@@ -104,6 +109,10 @@ are ignored in SuSE Linux, because the SuSE boot script concept
 uses a differential link scheme (see
 .IR init.d (7)).
 @@ELSE_SUSE@@
+The same applies for its counterpart
+.B Default\-Stop
+with the only difference that the script is stopped.
+.PP
 

Bug#983262: ITP: loguru -- enjoyable loggin' for Python

2021-02-21 Thread Steffen Moeller
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: moel...@debian.org

Subject: ITP: loguru -- enjoyable loggin' for Python
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: loguru
  Version : 0.5.3
  Upstream Author : Delgan 
* URL : https://github.com/Delgan/loguru/
* License : MIT
  Programming Lang: Python
  Description : enjoyable loggin' for Python
 Did you ever feel lazy about configuring a logger and used print()
 instead?... I did, yet logging is fundamental to every application
 and eases the process of debugging. Using Loguru you have no excuse
 not to use logging from the start, this is as simple as
  from loguru import logger.
 .
 Also, this library is intended to make Python logging less painful
 by adding a bunch of useful functionalities that solve caveats of the
 standard loggers. Using logs in your application should be an automatism,
 Loguru tries to make it both pleasant and powerful.
 Ready to use out of the box without boilerplate
 .
  * No Handler, no Formatter, no Filter: one function to rule them all
  * Easier file logging with rotation / retention / compression
  * Modern string formatting using braces style
  * Exceptions catching within threads or main
  * Pretty logging with colors
  * Asynchronous, Thread-safe, Multiprocess-safe
  * Fully descriptive exceptions
  * Structured logging as needed
  * Lazy evaluation of expensive functions
  * Customizable levels
  * Better datetime handling
  * Suitable for scripts and libraries
  * Entirely compatible with standard logging
  * Personalizable defaults through environment variables
  * Convenient parser
  * Exhaustive notifier

Remark: This package is maintained by Debian Python Team at
   https://salsa.debian.org/python-team/packages/loguru



Bug#983261: ttyd: systemd service file fails: Failed at step EXEC spawning /bin/ttyd: No such file or directory

2021-02-21 Thread Jonas Smedegaard
Package: ttyd
Version: 1.6.3-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

ttyd looks like an interesting tool - thanks for packaging it!

systemd service fails - seemingly expects install path /bin/ttyd
which is different from Debian packaged /usr/bin/ttyd


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmAyjTgACgkQLHwxRsGg
ASEEAw/9Gqcug8nCIslF08t+g/UY5sFi1wFKmTfOLE44cmC1QbzXsLNIAegERIYb
dh0VW/ipfhkm1gEzHcHjYwvhFCpAka5SEV5Ik4v9ILUpjhZSxjq/hBVCaKE0Wnik
uYKtt78DLRozB+ppYmwXBv6Yct1R4yXhH52j36RuZDNB+CpB6+DuXJQExyXb7GjY
yyv85s29larJ0hUdxmSMiLsvybErORSr0RJCMhazC7wWci4hMEgxwPtMpvziCzfW
58GpQ7Z/IU9Z/vVpNyEW/H3EgwQvHbOHEe49CwRboMgVP7Fv5EqHilTYXWN5UOIh
vemFr6KiOOueAGFfclsnRiHgo+8/4Go8AvVnoOwZ9vC3c0Y2isrhslsT5Q/ZGA1O
dNfNV5JbRPt1jTfkkCKE7iW0Ru0YHMkTXu20ic52v+Pksn+wiLX4OFGqX2yfY9XN
K6/siavZW4wSMQxZwUv2nF8LMMFCvRgFFjre0w2Cc71x3wJdh8Ne2Fu8Ad0VAhDY
TnzJUh4bpJYOdB0b05hiRGfo2LZ4ApVtn+HWM4o9H7N3TyKJtEFpPBAMfVDArQK4
bSDLKvcb1LHgkmtfFxX841uuj/LHyd/iTKfq7xji0cOfgRJlV6y/ONDonULFxuhD
ZUw0/oGwrunaEgLOFd0Vyy0dOwdtquKPGkbwLsI5aHGe4jFkG8g=
=Z58y
-END PGP SIGNATURE-



Bug#983201: new build dsc

2021-02-21 Thread PICCORO McKAY Lenz
I build new packages for iperf2 if someone DM interested just parsed
and tuned it for debian:

https://build.opensuse.org/package/show/home:vegnuli:deploy-vnx2/iperf2

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



Bug#983259: fzy: please ship concrete usable code for CTRL-R and CTRL-T, optionally enabled with debconf

2021-02-21 Thread Jonas Smedegaard
Package: fzy
Version: 1.0-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

fzy package could be improved if it included a pre-made script to source
from a shell script to hook into CTRL-r and CTRL-t.

Maybe borrow and derive the example scripts included with fzf?

Also see bug#973570 for related discussion on tighter system integration,
relevant also for fzy.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmAyiU4ACgkQLHwxRsGg
ASEyIg//alANFaq+shBJZtYW5fHLNsJE4GbjbmnrLney6cO/qJ/yeq5Cd8awOAy/
ga2jF3OUMN4wUo5eJ977uzG2Ey6spnven11Vwx1MK4IZuZE52WQH6yiLiAu7/8zX
YPZj5YlQhnZXUsmo+EdIXqoms/ukvK74Zy18KsoO+iuOnnslWaJj8n2pCOh5qM6p
evB1LUQKVCiMv24Or+vC8QouhmKu99dvEGuawR38/AbMeQGNlCRlJmTEPdcGPHZL
fGxD9GyhSUAo47sr0QqU/FZ0Xo3ZHMUF8C6ns2YVoUjtXVIkLa0TUOo/pz1khWJn
AXtvJ5g/pP5eLGgKuh4kv91BVgyA87a9iIsuxEiYUTURW8E/Q8iBUT63QmWFItCh
Je21wZPmwzuJOyBaJyJv7exCq1me8hFM59xz/jadmhgScQMrTiNWgLK9HAtIwEpa
0qWOHSy07uhJPkIQCo2h4PI482/7eJLljGejZVZyE2l2wMzKCV6UrYhOngbr2G/z
YulXu66EG3J13rEu5sV/a2PyOjQ0RRe+60xG9TB76ltCcVgWgcwnEznz+vv7SUDC
HYZChG9ijD/Hjy/3V0V051IIcPENjMCmaw/Rx2vVPS5sPA3txWaXQaOCuq6m0Rg7
UEnP5ezRMUwR9kUM5QB2rfuGGe3cZb8ZyZGoxdQuL9Vzh/R3Duk=
=rZmc
-END PGP SIGNATURE-



Bug#983258: db.c: add "keep_active_file" and "only_newsrc_groups" and use them

2021-02-21 Thread Bjarni Ingi Gislason
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 93b9b1e521748665423964c660c9b6fd259cbf6f Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sun, 21 Feb 2021 16:02:07 +A
>Subject: [PATCH] db.c: add "keep_active_file" and "only_newsrc_groups" and use
> them

Signed-off-by: Bjarni Ingi Gislason 
---
 db.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/db.c b/db.c
index cfe979d..4278dda 100644
--- a/db.c
+++ b/db.c
@@ -98,6 +98,8 @@ extern char
*master_directory, *db_directory, *db_data_directory, 
*news_directory, *news_lib_directory;
 extern int  db_data_subdirs, new_group_action;
 
+int keep_active_file = 0;
+
 master_header   master;
 
 #ifdef MALLOC_64K_LIMITATION
@@ -533,6 +535,9 @@ make_master_copy(int force_copy)
 /*
  * Init the groups data from active file.
  */
+
+int only_newsrc_groups = 0;
+
 void
 open_master(int mode)
 {
@@ -543,7 +548,11 @@ open_master(int mode)
 active_groups = NULL;
 sorted_groups = NULL;
 
-readactfile(); /* Read in the active file - count groups */
+if (only_newsrc_groups)
+   readpartactfile();
+else
+   readactfile();  /* Read in the active file - count groups */
+
 readtimfile(); /* Read the newsgroup creation time file */
 
 db_expand_master();/* uses count from readact() call! */
@@ -1007,6 +1016,7 @@ readactfile(void)
 int i;
 FILE   *actfp;
 stlist_t   *sthead, *stp = NULL;
+extern int  keep_active_file;
 
 if (actlist != NULL)
return;
@@ -1028,6 +1038,19 @@ readactfile(void)
  * groups we can use for internal tables.
  */
 sthead = NULL;
+gotoxy(0, 3);
+tprintf("Reading active file ... ");
+fflush(stdout);
+
+if (nntp_debug || keep_active_file) {
+   if (f_user == NULL) {
+   f_user = open_file(relative(active_directory, "ACTIVE"), 
OPEN_CREATE);
+   if (f_user == NULL) {
+   msg("Could not open file in the %s directoy for writing the 
active file, %s%s%d\n",
+active_directory, __FILE__, ":", __LINE__);
+   }
+}
+}
 
 #ifdef NNTP
 while (use_nntp ? nntp_fgets(actline, sizeof actline)
@@ -1037,6 +1060,9 @@ readactfile(void)
 #endif /* NNTP */
 
 {
+   if ( (nntp_debug || keep_active_file) && (f_user != NULL))
+   fprintf(f_user, "%s\n", actline);
+
stlist_t   *stnew = (stlist_t *) strkeep(actline, 
sizeof(stlisthdr_t), POOL_ACT);
if (stnew == NULL) {
nn_exitmsg(1, "out of mem for active file (at line %d)\n", count + 
1);
-- 
2.30.0



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason



Bug#973570: fzf: keybinding files should be installed under /etc

2021-02-21 Thread Jonas Smedegaard
Package: fzf
Version: 0.24.3-1+b1
Followup-For: Bug #973570

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Debian Policy §12.6 says that /usr/share/doc/*/examples/ is "for the
benefit of the system administrator and users as documentation only."

Notice the final part of "documentation only".

As I also commented today at the fine blog entry at
https://linuxnatives.net/2021/save-time-command-line-fuzzy-finder
users should not rely on files at that location for code execution.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmAyhi0ACgkQLHwxRsGg
ASEIHBAAkaaPfE/gJkNVPHZ2ucrjiWlNMHgk8KKfwhh03VBSpxs4pwDJPdxb4DsQ
cNL02F+FvvtYUDftydBzWs6reUzciOz8QMBTSrdWYvGYs0wJgGsUyOfeA9p22b3l
YGn9a57a4OJwMDb9mTyPONWBHz/9X2bRnVXUVqeoD0TtLL96VfIlCskTs4+oWx8F
WyqjVBKVKbHjXBPs70m/X+jAGSNoJEZY8a8/FCGW8h6diONeuy3L4iOSR+1Cdxjp
wEJQyYIZoS4QxSFaIptFEb8b2/YT+Kl5F9HeGTbo18y/gLi9m8WfHCrNp09IJML5
Nbylq057XJ54dF//6NjJ+OJqUrVM8fHYkF0pk9K7f+eth2iNJR2i6t5VbHSo6+tb
8qcZshNoTwRiycJ2PjJ7G+RBb0n8BcevESDrbYDEtqWNGoNFgLjQREnDqPLe2Y/R
YXOyTldCb6IG7nnIKs2SY0p+iE1OSUhxlGi8L5fW5VtnB08I14O/kHDS7rx82nFk
Kxz8e4asmHrtYhuWj8FLjCsJ5z5oC+mDD1HqigIo/OXI4zIa0TYY804uCfqgwwl3
blopD+ET8bs+y7X6rdTnK4BKK+U/hP6u/0J2RM672WDHjeG4cqWEnhRKWiz/MtPI
h5cmw7jyZQ9YvXSWn8VGO/wbVyJLE0N1SGZwpgNuDtbQZls2pj0=
=vh0w
-END PGP SIGNATURE-


Bug#976678: dstat: upgrade warnings when upgrading from python3.8 to python3.9

2021-02-21 Thread Christoph Biedl
Andres Salomon wrote...

> Python 3.9 just migrated to testing yesterday. When I did a
> dist-upgrade on my testing machine, I saw the following warnings that
> originated from dstat:

Gentle ping? It was nice to have that resolved in bullseye, and the fix
is simple. But time is running up.

If you want somebody to NMU it, just say the word. I could take care to
that, then.

Christoph


signature.asc
Description: PGP signature


Bug#983257: global.c

2021-02-21 Thread Bjarni Ingi Gislason
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 3ce77904fbb554af01ec01b35af3705798186d46 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sun, 21 Feb 2021 00:16:07 +
>Subject: [PATCH] global.c: use "mkstemp" instead of "mktemp"

  Warning from the linker:

/usr/bin/ld: global.o: in function `new_temp_file':
global.c:(.text+0x4df): warning: the use of `mktemp' is dangerous,
better use `mkstemp' or `mkdtemp'

Signed-off-by: Bjarni Ingi Gislason 
---
 global.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/global.c b/global.c
index a783672..1f8ef67 100644
--- a/global.c
+++ b/global.c
@@ -369,7 +369,7 @@ new_temp_file(void)
 }
 
 sprintf(buf, "%s/nn.XX", tmp_directory);
-mktemp(buf);
+mkstemp(buf);
 temp_file = buf;
 }
 
-- 
2.30.0



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason



Bug#983251: passwd is missing dependencies

2021-02-21 Thread Tim Woodall

On Sun, 21 Feb 2021, Chris Hofstaedtler wrote:


* Tim Woodall  [210221 15:28]:

I am unsure how debootstrap avoids the first problem - It could just be
down to luck that debootstrap configures base-passwd before passwd. grep
is Priority: required and Essential: yes so it could be argued that it
should be unpacked before attempting to configure passwd and so this
dependency is not required.


That is exactly the case. Both grep and base-passwd are Essential:
yes, so they _must_ function already (even when not configured yet).

Adding them to Depends: could be argued to be a bug.



The fundamental problem is actually that base-passwd is marked as
Essential but passwd required it to have run its postinst script.

Therefore the issue seems to be that base-passwd shouldn't be essential
at all.



Bug#940821: NFS Caching broken in 4.19.37

2021-02-21 Thread Anton Ivanov

On 21/02/2021 14:37, Bruce Fields wrote:

On Sun, Feb 21, 2021 at 11:38:51AM +, Anton Ivanov wrote:

On 21/02/2021 09:13, Salvatore Bonaccorso wrote:

On Sat, Feb 20, 2021 at 08:16:26PM +, Chuck Lever wrote:

Confirming you are varying client-side kernels. Should the Linux
NFS client maintainers be Cc'd?

Ok, agreed. Let's add them as well. NFS client maintainers any ideas
on how to trackle this?

This is not observed with Debian backports 5.10 package

uname -a
Linux madding 5.10.0-0.bpo.3-amd64 #1 SMP Debian 5.10.13-1~bpo10+1
(2021-02-11) x86_64 GNU/Linux

I'm still unclear: when you say you tested a certain kernel: are you
varying the client-side kernel version, or the server side, or both at
once?


Client side. This seems to be an entirely client side issue.

A variety of kernels on the clients starting from 4.9 and up to 5.10 
using 4.19 servers. I have observed it on a 4.9 client versus 4.9 server 
earlier.


4.9 fails, 4.19 fails, 5.2 fails, 5.4 fails, 5.10 works.

At present the server is at 4.19.67 in all tests.

Linux jain 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) 
x86_64 GNU/Linux


I can set-up a couple of alternative servers during the week, but so far 
everything is pointing towards a client fs cache issue, not a server one.


Brgds,


--b.



--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/



Bug#983255: firmware-realtek: Direct firmware load for rtw88/rtw8821c_fw.bin failed with error -2

2021-02-21 Thread Alois Schlögl
Package: firmware-realtek
Version: 20210208-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

security update, on linux backports kernel (upgrade from 5.9 to 5.10) 

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

apt update && apt upgrade && reboot 

   * What was the outcome of this action?

wlan adapter was not available after reboot

dmesg has these lines: 
lspci | grep -i wire
02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821CE 802.11ac 
PCIe Wireless Network Adapter

dmesg contains these lines: 

[4.938468] rtw_8821ce :02:00.0: Direct firmware load for 
rtw88/rtw8821c_fw.bin failed with error -2
[4.938472] rtw_8821ce :02:00.0: failed to request firmware
[4.938543] rtw_8821ce :02:00.0: failed to load firmware
[4.938571] rtw_8821ce :02:00.0: failed to setup chip efuse info
[4.938599] rtw_8821ce :02:00.0: failed to setup chip information
[4.939514] rtw_8821ce: probe of :02:00.0 failed with error -22

tried to install also latest firmware-realtek from unstable 
ii  firmware-realtek20210208-1  
all  Binary firmware for Realtek wired/wifi/BT adapters
but this did also not change anything. 


   * What outcome did you expect instead?

wlan working as before. 


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


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

Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.133+deb10u1

-- no debconf information



Bug#983251: passwd is missing dependencies

2021-02-21 Thread Chris Hofstaedtler
* Tim Woodall  [210221 15:28]:
> I am unsure how debootstrap avoids the first problem - It could just be
> down to luck that debootstrap configures base-passwd before passwd. grep
> is Priority: required and Essential: yes so it could be argued that it
> should be unpacked before attempting to configure passwd and so this
> dependency is not required.

That is exactly the case. Both grep and base-passwd are Essential:
yes, so they _must_ function already (even when not configured yet).

Adding them to Depends: could be argued to be a bug.

Chris



Bug#920434: ping does not round correctly

2021-02-21 Thread Jethro Beekman
Package: iputils-ping
Version: 3:20180629-2+deb10u1
Followup-For: Bug #920434

Dear Maintainer,

This bug is especially egregious for ping times between 1995 and 1999ns, where
it prints as “time=1.100 ms” instead (nearly 2× difference).


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

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

Versions of packages iputils-ping depends on:
ii  libc6   2.28-10
ii  libcap2 1:2.25-2
ii  libidn2-0   2.0.5-1+deb10u1
ii  libnettle6  3.4.1-1

Versions of packages iputils-ping recommends:
ii  libcap2-bin  1:2.25-2

iputils-ping suggests no packages.

-- no debconf information



Bug#983252: RFA: pencil2d -- Create hand-drawn animation using both bitmap and vector graphics

2021-02-21 Thread Mattia Rizzolo
Package: wnpp
Control: affects -1 src:pencil2d

Hi,

I'd like to ask for a new maintainer for Pencil2D.

Since I packaged it back in 2015 my interest in this program waned, so I
think it's proper that I hand it over to somebody who actually cares
about it.

The package is very simple, with a moderately active upstream
maintainer, and since the maintenance load is light I plan to keep it up
for the near future, but if you are interested in this package I'd be
happy to hand it over.

You can find more information about Pencil2D in their homepage: 
https://www.pencil2d.org/

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#983250: vlc: Crash when starting to play video under weston / wayland

2021-02-21 Thread Sebastian Ramacher
Control: tags -1 upstream

On 2021-02-21 15:14:16 +, Witold Baryluk wrote:
> Package: vlc
> Version: 3.0.12-2
> Severity: normal
> X-Debbugs-Cc: witold.bary...@gmail.com
> 
> I just decided to try wayland again for the first time in years, and test 
> some apps.
> 
> mpv works.
> 
> vlc doesn't.

Wayland support is spposed to be better with the upcoming vlc 4.0. No
idea when that version will be released, though.

Cheers

> 
> user@debian:~$ gdb --init-eval-command="set pagination off" --args vlc -vvv 
> Rick\ Astley\ -\ Never\ Gonna\ Give\ You\ Up\ \(Video\)-dQw4w9WgXcQ.mkv 
> GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
> Copyright (C) 2021 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 vlc...
> (No debugging symbols found in vlc)
> (gdb) r
> Starting program: /usr/bin/vlc -vvv Rick\ Astley\ -\ Never\ Gonna\ Give\ You\ 
> Up\ \(Video\)-dQw4w9WgXcQ.mkv
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> VLC media player 3.0.12 Vetinari (revision 3.0.12-1-0-gd147bb5e7e)
> [a5b0] main libvlc debug: VLC media player - 3.0.12 Vetinari
> [a5b0] main libvlc debug: Copyright © 1996-2020 the VideoLAN team
> [a5b0] main libvlc debug: revision 3.0.12-1-0-gd147bb5e7e
> [a5b0] main libvlc debug: configured with ./configure  
> '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' 
> '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' 
> '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' 
> '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' 
> '--runstatedir=/run' '--disable-maintainer-mode' 
> '--disable-dependency-tracking' '--disable-debug' '--config-cache' 
> '--disable-update-check' '--enable-fast-install' 
> '--docdir=/usr/share/doc/vlc' '--with-binary-version=3.0.12-2' '--enable-a52' 
> '--enable-aa' '--enable-aribsub' '--enable-avahi' '--enable-bluray' 
> '--enable-caca' '--enable-chromaprint' '--enable-chromecast' '--enable-dav1d' 
> '--enable-dbus' '--enable-dca' '--enable-dvbpsi' '--enable-dvdnav' 
> '--enable-faad' '--enable-flac' '--enable-fluidsynth' '--enable-freetype' 
> '--enable-fribidi' '--enable-gles2' '--enable-gnutls' '--enable-harfbuzz' 
> '--enable-jack' '--enable-kate' '--enable-libass' '--enable-libmpeg2' 
> '--enable-libxml2' '--enable-lirc' '--enable-mad' '--enable-matroska' 
> '--enable-mod' '--enable-mpc' '--enable-mpg123' '--enable-mtp' 
> '--enable-ncurses' '--enable-notify' '--enable-ogg' '--enable-opus' 
> '--enable-pulse' '--enable-qt' '--enable-realrtsp' '--enable-samplerate' 
> '--enable-sdl-image' '--enable-sftp' '--enable-shine' '--enable-shout' 
> '--enable-skins2' '--enable-sndio' '--enable-soxr' '--enable-spatialaudio' 
> '--enable-speex' '--enable-svg' '--enable-svgdec' '--enable-taglib' 
> '--enable-theora' '--enable-twolame' '--enable-upnp' '--enable-vdpau' 
> '--enable-vnc' '--enable-vorbis' '--enable-x264' '--enable-x265' 
> '--enable-zvbi' '--with-kde-solid=/usr/share/solid/actions/' '--disable-aom' 
> '--disable-crystalhd' '--disable-d3d11va' '--disable-decklink' 
> '--disable-directx' '--disable-dsm' '--disable-dxva2' '--disable-fdkaac' 
> '--disable-fluidlite' '--disable-freerdp' '--disable-goom' 
> '--disable-gst-decode' '--disable-libtar' '--disable-live555' 
> '--disable-macosx' '--disable-macosx-avfoundation' '--disable-macosx-qtkit' 
> '--disable-mfx' '--disable-microdns' '--disable-opencv' '--disable-projectm' 
> '--disable-schroedinger' '--disable-sparkle' '--disable-srt' '--disable-telx' 
> '--disable-vpx' '--disable-vsxu' '--disable-wasapi' '--enable-alsa' 
> '--enable-dc1394' '--enable-dv1394' '--enable-libplacebo' '--enable-linsys' 
> '--enable-nfs' '--enable-udev' '--enable-v4l2' '--enable-wayland' 
> '--enable-libva' '--enable-vcd' '--enable-smbclient' '--disable-oss' 
> '--enable-mmx' '--enable-sse' '--disable-neon' '--disable-altivec' 
> '--disable-omxil' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
> -ffile-prefix-map=/build/vlc-zugIQk/vlc-3.0.12=. -fstack-protector-strong 
> -Wformat -Werror=format-security ' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
> 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 
> -ffile-prefix-map=/build/vlc-zugIQk/vlc-3.0.12=. -fstack-protector-strong 
> 

  1   2   >