Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Thomas Stewart]

Yes, I'm using sssd against FreeIPA.

Tom


On 28 January 2021 02:12:11 GMT, "Limonciello, Mario" 
 wrote:
>Are you by chance using NFS mounted directories?  Or external entity
>for authentication such as LDAP or SSSD?

Bug#966222: FYI - fix for this is in MR !6

[Christian Ehrhardt]

In case no one is monitoring the merge requests, but does for these
bugs (as the MR is up for a while without response), see:
  https://salsa.debian.org/debian/fio/-/merge_requests/6

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#981114: nvidia-driver: Fails to display on any monitor change

[David Headland]

Package: nvidia-driver
Version: 460.39-1
Followup-For: Bug #981114


Hi Andreas,

I was unable to find the packages at present, but I understand that they
do take a little while to filter through the system. However, the source
was available, and I had no problem using debuild to create the
(unsigned) packages locally. Installing the new version of all currently
installed packages then running update-glx to select that version and
rebooting, I'm afraid the problem comes back.

I've replied using reportbug so you can see the collected information 
in case that's of use - the test case was to boot up, switch monitor
inputs, and switch back. These are the the old Xorg log fix - ~62s was
the switch away, ~73s was the attempt to switch back. No sync at all
when switching back. Tried to switch to a text console, still no
display, so rebooted.

For now, I'm going to switch back to the tesla-450 driver, but I'm very
happy to run any more tests if you'd like me to. Also, when the packages
filter through the system far enough for apt to see them, I'll re-test
with the official ones and confirm this situation.

All the best,
-Dave.

-- Package-specific info:
uname -a:
Linux scrat 5.10.0-2-amd64 #1 SMP Debian 5.10.9-1 (2021-01-20) x86_64 GNU/Linux

/proc/version:
Linux version 5.10.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP 
Debian 5.10.9-1 (2021-01-20)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  460.39  Thu Jan 21 21:54:06 UTC 
2021
GCC version:  gcc version 10.2.1 20210110 (Debian 10.2.1-6) 

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP108 [GeForce GT 
1030] [10de:1d01] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Gigabyte Technology Co., Ltd GP108 [GeForce GT 1030] 
[1458:375c]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video  226,   0 Jan 28 06:34 /dev/dri/card0
crw-rw+ 1 root render 226, 128 Jan 28 06:34 /dev/dri/renderD128
crw-rw-rw-  1 root root   195, 254 Jan 28 06:34 /dev/nvidia-modeset
crw-rw-rw-  1 root root   195,   0 Jan 28 06:34 /dev/nvidia0
crw-rw-rw-  1 root root   195, 255 Jan 28 06:34 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 Jan 28 06:34 pci-:01:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Jan 28 06:34 pci-:01:00.0-render -> ../renderD128
video:x:44:dh,mythtv

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Oct 25 11:58 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   49 Jan 28 06:13 
/etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root   51 Oct 25 11:58 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   48 Jan 28 06:13 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Jan 28 06:13 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   50 Oct 25 11:58 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 Oct 25 11:58 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   55 Jan 28 06:13 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root   55 Jan 28 06:13 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root   57 Oct 25 11:58 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   57 Oct 25 11:58 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   52 Jan 28 06:13 
/etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root   52 Jan 28 06:13 
/etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root   54 Oct 25 11:58 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   54 Oct 25 11:58 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x8

Bug#970497: igraph: FTBFS on mips64el

[Jerome BENOIT]

Hello,

I am currently isolating the faulty code on the porter Eller.

The issue seems to appear after the call to arpack functions,
so it does not look as an arparck issue.

Best wishes,
Jerome

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B

Bug#981176: Bug#981240: RFP: opendoas -- A portable version of OpenBSD's doas command

[Salvatore Bonaccorso]

Control: forcemerge 981176 981240

Hi,

On Thu, Jan 28, 2021 at 06:09:43AM +, Franklin Yu wrote:
> Package: wnpp
> Version: N/A; reported 2021-01-27
> Severity: wishlist
> 
> * Package name: opendoas
>   Version : 6.8
>   Upstream Author : Duncan Overbruck 
> * URL : https://github.com/Duncaen/OpenDoas
> * License : ISC
>   Programming Lang: C
>   Description : A portable version of OpenBSD's doas command.
> 
> See packages for other distributions on https://repology.org/project/opendoas.

There is a RFP for it already as #981176 so merging both bugs.

Regards,
Salvatore

Bug#950442: radicale: missing-systemd-service-for-init.d-script

[Antonio Russo]

Hello Andreas,

I lifted the systemd service file out of DOCUMENTATION.md.  Now that you point 
it
out, it would make sense for us to hard-code the Debian path to python3 in 
there.
However, I didn't really try to change it, since I'd like to stay as close to
upstream as possible.

As for upstreaming the changes: I assume that they had some good reason not to
put it in a file by itself.  I do not have any preexisting relationship with
them, so I don't feel like rocking the boat to change things up.

Best,
Antonio Russo


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#980809: [R-pkg-team] Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

[Graham Inggs]

Hi Dirk

On Thu, 28 Jan 2021 at 01:12, Dirk Eddelbuettel  wrote:
> Any update here?  It still points at Matrix aka rmatrix aka r-cran-matrix,
> and I still think wrongly.

I'm still waiting for the results of the autopkgtest against the
rebuilt r-cran-tmb on s390x.
Unfortunately, it went into the queue behind a bunch of perl tests.

Right now, I see results from 2020-12-11 and 2021-01-22, and two queued tests:
https://ci.debian.net/user/britney/jobs?package=r-cran-glmmtmb&suite[]=testing&arch[]=s390x

Regards
Graham

Bug#981240: RFP: opendoas -- A portable version of OpenBSD's doas command

[Franklin Yu]

Package: wnpp
Version: N/A; reported 2021-01-27
Severity: wishlist

* Package name: opendoas
  Version : 6.8
  Upstream Author : Duncan Overbruck 
* URL : https://github.com/Duncaen/OpenDoas
* License : ISC
  Programming Lang: C
  Description : A portable version of OpenBSD's doas command.

See packages for other distributions on https://repology.org/project/opendoas.

Bug#981236: miniupnpd: Syslogging is overly verbose due to the -d option

[Nye Liu]

Package: miniupnpd
Version: 2.2.1-1
Severity: normal

The miniupnpd systemd unit file sets the -d option to foreground it. However, 
that is extremely verbose.

It may be better to set `start_daemon` false in the config file instead.


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

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

Versions of packages miniupnpd depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  init-system-helpers1.60
ii  lsb-base   11.1.0
ii  miniupnpd-iptables 2.2.1-1
ii  uuid-runtime   2.36.1-6

miniupnpd recommends no packages.

miniupnpd suggests no packages.

-- debconf information:
* miniupnpd/iface: eth0
  miniupnpd/ip6script: false
* miniupnpd/start_daemon: true
  miniupnpd/force_igd_desc_v1: false
* miniupnpd/listen: eth1

-- debsums errors found:
debsums: changed file /lib/systemd/system/miniupnpd.service (from miniupnpd 
package)

Bug#981235: deja-dup: Does not check if encryption passphrase matches previous ones when making a fresh full backup

[Jaycee Santos]

Package: deja-dup
Version: 38.3-1
Severity: important

Dear Maintainer,

The current version of deja-dup in buster is affected by
https://wiki.gnome.org/Apps/DejaDup/PassphraseProblems2019.

When deja-dup decides to make a full backup after a while, it asks for an
encryption passphrase.

However, duplicity does not verify whether or not the passphrase is the same as
the one used in previous backups.

This can lead to a mismatching backup chain. Backups may be jeopardized if one
happens to make a typo when deja-dup makes a fresh backup once in a while.

The GNOME Wiki page states that deja-dup addressed the passphrase verification
problem in its 39.1 release.

Is it possible to have this fixed in buster?



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

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

Versions of packages deja-dup depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  duplicity0.7.18.2-1
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgoa-1.0-0b3.30.1-2
ii  libgoa-backend-1.0-1 3.30.1-2
ii  libgtk-3-0   3.24.5-1
ii  libnautilus-extension1a  3.30.5-2
ii  libpackagekit-glib2-18   1.1.12-5
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpeas-1.0-01.22.0-4
ii  libsecret-1-00.18.7-1

Versions of packages deja-dup recommends:
ii  gvfs-backends  1.38.1-5
ii  packagekit 1.1.12-5
ii  policykit-10.105-25

Versions of packages deja-dup suggests:
pn  python-boto 
pn  python-cloudfiles   
pn  python-swiftclient  

-- no debconf information

Bug#970386: Update?

[Noah Meyerhans]

I've prepared and tested an update and requested SRM approval in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981239

With any luck this makes it into 10.8

noah

Bug#981239: buster-pu: package dovecot/1:2.3.4.1-5+deb10u6

[Noah Meyerhans]

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

I'd like to update the dovecot IMAP suite in buster to address bug #970386.
This bug involves a server crash that's triggered when issuing a server-side
full-text search against a mailbox containing messages with certain malformed
MIME components.  The fix cherry-picked cleanly from upstream and I have
confirmed that it addresses the issue.

Thanks
noah
diff -Nru dovecot-2.3.4.1/debian/changelog dovecot-2.3.4.1/debian/changelog
--- dovecot-2.3.4.1/debian/changelog2020-12-28 15:18:55.0 -0800
+++ dovecot-2.3.4.1/debian/changelog2021-01-27 16:35:17.0 -0800
@@ -1,3 +1,10 @@
+dovecot (1:2.3.4.1-5+deb10u6) buster; urgency=medium
+
+  * Backport upstream fix for crash that occurred when searching mailboxes
+containing malformed MIME messages. (Closes: #970386)
+
+ -- Noah Meyerhans   Wed, 27 Jan 2021 16:35:17 -0800
+
 dovecot (1:2.3.4.1-5+deb10u5) buster-security; urgency=high
 
   * Import upstream fix for security issues:
diff -Nru dovecot-2.3.4.1/debian/patches/bug970386.patch 
dovecot-2.3.4.1/debian/patches/bug970386.patch
--- dovecot-2.3.4.1/debian/patches/bug970386.patch  1969-12-31 
16:00:00.0 -0800
+++ dovecot-2.3.4.1/debian/patches/bug970386.patch  2021-01-27 
16:35:17.0 -0800
@@ -0,0 +1,90 @@
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970386
+From: Timo Sirainen 
+Date: Mon, 31 Aug 2020 20:38:42 +0300
+Subject: [PATCH] lib-mail: message_parser_init_from_parts() - Fix crash if
+ MIME boundaries don't end
+
+If the last "boundary--" doens't exist, the parsing assert-crashed at
+deinit. This mainly happened when searching mails.
+
+Fixes:
+Panic: file message-parser.c: line 175 (message_part_finish): assertion 
failed: (ctx->nested_parts_count > 0)
+---
+ src/lib-mail/message-parser.c  | 13 -
+ src/lib-mail/test-message-parser.c | 21 -
+ 2 files changed, 28 insertions(+), 6 deletions(-)
+
+Index: dovecot/src/lib-mail/message-parser.c
+===
+--- dovecot.orig/src/lib-mail/message-parser.c
 dovecot/src/lib-mail/message-parser.c
+@@ -138,6 +138,7 @@ message_part_append(struct message_parse
+   struct message_part *parent = ctx->part;
+   struct message_part *part;
+ 
++  i_assert(!ctx->preparsed);
+   i_assert(parent != NULL);
+   i_assert((parent->flags & (MESSAGE_PART_FLAG_MULTIPART |
+  MESSAGE_PART_FLAG_MESSAGE_RFC822)) != 0);
+@@ -171,12 +172,14 @@ static void message_part_finish(struct m
+ {
+   struct message_part **const *parent_next_partp;
+ 
+-  i_assert(ctx->nested_parts_count > 0);
+-  ctx->nested_parts_count--;
+-
+-  parent_next_partp = array_back(&ctx->next_part_stack);
+-  array_pop_back(&ctx->next_part_stack);
+-  ctx->next_part = *parent_next_partp;
++  if (!ctx->preparsed) {
++  i_assert(ctx->nested_parts_count > 0);
++  ctx->nested_parts_count--;
++
++  parent_next_partp = array_back(&ctx->next_part_stack);
++  array_pop_back(&ctx->next_part_stack);
++  ctx->next_part = *parent_next_partp;
++  }
+ 
+   message_size_add(&ctx->part->parent->body_size, &ctx->part->body_size);
+   message_size_add(&ctx->part->parent->body_size, 
&ctx->part->header_size);
+Index: dovecot/src/lib-mail/test-message-parser.c
+===
+--- dovecot.orig/src/lib-mail/test-message-parser.c
 dovecot/src/lib-mail/test-message-parser.c
+@@ -180,9 +180,10 @@ static void test_message_parser_small_bl
+ static void test_message_parser_stop_early(void)
+ {
+   struct message_parser_ctx *parser;
+-  struct istream *input;
++  struct istream *input, *input2;
+   struct message_part *parts;
+   struct message_block block;
++  const char *error;
+   unsigned int i;
+   pool_t pool;
+   int ret;
+@@ -200,6 +201,24 @@ static void test_message_parser_stop_ear
+ &block)) > 0) ;
+   test_assert(ret == 0);
+   message_parser_deinit(&parser, &parts);
++
++  /* test preparsed - first re-parse everything with a stream
++ that sees EOF at this position */
++  input2 = i_stream_create_from_data(test_msg, i);
++  parser = message_parser_init(pool, input2, &set_empty);
++  while ((ret = message_parser_parse_next_block(parser,
++&block)) > 0) ;
++  test_assert(ret == -1);
++  message_parser_deinit(&parser, &parts);
++
++  /* now parse from the parts */
++  i_stream_seek(input2, 0);
++  parser = message_parser_init_from_parts(parts, input2, 
&set_em

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Sam Hartman]

General arguments about how the TC should conduct its business do not
belong on this bug.
I'd appreciate it if replies to this message are directed to a different
place than this bug.

We've established that the TC is operating consistently both with its
historical process and with currently permitted behavior for a group of
Debian developers.
You're making an argument about what the TC's behavior should be that is
general, not specific to this issue.

Please make that argument in a general forum and do not tie it to this
issue.

You're also making an argument that has been made before without
choosing to avail yourself of the history of the discussion on TC
privacy.
My recommendation would be to find someone who agrees with you who has
followed that history and learn it--at least the parts of the history
that support your position.
Your argument would come across stronger if you did.

> "Felix" == Felix Lechner  writes:

Felix> Hi,
Felix> On Tue, Jan 26, 2021 at 5:48 PM Sandro Tosi  wrote:
>> 
>> the ability to talk privately with the committee is something
>> CTTE has allowed for a long time

Felix> Debian has many great traditions, but the Magna Carta is much
Felix> older. I found a great article about it ([1], p. 5):

Felix> "the simple human need for fairness, reflected in western
Felix> jurisprudence since at least 1215 when it was pronounced in
Felix> the Magna Carta, underlies the legal concerns about ex parte
Felix> communications during administrative decisionmaking
Felix> processes. Fairness certainly requires an impartial
Felix> decisionmaker, and often the appearance of impartiality can
Felix> become as important a factor in the legal review of fairness
Felix> as actual impartiality."

Fortunately for all of us, the TC is not a legal body, and this is not a
legal dispute process, nor does jurisprudence apply as a concept.

Yes, you can consider whether concepts from jurisprudence should wrap
over to Debian processes, but you need to actually justify that, and
consider the trade offs.
It is unsurprising to me that the trade offs for a legal process that
can deprive someone of property and life work out differently than the
trade offs for a body charged with choosing a technical path for an
operating system.
That's true even when people are emotionally invested in the outcomes.
Fairness is one thing that someone might value.
It tends to be highly valued in jurisprudence, but other things might be
valued more highly in a proceeding like the TC.
And you don't get fairness when the process is emotionally draining
enough that key stakeholders refuse to cooperate.

Bug#981238: wrong library path on some platforms?

[Aleksi Suhonen]

Package: libpam-oath
Version: 2.6.6-1
Severity: important

The library is installed in /lib/security, but on armel platform it 
seems to be expected to be found in /lib/arm-linux-gnueabi/security/ at 
least as evidenced by this sshd error message:


Jan 28 04:27:07 debian sshd[9841]: PAM unable to dlopen(pam_oath.so): 
/lib/arm-linux-gnueabi/security/pam_oath.so: cannot open shared object 
file: No such file or directory


Linking the file to the proper location fixes the whole problem.

--
Aleksi Suhonen

() ascii ribbon campaign
/\ support plain text e-mail

Bug#981159: extra-cmake-modules: drop unused qt Build-Depends

[Norbert Preining]

Hi Helmut,

> -   qtdeclarative5-dev,
> -   qttools5-dev (>= 5.4),
> -   qttools5-dev-tools (>= 5.4),

Thanks, tested and committed to git.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#977694: 5.10.4 Debian kernel does not boot on raspi 4 with ext4 rootfs and usb-msd

[Ryutaroh Matsumoto]

Control: reassign -1 raspi-firmware 1.20210111+ds-2

Booting linux kernel 5.10.x from USB MSD needs either
* loading reset-raspberrypi.ko in initramfs,
* or rebuild kernel with CONFIG_RESET_RASPBERRYPI=y in .config

Anyway, the combination of linux-image-arm64/sid and raspi-firmware/sid
does not allow booting RPi4 from USB-MSD.
Boot from USB-MSD was possible in Debian kernel 5.9 series.

I think this boot failure should be fixed by
echo reset-raspberrypi >/usr/share/initramfs-tools/modules.d/raspi-firmware.conf
instead of CONFIG_RESET_RASPBERRYPI=y.

If this is considered an issue in src:linux, please reassign this back.

Best regards, Ryutaroh Matsumoto

Bug#981237: mycli: Mycli breaks with newer sqlparse

[David Engel]

Package: mycli
Version: 1.22.2-0.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The Debian package of mycli has the following dependency:

python3-sqlparse (>= 0.3.0)

Yet the python code in the package has the following dependency:

sqlparse>=0.3.0,<0.4.0

The debian sqlparse package in unstable was just updated to version
0.4.1-1.  This causes the mycli code to raise an exception and abort
because the installed sqlparse is too new.  The master branch of the
upstream, mycli source appears to still have the old dependency so
the problem is probably not fixed there yet either.

David

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

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

Versions of packages mycli depends on:
ii  python3 3.9.1-1
ii  python3-click   7.1.2-1
ii  python3-configobj   5.0.6-4
ii  python3-cryptography3.2.1-1
ii  python3-pkg-resources   51.3.3-1
ii  python3-prompt-toolkit  3.0.10-1
ii  python3-pygments2.7.1+dfsg-1
ii  python3-pymysql 0.9.3-2
ii  python3-sqlparse0.4.1-1
ii  python3-tabulate0.8.7-0.1
ii  python3-terminaltables  3.1.0-3

mycli recommends no packages.

mycli suggests no packages.

-- no debconf information

Bug#980778: RFS: tnftp/20200705-2 -- enhanced ftp client

[肖盛文]

Hi,

在 2021/1/27 下午11:36, Boyuan Yang 写道:

Hi,

Unfortunately there are other problems within the package. By rewriting
the debian/rules file, the old logic of renaming files and handling the
alternatives system is now broken. Please compare the built filelist of
your current package and the .deb filelist of tnftp/20200705-1 and you
will find the difference. Please read the old debian/rules again and
recover those file renaming logic.

Thanks,
Boyuan Yang


I used execute_after_dh_installman to recover those file renaming logic.


I'd uploaded the new package, welcome to review again.


Thanks !


--
肖盛文 xiao sheng wen Faris Xiao
微信(wechat)：atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x00186602339240CB



OpenPGP_0x00186602339240CB.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#968192: xkb-data: bepo_afnor missing eszett character

[Jean-Louis Biasini]

after learning a bit more about bépo layout, it turns out the 
problematics keys are all supposed to be dead keys.


not being detected as such due to XCompose not implementing them is the 
reason why it does not work properly


So I’ll report this to libx11-data you can close this.

On Thu, 20 Aug 2020 18:25:35 +0300 Jean-Louis Biasini 
 wrote:


> I spotted some more errors for caracter infinity and e as exposant see
> patch attached (new patch also include previous patch)
>
> Le 10/08/2020 à 15:08, Jean-Louis Biasini a écrit :
> > Package: xkb-data
> > Version: 2.29-2
> > Severity: normal
> > Tags: patch
> >
> > Dear Maintainer,
> >
> > the french bepo variant afnor contains an error which prevent the 
user from

> > typing german eszett caracter ß (code ssharp)
> >
> > The error is easily spotable in /usr/share/X11/xkb/symbols/fr since the
> > same
> > mapping already exist and is correctly mapped on other variant of the
> > bepo (see patch).
> >
> > thanks for your work,
> >
> > jean-louis
> >
> > -- System Information:
> > Debian Release: bullseye/sid
> > APT prefers stable-updates
> > APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable'),
> > (90, 'unstable')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
> > Kernel taint flags: TAINT_USER
> > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE

> > not set
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > -- no debconf information
> >
>
>

Bug#968192: the problem is actually related to XCompose

[Jean-Louis Biasini]

after learning a bit more about bépo layout, it turns out the 
problematics keys are all supposed to be dead keys.


not being detected as such due to XCompose not implementing them is the 
reason why it does not work properly


So I’ll report this to libx11-data you can close this.

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Limonciello, Mario]

Are you by chance using NFS mounted directories?  Or external entity for 
authentication such as LDAP or SSSD?

> -Original Message-
> From: Thomas Stewart 
> Sent: Wednesday, January 27, 2021 8:33
> To: Limonciello, Mario
> Cc: 943...@bugs.debian.org
> Subject: Re: Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh
> fwupd metadata and update motd.
> 
> 
> [EXTERNAL EMAIL]
> 
> On 27 Jan 2021, at 14:18, Limonciello, Mario wrote:
> > Can you check if fwupdmgr works as a standard user to talk to the daemon for
> you?
> 
> As a normal user I can run "fwupdmgr --version" fine[0].
> 
> However if I amend the unit to run the above[1] the output stops before
> daemon version[2].
> 
> Kind Regards
> --
> Tom
> 
> [0]
> $ id
> uid=1000(thomas) gid=1000(thomas)
> groups=1000(thomas),20(dialout),27(sudo),128(docker)
> $
> $ /usr/bin/fwupdmgr --version
> client version: 1.5.5
> compile-time dependency versions
> gusb:   0.3.5
> 
> daemon version: 1.5.5
> $
> 
> [1]
> ExecStart=/usr/bin/fwupdmgr --version
> 
> [2]
> Jan 27 14:24:38 systemd[1]: Starting Refresh fwupd metadata and update motd...
> Jan 27 14:24:38 fwupdmgr[199579]: client version:1.5.5
> Jan 27 14:24:38 fwupdmgr[199579]: compile-time dependency versions
> Jan 27 14:24:38 fwupdmgr[199579]: gusb:0.3.5
> Jan 27 14:24:38 fwupdmgr[199579]: Failed to connect to daemon: Exhausted all
> available authentication mechanisms (tried: EXTERNAL) (available: EXTERNAL)
> Jan 27 14:24:38 systemd[1]: fwupd-refresh.service: Main process exited,
> code=exited, status=1/FAILURE
> Jan 27 14:24:38 systemd[1]: fwupd-refresh.service: Failed with result 'exit-
> code'.
> Jan 27 14:24:38 systemd[1]: Failed to start Refresh fwupd metadata and update
> motd.

Bug#959474: Issues with Chinese language (all variants) when building some pages in buster

[Changwoo Ryu]

Korean is affected too and I added the "-O1" option workaround also to Korean.

Bug#978858: libthai: ftbfs with autoconf 2.70

[Theppitak Karoonboonyanan]

Control: tags -1 fixed-upstream

On Thu, Dec 31, 2020 at 9:33 PM Matthias Klose  wrote:

> The package fails to build in a test rebuild on at least amd64 with
> autoconf 2.70, but succeeds to build with autoconf 2.69. The
> severity of this report will be raised before the bookworm release,
> so nothing has to be done for the bullseye release.

This has been fixed upstream and should be available in next release:
https://github.com/tlwg/libthai/commit/896eba4e8f3faa079b2a6105bbb417adf92902ae

Regards,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/

Bug#981114: nvidia-driver: Fails to display on any monitor change

[Andreas Beckmann]

I've just uploaded nvidia-graphics-drivers 460.39-1 to sid, please try
that as well.

Andreas

Bug#981234: RM: plasma-base -- ROM; Not needed

[Norbert Preining]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-qt-...@lists.debian.org

Dear all,

plasma-base was an experiment to ensure locked upgrade, but it has
been rejected by the Qt/KDE team, and thus has lost its reason for
existence.

Please remove it from unstable (the only place where it is available).

Thanks

Norbert

Bug#981233: Useless in Bullseye

[David Prévot]

Package: php-webimpress-safe-writer
Version: 2.1.0-2
Severity: serious

[ Filled by the maintainer to see the package removed from testing ]

I recently packaged php-webimpress-safe-writer as a php-proxy-manager
dependency. Symfony just moved there dependency to a php-proxy-manager
fork that does not (yet) require php-webimpress-safe-writer. Since the
php-proxy-manager package in Debian now tracks this new fork, the
php-webimpress-safe-writer is now useless and I see no good reason to
ship it with Bullseye. I still intend to keep this package around in
Debian in case it becomes soon needed again by php-proxy-manager or
something else.

Regards

David


signature.asc
Description: PGP signature

Bug#981219: schroot overwrites cpuset

[David Bremner]

Roger Leigh  writes:
>
> The PAM auth and session handling is I think the most likely culprit,
> and this is not under our direct control.  Is there a particular PAM
> module which can change these cpusets?  If so, can you edit the
> schroot PAM configuration and see if it can be disabled this way?
> Possibly in @common-session?

I'm not sure (yet) what if any  pam module resets the Cpu_allowed mask,
but your idea seems worth investigating to me, since I noticed the same
behaviour with su.

d

Bug#978973: RFP: gnome-activity-journal -- Activity Journal for the GNOME desktop environment ( Powered by Zeitgeist 1.0.3 )

[crvi c]

Sure.

I've updated the latest build related instructions in
https://gitlab.gnome.org/crvi/gnome-activity-journal/-/blob/master/README.md

Feel free to skim through it, if possible.

Thanks

Bug#980079: mumble-server: service restart and stop borked

[Nils König]

Sorry it took me so long to come back to this.
And also sorry for the lengthy reply.

On Fri, Jan 15, 2021 at 09:27:30 +, Chris Knadle wrote:
> Is the system with this issue running systemd?

Yes, the affected system does run systemd.

> Which method of creating an SSL cert is being used?

certbot (Let's Encrypt)

> I've tested mumble-server on Debian 10.7 for this, with the default
> configuration, both with and without CAPABILITIES enabled, and I'm able to
> shut down mumble-server correctly on a system running systemd. […]

Welp, I couldn't reproduce it on other systems either; turned out some 
modification to the init-script I made months ago and forgot about was causing 
this (I suspect it only started to cause problems after a reboot).
Sorry, for wasting your time by jumping to a report to quickly.

Though, I also already heard about about the same thing happening to another 
user before (without any modification afaik). Hearing back from this user now,
the problem disappeared again for him without any apparent reason.
I'm afraid I don't know what's causing this issue for him and people 
reporting this upstream. Again, I'm terribly sorry to not have better checked 
on my side before reporting this.

Something (possibly related?) I noticed while investigating this:
If capabilities are used and uname in /etc/mumble-server.ini
is set to something else than "mumble-server", than this problem appears
as long as USER inside the init-script isn't also changed.
Ofc, before that happens murmur will first refuse to start at all, since
it will be unable to access vital files, like:
  /var/lib/mumble-server
  /var/log/mumble-server
  /etc/mumble-server.ini
Change ownership of those locations is perhaps more obvious than needing to 
edit some variable inside the init-script. Especially since after changing
ownership of those files murmur will at first glance appear to start just fine
as no error about the missing pid file is printed.
I'm however neither sure if that really is the cause for those upstream 
reports, nor what's the best way to solve this.


Now about the SSL-certs:

> I understand the problem of needing to start as root in order to read ssl
> certs, and […] I think there's an alternative; I think the SSL cert can
> be copied with different ownership + permissions to a location that
> mumble-server can access using a "post-hook" or "deploy-hook" call to
> certbot or dehydrated […]

Using --post-hook would be cleaner than my current method of just chaining
certbot renewal and restarting/reloading affected services, like so:

  certbot renew --quiet && service mumble-server restart

If the certificate should remain root-only, then
  --post-hook 'service mumble-server restart'
seems ok to me and is comfortably short.

Otherwise, if making it accessible to mumble-server is acceptable I assume 
calling a script similar to the following (!untested!) one in certbot's 
post-hook would be better and allows to utilise a reload instead of restart:

  #!/bin/sh
  set -e
  umask 077
  mkdir -p /var/lib/mumble-server/ssl
  cp /etc/letsencrypt/live/mumble.example.org/fullchain.pem 
/var/lib/mumble-server/ssl
  cp /etc/letsencrypt/live/mumble.example.org/privkey.pem   
/var/lib/mumble-server/ssl
  chown -R mumble-server:mumble-server /var/lib/mumble-server/ssl
  service mumble-server reload

> Mumble upstream also suggests […]
> https://wiki.mumble.info/wiki/Obtaining_a_Let%27s_Encrypt_Murmur_Certificate

Yes, I've seen this suggestion before, but didn't like it due to security 
concerns and opted for starting murmur as root instead (which then drops root 
privileges on its own).

> I'm fairly interested in trying to find a good solution to this, because
> this permission problem is a common gripe that I hear from users on the
> Mumble IRC channel, so if a better solution can be found maybe I could have
> upstream add it to the wiki or the website so others could take advantage of
> it.
> 
>-- Chris

~~ Nils

Bug#981202: kconfig: reduce Build-Depends

[Norbert Preining]

Hi Helmut,

> thus can be annotated . Please consider applying the attached

Thanks, added them to git.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#981229: dub: autopkgtest regression

[Matthias Klumpp]

Am Do., 28. Jan. 2021 um 00:33 Uhr schrieb Sebastian Ramacher
:
>
> Source: dub
> Version: 1.24.0-1
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
>
> | autopkgtest [03:11:10]: test run: [---
> | Package dub not found for registry at https://code.dlang.org/ (fallbacks 
> registry at https://codemirror.dlang.org/, registry at 
> https://dub.bytecraft.nl/, registry at https://code-mirror.dlang.io/): Failed 
> to download 
> https://code.dlang.org/api/packages/infos?packages=%5B%22dub%22%5D&include_dependencies=true&minimize=true
> | Getting a release version failed: No package dub was found matching the 
> dependency >=0.0.0
> | Retry with ~master...
> | Package dub not found for registry at https://code.dlang.org/ (fallbacks 
> registry at https://codemirror.dlang.org/, registry at 
> https://dub.bytecraft.nl/, registry at https://code-mirror.dlang.io/): Failed 
> to download 
> https://code.dlang.org/api/packages/infos?packages=%5B%22dub%22%5D&include_dependencies=true&minimize=true
> | No package dub was found matching the dependency ~master
> | autopkgtest [03:11:10]: test run: ---]
> | autopkgtest [03:11:11]: test run:  - - - - - - - - - - results - - - - - - 
> - - - -
> | run  FAIL non-zero exit status 2
>
> See
> https://ci.debian.net/data/autopkgtest/testing/amd64/d/dub/10040021/log.gz

Weird, I just tested this locally and it worked fine... Hopefully it's
not another GDC issue...

Regards,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#981005: linux-image-5.10.0-2-amd64: Bluetooth stopped working

[Pelle]

Relevant part of 5.10.0 dmesg:

   [20164.000149] ata1.00: configured for UDMA/100
   [20164.084110] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
   [20164.167454] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
   [20164.188123] usb 4-4: new full-speed USB device number 8 using ohci-pci
   [20164.382093] usb 4-4: New USB device found, idVendor=0930, idProduct=0220, 
bcdDevice= 0.01
   [20164.382103] usb 4-4: New USB device strings: Mfr=0, Product=0, 
SerialNumber=0
   [20164.390243] usb 4-4: firmware: direct-loading firmware 
ar3k/AthrBT_0x3101.dfu
   [20164.429414] PM: suspend exit
   [20164.455974] usb 4-4: firmware: direct-loading firmware 
ar3k/ramps_0x3101_40.dfu
   [20164.466587] usb 4-4: USB disconnect, device number 8
   [20165.036680] usb 4-4: new full-speed USB device number 9 using ohci-pci
   [20167.982738] wlp5s0: authenticate with 74:da:88:a9:c6:a6
   [20168.014007] wlp5s0: send auth to 74:da:88:a9:c6:a6 (try 1/3)
   [20168.017540] wlp5s0: authenticated
   [20168.028507] wlp5s0: associate with 74:da:88:a9:c6:a6 (try 1/3)
   [20168.037597] wlp5s0: RX AssocResp from 74:da:88:a9:c6:a6 (capab=0x411 
status=0 aid=2)
   [20168.037768] wlp5s0: associated
   [20168.054940] IPv6: ADDRCONF(NETDEV_CHANGE): wlp5s0: link becomes ready
   [20170.260959] usb 4-4: New USB device found, idVendor=0930, idProduct=0220, 
bcdDevice= 0.02
   [20170.260970] usb 4-4: New USB device strings: Mfr=0, Product=0, 
SerialNumber=0
   [20170.264703] Bluetooth: hci0: don't support firmware rome 0x3101
   [20171.105831] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
   [20171.117913] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
   [20171.802265] wlp5s0: AP 74:da:88:a9:c6:a6 changed bandwidth, new config is 
2417.000 MHz, width 1 (2417.000/0 MHz)

Bug#981232: unblock: perl/5.32.1-1

[Dominic Hargreaves]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

This is a pre-approval request.

As I wrote in 
https://lists.debian.org/debian-release/2021/01/msg00296.html

we'd like to get 5.32.1 into bullseye if possible. I should have probably
written all that in a bug instead so it can be tracked effectively.

As always, perl point releases are pretty conservative and we've
effectively imported them into s-p-u before.

All the reset of the context is in that post so I won't repeat it.
My preference is to upload 5.32.1 in whole as it's probably overall
less risky, and less maintenance work, but there is the option of
cherry-picking the targetted fixes too.

5.32.1 would need a binnmu of a few leaf packages
(libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl
libcommon-sense-perl) as usual.

perl 5.32.1 is currently in experimental - see


Cheers
Dominic

Bug#962596: ETA on a fixed being released in stable?

[Michael Simons (.NET)]

I see this was recently released to testing, is there an eta on when it will be 
available in stable, (e.g. buster)?

Thanks

Bug#981230: Unrecoverable split.

[Maurizio Cimaschi]

Package: corosync
Version: 3.0.1-2+deb10u1
Severity: wishlist

Dear Maintainer,
it seems that in version 3.0.1 of corosync there's a bug which causes
unrecoverable splits; it seems that it had been corrected in 3.0.3. Please
see Github issue #506.

 -> https://github.com/corosync/corosync/issues/506

The issue is unclear if the bug is in corosync or in Kronosnet, and it
seems to suggests to use at least library version 1.13. Besides in
buster-backports there's already version 1.16.

Please could the upgrade to newer version of corosync be considered ? It
should also require a dependency on the same version of
"libknet" in backports.

Thank you for your interest in the issue.

Regards.

Bug#981231: gdisk: autopkgtest regression

[Sebastian Ramacher]

Source: gdisk
Version: 1.0.6-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

| autopkgtest [03:26:17]: test command1:  - - - - - - - - - - results - - - - - 
- - - - -
| command1 FAIL stderr: Warning: Partition table header claims that 
the size of partition table
| autopkgtest [03:26:18]: test command1:  - - - - - - - - - - stderr - - - - - 
- - - - -
| Warning: Partition table header claims that the size of partition table
| entries is 0 bytes, but this program  supports only 128-byte entries.
| Adjusting accordingly, but partition table may be garbage.
| Warning: Partition table header claims that the size of partition table
| entries is 0 bytes, but this program  supports only 128-byte entries.
| Adjusting accordingly, but partition table may be garbage.
| Warning: Partition table header claims that the size of partition table
| entries is 0 bytes, but this program  supports only 128-byte entries.
| Adjusting accordingly, but partition table may be garbage.
| Warning: Partition table header claims that the size of partition table
| entries is 0 bytes, but this program  supports only 128-byte entries.
| Adjusting accordingly, but partition table may be garbage.
| Warning: Partition table header claims that the size of partition table
| entries is 0 bytes, but this program  supports only 128-byte entries.
| Adjusting accordingly, but partition table may be garbage.
| Warning: Partition table header claims that the size of partition table
| entries is 0 bytes, but this program  supports only 128-byte entries.
| Adjusting accordingly, but partition table may be garbage.
| Warning: Partition table header claims that the size of partition table
| entries is 0 bytes, but this program  supports only 128-byte entries.
| Adjusting accordingly, but partition table may be garbage.
| Warning: Partition table header claims that the size of partition table
| entries is 0 bytes, but this program  supports only 128-byte entries.
| Adjusting accordingly, but partition table may be garbage.
| Warning: Partition table header claims that the size of partition table
| entries is 0 bytes, but this program  supports only 128-byte entries.
| Adjusting accordingly, but partition table may be garbage.
| Warning: Partition table header claims that the size of partition table
| entries is 0 bytes, but this program  supports only 128-byte entries.
| Adjusting accordingly, but partition table may be garbage.
| Warning: Partition table header claims that the size of partition table
| entries is 0 bytes, but this program  supports only 128-byte entries.
| Adjusting accordingly, but partition table may be garbage.
| Warning: Partition table header claims that the size of partition table
| entries is 0 bytes, but this program  supports only 128-byte entries.
| Adjusting accordingly, but partition table may be garbage.
| autopkgtest [03:26:18]:  summary
| command1 FAIL stderr: Warning: Partition table header claims that 
the size of partition table

See
https://ci.debian.net/data/autopkgtest/testing/amd64/g/gdisk/10040076/log.gz

Cheers
-- 
Sebastian Ramacher

Bug#981229: dub: autopkgtest regression

[Sebastian Ramacher]

Source: dub
Version: 1.24.0-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

| autopkgtest [03:11:10]: test run: [---
| Package dub not found for registry at https://code.dlang.org/ (fallbacks 
registry at https://codemirror.dlang.org/, registry at 
https://dub.bytecraft.nl/, registry at https://code-mirror.dlang.io/): Failed 
to download 
https://code.dlang.org/api/packages/infos?packages=%5B%22dub%22%5D&include_dependencies=true&minimize=true
| Getting a release version failed: No package dub was found matching the 
dependency >=0.0.0
| Retry with ~master...
| Package dub not found for registry at https://code.dlang.org/ (fallbacks 
registry at https://codemirror.dlang.org/, registry at 
https://dub.bytecraft.nl/, registry at https://code-mirror.dlang.io/): Failed 
to download 
https://code.dlang.org/api/packages/infos?packages=%5B%22dub%22%5D&include_dependencies=true&minimize=true
| No package dub was found matching the dependency ~master
| autopkgtest [03:11:10]: test run: ---]
| autopkgtest [03:11:11]: test run:  - - - - - - - - - - results - - - - - - - 
- - -
| run  FAIL non-zero exit status 2

See
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dub/10040021/log.gz

Cheers
-- 
Sebastian Ramacher

Bug#981088: pacemaker: crm shell can't be executed due to a library error

[Markus Koschany]

Hello,

On Tue, 26 Jan 2021 08:24:19 +0100 Thorsten Rehm 
wrote:
> Package: pacemaker
> Version: 1.1.24-0+deb9u1
> Severity: normal
> 
> Dear Maintainer,
> 
> thank you for the effort and the update.
> Unfortunately there are still some problems with the updated version.
> 
> I've just updated the pacemaker package from 1.1.16-1+deb9u2 to
> 1.1.24-0+deb9u1. Afterwards parts of the Cluster Resource Manager
> (crm) can't be executed due to a library error. TL;DR:
> libpe_status.so.10 != libpe_status.so.16 and libpengine.so.10 !=
> libpengine.so.16

This can't be possible. You need to upgrade not only pacemaker but also all of
its dependencies. They are all part of the same source package. I have
tightened those dependencies explicitly. On my system crm_mon --version works
as expected. The command is part of the package pacemaker-cli-utils.

Regards,

Markus







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

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Kurt Roeckx]

On Thu, Jan 14, 2021 at 07:03:37PM +0100, Kurt Roeckx wrote:
> There are a whole bunch of other issues and pull requests related to
> this. I hope this is the end of the regressions in the X509 code.

So there is something else now:
https://github.com/openssl/openssl/issues/13931
https://github.com/openssl/openssl/pull/13982


Kurt

Bug#981228: khal: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13

[Sebastian Ramacher]

Source: khal
Version: 1:0.10.2-0.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
X-Debbugs-Cc: sramac...@debian.org

| === short test summary info 

| FAILED tests/cli_test.py::test_import_from_stdin - AssertionError: assert 
not...
| FAILED tests/khalendar_test.py::TestCollection::test_multi_uid_vdir - 
IndexEr...
| FAILED tests/khalendar_test.py::test_default_calendar - assert 0 == 1
| FAILED tests/khalendar_test.py::test_only_update_old_event - AssertionError: 
...
| FAILED tests/khalendar_test.py::test_birthdays - IndexError: list index out 
o...
| FAILED tests/khalendar_test.py::test_birthdays_no_year - assert 0 == 1
| = 6 failed, 284 passed, 1 xfailed, 1 xpassed in 3.62s 
==
| E: pybuild pybuild:353: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.9_khal/build; python3.9 -m pytest tests
| dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 
returned exit code 13
| make[1]: *** [debian/rules:32: override_dh_auto_test] Error 25

See
https://buildd.debian.org/status/fetch.php?pkg=khal&arch=all&ver=1%3A0.10.2-0.1&stamp=1611661499&raw=0

Cheers
-- 
Sebastian Ramacher

Bug#981227: python3-cpuset: missing dependency on python3-future

[David Bremner]

Package: python3-cpuset
Version: 1.6-4
Severity: serious
Justification: crashes on every invocation

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

If python3-future is not installed, then cset crashes on startup
at "from future import standard_library" with "ModuleNotFoundError:
No module named 'future'".

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

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

Versions of packages python3-cpuset depends on:
ii  python3  3.9.1-1

python3-cpuset recommends no packages.

python3-cpuset suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmAR9DIACgkQA0U5G1Wq
FSFIDhAAl8PgOMVDo0+i1/hBLALM2VPULRpwvXXekR33cy9Lz9x13Bc7aGQl+YHp
t1qM0DdDb4p4a8Uvm6bhRVCYhd/9uELiWKdMiAcjxgx9/CiR2P1SPqONk2Nw1NZz
RXLYneRAyTvOAI3xMXQy28KcGbsJPLOj2UD6XukaCbnF1skbS0cJe20/2zs8a+5E
wMi6DQomWF20U/mLpnaqJVL1hoOA/OOHIAjmQTf/MUUdFwInlMcyKlGyHkQRNrTv
k/9QXqvgTXScbh09zEkfBzjP2zE/nskDhwpvgq1tDB+0NJ77S7pdV89eqMZ0h1u1
uISDi1plkc5VNiAHK8p2qj5KUSa8kofh6KdYCDx3KxipXsxTFMXFiuRuitgWdQx4
IAzhQDMYtJ+1/SVEmcRTCC1R9niDsjPhkFqlyODEcDHBL3zSi1srhjbNfmgxYOm9
KdMB3CJig07FOwvxfCz3BjRVZVXuGrjDGs+TAuHfwVLVY2sdaiQ0TwJXnOY+/7kd
Wee+5GG18HCLJsFap4cnidPS43LxeHjNKoTcj6FhViXU8t12St17nRnNSEfSjcF5
5FI44YZk+J44iBWcqgHpPFh1bRf4Ay1jzVOmj9yywSRYyW//kzYOpdr79naY4DIZ
ukOUHXTvTGy0DweRHc7/VuUvMjnH2Udn+A/6IZ+2ZUsgEfWdmD0=
=GXNS
-END PGP SIGNATURE-

Bug#980809: [R-pkg-team] Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x

[Dirk Eddelbuettel]

Graham,

Any update here?  It still points at Matrix aka rmatrix aka r-cran-matrix,
and I still think wrongly.

Best,  Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#981226: redis: New systemd integration breaks replicaof handling

[Guillem Jover]

Source: redis
Source-Version: 5:6.0.9-3
Severity: important
Tags: upstream patch
Forwarded: https://github.com/redis/redis/pull/8409

[ This might be worth being serious, but I'm not sure this falls under
  uncommon usage or similar, or not, so please bump if you agree. :) ]

Hi!

While preparing to switch to bullseye, we noticed that the new systemd
integration breaks with replicaof handling.

I've submitted this upstream, but it would be nice to fix in Debian
even if upstream does not apply this in time for the freeze.

The github PR and the attached patch against the version in Debian,
describe the problem in further detail.

Thanks,
Guillem
From f9505104123664c45b762b8a7bb15406c205c01d Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 19 Jan 2021 00:34:59 +0100
Subject: [PATCH] Send the readiness notification when we are ready to accept
 connections

On a replica we do accept connections, even though commands accessing
the database will operate in read-only mode. But the server is still
already operational and processing commands.

Not sending the readiness notification means that on a HA setup where
the nodes all start as replicas (with replicaof in the config) with
a replica that cannot connect to the master server and which might not
come back in a predictable amount of time or at all, the service
supervisor will end up timing out the service and terminating it, with
no option to promote it to be the main instance. This seems counter to
what the readiness notification is supposed to be signaling.

Instead send the readiness notification when we start accepting
commands, and then send the various server status changes as that.

Fixes: commit 641c64ada10404356fc76c0b56a69b32c76f253c
Fixes: commit dfb598cf3304818e608ceb6b5d9529a293345c4a
---
 src/replication.c |6 ++
 src/server.c  |4 ++--
 2 files changed, 4 insertions(+), 6 deletions(-)

--- a/src/replication.c
+++ b/src/replication.c
@@ -1832,8 +1832,7 @@ void readSyncBulkPayload(connection *con
 serverLog(LL_NOTICE, "MASTER <-> REPLICA sync: Finished with success");
 
 if (server.supervised_mode == SUPERVISED_SYSTEMD) {
-redisCommunicateSystemd("STATUS=MASTER <-> REPLICA sync: Finished with success. Ready to accept connections.\n");
-redisCommunicateSystemd("READY=1\n");
+redisCommunicateSystemd("STATUS=MASTER <-> REPLICA sync: Finished with success. Ready to accept connections in read-write mode.\n");
 }
 
 /* Restart the AOF subsystem now that we finished the sync. This
@@ -2340,8 +2339,7 @@ void syncWithMaster(connection *conn) {
 if (psync_result == PSYNC_CONTINUE) {
 serverLog(LL_NOTICE, "MASTER <-> REPLICA sync: Master accepted a Partial Resynchronization.");
 if (server.supervised_mode == SUPERVISED_SYSTEMD) {
-redisCommunicateSystemd("STATUS=MASTER <-> REPLICA sync: Partial Resynchronization accepted. Ready to accept connections.\n");
-redisCommunicateSystemd("READY=1\n");
+redisCommunicateSystemd("STATUS=MASTER <-> REPLICA sync: Partial Resynchronization accepted. Ready to accept connections in read-write mode.\n");
 }
 return;
 }
--- a/src/server.c
+++ b/src/server.c
@@ -5324,10 +5324,10 @@ int main(int argc, char **argv) {
 if (server.supervised_mode == SUPERVISED_SYSTEMD) {
 if (!server.masterhost) {
 redisCommunicateSystemd("STATUS=Ready to accept connections\n");
-redisCommunicateSystemd("READY=1\n");
 } else {
-redisCommunicateSystemd("STATUS=Waiting for MASTER <-> REPLICA sync\n");
+redisCommunicateSystemd("STATUS=Ready to accept connections in read-only mode. Waiting for MASTER <-> REPLICA sync\n");
 }
+redisCommunicateSystemd("READY=1\n");
 }
 } else {
 InitServerLast();

Bug#970386: Update?

[Noah Meyerhans]

On Wed, Jan 27, 2021 at 08:38:39AM -0500, micah wrote:
> It looks like you were going to get this fixed in Buster 10.7 release,
> but I didn't see it come through. Did it get refused by the release
> managers, or is there something else holding it up?

I was hoping to also fix
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970692 for stable, but
the change has proven non-trivial to backport.  So things got hung up
there.

I'll see about fixing 970386.  There's an upcoming buster point release,
but odds of getting it prepared, tested, approved, and uploaded in time
are pretty slim.

noah

Bug#598280: Newsletter Debtcatcher.com - What's new for sale?

[Eric]

[[HEADLINE]]

[[PERMALINK_FULL_LINK]]







TITLE OF YOUR EMAIL

The content of your email goes here.

You can drag and drop blocks of text, images or other content elements to add 
them to your message. Customize the font and the colors. Add links to track 
clicks.







This is a second paragraph you can customize as your please.

If you have stored contact properties with your contacts, you can include 
personalization variables such as first name, last name in your message content.



[[DELIVERY_INFO]]
[[POSTAL_ADDRESS]]

Bug#980847: pre-approval: qutebrowser/2.0.0-1

[Axel Beckert]

Hi Sebastian,

Sebastian Ramacher wrote:
> … and what about the changes to the packaging? This would be easier to
> judge if something like a release candidate would be in testing already.
> The size of the diff doesn't look like something we can sensibly review.

Sure. You'll get that once 2.0.0 is released. Current ETA: Either
tonoght or tomorrow.

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

Bug#980847: pre-approval: qutebrowser/2.0.0-1

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-01-23 02:26:34 +0100, Axel Beckert wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please pre-approve the package qutebrowser/2.0.0-1.
> 
> [ Reason ]
> A major upstream release (2.0.0) of qutebrowser is going to be released
> soon (currently aimed at early next week, i.e. around 26th of January
> 2021).
> 
> While it certainly counts as a "large change", it is a leaf package and
> risk is believed to be small (see below).
> 
> [ Impact ]
> Users on Debian Stable will continue to use the previous release series
> (1.14.x) for the next couple of years. Since there are some changes
> around the names of commands/settings, this introduces an undesirable
> gap between users on Debian Stable and users on other distributions
> (many of qutebrowser's users are on rolling-release distributions).
> 
> This gap would make it more difficult both for upstream and the affected
> users to give/take support, share configuration files, etc.
> 
> [ Tests ]
> qutebrowser has a big automated testsuite with over 9000 (sic) tests.
> Note that many of those result from parametrization (running the same
> test with different sets of inputs), but still this reduces the
> potential for regressions. Upstream also uses other measures to reduce
> defects where appropriate, such as type annotations.
> 
> A part of its users is using it directly from its git repository, so
> that any remaining issues with changes usually get reported and fixed
> quickly.
> 
> [ Risks ] qutebrowser is a leaf package, so no coordination with other
> package(r)s is required. It is also a desktop application - while those
> certainly shouldn't be held to lower standards, the impact (or need for
> additional "preparation time" for users) might be smaller compared to
> e.g. a server application.
> 
> There are many changes upstream:
> 
>   $ git diff --stat v1.14.1...master
>   540 files changed, 12654 insertions(+), 10182 deletions(-)
> 
> Excluding tests/scripts/...:
> 
>   $ git diff --stat v1.14.1...master -- qutebrowser/
>   199 files changed, 5189 insertions(+), 5794 deletions(-)

… and what about the changes to the packaging? This would be easier to
judge if something like a release candidate would be in testing already.
The size of the diff doesn't look like something we can sensibly review.

Cheers

> 
> However, the bulk of those changes are a result of relatively boring
> changes upstream, such as dropping support for old Python/Qt versions.
> 
> The upstream changelog is probably a better indication:
> https://github.com/qutebrowser/qutebrowser/blob/master/doc/changelog.asciidoc#v200-unreleased
> 
> [ Checklist ]
> (N/A because this is a pre-approval)
> 
> [ Other info ]
> The upstream maintainer is on Cc for this bug and is willing to work
> with the package maintainers for this, where needed. If (despite all
> measures) regressions would be introduced, a potential patch release
> would happen as soon as possible. Patch releases are done from a
> dedicated v2.0.x maintenance branch, keeping care to keep changes as
> small as possible and without any non-bugfix changes.
> 
> The release also introduces a new optional dependency on the Python
> "adblock" module for better ad blocking. It is currently not packaged
> for Debian and doing so is outside of the scope of this request. If the
> dependency is unavailable, qutebrowser will fall back on the same
> hosts-based adblocking it used before this release.
> 
> So please pre-approve qutebrowser/2.0.0-1.
> 
> For Debian's qutebrowser package, the qutebrowser package maintainers
> and upstream.
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
> (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), 
> (1, 'buildd-experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> LSM: AppArmor: enabled
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#981141: transition: gdk-pixbuf binNMUs to drop transitional package

[Sebastian Ramacher]

Control: forwarded -1 
https://release.debian.org/transitions/html/libgdk-pixbuf-2.0-0.html

On 2021-01-26 22:18:33 +, Simon McVittie wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> The library package libgdk-pixbuf2.0-0 was recently (in early December)
> split into libgdk-pixbuf-2.0-0 and the deprecated libgdk-pixbuf-xlib-2.0-0,
> with a transitional libgdk-pixbuf2.0-0 that depends on both. Newly built
> packages will depend on libgdk-pixbuf-2.0-0 and/or libgdk-pixbuf-xlib-2.0-0,
> but binary packages that were built before December still depend on
> what is now a transitional package.
> 
> This is a "soft" transition and does not need a flag-day or coordination:
> if bullseye releases with this transition incomplete, the only practical
> impact is that the deprecated libgdk-pixbuf-xlib-2.0-0 stays installed
> on more systems.
> 
> If you're still willing to trigger binNMUs at this stage of the freeze,
> reverse dependencies of libgdk-pixbuf2.0-0 could be rebuilt to drop the
> dependency on the transitional package. Most of them will lose their
> unnecessary indirect dependency on the deprecated library as a result.
> 
> A few packages that were most recently built shortly after the transition
> might show as both "good" and "bad", because they depend on
> "libgdk-pixbuf-2.0-0 | libgdk-pixbuf2.0-0". This is harmless and I don't
> mind whether they get rebuilt or not.
> 
> Ben file:
> 
> title = "gdk-pixbuf";
> is_affected = .depends ~ "libgdk-pixbuf2.0-0" | .depends ~ 
> "libgdk-pixbuf-2.0-0" | .depends ~ "libgdk-pixbuf-xlib-2.0-0";
> is_good = .depends ~ "libgdk-pixbuf-2.0-0" | .depends ~ 
> "libgdk-pixbuf-xlib-2.0-0";
> is_bad = .depends ~ "libgdk-pixbuf2.0-0";

The tracker is now available at
https://release.debian.org/transitions/html/libgdk-pixbuf-2.0-0.html.
Unless this transition comes close to completion due to other uploads
and rebuilds during the freeze, I don't plan to schedule binNMUs for
bullseye.

Cheers

> 
> Thanks,
> smcv
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#981225: clementine: Clicking on seekbar is off by one pixel

[Daniel Perelman]

Package: clementine
Version: 1.4.0~rc1+git347-gfc4cb6fc7+dfsg-1+b1
Severity: normal

Dear Maintainer,

When hovering over the progress bar in the bottom-right, a tooltip shows
what time will be seeked to. When actually clicking, the playback time
is actually set to slightly earlier, apparently exactly the time shown
by the tooltip when moving the mouse cursor one pixel to the left.

Most of the time, this wouldn't even be noticeable, but when playing
hour-long podcast episodes, that one pixel comes out to ~25 seconds.
I end up just using keyboard shortcuts for the fine-tuning.

I tried disabling the moodbar, but it made no difference.

Possibly related, I am on a system with a 1.5x HiDPI monitor; I do not
have window scaling enabled (as the options are 1x and 2x) but I do have
custom DPI scaling (under xfce's settings Appearance->Fonts) set to 144.


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

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages clementine depends on:
ii  gstreamer1.0-plugins-base   1.18.1-dmo1
ii  gstreamer1.0-plugins-good   1.18.1-dmo1
ii  gstreamer1.0-plugins-ugly   1:1.18.1-dmo1
ii  libasound2  1.2.3.2-1
ii  libc6   2.30-4
ii  libcdio19   1:2.1.0-dmo3
ii  libchromaprint1 1:1.5.0-dmo1
ii  libcrypto++88.4.0-1
ii  libfftw3-double33.3.8-2
ii  libgcc-s1   10-20200502-1
ii  libglib2.0-02.66.2-1
ii  libgpod40.8.3-15
ii  libgstreamer-plugins-base1.0-0  1.18.1-dmo1
ii  libgstreamer1.0-0   1.18.1-1
ii  liblastfm5-11.0.9-1.1
ii  libmtp9 1.1.17-3
ii  libmygpo-qt5-1  1.1.0-4
ii  libprotobuf23   3.12.3-2+b1
ii  libpulse0   13.0-5
ii  libqt5concurrent5   5.15.1+dfsg-2
ii  libqt5core5a5.15.1+dfsg-2
ii  libqt5dbus5 5.15.1+dfsg-2
ii  libqt5gui5  5.15.1+dfsg-2
ii  libqt5network5  5.15.1+dfsg-2
ii  libqt5sql5  5.15.1+dfsg-2
ii  libqt5widgets5  5.15.1+dfsg-2
ii  libqt5x11extras55.15.1-2
ii  libsqlite3-03.33.0-1
ii  libstdc++6  10-20200502-1
ii  libtag1v5   1.11.1+dfsg.1-3
ii  libx11-62:1.6.12-1
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages clementine recommends:
ii  gstreamer1.0-pulseaudio  1.18.1-dmo1

Versions of packages clementine suggests:
ii  gstreamer1.0-plugins-bad  1:1.18.1-dmo2

-- no debconf information

Bug#981171: [PATCH 01/13] Do not document mktemp (3)

[Michael Kerrisk (man-pages)]

Salut Bastien,

On 1/27/21 4:48 PM, roucaries.bast...@gmail.com wrote:
> From: Bastien Roucariès 
> 
> Do not use for documentation purposes the unsecure mktemp function

This message doesn't correspond to the change below (which removes
a reference to "tempnam" and adds a reference to "mktemp".

But also, I don't think it makes systems more secure to
remove the info that tempnam is influence by TMPDIR.

And, this patch is surely not correct. Yes, TMPDIR influences
tmpfile(3). But how does TMPDIR influence mktemp(3), mkstemp(3),
and mkdtemp(3), which base the temporary filename on a path
supplied by the caller?

Finally, a request for patches: the format of the 
subject line should rather be:

[PATCH ...] environ.7: Do not document...

Thanks,

Michael

> Signed-off-by: Bastien Roucariès 
> ---
>  man7/environ.7 | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/man7/environ.7 b/man7/environ.7
> index 182d823d2..d889310d6 100644
> --- a/man7/environ.7
> +++ b/man7/environ.7
> @@ -191,7 +191,10 @@ and
>  .IP *
>  .B TMPDIR
>  influences the path prefix of names created by
> -.BR tempnam (3)
> +.BR mktemp (1),
> +.BR mkstemp (3),
> +.BR mkdtemp (3),
> +.BR tmpfile (3),
>  and other routines, and the temporary directory used by
>  .BR sort (1)
>  and other programs.
> @@ -289,6 +292,7 @@ should consider renaming their option to
>  .BR csh (1),
>  .BR env (1),
>  .BR login (1),
> +.BR mktemp (1),
>  .BR printenv (1),
>  .BR sh (1),
>  .BR tcsh (1),
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Bug#981146: loggedfs: fails: fusermount: unknown option 'nonempty'

[Paul Wise]

On Wed, 2021-01-27 at 20:08 +0100, Stephen Kitt wrote:

> No worries, they’re still bugs affecting loggedfs! I’ll downgrade
> this one and fix the other. (I’ll also suggest a fix for the nonempty
> handling in fuse3...)

I had a thought that might work for loggedfs:

Hardcode which fusermount arguments to use and the fuse or fuse3
dependency based on which library loggedfs linked against at build
time. libfuse2 is never going to switch to fuse3 and vice versa and the
dependencies should ensure that the corresponding fusermount is
installed (needed since libfuse doesn't have the dep itself). This
should continue to work if the two libfuses get a dependency.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#947771: unbound: cannot restart daemon under sysvinit-core when apparmor is enforced

[Gedalya]

Hello,

I find the following is enough:

--- unbound.init    2020-12-24 00:34:24.0 +
+++ /etc/init.d/unbound    2021-01-27 18:15:25.663526469 +
@@ -42,7 +42,7 @@
 
 stop)
 log_daemon_msg "Stopping $DESC" "$NAME"
-    if start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE --name 
$NAME --retry 5; then
+    if start-stop-daemon --stop --quiet --oknodo --remove-pidfile 
--pidfile $PIDFILE --name $NAME --retry 5; then
 $HELPER resolvconf_stop
 $HELPER chroot_teardown
 log_end_msg 0
@@ -53,7 +53,7 @@
 
 restart|force-reload)
 log_daemon_msg "Restarting $DESC" "$NAME"
-    start-stop-daemon --stop --quiet --pidfile $PIDFILE --name $NAME 
--retry 5
+    start-stop-daemon --stop --quiet --remove-pidfile --pidfile $PIDFILE 
--name $NAME --retry 5
 $HELPER resolvconf_stop
 if start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE 
--name $NAME --startas $DAEMON -- $DAEMON_OPTS; then
 $HELPER chroot_setup

Bug#981096: file 5.35-4+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 981096 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: file
Version: 5.35-4+deb10u2

Explanation: increase name recursion depth to 50 by default

Bug#981047: tang 7-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 981047 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: tang
Version: 7-1+deb10u1

Explanation: avoid race condition between keygen and update

Bug#980919: m2crypto 0.31.0-4+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 980919 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: m2crypto
Version: 0.31.0-4+deb10u1

Explanation: fix compatibility with OpenSSL 1.1.1i and newer

Bug#980835: fcitx 4.2.9.6-5+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 980835 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: fcitx
Version: 4.2.9.6-5+deb10u1

Explanation: fix input method support in Flatpaks

Bug#981224: ruby-uglifier: FTBFS: tests fail: uglifier_spec.rb:383, uglifier_spec.rb:751

[Andreas Beckmann]

Source: ruby-uglifier
Version: 4.2.0+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

ruby-uglifier/experimental recently started to FTBFS, probably after some
build-dependency was updated:

[...]
Failures:

  1) Uglifier keeps unused function arguments when keep_fargs option is set
 Failure/Error: expect(Uglifier.compile(code, options.call(false))).not_to 
include("c)")
   expected "function plus(a,b,c){return a+b}plus(1,2);" not to include "c)"
 # /build/ruby-uglifier-4.2.0+dfsg/spec/uglifier_spec.rb:399:in `block (2 
levels) in '

  2) Uglifier context_source_lines contains harmony error message and follows 
error_context_lines option
 Failure/Error:
   expect { Uglifier.compile(code, :harmony => false, :error_context_lines 
=> 4) }
 .to raise_error(Uglifier::Error, %r{
   harmony\smode [^\n]+ Uglifier\.new  # harmony error mesage
   .+ --\n [^\n]+ //_1\n   # 1 should be the first line
   .+ => [^\n]+ bar \e\[\d+m \(\)  # should point to () at line 3
   .+ //_7\n ==\z  # 7 should be the last line
 }xm)

   expected Uglifier::Error with message matching /
 harmony\smode [^\n]+ Uglifier\.new  # harmony error mesage
 .+ --\n [^\n]+ \/\/_...() at line 3
 .+ \/\/_7\n ==\z  # 7 should be the last 
line
   /mx, got # with backtrace:
 # /build/ruby-uglifier-4.2.0+dfsg/lib/uglifier.rb:302:in `parse_result'
 # /build/ruby-uglifier-4.2.0+dfsg/lib/uglifier.rb:232:in `run_uglifyjs'
 # /build/ruby-uglifier-4.2.0+dfsg/lib/uglifier.rb:170:in `compile'
 # /build/ruby-uglifier-4.2.0+dfsg/lib/uglifier.rb:137:in `compile'
 # /build/ruby-uglifier-4.2.0+dfsg/spec/uglifier_spec.rb:752:in `block 
(4 levels) in '
 # /build/ruby-uglifier-4.2.0+dfsg/spec/uglifier_spec.rb:752:in `block 
(3 levels) in '
 # /build/ruby-uglifier-4.2.0+dfsg/spec/uglifier_spec.rb:752:in `block (3 
levels) in '

Finished in 34.44 seconds (files took 0.08862 seconds to load)
100 examples, 2 failures, 7 pending

Failed examples:

rspec /build/ruby-uglifier-4.2.0+dfsg/spec/uglifier_spec.rb:383 # Uglifier 
keeps unused function arguments when keep_fargs option is set
rspec /build/ruby-uglifier-4.2.0+dfsg/spec/uglifier_spec.rb:751 # Uglifier 
context_source_lines contains harmony error message and follows 
error_context_lines option

/usr/bin/ruby2.7 
-I/usr/share/rubygems-integration/all/gems/rspec-support-3.9.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib
 /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/exe/rspec --pattern 
./spec/\*\*/\*_spec.rb --format documentation failed
ERROR: Test "ruby2.7" failed. Exiting.
dh_auto_install: error: dh_ruby --install 
/build/ruby-uglifier-4.2.0\+dfsg/debian/ruby-uglifier returned exit code 1


Andreas


ruby-uglifier_4.2.0+dfsg-1.log.gz
Description: application/gzip

Bug#981219: schroot overwrites cpuset

[Roger Leigh]

On 27 Jan 2021, at 20:39, David Bremner  wrote:
> 
> Package: schroot
> Version: 1.6.10-11+b1
> Severity: normal
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> As you can see with session below, schroot throws away the processor
> affinities present in the parent process.  This breaks a common
> strategy (used e.g. by slurm) for sharing multi-processor machines.

We don’t actively do anything within schroot to change this, so it must be a 
side-effect of some action it takes during session setup.

The main actions under our control are basic fork/chroot/setuid/setgid/exec and 
I doubt these are responsible.

The PAM auth and session handling is I think the most likely culprit, and this 
is not under our direct control.  Is there a particular PAM module which can 
change these cpusets?  If so, can you edit the schroot PAM configuration and 
see if it can be disabled this way?  Possibly in @common-session?


Thanks,
Roger

Bug#981176: RFP: doas -- minimal replacement for sudo

[Scupake]

On Wed, Jan 27, 2021 at 10:28:25PM +0100, Bernd Zeimetz wrote:
> git push origin master:master 
> or git push --all if you have more branches to push.

Still having the same issue, here's the entire error:

---
Enumerating objects: 56, done.
Counting objects: 100% (56/56), done.
Delta compression using up to 2 threads
Compressing objects: 100% (48/48), done.
Writing objects: 100% (56/56), 47.66 KiB | 3.97 MiB/s, done.
Total 56 (delta 5), reused 0 (delta 0), pack-reused 0
remote: GitLab: 
remote: A default branch (e.g. master) does not yet exist for debian/doas
remote: Ask a project Owner or Maintainer to create a default branch:
remote: 
remote:   https://salsa.debian.org/debian/doas/-/project_members
remote: 
To https://salsa.debian.org/debian/doas.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://salsa.debian.org/debian/doas.git'
---

Maybe I don't have permission to create a default branch?

---
Scupake :D
4737A2C0A769B53AE82F77922BD8BE5CDD5ADA16


signature.asc
Description: PGP signature

Bug#980964: Bug#980965: Bug#980964: pdns: flaky autopkgtest on s390x

[Chris Hofstaedtler]

* Paul Gevers  [210125 22:18]:
> I don't have easy control over on which worker a job gets run. Unless I
> start it manually on the worker, but then there are no logs.
> 
> I went ahead and did that anyways, find the data attached.

Thanks for doing that.

The log repeats these messages over and over:

Jan 25 20:05:03 ci-025-b5185c19 systemd[1]: pdns-recursor.service: Main process 
exited, code=exited, status=226/NAMESPACE
Jan 25 20:05:03 ci-025-b5185c19 systemd[1]: pdns-recursor.service: Failed with 
result 'exit-code'.

TTBOMK this means some namespacing and/or protection feature
implemented by systemd is broken on this worker. I don't know if
this is a kernel, systemd, libc or some other problem, but it's
not a pdns(-recursor) problem.

Maybe it's best to start diffing the system configuration of the
ppc64el workers, given the other one works?

Chris

Bug#979696: Bug in Package nvidia-driver

[Andreas Beckmann]

Control: tag -1 moreinfo

On 1/10/21 10:02 AM, 2704...@gmx.de wrote:
> Package: nvidia-driver
> Version: debian testing
> 
> Debian testing bullseye
> 
> After the last kernel upgrade, the dkms modules was not build.
> computer starts with blackscreen. no light-display manager.
> 
> Same Bug like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972856

Do you have version numbers? dkms logs?
Have you tried the latest version?


Andreas

Bug#981223: goldencheetah: Crashes during initial data import

[Michael Below]

Package: goldencheetah
Version: 1:3.5-1
Severity: normal

Dear Maintainer,

yesterday I used Golden Cheetah on this system for the first time.
After adding a user, I tried to import some workouts from a Garmin Edge
530. I was able to select one or more workouts and start the import,
but Golden Cheetah crashed repeatedly at the point just before it would
complete the import and switch to the main window.

I had started the program from Gnome. On the fifth try I started Golden
Cheetah from the command line, to see possible crash output, but then
it worked. I subsequently imported all data files I had tried before.

To my impression, there may be something wrong with the initial
database creation or such.

Happy to provide any further info.

Thanks for your work!

Cheers
Michael

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

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

Versions of packages goldencheetah depends on:
ii  libc6  2.31-9
ii  libgcc-s1  10.2.1-6
ii  libical3   3.0.9-1
ii  libkmlbase11.3.0-9
ii  libkmldom1 1.3.0-9
ii  libqt5bluetooth5   5.15.2-2
ii  libqt5charts5  5.15.2-2
ii  libqt5concurrent5  5.15.2+dfsg-2
ii  libqt5core5a   5.15.2+dfsg-2
ii  libqt5gui5 5.15.2+dfsg-2
ii  libqt5multimedia5  5.15.2-2
ii  libqt5network5 5.15.2+dfsg-2
ii  libqt5opengl5  5.15.2+dfsg-2
ii  libqt5serialport5  5.15.2-2
ii  libqt5sql5 5.15.2+dfsg-2
ii  libqt5sql5-sqlite  5.15.2+dfsg-2
ii  libqt5svg5 5.15.2-2
ii  libqt5webkit5  5.212.0~alpha4-11
ii  libqt5widgets5 5.15.2+dfsg-2
ii  libqt5xml5 5.15.2+dfsg-2
ii  libstdc++6 10.2.1-6
ii  libusb-0.1-4   2:0.1.12-32
ii  libvlc53.0.12-1
ii  zlib1g 1:1.2.11.dfsg-2

goldencheetah recommends no packages.

goldencheetah suggests no packages.

-- no debconf information

Bug#979551: [Pkg-javascript-devel] Bug#979551: node-babel7: update-alternatives set up fails

[Xavier]

Le 27/01/2021 à 22:20, Xavier a écrit :
> Control: tags -1 + confirmed
> 
> Hi,
> 
> this can be fixed using `--slave` parameter of update-alternatives
> instead of a main link for manpages

However it seems not possible to decrease an alternative from "master"
to "slave". For now I propose to remove alternatives for manpages, later
I'll use "--slave" (with node-babel8 release)

Bug#974839: [Help] Test failures in q2-feature-classifier

[Étienne Mollier]

Hi Andreas,

Andreas Tille, on 2021-01-27 21:42:41 +0100:
> I think, if the test might pass without this option we could go with
> this or even remove those tests temporarily and discuss the issue with
> upstream without pressure of an open RC bug (which is unrelated).

I would vote against skipping this test, as it shows the
underlying code is not functional.  I reinforced a bit my patch,
given that the initial implementation was rather fragile and
pushed another iteration.  I'm fine about `dch -r` the package
and upload tomorrow to close presently open bugs, if there are
no objections; I see I have DM permissions on this one.

There is an ever growing breadcrumb of patches not forwarded
upstream behind me, I think I'll have to spend some time
forwarding them appropriately, at the end of the week hopefully.

Have a good evening,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/0, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#981222: update-alternatives: please provide a way to change a master alternative into a slave one

[Xavier Guimard]

Package: dpkg
Version: 1.20.7.1
Severity: normal

Hi,

I made an error using master alternatives to install some manpages, but
I can't change this because update-alternatives refuse to replace a
master alternative into a slave one during upgrade. Could you provide a
way to do this in debian/alternatives file ?

Cheers,
Xavier

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-9
ii  liblzma5 5.2.5-1.0
ii  libselinux1  3.1-2+b2
ii  tar  1.32+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.1.18
pn  debsig-verify  

-- no debconf information

Bug#979450: booth: autopkgtest fails on ci-worker-ppc64el-01 (but apparently not on other ppc64el workers)

[Valentin Vidic]

On Wed, Jan 27, 2021 at 10:37:56PM +0100, Paul Gevers wrote:
> debian@ci-worker-ppc64el-01:~$ sudo cat /etc/lxc/default.conf
> # MANAGED WITH CHEF; DON'T CHANGE BY HAND
> lxc.net.0.type = veth
> lxc.net.0.link = virbr0
> lxc.net.0.flags = up
> lxc.apparmor.profile = generated
> lxc.apparmor.allow_nesting = 1

I think this is only for new containers and for the existing ones these
options would be in /var/lib/lxc//config. Also apparmor
should log mount failures in kernel log or somewhere...

-- 
Valentin

Bug#980803: Solved

[Limon Kiwi]

Well, I configured a kit to build projects and the examples appeared. So, I
don't know if this is the way it should work, but I solved it. Thanks for
your response!

Bug#979450: booth: autopkgtest fails on ci-worker-ppc64el-01 (but apparently not on other ppc64el workers)

[Paul Gevers]

Hi,

On 27-01-2021 22:18, Valentin Vidic wrote:
> On Wed, Jan 27, 2021 at 09:56:34PM +0100, Paul Gevers wrote:
>> Please see: https://salsa.debian.org/-/snippets/520 Do you seen anything
>> weird?
> 
> I don't think anything would show up in the mounts on the host itself.
> The problem is probably with some of the hardenings enabled in the
> corosync service, for example:
> 
> https://salsa.debian.org/ha-team/corosync/-/blob/debian/master/debian/patches/Enable-PrivateTmp-in-the-systemd-service-files.patch
> 
> I seem to remember having this problem on my machine too were apparmor
> was blocking the mount, and the solution was to add these to the config
> of all containers:
> 
> # Apparmor enable
> lxc.apparmor.profile = generated
> lxc.apparmor.allow_nesting = 1
> 
> More details in /usr/share/doc/lxc/NEWS.Debian.gz
> 

debian@ci-worker-ppc64el-01:~$ sudo cat /etc/lxc/default.conf
# MANAGED WITH CHEF; DON'T CHANGE BY HAND
lxc.net.0.type = veth
lxc.net.0.link = virbr0
lxc.net.0.flags = up
lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#981221: btrbk: New upstream release

[Vincent Blut]

Package: btrbk
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

The freeze is coming fast and Bullseye will potentially be released with a
pretty old version of btrbk. Can we hope to have a newer release?

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/VQBlxWoTJPh4vI5ipzudlpxp4AFAmAR26EACgkQipzudlpx
p4AKrw/7BfZ24fQmrXSgadfE0y8q9QxFO/eb5JF7UThSAn1Ry3FVnjpbLQ6j9HQ5
cCm4EsV5/AEsXtOnZZ+g8Cm0b3hItwdVhh3lGHDYjDtvu2bCliFXlcrXGsOAvQuF
CK8igE+mn+fMq0C/28eqdkG7XfvsRq8iCznVyklLmTA10e1XitP9wnLVl30glNfj
7G9/UM1rv/5vn0Xfoipxc/gscH4HYrN4XEPv2mSL/qTpxYDAo2aSiPgpq7gMjnKY
3rbV/WCwFH9c+abzLHV2KevBkX1IdKeO0OPCCcgzGo8AvLKoAnPLm+FP2QfXX6Lv
KbE7U0xkHI1CxaxETUOWtCsB6XAo6/8Q6n3JiedMj8OR63vn20Hw9N7uzO8zqrlt
29pQ3QyUt22SO9UK2MzHsE7i8RvyZtLid/VSbpbbskxCpvlPI5sfsBdPSx8t6NEo
hpRMI4lULanZ05erv//amcS1lsUk0Rsd3wkwroHkw3MfswZX8MDE0ZcK0PnZYjcv
n55wgLbyTwbRayy2p/B3BTRqb0khmSvzIxYiu4Dlb+rKGIo+QV/wF26ONWksxyMe
pnkNPbj8niFqzd9s5ttIoITR9vCwzYcI2T3OQ3aPIC151Olj98Qo8z20dA3ltHpb
uOUzNaS1NVmWnuVVnDvNQtSSI/rUP+atsthzPMpC+jWf0xhWmyo=
=1UXC
-END PGP SIGNATURE-

Bug#981176: RFP: doas -- minimal replacement for sudo

[Bernd Zeimetz]

On 1/27/21 10:27 PM, Bernd Zeimetz wrote:
> 
> 
> On 1/27/21 9:58 PM, Scupake wrote:
>> Hello,
>>
>> I am getting an error when trying to git push, it's teling me that:
>> "A default branch (e.g. master) does not yet exist for debian/doas
>> Ask a project Owner or Maintainer to create a default branch"
> 
> git push origin master:master


or git push --all if you have more branches to push.



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#981176: RFP: doas -- minimal replacement for sudo

[Bernd Zeimetz]

On 1/27/21 9:58 PM, Scupake wrote:
> Hello,
> 
> I am getting an error when trying to git push, it's teling me that:
> "A default branch (e.g. master) does not yet exist for debian/doas
> Ask a project Owner or Maintainer to create a default branch"

git push origin master:master


> 
> ---
> Scupake :D
> 4737A2C0A769B53AE82F77922BD8BE5CDD5ADA16
> 

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#980261: RFS: jgmenu/4.3.0-1 [RFP] -- Simple X11 menu

[Johan Malm]

GPL2 applies.

> On 26 Jan 2021, at 22:27, Boyuan Yang  wrote:
> 
> X-Debbugs-CC: mat...@linuxmint.pl jgm...@gmail.com
> 
> 
>> On Sat, 16 Jan 2021 21:38:16 +0100 =?UTF-8?Q?Mateusz_=c5=81ukasik?=
>>  wrote:
>> Package: sponsorship-requests
>> Severity: wishlist
>> 
>> Dear mentors,
>> 
>> I am looking for a sponsor for my package "jgmenu":
>> 
>>* Package name: jgmenu
>>  Version : 4.3.0-1
>>  Upstream Author : Johan Malm 
>>* URL : https://jgmenu.github.io/
>>* License : LGPL-2+, GPL-2+, Expat, LGPL-3+
>>* Vcs : https://github.com/mati75/jgmenu
>>  Section : x11
>> 
>> It builds those binary packages:
>> 
>> jgmenu-xfce4-panel-applet - xfce4-panel applet for jgmenu
>> jgmenu - Simple X11 menu
>> 
>> To access further information about this package, please visit the
> following URL:
>> 
>> https://mentors.debian.net/package/jgmenu/
>> 
>> Alternatively, one can download the package with dget using this
> command:
>> 
>> dget -x
> https://mentors.debian.net/debian/pool/main/j/jgmenu/jgmenu_4.3.0-1.dsc
>> 
>> Changes for the initial release:
>> 
>>jgmenu (4.3.0-1) unstable; urgency=medium
>>.
>>  * Initial release. (Closes: #882210)
> 
> 
> One major problem: debian/copyright in your work says that the whole
> project is licensed under GPL-2+, however the LICENSE file from
> upstream only gives GPLv2 license text. The README file also does not
> mention that the whole project is licensed under GPLv2 **or later**.
> 
> Could you please contact upstream to clarify the case? The best output
> would be adding a "the whole project is licensed under GPLv2 or later"
> sentense in the README file, which would make things clear to everyone.
> 
> P.S. I took a look at upstream's debian/copyright file at
> https://github.com/johanmalm/jgmenu/blob/master/debian/copyright , in
> which the upstream only mentioned GPL-2, not GPL-2+. If upstream is
> only willing to release the whole project under GPL-2-only, using GPL-
> 2+ is wrong and must be fixed.
> 
> -- 
> Thanks,
> Boyuan Yang

Bug#979551: node-babel7: update-alternatives set up fails

[Xavier]

Control: tags -1 + confirmed

Hi,

this can be fixed using `--slave` parameter of update-alternatives
instead of a main link for manpages

Bug#979450: booth: autopkgtest fails on ci-worker-ppc64el-01 (but apparently not on other ppc64el workers)

[Valentin Vidic]

On Wed, Jan 27, 2021 at 09:56:34PM +0100, Paul Gevers wrote:
> Please see: https://salsa.debian.org/-/snippets/520 Do you seen anything
> weird?

I don't think anything would show up in the mounts on the host itself.
The problem is probably with some of the hardenings enabled in the
corosync service, for example:

https://salsa.debian.org/ha-team/corosync/-/blob/debian/master/debian/patches/Enable-PrivateTmp-in-the-systemd-service-files.patch

I seem to remember having this problem on my machine too were apparmor
was blocking the mount, and the solution was to add these to the config
of all containers:

# Apparmor enable
lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1

More details in /usr/share/doc/lxc/NEWS.Debian.gz

-- 
Valentin

Bug#981184: firefox-esr: doesn't load pages over internet

[Mike Hommey]

On Wed, Jan 27, 2021 at 01:23:02PM +0100, Emilian Nowak wrote:
> Package: firefox-esr
> Version: 78.6.1esr-1
> Severity: important
> 
> Dear Maintainer,
> Every time i try to open page from internet for example bugs.debian.org -
> nothing happnes. Page is not loading.
> 
> I can see in developer console that request is send, but
> there is no response.
> 
> When I access my http on http://localhost it works as expected.
> I tested it on safe-mode, and one clean newly created user.
> 
> Screenshot attached from developer console.

Can you try upgrading libnss3?

Mike

Bug#980571: Debian-jami does not embed ffmpeg

[Alexandre Viau]

> Am I correct in I assuming it is not using the embedded ffmpeg
> source, and the fix need to go in the ffmpeg package?

Yes.


-- 
Alexandre Viau
av...@debian.org



OpenPGP_signature
Description: OpenPGP digital signature

Bug#981052: xen: XSA-360: IRQ vector leak on x86

[Hans van Kranenburg]

Hi,

On 1/25/21 8:08 PM, Salvatore Bonaccorso wrote:
> Source: xen
> Version: 4.14.0+88-g1d1d1f5391-2
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi
> 
> For details see https://xenbits.xen.org/xsa/advisory-360.html . 
> 
> It does not affect version in buster afaict.

Indeed. Currently upstream stable-4.11 is at commit 310ab79875, which is
actually the same as our buster-security package
(4.11.4+57-g41a822c392-2) because the last upload was done using the
embargoed patches.

Unless something really interesting suddenly happens next Tuesday, there
won't be a buster security update happening together with the 10.8 point
release.

For unstable, I plan do do something at the end of this week, and base
it on the current stable-4.14 of course with the XSA-360 thing. And, we
will have reproducible builds, woohoo!

Thanks,
Hans

Bug#980571: please forward to upstream

[Alexandre Viau]

Hello,

Would you please forward this patch to upstream?

We have a very good relation with upstream and they respond extremely
quickly to our patches, so I see no need to maintain this patch in Debian.

CC-ing Amin.

Cheers,


-- 
Alexandre Viau
av...@debian.org



OpenPGP_signature
Description: OpenPGP digital signature

Bug#981176: RFP: doas -- minimal replacement for sudo

[Scupake]

Hello,

I am getting an error when trying to git push, it's teling me that:
"A default branch (e.g. master) does not yet exist for debian/doas
Ask a project Owner or Maintainer to create a default branch"

---
Scupake :D
4737A2C0A769B53AE82F77922BD8BE5CDD5ADA16


signature.asc
Description: PGP signature

Bug#979450: booth: autopkgtest fails on ci-worker-ppc64el-01 (but apparently not on other ppc64el workers)

[Paul Gevers]

Hi Valentin,

On 27-01-2021 14:16, Valentin Vidic wrote:
> I added some more logging in the new package version and it seems to be a 
> mount
> permission problem. Perhaps this worker has a different configuration somehow?

Please see: https://salsa.debian.org/-/snippets/520 Do you seen anything
weird?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#981220: gcc-xtensa-lx106: libgcc doesn't contain soft float functions

[Keith Packard]

Package: gcc-xtensa-lx106
Version: 10.2.1-3+8
Severity: normal
X-Debbugs-Cc: kei...@keithp.com

It seems that libgcc built for this toolchain is missing the soft float
emulation functions?

This program fails to link:

cat > test.c << EOF
#include 
#include 
#include 

int main(void)
{
char foo[50];
double q;
strcpy(foo, "3.1415");
sscanf(foo, "%lf", &q);
return (int) (sin(q) * 100);
}
EOF
xtensa-lx106-elf-gcc --specs=picolibc.specs test.c -lm





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

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

Versions of packages gcc-xtensa-lx106 depends on:
ii  binutils-xtensa-lx106  2.35.1-7+3+b1
ii  libc6  2.31-9
ii  libgcc-s1  10.2.1-6
ii  libgmp10   2:6.2.1+dfsg-1
ii  libmpc31.2.0-1
ii  libmpfr6   4.1.0-3
ii  libstdc++6 10.2.1-6
ii  zlib1g 1:1.2.11.dfsg-2

gcc-xtensa-lx106 recommends no packages.

gcc-xtensa-lx106 suggests no packages.

-- no debconf information

Bug#981180: O: aranym -- Atari Running on Any Machine

[John Paul Adrian Glaubitz]

Control: retitle -1 ITA: aranym -- Atari Running on Any Machine
Control: owner -1 !

I will adopt this package to update it to the latest upstream
version and move the packaging source to Debian Salsa.

Thanks,
Adrian

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

Bug#980794: octave-iso2mesh: Arbitrary limitation of build architectures

[Qianqian Fang]

On 1/27/21 12:12 PM, Rafael Laboissière wrote:
N.B.: I am moving this discussion into the mailing list of the Debian 
Octave Group and also adding Qianqian Fang (the original developer of 
the package and also upstream author) to the Cc list.


* John Paul Adrian Glaubitz  [2021-01-22 
12:10]:



Source: octave-iso2mesh
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org

The last upload octave-iso2mesh arbitrarily limited the list of build 
architectures on the assumption that only certain architectures have 
buildds with enough disk spaces which is certainly not true. The 
available disk space depends on the buildd used, not the architecture.


Furthermore, it may happen that the buildd disk space fills up which 
can happen if the machine crashes, gets automatically rebooted and 
the previous builds are therefore not cleaned up. This is something 
observed on the buildd blaauw which crashes regularly due to a bug in 
the kernel [1].


Could you therefore remove the architecture limitation list or - at 
least - re-add the Debian Ports architectures (e.g. alpha, hppa, 
ia64, m68k, powerpc, ppc64, riscv64, sh4, sparc64 and x32)?



hi Rafael, thanks for looping me in.

@Adrian,

as Rafael mentioned, the crash was caused by is compiling libCGAL based 
executables when building iso2mesh-tools, which is a dependency of 
octave-iso2mesh.


Most of these errors were caused by "*virtual memory exhausted*" error 
by gcc during compilation. I've seen similar errors when submitting 
iso2mesh for Fedora previously, see


https://bugzilla.redhat.com/show_bug.cgi?id=1758626#c11

one of the failed builds can be found at the below link, but the log 
files seems to no longer exist


https://koji.fedoraproject.org/koji/taskinfo?taskID=38115425

occasionally, the build may go through, but often times, it comes back 
in the next build attempt.



I'd love to make iso2mesh available on all supported platforms (which it 
should compile if given enough virtual memory), but given the unreliable 
compilation, excluding some of these platform is just practical 
workaround. Eventually, we can either solve this issue by fine tuning 
the build system virtual memory parameters, or work with CGAL developers 
to find out if there is a flag to reduce memory overhead. I suppose this 
issue is not alone, and should appear on other utilities that depend on 
libcgal-dev.


if anyone knows other workarounds to build libcgal-based binaries on 
embedded processors, we are happy to know and implement.


Qianqian




I am the responsible person for the build architecture limitation.  It 
was an attempt to get octave-iso2mesh into bullseye, at least for a 
limited set of release-official architectures.  However, the package 
did not yet migrated into testing, even though a request for the 
removal of the binary packages for armel, armhf, and mipsel have been 
filed (see Bug#979623).


Those architectures have been removed because the CGAL-dependent 
building consumes lots of memory.  I think that other packages in 
Debian are been hit by the same problem.


I fully agree that this is not an ideal situation.  I think that, once 
Bug#979623 is fixed, we should remove the architecture restriction.


What do the others think?

Best,

Rafael Laboissière

Bug#974839: [Help] Test failures in q2-feature-classifier

[Andreas Tille]

Hi Étienne,

On Wed, Jan 27, 2021 at 07:58:51PM +0100, Étienne Mollier wrote:
> 
> Your guess is right; setting the PYTHONPATH to the build
> directory allows most tests to run.  There were a couple of
> tests which then still failed to execute with the following
> symptom though:
> 
>   Command: vsearch --search_exact 
> /<>/.pybuild/cpython3_3.9/build/q2_feature_classifier/tests/data/se-dna-sequences.fasta
>  --id 0.8 --query_cov 0.8 --strand both --maxaccepts 10 --maxrejects 0 --db 
> /<>/.pybuild/cpython3_3.9/build/q2_feature_classifier/tests/data/se-dna-sequences.fasta
>  --threads 1 --output_no_hits --blast6out /tmp/tmpomuor76d
>   
>   - Captured stderr call 
> -
>   Fatal error: Invalid options to command search_exact
>   Invalid option(s): --id --maxaccepts --maxrejects --query_cov
>   The valid options for the search_exact command are: --alnout --biomout 
> --blast6out --bzip2_decompress --db --dbmask --dbmatched --dbnotmatched 
> --fasta_width --fastapairs --gzip_decompress --hardmask --log --match 
> --matched --maxhits --maxqsize --maxqt --maxseqlength --maxsizeratio --maxsl 
> --mincols --minqt --minseqlength --minsizeratio --minsl --mintsize --mismatch 
> --mothur_shared_out --no_progress --notmatched --notrunclabels --otutabout 
> --output_no_hits --qmask --quiet --relabel --relabel_keep --relabel_md5 
> --relabel_self --relabel_sha1 --rowlen --samheader --samout --self --sizein 
> --sizeout --strand --threads --top_hits_only --uc --uc_allhits --userfields 
> --userout --xee --xsize
> 
> I believe this is not caught by upstream because their CI seems
> to stick to vsearch <= 2.7.0.  I could devise a patch to remove
> the use of invalid options with search_exact.  It is sufficient
> to enable the test suite to pass through and pushed changes to
> Salsa[1].  However I am unsure whether just skipping invalid
> options is the right way to go, or if there are some other
> options that might need setting instead.  Are there people at
> ease with vsearch use around ?

I think, if the test might pass without this option we could go with
this or even remove those tests temporarily and discuss the issue with
upstream without pressure of an open RC bug (which is unrelated).

As always: Thanks a lot for your work on this

Andreas.
 
> [1] https://salsa.debian.org/med-team/q2-feature-classifier


-- 
http://fam-tille.de

Bug#954170: Help: Test suite failures (Was: ITP: anndata -- Annotated gene by sample numpy matrix)

[Steffen Möller]

Hi all,

Am 06.11.20 um 23:20 schrieb Diane Trout:
> On Fri, 2020-11-06 at 08:23 +0100, Andreas Tille wrote:
>> Dear Diane,
>>
>> would you mind pushing your patch to the Git repository?  I mean its
>> your ITP and you are Uploader - so I hesitate to push your very own
>> patch on behalf of you. ;-)
>>
>> Thanks a lot for your helpful hints and contacting upstream
> I pushed the patches... Is there anything else anyone wants to do to
> the package or should I submit to NEW?

To me, https://salsa.debian.org/med-team/python-anndata looks fine,
except that it reads "UNRELEASED" :) . Or did anthing happen in the
meantime that I have missed?

I am perfectly happy with an upload. Please go ahead, with a bit of luck
we make it into the release, still.

Best,

Steffen

Bug#981219: schroot overwrites cpuset

[David Bremner]

Package: schroot
Version: 1.6.10-11+b1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

As you can see with session below, schroot throws away the processor
affinities present in the parent process.  This breaks a common
strategy (used e.g. by slurm) for sharing multi-processor machines.

╭─ simplex:~ 
╰─% grep Cpus_allowed_list /proc/self/status
Cpus_allowed_list:  0,2,4,6,8,10,12,14,16,18,40,42,44,46,48,50,52,54,56,58
╭─ simplex:~ 
╰─% schroot -c sid grep Cpus_allowed_list /proc/self/status
Cpus_allowed_list:  0-79


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

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

Versions of packages schroot depends on:
ii  libboost-filesystem1.74.0   1.74.0-8
ii  libboost-iostreams1.74.01.74.0-8
ii  libboost-program-options1.74.0  1.74.0-8
ii  libc6   2.31-9
ii  libgcc-s1   10.2.1-6
ii  libpam0g1.4.0-2
ii  libstdc++6  10.2.1-6
ii  libuuid12.36.1-6
ii  lsb-base11.1.0
ii  schroot-common  1.6.10-11

schroot recommends no packages.

Versions of packages schroot suggests:
pn  aufs-tools | unionfs-fuse  
ii  btrfs-progs5.10-1
ii  debootstrap1.0.123
ii  lvm2   2.03.11-2
ii  qemu-user-static   1:5.2+dfsg-3
pn  zfsutils-linux 

- -- Configuration Files:
/etc/schroot/sbuild/fstab changed [not included]

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmARz30ACgkQA0U5G1Wq
FSEh5A/9GLOpmcFnAOm8xIJvcbHyq4AVewbOWIrrZ4UcKCLL/CA3eGbgWcmfhA0l
qJD64wLE9DRBxARSfR0eJjSquWeBd1BhsiYPvhpJ20E5gNzecFFdNbl7zl7YiiMv
lGyI5w2CfO4WR+qqOthf5trtonSuiFf1SazCbSWoGnv2CZd6QUCtY8NSSUcHOhBd
Xq+dgtRLIoXBcThIXqcTVbeUUahBfip4/SRH9XF9Y2zeVACmISXIX/G9wWxCMnjV
ltTFTCI9he4KxBXvkz7JS/lw/FmZW77XkIqdJYVuRG/UOHtTtJrWgmP/CTNaUD0X
fH/eP3RT94oFXWq1CJsH7mZAczZKDR4NGowhiYlKVh4SxJ/WhAD5rgbquCCc7ROx
TQg7k9raP74YMQ1zwCfNih8SOwDPhZq00pxRo0VFk40nv+2hahqH+pqgpRlMGsXb
3Lyx/2cS44Q52nJZcNJvnRg64xCRauQAQHK+Z5dFsJfFlv/V6avdh0iEB/ypXFVC
KJvMQHm7UXJuWN7DqzGCPKvDnWKlWKX3dlHugE7MM2kCNxUqFP6/eGU6ABSc/oei
BecLbmp/zw9RYbVgpsmIjJ/qyIXsMlE9t1z7+bNoq/ImuQQsI3zNduFrn3eKbdBv
NOqFTkDGN+fF7S0UzIhFF1M2R+V/voXlJlKk4BsoTpgo3IGcGW4=
=E1e3
-END PGP SIGNATURE-

Bug#979819: python3-distutils version 3.9.x breaks python3.8-stdlib with no version limit

[Shai Berger]

Thanks again.

Bug#906072: ITP: ogon -- ogon session manager and RDP server

[Mike Gabriel]

Hi Matthias,

On  Mi 27 Jan 2021 16:13:55 CET, Matthias Klumpp wrote:


Hi Mike and everyone else involved with this packaging project!

First of all, thank you for working on this, ogon looks like a rather
complicated thing to package.
I would like to ask what the status of this project currently is. Do
you think that there is any chance this could still make it into
bullseye? Is there anything you would need help with?

Cheers,
Matthias


Bullseye won't happen for ogon. There are some blocking issues where  
upstream patches to third party projects are required that we don't  
have yet in Debian.


I will look into doing the first uploads (hope that Marcel, who did  
quite a bit of the heavy listing recently, is back then...) after the  
bullseye release (or also during the freezes, possibly).


Once we have all the components in experimental and everything works  
nicely, we can throw the packages on to the bullseye-backports archive  
area and make Ogon available for Debian 11 users.


However, until beginning of February, I will be fully occupied with  
the packages I already have in testing (some of them still need some  
love).


And... Thanks for your interest!!!

Mike
--

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

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



pgpebVlksjVBa.pgp
Description: Digitale PGP-Signatur

Bug#981176: RFP: doas -- minimal replacement for sudo

[Bernd Zeimetz]

Hi,

On 1/27/21 8:40 PM, Scupake wrote:
> On Wed, Jan 27, 2021 at 08:20:55PM +0100, Bernd Zeimetz wrote:
>> whats your salsa username?
> @Scupake
> I have just created my account a little bit ago.

found your user :)

> Also, are you going to make a repository in the debian group or should I
> just make a repository?

repository created, you should have got an invitation.

I've configured the CI to use


debian/.gitlab-ci.yml

please use the salsa pipeline to test the package. please note that this
requires to use git-buildpackage. let me know if you have troubles with that

CI documentation is at

https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/README.md


thanks,

Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#718272: Processed: reopening 718272

[Jonas Smedegaard]

close 718272
thanks

Quoting Moritz Mühlenhoff (2021-01-27 20:03:40)
> reopen 718272
> thx
> 
> Reopening. The reasons are listed in the bug log and were given by
> the upstream developers. If you want to provide it to bullseye
> stable users, get it into fasttrack.debian.net.

Thanks for sharing your interpretation of the state of this bug, and for 
suggesting how to maintain this package.

I disagree with both the interpretation and the suggestion, however.
Closing, reflecting my views on this bug as package maintainer.

 - 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#981176: RFP: doas -- minimal replacement for sudo

[Scupake]

On Wed, Jan 27, 2021 at 08:20:55PM +0100, Bernd Zeimetz wrote:
> whats your salsa username?
@Scupake
I have just created my account a little bit ago.

Also, are you going to make a repository in the debian group or should I
just make a repository?

---
Scupake :D
4737A2C0A769B53AE82F77922BD8BE5CDD5ADA16


signature.asc
Description: PGP signature

Bug#980903: debhelper: doc-base doc-id deduplication does not work as documented with multiple "dh_installdocs -p" calls; causes /usr/share/doc-base/ to be installed multiple times

[Axel Beckert]

Hi Niels,

thanks for your reply!

TL;DR:

* Will probably go down the documentation update route for bullseye.

* I'm refusing to merge my own proposed patch without a review, at
  least for bullseye.

* Reviews welcome nevertheless. :-)

Niels Thykier wrote:
> I have not examined this fully and I do not expect to be diving into the
> details here any time soon.

Yeah, I feared something like this after your comment in the according
zsh branch on Salsa which triggers this.

> Personally, it seems a bit like a "last minute bug"

Yes, it of course is. But not for the sake of making last minute
changes. I just discovered it in the wrong moment.

I would have filed it more or less the same in the midst of the
development cycle. (Well, maybe then even without that alternative "at
least document it". ;-)

> and I am do not feel I have the necessary spoons to tackle it (or
> rather any fall out if it goes less than perfectly smooth).

I feel competent enough to make further changes in case it causes
regressions. I'm though a bit unsure about its real impact, at least
as of now.

Running builds with and without it and then diffoscope it obviously
won't help as a change is to be expected.

> As it seems urgent to you

No, not "urgent". That's definitely the wrong term. It's more like
"important" (sic!).

But more in the way like there being an undiscovered bug which causes
broken packages to be build and nobody discovered it for a decade.
(Does the latter sound familiar to any one today? Ok, unfair, that
sudo issue is much more severe, but equally old and undiscovered until
recently as well. ;-)

Anyway, I also do recognize that this bug obviously hasn't been ever
triggered before (and then reported, at least). So while it is a bug
which causes debhelper to build uninstallable packages, it is
definitely rare. It needs at least these things to be present:

1. doc-base is used

2. multiple binary packages are build

3. dh_installdocs -p is used at least twice (probably implies
   2.).

4. one document ID is split over two built packages (and both are
   present in the calls of 3.).

And now that I wrote that explicitly, I start to see that why this
combination is so rare that I only undiscovered a decade after the
code had been committed.

> and I suspect you have researched this (at least much better than I
> will have energy to do for now),

I've read all documentation I could find on this, but that's more or
less only dh_installdocs(1) (and the dh_installdocs source code in a
RTFS sense) on debhelper's side and
file://localhost/usr/share/doc/doc-base/doc-base.html/interface.html#s2.5.1
on doc-base's side.

In theory the actual filenames of the files in /usr/share/doc-base/
should not make a difference as long as they're unique.

I'm Cc'ing the doc-base maintainer to see if he can give some input on
this.

Robert: My proposed programmatical fix for this is in
https://salsa.debian.org/debian/debhelper/-/merge_requests/45

I'd be happy about a review, especially from someone understanding
doc-base and/or debhelper. That patch would change the filename
scheme, with which debhelper generates files in /usr/share/doc-base/
to always being "packagename.documentid" to avoid any file conflicts.

> I am fine with letting you manage it from here if you wish to do
> that.

Ok, fair enough.

So what I would like to have on this is at least a second pair of
eyes, because I'm very well aware of the potential impact of at least
my proposed solution.

Also to have it mentioned: For me it is way more important to me that
there's any fix for that (including documentation) than to have my
proposed fix in debhelper.

> Assuming you wish to have this fixed for bullseye,

As I wrote, I'm fine with proper documentation on this as alternative
to a code change as I do see that there is a potential for regressions
even though I don't see yet where actually a regression would be
possible. (But that's a common property of regressions, isn't it.)

So unless someone else does a (positive) review of my proposed patch,
I won't commit that one to the master branch.

But I will propose an alternative patch which purely updates
dh_installdocs' POD to explicitly mention this issue. IMHO this should
be no issue, even without a review and unless I get further feedback,
I'd go down that route and downgrade this bug-report to important
(which it technically would be without the "maintainer's opinion"
thing).

Niels: If you're more comfortable with that documentation approarch at
this stage at the freeze, I'm totally fine with going down that route
in any case for bullseye and leave the remainder open for bookworm.
Actually, the longer I think about it, the more I prefer that variant,
too. :-)

> then I propose the following:
> 
>  1) Please base your work on debhelper's master branch.

I thought, I did. Will check. Ah, I see, you did some work there
today. Fair enough. :-)

> It is mostly typo fixes and translation work. Please do commit
> direct

Bug#960686: dh_strip should tell about the original names when emitting error messages

[Niels Thykier]

Control: reassign -1 binutils

On Fri, 15 May 2020 14:18:59 +0200 Matthias Klose  wrote:
> Package: debhelper
> Version: 13
> Severity: minor
> 
> Building gcc-snapshot you see
> 
> dh_strip -pgcc-snapshot -Xdebug -X/cgo -Xbin/go -Xbin/gofmt \
> 
> objcopy: debian/gcc-snapshot/usr/lib/gcc-snapshot/bin/stPxkJ3q: debuglink
> section already exists
> [...]
> 
> It would be nice to emit the name of the original files as well, making
> debugging issues a bit easier. So maybe buffer objcopy's output and in case 
> of a
> message, print the original file name.
> 
> 
> 

Hi,

That "gibberish" name is an internal name used in objcopy and it makes
more sense to fix this bug at its roots (which would be in objcopy
itself), reassigning accordingly.

Reproducer:

"""
$ cd /tmp
$ cp /bin/ls .
$ objcopy --add-gnu-debuglink /bin/test ls
objcopy: stnJQXz3: debuglink section already exists
"""

The "stnJQXz3" name is indeed not very helpful and should have said "ls"
(or "/tmp/ls" in this case)

~Niels

Bug#981218: ITP: python-rocksdb -- Python bindings for RocksDB

[Martina Ferrari]

Package: wnpp
Severity: wishlist
Owner: Martina Ferrari 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-rocksdb
  Version : 0.8.0~rc3
  Upstream Author : Martina Ferrari 
* URL : https://github.com/NightTsarina/python-rocksdb
* License : BSD-3-clause
  Programming Lang: Python
  Description : Python bindings for RocksDB

 RocksDB is a C++ library providing an embedded key-value store, where keys and
 values are arbitrary byte streams. It was developed at Facebook based on
 LevelDB and provides backwards-compatible support for LevelDB APIs.
 .
 RocksDB is optimized for Flash with extremely low latencies. RocksDB uses a
 Log Structured Database Engine for storage, written entirely in C++.
 .
 RocksDB features highly flexible configuration settings that may be tuned to
 run on a variety of production environments, including pure memory, Flash,
 hard disks or HDFS. It supports various compression algorithms and good tools
 for production support and debugging.
 .
 This package provides the Python bindings.

Bug#981176: RFP: doas -- minimal replacement for sudo

[Bernd Zeimetz]

On 1/27/21 7:30 PM, Scupake wrote:
> On Wed, Jan 27, 2021 at 06:48:39PM +0100, Bernd Zeimetz wrote:
>> nice, I'll happily sponsor the upload.
> Thanks!
> 
>> Would you be willing to put your packaging work on salsa.debian.org?
>> Maybe in the debian group? I could create a repository there if necessary.
> Sure, I don't mind.

whats your salsa username?



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#981200: RFS: sanlock/3.8.3-1 -- Shared storage lock manager

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: sanlock
   Version : 3.8.3-1
   Upstream Author :
 * URL : https://www.pagure.io/sanlock/
 * License : LGPL-2.1+, GPL-2+
 * Vcs :
   Section : libs

It builds those binary packages:

  python3-sanlock - Python3 bindings to shared storage lock manager
  libsanlock-dev - Shared storage lock manager (development files)
  libsanlock1 - Shared storage lock manager (shared library)
  libsanlock-client1 - Shared storage lock manager (client library)
  sanlk-reset - Host reset daemon and client using sanlock
  sanlock - Shared storage lock manager

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/s/sanlock/sanlock_3.8.3-1.dsc

Changes since the last upload:

 sanlock (3.8.3-1) unstable; urgency=medium
 .
   * New upstream version 3.8.3
   * Move libraries and pkg-config to a multiarch location (Closes: #980335)
 Thanks to Helmut Grohne for patch
   * New package: sanlk-reset
   * Drop patches applied upstream
   * d/rules: Drop Python version flag
   * Move Python example file to correct folder
   * d/control:
 - Drop Built-Using for Python3 package
 - Change section for binary package sanlock, from libs to utils
 - Remove sanlock as dependency for libsanlock-dev
 - Remove libblkid1 as build-dependency

Regards,
Håvard

Bug#980626: [Pkg-opencl-devel] Bug#980626: pocl: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

[Andreas Beckmann]

Control: tag -1 confirmed

On 1/20/21 9:43 PM, Lucas Nussbaum wrote:
>> E: Build killed with signal TERM after 150 minutes of inactivity
That's kernel/test_rotate hanging.

I can now reproduce this locally, too.
Seems to be dependent on the Host CPU.
Yours is the same as mine:
>  Default target: x86_64-pc-linux-gnu
>  Host CPU: skylake-avx512

This does not happen with newer llvm ... only llvm-9
But it still happens without the hardening flags that I had enabled
recently ...
And it does not happen with pocl 1.5, so let me bisect...

Andreas

Bug#981217: ITP: golang-github-phpdave11-gofpdf -- A PDF document generator with high level support for text, drawing and images

[Felix Yan]

Package: wnpp
Severity: wishlist
Owner: Felix Yan 

* Package name: golang-github-phpdave11-gofpdf
  Version : 1.4.2-1
  Upstream Author : Dave Barnes
* URL : https://github.com/phpdave11/gofpdf
* License : Expat
  Programming Lang: Go
  Description : A PDF document generator with high level support for text, 
drawing and images

 Package gofpdf implements a PDF document generator with high level
 support for text, drawing and images. Features: UTF-8 support;
 Choice of measurement unit, page format and margins• Page header
 and footer management; Automatic page breaks, line breaks, and text
 justification; Inclusion of JPEG, PNG, GIF, TIFF and basic path-only
 SVG images; Colors, gradients and alpha channel transparency;
 Outline bookmarks; Internal and external links; TrueType, Type1
 and encoding support; Page compression; Lines, Bézier curves,
 arcs, and ellipses; Rotation, scaling, skewing, translation, and
 mirroring; Clipping; Document protection; Layers; Templates;
 Barcodes; Charting facility; Import PDFs as templates gofpdf has no
 dependencies other than the Go standard library.

Adding as a new dependency for golang-github-ruudk-golang-pdf417

Bug#981216: RM: q2-quality-filter [armhf i386] -- ROM; dependency python3-skbio uninstallable on 32 bits targets

[Étienne Mollier]

Package: ftp.debian.org
Severity: normal

Greetings,

q2-quality-filter currently fails to migrate to Testing due to
missing python3-skbio dependency for running autopkgtest on
armhf and i386 targets.  Prior uploads of the package were
missing the depency and tests, therefore the package probably
never worked on these platforms anyway.

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


signature.asc
Description: PGP signature

Bug#969597: libzstd: Please correct version in symbol file

[Stephen Kitt]

On Mon, 25 Jan 2021 23:20:37 +0100, Sebastian Andrzej Siewior
 wrote:
> On 2021-01-25 22:59:08 [+0100], Stephen Kitt wrote:
> > That was no doubt the intention, however in practice the symbol
> > visibility wasn’t as expected: looking at the .so build in version
> > 1.3.8, common/pool.c includes common/zstd_internal.h which defines
> > ZSTD_STATIC_LINKING_ONLY before including zstd.h, and as a result the
> > symbols are visible.
> > 
> > (It’s unfortunate that the build hides the exact commands used, so
> > they’re not visible in the build logs, but that’s another issue. Easy
> > enough to fix in a local build to see exactly what’s going on...)
> > 
> > So the cat is out of the bag, and the symbols are present and visible
> > in the .so. The symbols file is generated and only reflects the
> > reality of what is present in the file (apart from the version numbers
> > which are added manually).  
> 
> I opened the bug because I couldn't use these symbols in Buster's zstd
> but had to use bpo instead. rsync is meanwhile available in bpo and
> pulls-in the libzstd from bpo which is good.
> 
> I have no idea what should be done here to close this properly.

I think the best fix at this point will be to bump the versions in the symbols
file to match the intention, and then binNMU all the packages with a
dependency on (>= 1.3.8) so that they get fixed to (>= 1.4.0) if appropriate.

I haven’t finished looking into the current upstream situation in detail but
it seems this is fixed, so we shouldn’t run into the issue for later symbols.

I’ll NMU zstd (unless anyone from the med team objects) and send a summary to
the release team.

Regards,

Stephen


pgpfQI4nxZKR0.pgp
Description: OpenPGP digital signature