Bug#984158: grfcodec: diff for NMU version 6.0.6-5.1

[Matthijs Kooijman]

Hi Adrian,

> I've prepared an NMU for grfcodec (versioned as 6.0.6-5.1) and uploaded 
> it to DELAYED/15. Please feel free to tell me if I should cancel it, or
> to use the changes for a maintainer upload instead.
Thanks for your interest and picking this up!

However, I had actually *just* uploaded a new version myself yesterday, but
it seems they are not picked up. I suspect this is because my gpg key
expired and the validity extension I did a while ago isn't picked up by
the keyring yet. As soon as it is, I expect my pending packages will be
processed.

See also https://salsa.debian.org/openttd-team/grfcodec/-/commits/master/

I suspect it would be best to cancel your upload, and use my version
instead.

Gr.

Matthijs


signature.asc
Description: PGP signature

Bug#1000466: [Debichem-devel] Bug#1000466: phonopy: autopkgtest failure

[Andrius Merkys]

Hi,

On 2021-11-23 20:20, Adrian Bunk wrote:
> /usr/lib/python3/dist-packages/phonopy/qha/eos.py:137: SystemExit
> - Captured stdout call 
> -
> You need to install python-scipy.
> === short test summary info 
> 
> FAILED test/qha/test_QHA.py::test_QHA_Si - SystemExit: 1
> = 1 failed, 138 passed, 1 skipped in 62.19s (0:01:02) 
> ==
> autopkgtest [15:31:27]: test command1: ---]
> autopkgtest [15:31:27]: test command1:  - - - - - - - - - - results - - - - - 
> - - - - -
> 
> 
> python3-scipy is a !nocheck build dependency.

This most likely is limited to testing, as I cannot reproduce the
autopkgtest failure in clean sid chroot. Most likely some dependency in
unstable pulls python3-scipy in. It would make sense to add explicit
autopkgtest dependency on python3-scipy, though.

Thanks,
Andrius

Bug#1000492: missing dep-5 copyright file

[Marc Haber]

Package: daemon
Version: 0.7-1
Severity: wishlist
Tags: help

Hi,

daemon is missing a dep-5 compatible copyright file. I probably won't
have time to add this in the near future, help is appreciated.

Greetings
Marc

Bug#998627: linux: please enable the new NTFS3 driver in 5.15

[Wenbin Lv]

Hi,

On Wed, Nov 24, 2021 at 5:36 AM Salvatore Bonaccorso  wrote:
>
> Hi,
>
>
> Are tools available to handle creation and checking of such NTFS3
> filesystems? The last time I went to the paragon software site it
> mentioned it was planning. This is not a must, but kept me for
> slightly on the on hold position for enabling it.
>
> Regards,
> Salvatore
>

Paragon only mentioned they are planning to release mkfs.ntfs in their
FAQ, not the fsck tool[1]. So we'll need ntfs-3g or Windows for fsck
anyway if they don't release it. Stability and further code
maintenance, however, are matters of greater concern as Ted Ts'o
pointed out[2]. Maybe we should hold it back for some time to see what
will happen.

Best regards,
Wenbin Lv

[1] https://www.paragon-software.com/home/ntfs3-driver-faq/
[2] https://lore.kernel.org/lkml/yqnhxiu+eaaxi...@mit.edu/

Bug#1000491: FTBFS with Why3 1.4.0

[Stéphane Glondu]

Source: frama-c
Version: 20201209+titanium-4.1
Severity: serious
Tags: ftbfs

Dear Maintainer,

Frama-c FTBFS with Why3 1.4.0:
> [...]
> File "src/plugins/wp/Why3Provers.ml", line 31, characters 19-61:
> 31 |   let config = Why3.Whyconf.load_default_config_if_needed config in
> ^^
> Error: Unbound value Why3.Whyconf.load_default_config_if_needed
> make[1]: *** [share/Makefile.generic:78: src/plugins/wp/Why3Provers.cmo] 
> Error 2
> make[1]: *** Waiting for unfinished jobs
> make[1]: Leaving directory '/<>'
> dh_auto_build: error: make -j4 returned exit code 2
> make: *** [debian/rules:45: binary-arch] Error 25
> dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
> status 2

This may be fixed by the new upstream release v23 (Vanadium).


Cheers,

-- 
Stéphane


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

Kernel: Linux 5.14.0-4-amd64 (SMP w/4 CPU threads)
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

Bug#998565: Errors due to changes in iso-codes data

[Stuart Prescott]

Hi Scott

> > The tests look easy enough to fix, so it's worth trying to do that. (and
> > it's in the Debian group on salsa to make that easy :)

I've looked at them and fixed most of the tests locally without issues. I guess 
I should push that somewhere so that it is visible. I'll start a draft PR with 
upstream for it.

> > I'm a bit surprised by some of the data changes though -- apparently
> > England is no longer a part of the UK. Yes, that's quite complicated, but
> > the ISO-3166-2 info does still list ENG and EAW. As the pycountry tests
> > highlight, those divisions disappeared from iso_3166-2.json with the
> > switch over to a different data harvester.
> > 
> > https://www.iso.org/obp/ui/#iso:code:3166:GB
> > 
> > Is that correct and intended?
> 
> Good question.  I not sure how to adapt one test to the new data, so I'll
> leave it on to you to deal with.  

I'm happy to look for alternate sets of divisions to replace these UK ones in 
the test if that's appropriate. I guess I need the input from Tobias to know 
whether the pycountry test failure has found a bug in the pycountry test code 
or a bug in the iso-codes data.

The test failures regarding AL-BU look like an intended data change that needs 
a fix in the pycountry data. Finding a different second level division and then 
coming back to the national and first level divisions is needed... Tobias might 
have a suggestion there, otherwise I'll trawl the ISO database to find a 
different test case.

https://www.iso.org/obp/ui/#iso:code:3166:AL 
https://en.wikipedia.org/wiki/ISO_3166-2:AL

> Please address this before it gets auto-removed.

Yes, will do. (and just discussing this bug keeps resetting the autoremoval 
timer, of course!)

cheers
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#993810: pure-ftpd CVE-2021-40524

[Istiak Ferdous]

Hi,

pure-ftpd CVE-2021-40524 got a fix and new release 1.0.50 is now available.

https://github.com/jedisct1/pure-ftpd/commit/37ad222868e52271905b94afea4fc780d83294b4

https://github.com/jedisct1/pure-ftpd/releases/tag/1.0.50

Thanks

Istiak Ferdous

Bug#949450: thunderbird: tb not usable with apparmor profile enabled.

[Thomas Guyot-Sionnest]

FYI this is the fix for chrome (attached patch), but maybe I should
report to a separate bug as it covers more than TB...

I haven't looked at the gpg issue and apparmor configuration but it may
too be best fixed at a global level... Unless we only want to allow
specific applications to run gpg?

The fix is inspired from https://askubuntu.com/q/1357638/628778

--
Thomas
--- a/etc/apparmor.d/abstractions/ubuntu-helpers	2021-04-03 02:09:19.0 -0400
+++ b/etc/apparmor.d/abstractions/ubuntu-helpers	2021-11-24 00:55:23.649143462 -0500
@@ -70,6 +70,7 @@
   /opt/google/chrome{,-beta,-unstable}/chrome-sandbox PUxr,
   /opt/google/chrome{,-beta,-unstable}/google-chrome Pixr,
   /opt/google/chrome{,-beta,-unstable}/chrome Pixr,
+  /opt/google/chrome{,-beta,-unstable}/{,chrome_}crashpad_handler Pixr,
   /opt/google/chrome{,-beta,-unstable}/{,**/}lib*.so{,.*} m,
 
   # Full access

Bug#998565: Errors due to changes in iso-codes data

[Scott Kitterman]

On Tue, 16 Nov 2021 01:30:55 +1100 Stuart Prescott  wrote:
> Hi Scott & Tobias
> 
> On Monday, 15 November 2021 21:13:09 AEDT Dr. Tobias Quathamer wrote:
> > On Sun, 14 Nov 2021 20:30:06 -0500 Scott Kitterman 
> > 
> > wrote:
> > > I looked at this a bit today and it looks like the test failures are due
> > > to
> > > updates in the iso-codes data used by the tests, not any real failures.  I
> > > think disabling the failing tests for now would be a reasonable way to
> > > keep
> > > this in testing (I'm interested to avoid transitive removal of xml2rfc).
> > > 
> > > Unless there's some objection to this, I will probably NMU later in the
> > > week.
> > > 
> > > Scott K
> > 
> > Hi Scott,
> > 
> > iso-codes maintainer here -- I've just seen this bug and your mail. Your
> > analysis is correct, from my point of view, you should go ahead with the
> > NMU.
> 
> The tests look easy enough to fix, so it's worth trying to do that. (and it's 
> in the Debian group on salsa to make that easy :)
> 
> I'm a bit surprised by some of the data changes though -- apparently England 
> is no longer a part of the UK. Yes, that's quite complicated, but the 
> ISO-3166-2 info does still list ENG and EAW. As the pycountry tests 
> highlight, 
> those divisions disappeared from iso_3166-2.json with the switch over to a 
> different data harvester.
> 
> https://www.iso.org/obp/ui/#iso:code:3166:GB 
> 
> Is that correct and intended?

Good question.  I not sure how to adapt one test to the new data, so I'll leave 
it on to you to deal with.  Please address this before it gets auto-removed.

Scott K

Bug#996319: Builds fine

[Daniel Leidert]

The package builds and tests without errors.

There errors show problems with file recognition and also errors that files are
not found. It actually looks weird and if there were problems with /tmp.

Let's wait and see if this re-appears.

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#999510: libidn2 FTBFS for musl-linux-any: broken gettext check

[Helmut Grohne]

Hi Simon,

On Tue, Nov 23, 2021 at 08:46:15PM +0100, Simon Josefsson wrote:
> Hi.  Thanks for the report.  I don't understand, what error message do
> you get?  As far as I can tell, that idiom is used in many GNU packages,
> and if we really should change, I think the change should be done in
> many packages.  Is there anything unique to libidn2 here?

You don't get any error message. The check simply considers that no libc
other than glibc has a suitable gettext. The check is broken. That's why
the check has been fixed upstream (in an incremented version). Yes,
you're correct that many GNU packages need to bump up the version of the
check. It's totally non-unique to libidn2. Other packages include bison
and popt.

Helmut

Bug#1000490: parted: heap-overflow after getline

[wangyangbo]

Package: parted
Version: 3.4-1
Severity: normal

Dear Maintainer,

echo 'int main(){
  ped_malloc(10);
  return 0;
}' >a.c
gcc a.c -lparted -fsanitize=address
./a.out running by no-root,

Will see heap-buffer-overflow from ped_disk_gpt_init.
I have fixed it, will submit after this report.


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

Kernel: Linux 5.10.0-9-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 parted depends on:
ii  libc6 2.31-13+deb11u2
ii  libparted23.4-1
ii  libreadline8  8.1-1
ii  libtinfo6 6.2+20201114-2

parted recommends no packages.

Versions of packages parted suggests:
pn  parted-doc  

Bug#998471: gpgme1.0: diff for NMU version 1.16.0-1.2

[Stefano Rivera]

Control: tags 998471 + patch
Control: tags 998471 + pending

Dear maintainer,

Turns out the bug is actually that autoconf has a hardcoded list of
Python versions and 3.10 isn't in the list. When it is in the list,
there is also a bug somewhere that treats it as python 3.1.

But... Let's just avoid the hardcoded list entirely, I've prepared an
NMU to do that.

I've prepared an NMU for gpgme1.0 (versioned as 1.16.0-1.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Also filed as https://salsa.debian.org/debian/gpgme/-/merge_requests/3

Regards,

SR
diff -Nru gpgme1.0-1.16.0/debian/changelog gpgme1.0-1.16.0/debian/changelog
--- gpgme1.0-1.16.0/debian/changelog	2021-09-15 01:31:55.0 -0400
+++ gpgme1.0-1.16.0/debian/changelog	2021-11-23 21:15:08.0 -0400
@@ -1,3 +1,10 @@
+gpgme1.0 (1.16.0-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Patch: Avoid a hardcoded list of known Python versions. (Closes: #998471)
+
+ -- Stefano Rivera   Tue, 23 Nov 2021 21:15:08 -0400
+
 gpgme1.0 (1.16.0-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru gpgme1.0-1.16.0/debian/patches/0004-core-Fix-use-after-free-issue-in-test.patch gpgme1.0-1.16.0/debian/patches/0004-core-Fix-use-after-free-issue-in-test.patch
--- gpgme1.0-1.16.0/debian/patches/0004-core-Fix-use-after-free-issue-in-test.patch	1969-12-31 20:00:00.0 -0400
+++ gpgme1.0-1.16.0/debian/patches/0004-core-Fix-use-after-free-issue-in-test.patch	2021-11-23 21:15:08.0 -0400
@@ -0,0 +1,122 @@
+From: =?utf-8?q?Ingo_Kl=C3=B6cker?= 
+Date: Sat, 26 Jun 2021 18:02:47 +0200
+Subject: core: Fix use-after-free issue in test
+
+* tests/gpg/t-edit-sign.c (sign_key, verify_key_signature): New.
+(main): Factored out signing and verifying the result.
+--
+
+Factoring the two steps of the test into different functions fixes the
+use-after-free issue that was caused by accidentaly using a variable
+of the first step in the second step.
+
+GnuPG-bug-id: 5509
+---
+ tests/gpg/t-edit-sign.c | 54 +
+ 1 file changed, 37 insertions(+), 17 deletions(-)
+
+diff --git a/tests/gpg/t-edit-sign.c b/tests/gpg/t-edit-sign.c
+index 2f98362..e0494c5 100644
+--- a/tests/gpg/t-edit-sign.c
 b/tests/gpg/t-edit-sign.c
+@@ -107,31 +107,19 @@ interact_fnc (void *opaque, const char *status, const char *args, int fd)
+ }
+ 
+ 
+-int
+-main (int argc, char **argv)
++void
++sign_key (const char *key_fpr, const char *signer_fpr)
+ {
+   gpgme_ctx_t ctx;
+   gpgme_error_t err;
+   gpgme_data_t out = NULL;
+-  const char *signer_fpr = "A0FF4590BB6122EDEF6E3C542D727CC768697734"; /* Alpha Test */
+   gpgme_key_t signing_key = NULL;
+-  const char *key_fpr = "D695676BDCEDCC2CDD6152BCFE180B1DA9E3B0B2"; /* Bravo Test */
+   gpgme_key_t key = NULL;
+-  gpgme_key_t signed_key = NULL;
+-  gpgme_user_id_t signed_uid = NULL;
+-  gpgme_key_sig_t key_sig = NULL;
+   char *agent_info;
+-  int mode;
+-
+-  (void)argc;
+-  (void)argv;
+-
+-  init_gpgme (GPGME_PROTOCOL_OpenPGP);
+ 
+   err = gpgme_new (&ctx);
+   fail_if_err (err);
+ 
+-  /* Sign the key */
+   agent_info = getenv("GPG_AGENT_INFO");
+   if (!(agent_info && strchr (agent_info, ':')))
+ gpgme_set_passphrase_cb (ctx, passphrase_cb, 0);
+@@ -159,8 +147,23 @@ main (int argc, char **argv)
+   gpgme_data_release (out);
+   gpgme_key_unref (key);
+   gpgme_key_unref (signing_key);
++  gpgme_release (ctx);
++}
++
++
++void
++verify_key_signature (const char *key_fpr, const char *signer_keyid)
++{
++  gpgme_ctx_t ctx;
++  gpgme_error_t err;
++  gpgme_key_t signed_key = NULL;
++  gpgme_user_id_t signed_uid = NULL;
++  gpgme_key_sig_t key_sig = NULL;
++  int mode;
++
++  err = gpgme_new (&ctx);
++  fail_if_err (err);
+ 
+-  /* Verify the key signature */
+   mode  = gpgme_get_keylist_mode (ctx);
+   mode |= GPGME_KEYLIST_MODE_SIGS;
+   err = gpgme_set_keylist_mode (ctx, mode);
+@@ -168,7 +171,7 @@ main (int argc, char **argv)
+   err = gpgme_get_key (ctx, key_fpr, &signed_key, 0);
+   fail_if_err (err);
+ 
+-  signed_uid = key->uids;
++  signed_uid = signed_key->uids;
+   if (!signed_uid)
+ {
+   fprintf (stderr, "Signed key has no user IDs\n");
+@@ -180,7 +183,7 @@ main (int argc, char **argv)
+   exit (1);
+ }
+   key_sig = signed_uid->signatures->next;
+-  if (strcmp ("2D727CC768697734", key_sig->keyid))
++  if (strcmp (signer_keyid, key_sig->keyid))
+ {
+   fprintf (stderr, "Unexpected key ID in second user ID sig: %s\n",
+ key_sig->keyid);
+@@ -196,6 +199,23 @@ main (int argc, char **argv)
+ 
+   gpgme_key_unref (signed_key);
+   gpgme_release (ctx);
++}
++
++
++int
++main (int argc, char **argv)
++{
++  const char *signer_fpr = "A0FF4590BB6122EDEF6E3C542D727CC768697734"; /* Alpha Test */
++  const char *signer_keyid = signer_fpr + strlen(signer_fpr) - 16;
++  const char *key_fpr = "D695676BDCEDCC2CDD6152BCFE180B1DA9E3B0B2"; /* Bravo Test */
++
++  (void)argc;
++  (void)ar

Bug#898926: I think firefox is to blame

[Jonathan Krebs]

this could be the same issue: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948691

Bug#962216: Github link

[積丹尼 Dan Jacobson]

See also https://github.com/systemd/systemd/issues/21491 .

Bug#948691: MOZ_APP_LAUNCHER

[Jonathan Krebs]

Also removing the environment variable from thunderbird via gdb before clicking 
a link in an email will make firefox behave correctly, and starting firefox by

env MOZ_APP_LAUNCHER=/usr/bin/pluma firefox

will make firefox want to set pluma.desktop as default browser :)

Bug#948691: MOZ_APP_LAUNCHER

[Jonathan Krebs]

I have this behavior on firefox 94 from sid,

I suspect the MOZ_APP_LAUNCHER environment variable, which is set by 
thunderbird and evaluated in 
browser/components/shell/nsGNOMEShellService.cpp:135

(Filtered) environment of firefox, when started through thunderbird (this wants 
thunderbird.desktop as default browser):
We have thunderbird in $MOZ_APP_LAUNCHER and firefox in 
$GIO_LAUNCHED_DESKTOP_FILE

DESKTOP_SESSION=mate
GDM_LANG=de_DE.utf8
GIO_LAUNCHED_DESKTOP_FILE=/usr/share/applications/firefox.desktop
GIO_LAUNCHED_DESKTOP_FILE_PID=3669595
HOME=/home/j
LANG=C.UTF-8
LC_MEASUREMENT=en_DK.UTF-8
LC_PAPER=en_DK.UTF-8
LC_TIME=en_DK.UTF-8
LD_LIBRARY_PATH=/usr/lib/firefox
LD_PRELOAD=libmozsandbox.so
LOGNAME=j
MATE_DESKTOP_SESSION_ID=this-is-deprecated
MOZ_APP_LAUNCHER=/usr/bin/thunderbird
MOZ_APP_SILENT_START=
MOZ_ASSUME_USER_NS=1
MOZ_CRASHREPORTER_[...]
MOZ_LAUNCHED_CHILD=
MOZ_PROFILER_STARTUP=
MOZ_SANDBOXED=1
MOZ_SANDBOX_USE_CHROOT=1402653184
TB_FAIL=0
TB_HELP=0
TB_VERBOSE=0
XDG_CURRENT_DESKTOP=MATE
XDG_[...]
XDG_SESSION_TYPE=x11

(Filtered) environment when started through MATE-Panel: (this wants 
firefox.desktop as default browser)

GIO_LAUNCHED_DESKTOP_FILE=/usr/share/applications/firefox.desktop
GIO_LAUNCHED_DESKTOP_FILE_PID=3674365
LD_LIBRARY_PATH=/usr/lib/firefox
LD_PRELOAD=libmozsandbox.so
MOZ_APP_SILENT_START=
MOZ_ASSUME_USER_NS=1
MOZ_CRASHREPORTER_[...]
MOZ_HEADLESS=1
MOZ_LAUNCHED_CHILD=
MOZ_PROFILER_STARTUP=
MOZ_SANDBOXED=1
MOZ_SANDBOX_USE_CHROOT=11476395008
PATH=/home/j/.cargo/bin:/home/j/config/bin:/home/j/.local/bin:/home/j/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin:/sbin:/usr/sbin
PWD=/home/j
XDG_SESSION_DESKTOP=mate
XDG_SESSION_TYPE=x11

Bug#1000489: ITP: obs-cli -- command-line remote control for OBS Studio

[Benjamin Drung]

X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name: obs-cli
  Version : 0.2.0-1
  Upstream Author : Christian Muehlhaeuser
* URL : https://github.com/muesli/obs-cli
* License : Expat
  Programming Lang: Go
  Description : command-line remote control for OBS Studio

OBS-cli is a command-line remote control for Open Broadcaster Software
(OBS) Studio. It requires the obs-websocket plugin to be installed on
your system.
 .
 obs-cli supports following commands:
  * label countdown/text
  * recording start/status/stop/toggle
  * scene switch
  * sceneitem center/hide/list/show/toggle
  * source list/toggle-mute
  * stream start/status/stop/toggle

I will use this binary and maintain the package as part of the Go team.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#1000486: buster-pu: package btrbk/0.27.1-1+deb10u2

[Thorsten Alteholz]

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


The attached debdiff for btrbk fixes a regression of CVE-2021-38173 in 
Buster.


The regression was reported in #996260 [1] and a pointer to the fix was 
provided. There was at least one report about a now working version 
+deb10u2.


  Thorsten

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996260diff -Nru btrbk-0.27.1/debian/changelog btrbk-0.27.1/debian/changelog
--- btrbk-0.27.1/debian/changelog   2021-08-29 19:03:02.0 +0200
+++ btrbk-0.27.1/debian/changelog   2021-11-23 16:03:02.0 +0100
@@ -1,3 +1,11 @@
+btrbk (0.27.1-1+deb10u2) buster; urgency=high
+
+  * Non-maintainer upload by the LTS Team.
+  * regression fix for CVE-2021-38173
+(Closes: #996260, #996266)
+
+ -- Thorsten Alteholz   Tue, 23 Nov 2021 16:03:02 +0100
+
 btrbk (0.27.1-1+deb10u1) buster; urgency=high
 
   * Non-maintainer upload by the LTS Team.
diff -Nru btrbk-0.27.1/debian/patches/CVE-2021-38173-regression.patch 
btrbk-0.27.1/debian/patches/CVE-2021-38173-regression.patch
--- btrbk-0.27.1/debian/patches/CVE-2021-38173-regression.patch 1970-01-01 
01:00:00.0 +0100
+++ btrbk-0.27.1/debian/patches/CVE-2021-38173-regression.patch 2021-11-23 
15:52:28.0 +0100
@@ -0,0 +1,51 @@
+commit c03e960d9044961fcfbeaa5d5aeb5bcc1bc0cc7a
+Author: Axel Burri 
+Date:   Tue Nov 19 22:07:37 2019 +0100
+
+ssh_filter_btrbk.sh: exclude "btrfs subvolume show|list" from restrict-path
+
+btrbk requires "btrfs subvolume list|show" queries from the mount
+point in order to build btrfs trees. This conflicts with tightly set
+--restrict-path.
+
+Index: btrbk-0.27.1/doc/ssh_filter_btrbk.1.asciidoc
+===
+--- btrbk-0.27.1.orig/doc/ssh_filter_btrbk.1.asciidoc  2021-11-23 
15:52:22.921452288 +0100
 btrbk-0.27.1/doc/ssh_filter_btrbk.1.asciidoc   2021-11-23 
15:52:22.917452292 +0100
+@@ -34,8 +34,8 @@
+ 
+ The following commands are always allowed:
+ 
+- - "btrfs subvolume show"
+- - "btrfs subvolume list"
++ - "btrfs subvolume show" (not affected by "--restrict-path")
++ - "btrfs subvolume list" (not affected by "--restrict-path")
+  - "readlink"
+  - "cat /proc/self/mountinfo"
+  - pipes through "gzip", "pigz", "bzip2", "pbzip2", "xz", "lzop",
+@@ -79,7 +79,8 @@
+ Allow btrfs receive command: "btrfs receive".
+ 
+ -p, --restrict-path ::
+-Restrict btrfs commands to .
++Restrict commands to . Note that "btrfs subvolume show",
++"btrfs subvolume list" are NOT affected by this option.
+ 
+ -l, --log::
+ Log ACCEPT and REJECT messages to the system log.
+Index: btrbk-0.27.1/ssh_filter_btrbk.sh
+===
+--- btrbk-0.27.1.orig/ssh_filter_btrbk.sh  2021-11-23 15:52:22.921452288 
+0100
 btrbk-0.27.1/ssh_filter_btrbk.sh   2021-11-23 15:52:22.921452288 +0100
+@@ -161,8 +161,9 @@
+ shift
+ done
+ 
+-allow_cmd "${sudo_prefix}btrfs subvolume show"; # subvolume queries are 
always allowed
+-allow_exact_cmd "${sudo_prefix}btrfs subvolume list ${file_match}"; # 
subvolume queries are always allowed
++# NOTE: subvolume queries no NOT affected by "--restrict-path":
++# btrbk also calls show/list on the mount point of the subvolume
++allow_exact_cmd "${sudo_prefix}btrfs subvolume (show|list)( ${option_match})* 
${file_match}";
+ allow_cmd "${sudo_prefix}readlink"  # used to resolve mountpoints
+ allow_exact_cmd "cat /proc/self/mountinfo"  # used to resolve mountpoints
+ allow_exact_cmd "cat /proc/self/mounts" # legacy, for btrbk < 0.27.0
diff -Nru btrbk-0.27.1/debian/patches/series btrbk-0.27.1/debian/patches/series
--- btrbk-0.27.1/debian/patches/series  2021-08-29 19:03:02.0 +0200
+++ btrbk-0.27.1/debian/patches/series  2021-11-23 15:52:21.0 +0100
@@ -1 +1,2 @@
 CVE-2021-38173.patch
+CVE-2021-38173-regression.patch

Bug#1000487: ITP: golang-github-andreykaipov-goobs -- control OBS Studio via WebSockets (Go library)

[Benjamin Drung]

X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name: golang-github-andreykaipov-goobs
  Version : 0.7.1+ds1-1
  Upstream Author : Andrey Kaipov
* URL : https://github.com/andreykaipov/goobs
* License : Apache-2.0
  Programming Lang: Go
  Description : control OBS Studio via WebSockets (Go library)

goobs is a Go client library for controlling Open Broadcaster Software 
(OBS) studio via WebSockets (using obs-websocket).

I will maintain the package as part of the Go team. This library is a
dependency for obs-cli which I want to package and use.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#1000485: bullseye-pu: package btrbk/0.27.1-1.1+deb11u2

[Thorsten Alteholz]

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

The attached debdiff for btrbk fixes a regression of CVE-2021-38173 in
Bullseye.

The regression was reported in #996260 [1] and a pointer to the fix was
provided. There was at least one report about a now working version 
+deb10u2 in Buster, which is based on the same version as Bullseye.


  Thorsten

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996260
diff -Nru btrbk-0.27.1/debian/changelog btrbk-0.27.1/debian/changelog
--- btrbk-0.27.1/debian/changelog   2021-08-29 19:03:02.0 +0200
+++ btrbk-0.27.1/debian/changelog   2021-11-23 20:03:02.0 +0100
@@ -1,3 +1,11 @@
+btrbk (0.27.1-1.1+deb11u2) bullseye; urgency=high
+
+  * Non-maintainer upload by the LTS Team.
+  * regression fix for CVE-2021-38173
+(Closes: #996260, #996266)
+
+ -- Thorsten Alteholz   Tue, 23 Nov 2021 20:03:02 +0100
+
 btrbk (0.27.1-1.1+deb11u1) bullseye; urgency=high
 
   * Non-maintainer upload by the LTS Team.
diff -Nru btrbk-0.27.1/debian/patches/CVE-2021-38173-regression.patch 
btrbk-0.27.1/debian/patches/CVE-2021-38173-regression.patch
--- btrbk-0.27.1/debian/patches/CVE-2021-38173-regression.patch 1970-01-01 
01:00:00.0 +0100
+++ btrbk-0.27.1/debian/patches/CVE-2021-38173-regression.patch 2021-11-23 
20:03:02.0 +0100
@@ -0,0 +1,51 @@
+commit c03e960d9044961fcfbeaa5d5aeb5bcc1bc0cc7a
+Author: Axel Burri 
+Date:   Tue Nov 19 22:07:37 2019 +0100
+
+ssh_filter_btrbk.sh: exclude "btrfs subvolume show|list" from restrict-path
+
+btrbk requires "btrfs subvolume list|show" queries from the mount
+point in order to build btrfs trees. This conflicts with tightly set
+--restrict-path.
+
+Index: btrbk-0.27.1/doc/ssh_filter_btrbk.1.asciidoc
+===
+--- btrbk-0.27.1.orig/doc/ssh_filter_btrbk.1.asciidoc  2021-11-23 
15:52:22.921452288 +0100
 btrbk-0.27.1/doc/ssh_filter_btrbk.1.asciidoc   2021-11-23 
15:52:22.917452292 +0100
+@@ -34,8 +34,8 @@
+ 
+ The following commands are always allowed:
+ 
+- - "btrfs subvolume show"
+- - "btrfs subvolume list"
++ - "btrfs subvolume show" (not affected by "--restrict-path")
++ - "btrfs subvolume list" (not affected by "--restrict-path")
+  - "readlink"
+  - "cat /proc/self/mountinfo"
+  - pipes through "gzip", "pigz", "bzip2", "pbzip2", "xz", "lzop",
+@@ -79,7 +79,8 @@
+ Allow btrfs receive command: "btrfs receive".
+ 
+ -p, --restrict-path ::
+-Restrict btrfs commands to .
++Restrict commands to . Note that "btrfs subvolume show",
++"btrfs subvolume list" are NOT affected by this option.
+ 
+ -l, --log::
+ Log ACCEPT and REJECT messages to the system log.
+Index: btrbk-0.27.1/ssh_filter_btrbk.sh
+===
+--- btrbk-0.27.1.orig/ssh_filter_btrbk.sh  2021-11-23 15:52:22.921452288 
+0100
 btrbk-0.27.1/ssh_filter_btrbk.sh   2021-11-23 15:52:22.921452288 +0100
+@@ -161,8 +161,9 @@
+ shift
+ done
+ 
+-allow_cmd "${sudo_prefix}btrfs subvolume show"; # subvolume queries are 
always allowed
+-allow_exact_cmd "${sudo_prefix}btrfs subvolume list ${file_match}"; # 
subvolume queries are always allowed
++# NOTE: subvolume queries no NOT affected by "--restrict-path":
++# btrbk also calls show/list on the mount point of the subvolume
++allow_exact_cmd "${sudo_prefix}btrfs subvolume (show|list)( ${option_match})* 
${file_match}";
+ allow_cmd "${sudo_prefix}readlink"  # used to resolve mountpoints
+ allow_exact_cmd "cat /proc/self/mountinfo"  # used to resolve mountpoints
+ allow_exact_cmd "cat /proc/self/mounts" # legacy, for btrbk < 0.27.0
diff -Nru btrbk-0.27.1/debian/patches/series btrbk-0.27.1/debian/patches/series
--- btrbk-0.27.1/debian/patches/series  2021-08-29 19:03:02.0 +0200
+++ btrbk-0.27.1/debian/patches/series  2021-11-23 20:03:02.0 +0100
@@ -1 +1,2 @@
 CVE-2021-38173.patch
+CVE-2021-38173-regression.patch

Bug#1000484: ITP: golang-github-dave-jennifer -- code generator for Go

[Benjamin Drung]

X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name: golang-github-dave-jennifer
  Version : 1.4.1-1
  Upstream Author : Dave Brophy
* URL : https://github.com/dave/jennifer
* License : Expat
  Programming Lang: Go
  Description : Jennifer is a code generator for Go

Jennifer is a code generator for Go. It has a comprehensive suite of
examples. See
https://pkg.go.dev/github.com/dave/jennifer/jen?utm_source=godoc#pkg-examples
for an index.

This Go library is needed to build golang-github-andreykaipov-goobs. It
will be team-maintained within the Debian Go Packaging Team.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[David Prévot]

Hi,

Le 23/11/2021 à 15:57, Paul Gevers a écrit :

On 23-11-2021 11:52, Ondřej Surý wrote:

On 22. 11. 2021, at 22:28, David Prévot  wrote:



I’ve just uploaded a version with your fix.


Thanks a lot.


+1.


David, can we now agree on a timeframe when we start the transition?



[…] it's not up to him to decide.


[…] David, I think you already said you wouldn't 
mind if the transition already started now, is that the stance of the 
Debian PHP PEAR Maintainers?


AFAICT, nobody objects (the team is CCed, since a few mails). We’re also 
holding on some updates because some packages already require PHP 8 
(other are still after PHP 5 compatibility, the world is a mess ;).


How much of the broken reverse dependencies 
are outside that teams maintenance (approximately)?


No clue, sorry. Not sure autopkgtest are used a lot outside of the PHP 
PEAR (and Composer) and Horde teams, that doesn’t help to get a quick grasp.



And I would prefer if we roughly agree on a timeframe when we start
the transition to php8.2 - I can upload the 8.2.0~beta1 as soon as it
is ready upstream

[…]
The Release Team _very much_ welcomes staging/testing these things in 
experimental exactly as you propose. So by all means, upload early, 
including the relevant php-defaults too.

[…]
But it also depends a bit on 
the cooperation of the maintainers of your reverse dependencies and/or 
NMU actions. This takes time and coordination.


Thanks for sharing your plans in advance, happy to try and make this 
timeframe work.


Regards

David


OpenPGP_signature
Description: OpenPGP digital signature

Bug#996653: RFS: dynarmic/5+git20211012.cce7e4e+ds-1 [ITP] -- ARMdynamic recompiler

[Bastian Germann]

Control: tags -1 moreinfo

On 23.11.21 21:48, Andrea Pappacoda wrote:

On Tue, 23 Nov 2021 18:13:10 +0100 Andrea Pappacoda  wrote:
 > > FTBFS on arm64:
 >
 > This makes me think that arm64 host support is still incomplete. Until
 > it released as stable by upstream, I think it's better to disable arm64
 > builds.

Or maybe not. Some build issues are probably related to the fact that libzydis-dev does not depend 
on libzycore-dev while it should - this causes Dynarmic to FTBFS also on amd64. Also, libxbyak-dev 
pre-6.00-2 had a small issue that made it impossible to make it discoverable through CMake's 
find_package(). I've uploaded a fixed zydis revision (-3) on Mentors, and tomorrow I'll also work on 
Dynarmic and arm64.


Okay. I have just uploaded the new zydis version.
Please untag moreinfo when you have uploaded a new dynarmic.

Bug#998627: linux: please enable the new NTFS3 driver in 5.15

[Vincent Blut]

Le 2021-11-23 22:34, Salvatore Bonaccorso a écrit :
> Hi,
> 
> On Tue, Nov 23, 2021 at 12:37:02PM +0100, Vincent Blut wrote:
> > Hi,
> > 
> > Le 2021-11-22 18:54, Boyuan Yang a écrit :
> > > Hi,
> > > 
> > > On Fri, 5 Nov 2021 16:55:33 +0800 Wenbin Lv  wrote:
> > > > Package: src:linux
> > > > Version: 5.15-1~exp1
> > > > Severity: wishlist
> > > > 
> > > > Hi,
> > > > Paragon's NTFS3 driver has been merged to 5.15, and it offers much
> > > > better performance compared to ntfs-3g. Currently it is not enabled in
> > > > Debian's kernel config, nor can I mount NTFS partitions using '-t
> > > > ntfs3'.
> > > > Please enable it if you consider it stable enough. Thank you!
> > > 
> > > Now that 5.15 has been uploaded to Unstable, this issue will attract wider
> > > attention. Please consider enabling it in future uploads.
> > 
> > I'll send a merge request to the kernel team later today.
> 
> Are tools available to handle creation and checking of such NTFS3
> filesystems?

Not yet AFAIK.

> The last time I went to the paragon software site it mentioned it was
> planning. This is not a must, but kept me for slightly on the on hold
> position for enabling it.

Understandable! Let's hold off for the moment then.
 
> Regards,
> Salvatore

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1000483: postgresql-13: upgrade from version 11 to 13 failed to migrate data

[Christoph Berg]

Control: tags -1 moreinfo

Re: Axel
> Package: postgresql-13
> Version: 13.5-0+deb11u1
> Severity: important
> 
> Dear Maintainer,
> 
> During the upgrade procedure from Debian 10 to 11, Postgresql was upgraded, 
> too, but
> version 11 was purged without cluster migrationm, so I had to re-enable the 
> Buster
> repository, reinstall version 11, and perform migration manually.

Did you "apt autoremove" or any similar commands?

Can you post /var/log/apt/term.log?

Christoph

Bug#1000483: postgresql-13: upgrade from version 11 to 13 failed to migrate data

[Axel]

Package: postgresql-13
Version: 13.5-0+deb11u1
Severity: important

Dear Maintainer,

During the upgrade procedure from Debian 10 to 11, Postgresql was upgraded, 
too, but
version 11 was purged without cluster migrationm, so I had to re-enable the 
Buster
repository, reinstall version 11, and perform migration manually.

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

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

Versions of packages postgresql-13 depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13+deb11u2
ii  libgcc-s1  10.2.1-6
ii  libgssapi-krb5-2   1.18.3-6+deb11u1
ii  libicu67   67.1-7
ii  libldap-2.4-2  2.4.57+dfsg-3
ii  libllvm11  1:11.0.1-2
ii  libpam0g   1.4.0-9+deb11u1
ii  libpq5 13.5-0+deb11u1
ii  libselinux13.1-3
ii  libssl1.1  1.1.1k-1+deb11u1
ii  libstdc++6 10.2.1-6
ii  libsystemd0247.3-6
ii  libuuid1   2.36.1-8
ii  libxml22.9.10+dfsg-6.7
ii  libxslt1.1 1.1.34-4
ii  locales2.31-13+deb11u2
ii  locales-all2.31-13+deb11u2
ii  postgresql-client-13   13.5-0+deb11u1
ii  postgresql-common  225
ii  ssl-cert   1.1.0+nmu1
ii  tzdata 2021a-1+deb11u1
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages postgresql-13 recommends:
ii  sysstat  12.5.2-2

postgresql-13 suggests no packages.

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

Bug#1000482: neomutt: license conflict with libsasl2

[Bastian Germann]

Package: neomutt
Version: 20201127+dfsg.1-1.2
Severity: important

Hi,

neomutt depends on libsasl2-2, which is licensed under CMU's BSD-4-clause 
license and covered by the RSA-MD and OpenSSL
licenses. All of them have an advertisement clause in place, which is known to 
be incompatible with GPL.
There are several possible solutions to this problem:

1) Build without SASL support.

2) Support my request at #996892.

3) Ask upstream to add a license exception for libsasl2-2, similar to the one 
that was required by Debian for OpenSSL
for a long time.

Thanks for your consideration,
Bastian

Bug#981030: RFS: sctk/2.4.10-20151007-1312Z+dfsg2-4 -- speech recognition scoring toolkit

[Bastian Germann]

Am 22.11.21 um 16:10 schrieb Giulio Paci:

I guess the main reason for this weird behavior is described in (option 
-mfpmath):

https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/x86-Options.html#x86-Options 



and in (option -ffloat-store):

https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/Optimize-Options.html#Optimize-Options 
.


Using -ffloat-store option indeed seems to fix the issue.


However I am wondering:
1) is this the proper solution?
2) is it correct that the compiler does not guarantee the above assumptions?

Do you have any suggestion?


Hi,

I am not very knowlegable about floating point semantics in various compiler 
optimizations,
so unfortunately I do not have any suggestion. Does upstream have an opinion on 
this?

Thanks,
Bastian

Bug#1000481: upgrade-reports: Bullseye kernel hangs while initialising i915 gpu driver on old intel graphic chip

[Ben Mueller]

Package: upgrade-reports
Severity: normal
X-Debbugs-Cc: letter...@internix.de

My previous release is: Buster
I am upgrading to: Bullseye
Archive date: ?
Upgrade date: 2021-11-21
uname -a before upgrade: (kernel: linux-image-4.19.0-18-amd64 4.19.208-1)
uname -a after upgrade: Linux rappel 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 
(2021-09-30) x86_64 GNU/Linux
Method: apt

Contents of /etc/apt/sources.list:
deb http://ftp.de.debian.org/debian/ bullseye main contrib non-free
deb-src http://ftp.de.debian.org/debian/ bullseye main
deb http://security.debian.org/debian-security bullseye-security main contrib 
non-free
deb-src http://security.debian.org/debian-security bullseye-security main
deb http://ftp.de.debian.org/debian/ bullseye-updates main contrib non-free
deb-src http://ftp.de.debian.org/debian/ bullseye-updates main

Further Comments/Problems:
The update went fine without errors. But booting with the new kernel did
not work. The display went black shortly after loading the new kernel. I
think it was the moment when it normally changes the display resolution.
The boot process did not continue. Keyboard and mouse were not functioning.
I had to hard switch off the computer. There were no logs written to disk.
Fortunately my old kernel linux-image-4.19.0-18-amd64 was still able to
boot.

I solved the problem by inserting a boot parameter "intel_iommu=off" to
grub. With this parameter the kernel from bullseye
linux-image-5.10.0-9-amd64 was able to boot properly and the graphic was
fine on console and with x. The kernel from buster did not need this
boot parameter.

I think the problem is, that the i915 gpu driver has difficulties to
initialise my old intel graphic chip. According to lspci it is:

00:02.0 VGA compatible controller: Intel Corporation 82Q35 Express Integrated 
Graphics Controller (rev 02) (prog-if 00 [VGA controller])
Subsystem: Fujitsu Technology Solutions 82Q35 Express Integrated 
Graphics Controller
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at f020 (32-bit, non-prefetchable) [size=512K]
I/O ports at 1c70 [size=8]
Memory at e000 (32-bit, prefetchable) [size=256M]
Memory at f000 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at 000c [virtual] [disabled] [size=128K]
Capabilities: 
Kernel driver in use: i915
Kernel modules: i915

I hope this report will be useful to other people trying to run the
bullseye kernel on old intel hardware.

Bug#997959: git-annex: FTBFS on 32-bit ARM architectures, but built successfully before

[Sean Whitton]

Hello,

On Wed 24 Nov 2021 at 02:21AM +0530, Nilesh Patra wrote:

> Hi Sean, Richard,
>
> On Wed, 27 Oct 2021 12:20:04 -0700 Sean Whitton  
> wrote:
>> Source: git-annex
>> Version: 8.20210223-2
>> Severity: serious
>> git-annex recently began to FTBFS on 32-bit ARM architectures, and I am
>> not really in a position atm to dig deeply into the problem.
>> [.. log ..]
>
> This bug is now triggering removals of its reverse-dependencies.
> Would you (or any list member) have some bandwidth to take a deeper look into 
> this?

I don't, I'm afraid.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1000324: RFS: ghostwriter/2.1.0-1 -- Distraction-free, themeable Markdown editor

[Nicholas D Steeves]

P.S. Yes, these methods aren't mutually exclusive; they can be combined.
I was just trying to keep things simple ;-)


signature.asc
Description: PGP signature

Bug#1000324: RFS: ghostwriter/2.1.0-1 -- Distraction-free, themeable Markdown editor

[Nicholas D Steeves]

Hi Sebastien,

Sebastien Chavaux  writes:
>
> Thank you first of all. So it's not that I don't want to maintain git /
> salsa, it's that I'm not comfortable with it, should do a remedial course
> on it.
>

I also found git hard to start out with.  The first thing I noticed that
all documentation seemed to omit was how important it is to set EDITOR
in ~/.bashrc.

Beyond that, here are the three approaches I took:

1. Keep it simple, and use debcommit.  With this approach I assume
whole-repository granularity.  Note that one pitfall with this method is
that you may need to manually run "git status", "git add ./", and "git
remove list of files".  "git add ./" will also add backup-files~, which
is annoying.  To be fair, debcommit+git does support more a more
fine-grained staging and committing workflow, but I never really got
comfortable with it.  One significant advantage to this approach is that
it encourages objective-driven development.  eg: your "* changelog
entry for foo" can be seen as your goal; then you work to accomplish
your goal.
   * uscan
   * dch -v1.0.1
 # Make any change, even as simple as  , then save
   and exit
   * debcommit -a
 # This "opens a new changelog entry" in git history
[a]* Attempt a build
   * If it fails, make changes
   * dch
 # Document the purpose of your changes, save, and exit
   * debcommit -a
   ... cycle back to [a]
   and so on...  Eventually "dch -r", commit, and tag.

2. git-buildpackage a bit more difficult, but still fairly easy to use,
and optionally enables a the opposite workflow, where the changelog is
generated from commit messages.  When this was my primary approach I
manually ran git commands as necessary.

3. Learn to use Magit to exploit the full power of git staging,
reverting, rebasing, 3-way diffing during conflicts, etc.  This is now
my preferred approach, because it enables one to do all the work at
once, then quickly stage specific groups of files and lines from files
(such as changelog) into atomic, self-contained commits.  Getting
comfortable with this approach requires getting comfortable with Emacs,
which might not be something you're interested in.  For what it's worth,
I was initially skeptical, but after a few months found it totally
worthwhile.

Whatever approach you end up taking, I hope you'll one day have an
empowering "Aha!" moment when you realise that your work wasn't wiped
out by a hasty "git reset --hard committish".  eg:
  https://stackoverflow.com/questions/5473/how-can-i-undo-git-reset-hard-head1

Beyond this, it's a bit annoying to have to locally delete a release tag
if your mentor asks for revisions; this includes updating the changelog,
committing, rerunning "dch -r", committing, and retagging.

> I will see how to define the same list of architectures as qtwebengine5. I
> watch this and do it after work.
>

This sounds like a good approach to me :-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#998627: linux: please enable the new NTFS3 driver in 5.15

[Salvatore Bonaccorso]

Hi,

On Tue, Nov 23, 2021 at 12:37:02PM +0100, Vincent Blut wrote:
> Hi,
> 
> Le 2021-11-22 18:54, Boyuan Yang a écrit :
> > Hi,
> > 
> > On Fri, 5 Nov 2021 16:55:33 +0800 Wenbin Lv  wrote:
> > > Package: src:linux
> > > Version: 5.15-1~exp1
> > > Severity: wishlist
> > > 
> > > Hi,
> > > Paragon's NTFS3 driver has been merged to 5.15, and it offers much
> > > better performance compared to ntfs-3g. Currently it is not enabled in
> > > Debian's kernel config, nor can I mount NTFS partitions using '-t
> > > ntfs3'.
> > > Please enable it if you consider it stable enough. Thank you!
> > 
> > Now that 5.15 has been uploaded to Unstable, this issue will attract wider
> > attention. Please consider enabling it in future uploads.
> 
> I'll send a merge request to the kernel team later today.

Are tools available to handle creation and checking of such NTFS3
filesystems? The last time I went to the paragon software site it
mentioned it was planning. This is not a must, but kept me for
slightly on the on hold position for enabling it.

Regards,
Salvatore

Bug#1000479: buster-pu: package jtreg/5.1-b01-2~deb10u1

[Moritz Muehlenhoff]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ebo...@apache.org, d...@debian.org

The build requirements for openjdk-11 were bumped, starting with
11.0.13 jtreg 5 (and along with it a jtharness 6) are required to
run the test suite. Since we need to follow 11.0.x releases for
security updates, this blocks an update of 11.0.13 for buster-security.

Attached are debdiffs against the versions relative to what's in
bullseye. Fortunately openjdk is the only reverse dep of jtreg/jtharness.

That's not great, but still less worse than firefox/rust :-)

Debdiff below.

diff -Nru jtreg-5.1-b01/debian/changelog jtreg-5.1-b01/debian/changelog
--- jtreg-5.1-b01/debian/changelog  2020-07-15 04:28:47.0 +
+++ jtreg-5.1-b01/debian/changelog  2021-11-19 16:26:05.0 +
@@ -1,3 +1,10 @@
+jtreg (5.1-b01-2~deb10u1) buster; urgency=medium
+
+  * Rebuild for buster, needed for latest OpenJDK 11.x release
+- Switch to debhelper 12
+
+ -- Moritz Muehlenhoff   Fri, 19 Nov 2021 16:26:05 +
+
 jtreg (5.1-b01-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru jtreg-5.1-b01/debian/compat jtreg-5.1-b01/debian/compat
--- jtreg-5.1-b01/debian/compat 1970-01-01 00:00:00.0 +
+++ jtreg-5.1-b01/debian/compat 2021-11-19 16:26:05.0 +
@@ -0,0 +1 @@
+12
diff -Nru jtreg-5.1-b01/debian/control jtreg-5.1-b01/debian/control
--- jtreg-5.1-b01/debian/control2020-07-15 04:28:47.0 +
+++ jtreg-5.1-b01/debian/control2021-11-19 16:26:05.0 +
@@ -5,7 +5,7 @@
 Uploaders: Guillaume Mazoyer 
 Build-Depends:
  ant,
- debhelper-compat (= 13),
+ debhelper,
  default-jdk,
  help2man,
  javahelp2,

Bug#1000480: buster-pu: package jtharness/6.0-b15-1~deb10u1

[Moritz Muehlenhoff]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ebo...@apache.org, d...@debian.org

The build requirements for openjdk-11 were bumped, starting with
11.0.13 jtreg 5 (and along with it a jtharness 6) are required to
run the test suite. Since we need to follow 11.0.x releases for
security updates, this blocks an update of 11.0.13 for buster-security.

Attached are debdiffs against the versions relative to what's in
bullseye. Fortunately openjdk is the only reverse dep of jtreg/jtharness.

That's not great, but still less worse than firefox/rust :-)

Debdiff below.

diff -Nru jtharness-6.0-b15/debian/changelog jtharness-6.0-b15/debian/changelog
--- jtharness-6.0-b15/debian/changelog  2021-01-21 15:33:45.0 +
+++ jtharness-6.0-b15/debian/changelog  2021-11-19 16:17:12.0 +
@@ -1,3 +1,10 @@
+jtharness (6.0-b15-1~deb10u1) buster; urgency=medium
+
+  * Rebuild for buster, needed for latest OpenJDK 11.x release
+- Switch to debhelper 12
+
+ -- Moritz Muehlenhoff   Fri, 19 Nov 2021 16:17:12 +
+
 jtharness (6.0-b15-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru jtharness-6.0-b15/debian/compat jtharness-6.0-b15/debian/compat
--- jtharness-6.0-b15/debian/compat 1970-01-01 00:00:00.0 +
+++ jtharness-6.0-b15/debian/compat 2021-11-19 16:17:12.0 +
@@ -0,0 +1 @@
+12
diff -Nru jtharness-6.0-b15/debian/control jtharness-6.0-b15/debian/control
--- jtharness-6.0-b15/debian/control2021-01-21 15:18:46.0 +
+++ jtharness-6.0-b15/debian/control2021-11-19 16:17:12.0 +
@@ -5,7 +5,7 @@
 Uploaders: Guillaume Mazoyer 
 Build-Depends:
  ant,
- debhelper-compat (= 13),
+ debhelper,
  default-jdk,
  javahelper,
  junit4,

Bug#1000471: glewlwyd FTBFS can't find functions.

[Nicolas Mora]

Hello,

Le 2021-11-23 à 15 h 20, peter green a écrit :

Package: glewlwyd
Version: 2.5.2-3
Severity: serious
Tags: ftbfs

Unfortunately it seems that even after the cross-fetch fix, glewlwyd 
still FTBFS as a

result of changes in iddawc/rhonabwy.

Thanks, that's because the dependencies were updated lately, and some 
api was changed.


I have the package glewlwyd 2.6.0 ready to upload, as soon as 
node-i18next-http-backend 1.3.1+dfsg-3 will be available on my schroot, 
today or tomorrow.


/Nicolas

Bug#810890: caddy in NEW queue

[Geert Stappers]

Hi,

For your information:

At https://ftp-master.debian.org/new.html is
currently visible that on 2021-11-21 an upload to the NEW queue was
done. Uploaded to expiremental, but uploaded.

Maintainer: Debian Go Packaging Team
Changed-By: Peymaneh Nejad
Sponsor: ge...@debian.org


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1000478: dh-sysuser: User removal is never invoked (and the implementation is buggy)

[Andrea Bolognani]

Package: dh-sysuser
Version: 1.3.5.1
Severity: important
X-Debbugs-CC: e...@kiyuko.org

Contrary to intention, users created by dh-sysuser are not actually
deleted when the package is purged.

Using the libvirt-dbus package, which I maintain, as an example:

  $ grep libvirtdbus /etc/passwd /etc/group
  $ sudo apt-get install -y libvirt-dbus
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  The following NEW packages will be installed:
libvirt-dbus
  0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
  Need to get 0 B/61.2 kB of archives.
  After this operation, 337 kB of additional disk space will be used.
  Selecting previously unselected package libvirt-dbus.
  (Reading database ... 226040 files and directories currently installed.)
  Preparing to unpack .../libvirt-dbus_1.4.0-2_amd64.deb ...
  Unpacking libvirt-dbus (1.4.0-2) ...
  Setting up libvirt-dbus (1.4.0-2) ...
  Processing triggers for dbus (1.12.20-3) ...
  Processing triggers for man-db (2.9.4-2) ...
  $ grep libvirtdbus /etc/passwd /etc/group
  /etc/passwd:libvirtdbus:x:998:998:Created by dh-sysuser for 
libvirt-dbus:/nonexistent:/usr/sbin/nologin
  /etc/group:libvirtdbus:x:998:
  $ sudo apt-get remove --purge -y libvirt-dbus
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  The following packages will be REMOVED:
libvirt-dbus*
  0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
  After this operation, 337 kB disk space will be freed.
  (Reading database ... 226061 files and directories currently installed.)
  Removing libvirt-dbus (1.4.0-2) ...
  Processing triggers for dbus (1.12.20-3) ...
  Processing triggers for man-db (2.9.4-2) ...
  $ grep libvirtdbus /etc/passwd /etc/group
  /etc/passwd:libvirtdbus:x:998:998:Created by dh-sysuser for 
libvirt-dbus:/nonexistent:/usr/sbin/nologin
  /etc/group:libvirtdbus:x:998:
  $

Looking at the code for sysuser-helper, the reason for this behavior
is pretty obvious:

  command="${1}" ; shift
  case "${command}" in
prerm)
  case ${1:-} in
purge|abort-install)
  rmdir --ignore-fail-on-non-empty "${CONF_HOME}"
  if ! [ -d "${CONF_HOME}" ] ; then
if ! userdel --force "${CONF_USERNAME}" ; then
  echo >&2 "warning: failed to remove ${CONF_USERNAME}. Proceeding 
anyway."
fi
  fi
  esac
  esac

So users are deleted when sysuser-helper is called from prerm and the
operation is purge or abort-install. But deb-prerm(5) lists all
possible ways in which prerm can be invoked, and neither of the above
can happen. The result is that users created via dh-sysuser are never
deleted.

Additionally, the call to rmdir needs to be guarded by a check for
the /nonexistent scenario, just like the use of --create-home is for
the postinst part, because it will result in a script failure
otherwise:

  $ sudo rmdir --ignore-fail-on-non-empty /nonexistent
  rmdir: failed to remove '/nonexistent': No such file or directory
  $ echo $?
  1
  $

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1000476: lintian: autopkgtest regression: autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/binaries/corrupted/legacy-debug/generic.t

[Felix Lechner]

Control: tags -1 + pending

Hi,

Thanks for this message.

On Tue, Nov 23, 2021 at 12:48 PM Paul Gevers  wrote:
>
> ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/odd-inputs/strings-elf-detection/generic.t

That test was already dropped from Lintian. [1]

> ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/binaries/corrupted/legacy-debug/generic.t

That test was adjusted for recent versions of Binutils. [2]

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/commit/deba665363a3dd4da8b806df07091c9c482206d7
[2] 
https://salsa.debian.org/lintian/lintian/-/commit/c16b75a7547e547a13a1f1add4d80bb72e16c361

Bug#999777: 6.3-1 breaks scrolling in neovim on gnome-terminal with vertical splits

[Sven Joachim]

Control: block -1 by 999871

On 2021-11-18 20:15 +0100, Sven Joachim wrote:

> On 2021-11-17 20:21 -0500, Thomas Dickey wrote:
>
>> Since the feature was already present in a different form,
>> it seems that neovim is the only widespread user of this.
>
> Quite likely.
>
>>> I am not quite sure what to do with this in ncurses.  As long as the
>>> problem only affects neovim and VTE based terminal emulators I am
>>> inclined to ignore it, but if it turns out to be more widespread I could
>>> back out the new feature, like I did in #933053.
>>
>> I don't see that it's necessary.
>
> Yes, I think a versioned Breaks against neovim should be sufficient,
> once a fixed neovim package is available.

A fixed neovim has been requested by Josh in #999871 (a clone of this
bug), adding that one as a blocker.

Cheers,
   Sven

Bug#996780: gnome-boxes: Systematic system freeze few seconds after launching a Windows WM

[Mathieu R.]

i'm not, i'm using intel drivers

Le sam. 20 nov. 2021, 18 h 43, Gunnar Hjalmarsson  a
écrit :

> Are you possibly using a NVIDIA driver? Asking because of this:
>
> https://github.com/NVIDIA/egl-wayland/issues/27#issuecomment-951725683
>
> --
> Cheers,
> Gunnar Hjalmarsson
>

Bug#997959: git-annex: FTBFS on 32-bit ARM architectures, but built successfully before

[Nilesh Patra]

Hi Sean, Richard,

On Wed, 27 Oct 2021 12:20:04 -0700 Sean Whitton  
wrote:
> Source: git-annex
> Version: 8.20210223-2
> Severity: serious
> git-annex recently began to FTBFS on 32-bit ARM architectures, and I am
> not really in a position atm to dig deeply into the problem.
> [.. log ..]

This bug is now triggering removals of its reverse-dependencies.
Would you (or any list member) have some bandwidth to take a deeper look into 
this?

Let me know.

Regards,
Nilesh


signature.asc
Description: PGP signature

Bug#1000477: bullseye-pu: package gmp/2:6.2.1+dfsg-1+deb11u1

[Anton Gladky]

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


Dear release team,

I have prepared a fix for bullseye, fixing CVE-2021-43618.
The fix was also successfully fixed in unstable and testing.
Gitlab-CI is employed for the package testing. Diff is aattached.

[ Checklist ]
 [x] *all* changes are documented in the d/changelog
 [x] I reviewed all changes and I approve them
 [x] attach debdiff against the package in (old)stable
 [x] the issue is verified as fixed in unstable

Thanks

Anton
diff -Nru gmp-6.2.1+dfsg/debian/changelog gmp-6.2.1+dfsg/debian/changelog
--- gmp-6.2.1+dfsg/debian/changelog 2020-11-15 19:04:37.0 +0100
+++ gmp-6.2.1+dfsg/debian/changelog 2021-11-23 21:37:19.0 +0100
@@ -1,3 +1,10 @@
+gmp (2:6.2.1+dfsg-1+deb11u1) bullseye; urgency=medium
+
+  * [ba91bc2] Add .gitlab-ci.yml
+  * [a848ad6] Avoid bit size overflows. CVE-2021-43618
+
+ -- Anton Gladky   Tue, 23 Nov 2021 21:37:19 +0100
+
 gmp (2:6.2.1+dfsg-1) unstable; urgency=medium
 
   [ Steve Robbins ]
diff -Nru gmp-6.2.1+dfsg/debian/.gitlab-ci.yml 
gmp-6.2.1+dfsg/debian/.gitlab-ci.yml
--- gmp-6.2.1+dfsg/debian/.gitlab-ci.yml1970-01-01 01:00:00.0 
+0100
+++ gmp-6.2.1+dfsg/debian/.gitlab-ci.yml2021-11-23 21:31:26.0 
+0100
@@ -0,0 +1,6 @@
+include:
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml
+variables:
+  RELEASE: 'bullseye'
+  SALSA_CI_DISABLE_REPROTEST: 1
+  SALSA_CI_DISABLE_BLHC: 1
diff -Nru gmp-6.2.1+dfsg/debian/patches/CVE-2021-43618.patch 
gmp-6.2.1+dfsg/debian/patches/CVE-2021-43618.patch
--- gmp-6.2.1+dfsg/debian/patches/CVE-2021-43618.patch  1970-01-01 
01:00:00.0 +0100
+++ gmp-6.2.1+dfsg/debian/patches/CVE-2021-43618.patch  2021-11-23 
21:36:27.0 +0100
@@ -0,0 +1,25 @@
+# Origin: https://gmplib.org/repo/gmp-6.2/rev/561a9c25298e
+# HG changeset patch
+# User Marco Bodrato 
+# Date 1634836009 -7200
+# Node ID 561a9c25298e17bb01896801ff353546c6923dbd
+# Parent  e1fd9db13b475209a864577237ea4b9105b3e96e
+mpz/inp_raw.c: Avoid bit size overflows
+
+Index: gmp/mpz/inp_raw.c
+===
+--- gmp.orig/mpz/inp_raw.c
 gmp/mpz/inp_raw.c
+@@ -88,8 +88,11 @@ mpz_inp_raw (mpz_ptr x, FILE *fp)
+ 
+   abs_csize = ABS (csize);
+ 
++  if (UNLIKELY (abs_csize > ~(mp_bitcnt_t) 0 / 8))
++return 0; /* Bit size overflows */
++
+   /* round up to a multiple of limbs */
+-  abs_xsize = BITS_TO_LIMBS (abs_csize*8);
++  abs_xsize = BITS_TO_LIMBS ((mp_bitcnt_t) abs_csize * 8);
+ 
+   if (abs_xsize != 0)
+ {
diff -Nru gmp-6.2.1+dfsg/debian/patches/series 
gmp-6.2.1+dfsg/debian/patches/series
--- gmp-6.2.1+dfsg/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ gmp-6.2.1+dfsg/debian/patches/series2021-11-15 22:20:32.0 
+0100
@@ -0,0 +1 @@
+CVE-2021-43618.patch

Bug#1000476: lintian: autopkgtest regression: autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/binaries/corrupted/legacy-debug/generic.t

[Paul Gevers]

Source: lintian
Version: 2.113.0
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
lintianfrom testing2.113.0
all others from testingfrom testing

I copied some of the output at the bottom of this report.

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


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/armhf/l/lintian/16912872/log.gz

../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/tracking/generic-dh-make-2008/generic.t 
 ok
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/lintian-features/lintian-suppress-tags/generic.t 
... ok

# Literal output does not match
# # --- 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/odd-inputs/strings-elf-detection/literal
# +++ 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/odd-inputs/strings-elf-detection/literal.actual.parsed
# +W: strings-elf-detection-dbgsym: elf-error In program headers: Unable 
to find program interpreter name 
[usr/lib/debug/.build-id/45/e1c08eeb668890993873e92eb9c047c87cfb25.debug]

# #   Failed test 'Lintian passes for strings-elf-detection'
#   at /usr/share/lintian/lib/Test/Lintian/Run.pm line 341.
# Looks like you failed 1 test of 1.
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/odd-inputs/strings-elf-detection/generic.t 
. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/runner-features/runtests-options/generic.t 
. ok
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/tracking/generic-dh-make-2005/generic.t 
 ok
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/lintian-features/lintian-display-level/generic.t 
... ok
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/runner-features/runtests-calibration/generic.t 
. ok


Test Summary Report
---
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/binaries/corrupted/legacy-debug/generic.t 
(Wstat: 256 
Tests: 1 Failed: 1)

  Failed test:  1
  Non-zero exit status: 1
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/odd-inputs/strings-elf-detection/generic.t 


(Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=1447, Tests=62792, 303 wallclock secs (11.66 usr 23.72 sys + 
4309.74 cusr 32394.30 csys = 36739.42 CPU)

Result: FAIL

The test suite ran for 5 minutes and 4 seconds.

autopkgtest [00:18:34]: test build-and-evaluate-test-packages




OpenPGP_signature
Description: OpenPGP digital signature

Bug#995471: I would be great to have virt-top available on bullseye

[BW]

I agree, please add virt-top to stable or backport

Bug#1000475: minimac4: autopkgtest regression: *** stack smashing detected ***: terminated

[Paul Gevers]

Source: minimac4
Version: 1.0.2-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
minimac4   from testing1.0.2-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. Similar to bug 
#1000413 I think this issue points at ABI breakage. The following in the 
changelog looks very suspicious:

   * Rebuild minimac4 against new version of libstatgen
This is a hint. The test passes in unstable.

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


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/m/minimac4/16920779/log.gz




 
  Minimac4 - Fast Imputation Based on State Space Reduction HMM



   (c) 2014 - Sayantan Das, Christian Fuchsberger, David Hinds
 Mary Kate Wing, Goncalo Abecasis
 Version: 1.0.2;
 Built: 2021-11-11 by Reproducible

 Command Line Options:Reference Haplotypes : --refHaps 
[refPanel.m3vcf.gz], --passOnly,

  --rsid, --referenceEstimates [ON],
  --mapFile 
[docs/geneticMapFile.b38.map.txt.gz]

  Target Haplotypes : --haps [targetStudy.vcf.gz]
  Output Parameters : --prefix [testRun], --estimate, --nobgzip,
  --vcfBuffer [200], --format [GT,DS],
  --allTypedSites, --meta, --memUsage
Chunking Parameters : --ChunkLengthMb [20.00], --ChunkOverlapMb 
[3.00]

  Subset Parameters : --chr [], --start, --end, --window
   Approximation Parameters : --minimac3, --probThreshold [0.01],
  --diffThreshold [0.01], --topThreshold [0.01]
   Other Parameters : --log, --help, --cpus [5], --params
  PhoneHome : --noPhoneHome [ON], --phoneHomeThinning [50]


 URL = http://genome.sph.umich.edu/wiki/Minimac4
 Starting Main Imputation/Estimation Analysis ...
 Performing preliminary check on input parameters...

--
 PRELIMINARY FILE CHECK 


--

 Checking GWAS haplotype file : targetStudy.vcf.gz

 Gathering variant information ...


 ERROR !!!  Empty Value for Individual : TA98 at First Marker   Most 
probably a corrupted VCF file. Please check input VCF file !!! *** stack 
smashing detected ***: terminated

Aborted
autopkgtest [07:10:54]: test run-sample-analysis




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000452: please consider adding a warning for changelog in the past

[Felix Lechner]

Hi Marc,

On Tue, Nov 23, 2021 at 11:12 AM Marc Haber
 wrote:
>
> The archive rejecting the upload might be see a bit hostile
> (at least that's how my subconsciousness usually reacts

Are you sure? Maybe your subconscious would have preferred a
rejection. At a minimum, you are wishing for some kind of improvement.

Lintian already does other things, such as checking that your most
recent timestamp postdates the release date of the policy version with
which the sources declare compliance [1] but that would not have
caught gensio, which I think is the package you uploaded.

Kind regards
Felix Lechner

[1] https://lintian.debian.org/tags/timewarp-standards-version

Bug#992927: mutt: Mutt 2.1.2 is available, fixing a potential data-loss IMAP bug

[Kevin J. McCarthy]

On Tue, Nov 23, 2021 at 08:45:47PM +0100, Hannes von Haugwitz wrote:

Is there any progress with this bug?


Mutt 2.1.3 included the corrected sort commit referenced in my last 
email.  So, for unstable/testing it would be nice to get 2.1.3 uploaded.


For stable/oldstable I guess it rests in the hands of Debian process, 
but ideally the three links from my last email would be backported to 
those.


-Kevin

Bug#1000474: icingaweb2: Does not work with PHP 8.1

[Bas Couwenberg]

Source: icingaweb2
Version: 2.9.5-1
Severity: important
Tags: upstream
Control: forwarded -1 https://github.com/Icinga/icingaweb2/issues/4609
Control: block 976811 by -1

Dear Maintainer,

icingaweb2 does not work with php8.1 from experimental.

The web page shows lots of deprecations and a fatal error:

 Deprecated: Return type of Icinga\Application\Libraries::getIterator() should 
either be compatible with IteratorAggregate::getIterator(): Traversable, or the 
#[\ReturnTypeWillChange] attribute should be used to temporarily suppress the 
notice in /usr/share/php/Icinga/Application/Libraries.php on line 20
 
 Deprecated: Return type of Icinga\Application\Config::count() should either be 
compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] 
attribute should be used to temporarily suppress the notice in 
/usr/share/php/Icinga/Application/Config.php on line 125
 
 Deprecated: Return type of Icinga\Application\Config::current() should either 
be compatible with Iterator::current(): mixed, or the #[\ReturnTypeWillChange] 
attribute should be used to temporarily suppress the notice in 
/usr/share/php/Icinga/Application/Config.php on line 145
 
 Deprecated: Return type of Icinga\Application\Config::next() should either be 
compatible with Iterator::next(): void, or the #[\ReturnTypeWillChange] 
attribute should be used to temporarily suppress the notice in 
/usr/share/php/Icinga/Application/Config.php on line 175
 
 Deprecated: Return type of Icinga\Application\Config::key() should either be 
compatible with Iterator::key(): mixed, or the #[\ReturnTypeWillChange] 
attribute should be used to temporarily suppress the notice in 
/usr/share/php/Icinga/Application/Config.php on line 165
 
 Deprecated: Return type of Icinga\Application\Config::valid() should either be 
compatible with Iterator::valid(): bool, or the #[\ReturnTypeWillChange] 
attribute should be used to temporarily suppress the notice in 
/usr/share/php/Icinga/Application/Config.php on line 155
 
 Deprecated: Return type of Icinga\Application\Config::rewind() should either 
be compatible with Iterator::rewind(): void, or the #[\ReturnTypeWillChange] 
attribute should be used to temporarily suppress the notice in 
/usr/share/php/Icinga/Application/Config.php on line 135
 
 Deprecated: Return type of Icinga\Web\Session\SessionNamespace::getIterator() 
should either be compatible with IteratorAggregate::getIterator(): Traversable, 
or the #[\ReturnTypeWillChange] attribute should be used to temporarily 
suppress the notice in /usr/share/php/Icinga/Web/Session/SessionNamespace.php 
on line 35
 
 Deprecated: Return type of 
Zend_Controller_Action_HelperBroker_PriorityStack::getIterator() should either 
be compatible with IteratorAggregate::getIterator(): Traversable, or the 
#[\ReturnTypeWillChange] attribute should be used to temporarily suppress the 
notice in 
/usr/share/icingaweb2/library/vendor/Zend/Controller/Action/HelperBroker/PriorityStack.php
 on line 91
 
 Deprecated: Return type of 
Zend_Controller_Action_HelperBroker_PriorityStack::offsetExists($priorityOrHelperName)
 should either be compatible with ArrayAccess::offsetExists(mixed $offset): 
bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily 
suppress the notice in 
/usr/share/icingaweb2/library/vendor/Zend/Controller/Action/HelperBroker/PriorityStack.php
 on line 102
 
 Deprecated: Return type of 
Zend_Controller_Action_HelperBroker_PriorityStack::offsetGet($priorityOrHelperName)
 should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, 
or the #[\ReturnTypeWillChange] attribute should be used to temporarily 
suppress the notice in 
/usr/share/icingaweb2/library/vendor/Zend/Controller/Action/HelperBroker/PriorityStack.php
 on line 117
 
 Deprecated: Return type of 
Zend_Controller_Action_HelperBroker_PriorityStack::offsetSet($priority, 
$helper) should either be compatible with ArrayAccess::offsetSet(mixed $offset, 
mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used 
to temporarily suppress the notice in 
/usr/share/icingaweb2/library/vendor/Zend/Controller/Action/HelperBroker/PriorityStack.php
 on line 137
 
 Deprecated: Return type of 
Zend_Controller_Action_HelperBroker_PriorityStack::offsetUnset($priorityOrHelperName)
 should either be compatible with ArrayAccess::offsetUnset(mixed $offset): 
void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily 
suppress the notice in 
/usr/share/icingaweb2/library/vendor/Zend/Controller/Action/HelperBroker/PriorityStack.php
 on line 173
 
 Deprecated: Return type of 
Zend_Controller_Action_HelperBroker_PriorityStack::count() should either be 
compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] 
attribute should be used to temporarily suppress the notice in 
/usr/share/icingaweb2/library/vendor/Zend/Controller/Action/HelperBroker/PriorityStack.php
 on line 198
 
 Deprecated: Return type of 
Zend_View_Helper_Placeh

Bug#1000473: buster-pu: package gmp/gmp_6.1.2+dfsg-4+deb10u1

[Anton Gladky]

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


Dear release team,

I have prepared a fix for buster, fixing CVE-2021-43618.
The fix was also successfully fixed in unstable and testing.
Gitlab-CI is employed for the package testing. Diff is applied.
Thanks

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

Thanks

Anton
diff -Nru gmp-6.1.2+dfsg/debian/changelog gmp-6.1.2+dfsg/debian/changelog
--- gmp-6.1.2+dfsg/debian/changelog 2018-12-02 07:39:34.0 +0100
+++ gmp-6.1.2+dfsg/debian/changelog 2021-11-23 21:09:08.0 +0100
@@ -1,3 +1,10 @@
+gmp (2:6.1.2+dfsg-4+deb10u1) buster; urgency=medium
+
+  * [1f4ce6d] Add .gitlab-ci.yml
+  * [df6d314] Avoid bit size overflows. CVE-2021-43618
+
+ -- Anton Gladky   Tue, 23 Nov 2021 21:09:08 +0100
+
 gmp (2:6.1.2+dfsg-4) unstable; urgency=medium
 
   * Team Upload.
diff -Nru gmp-6.1.2+dfsg/debian/.gitlab-ci.yml 
gmp-6.1.2+dfsg/debian/.gitlab-ci.yml
--- gmp-6.1.2+dfsg/debian/.gitlab-ci.yml1970-01-01 01:00:00.0 
+0100
+++ gmp-6.1.2+dfsg/debian/.gitlab-ci.yml2021-11-23 21:04:00.0 
+0100
@@ -0,0 +1,6 @@
+include:
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml
+variables:
+  RELEASE: 'buster'
+  SALSA_CI_DISABLE_REPROTEST: 1
+  SALSA_CI_DISABLE_BLHC: 1
diff -Nru gmp-6.1.2+dfsg/debian/patches/CVE-2021-43618.patch 
gmp-6.1.2+dfsg/debian/patches/CVE-2021-43618.patch
--- gmp-6.1.2+dfsg/debian/patches/CVE-2021-43618.patch  1970-01-01 
01:00:00.0 +0100
+++ gmp-6.1.2+dfsg/debian/patches/CVE-2021-43618.patch  2021-11-23 
21:06:22.0 +0100
@@ -0,0 +1,25 @@
+# Origin: https://gmplib.org/repo/gmp-6.2/rev/561a9c25298e
+# HG changeset patch
+# User Marco Bodrato 
+# Date 1634836009 -7200
+# Node ID 561a9c25298e17bb01896801ff353546c6923dbd
+# Parent  e1fd9db13b475209a864577237ea4b9105b3e96e
+mpz/inp_raw.c: Avoid bit size overflows
+
+Index: gmp/mpz/inp_raw.c
+===
+--- gmp.orig/mpz/inp_raw.c
 gmp/mpz/inp_raw.c
+@@ -89,8 +89,11 @@ mpz_inp_raw (mpz_ptr x, FILE *fp)
+ 
+   abs_csize = ABS (csize);
+ 
++  if (UNLIKELY (abs_csize > ~(mp_bitcnt_t) 0 / 8))
++return 0; /* Bit size overflows */
++
+   /* round up to a multiple of limbs */
+-  abs_xsize = BITS_TO_LIMBS (abs_csize*8);
++  abs_xsize = BITS_TO_LIMBS ((mp_bitcnt_t) abs_csize * 8);
+ 
+   if (abs_xsize != 0)
+ {
diff -Nru gmp-6.1.2+dfsg/debian/patches/series 
gmp-6.1.2+dfsg/debian/patches/series
--- gmp-6.1.2+dfsg/debian/patches/series2018-12-02 07:39:27.0 
+0100
+++ gmp-6.1.2+dfsg/debian/patches/series2021-11-23 21:06:09.0 
+0100
@@ -1 +1,2 @@
 gmp-exception-sigfpe.patch
+CVE-2021-43618.patch

Bug#1000255: mpv: autopkgtest failures

[Sebastian Ramacher]

Control: reassign -1 src:python-mpv 0.5.2-1
Control: forwarded -1 https://github.com/jaseg/python-mpv/issues/187

On 2021-11-21 23:21:24, Sebastian Ramacher wrote:
> Control: tags -1 help
> 
> On 2021-11-20 09:34:37 +0100, Gianfranco Costamagna wrote:
> > Source: mpv
> > Version: 0.34.0-1
> > Severity: serious
> > 
> > 
> > Hello, the last version 0.34.0 is regressed on arm64 armhf and probably 
> > other architectures.
> > 
> > Look, e.g.
> > https://ci.debian.net/data/autopkgtest/testing/arm64/p/python-mpv/16812363/log.gz
> > 
> > (Reading database ... 16518 files and directories currently installed.)
> > Removing autopkgtest-satdep (0) ...
> > autopkgtest [18:11:22]: test unittests: [---
> > === python3.9 ===
> > Segmentation fault
> > autopkgtest [18:11:43]: test unittests: ---]
> > autopkgtest [18:11:43]: test unittests:  - - - - - - - - - - results - - - 
> > - - - - - - -
> > unittestsFAIL non-zero exit status 139
> > autopkgtest [18:11:43]:  summary
> > unittestsFAIL non-zero exit status 139
> > 
> > I don't know which update triggered the regression, if the program itself 
> > or something else in the toolchain.
> > 
> > Can you please have a look?
> > 
> > https://ci.debian.net/packages/p/python-mpv/testing/arm64/
> 
> The failing test is test_write. It crashes due to an infinte recursion
> in libx11-6's XPutImage which calls PutSubImage:
> 
> #0  0xf4f3e31c in PutSubImage (dpy=dpy@entry=0x5776b8, d=d@entry=2097154, 
> gc=gc@entry=0x5a01e0, image=image@entry=0x5a2ca8, req_xoffset=0, 
> req_yoffset=req_yoffset@entry=0, x=0, y=y@entry=0, req_width=2096928, 
> req_height=req_height@entry=1, 
> dest_bits_per_pixel=dest_bits_per_pixel@entry=32, 
> dest_scanline_pad=dest_scanline_pad@entry=32) at ../../src/PutImage.c:878
> #1  0xf4f3e7a4 in PutSubImage (dpy=dpy@entry=0x5776b8, d=d@entry=2097154, 
> gc=gc@entry=0x5a01e0, image=image@entry=0x5a2ca8, req_xoffset=0, 
> req_yoffset=req_yoffset@entry=0, x=0, y=y@entry=0, req_width=2096928, 
> req_height=req_height@entry=1, 
> dest_bits_per_pixel=dest_bits_per_pixel@entry=32, 
> dest_scanline_pad=dest_scanline_pad@entry=32) at ../../src/PutImage.c:920
> #2  0xf4f3e7a4 in PutSubImage (dpy=dpy@entry=0x5776b8, d=d@entry=2097154, 
> gc=gc@entry=0x5a01e0, image=image@entry=0x5a2ca8, req_xoffset=0, 
> req_yoffset=req_yoffset@entry=0, x=0, y=y@entry=0, req_width=2096928, 
> req_height=req_height@entry=1, 
> dest_bits_per_pixel=dest_bits_per_pixel@entry=32, 
> dest_scanline_pad=dest_scanline_pad@entry=32) at ../../src/PutImage.c:920
> #3  0xf4f3e7a4 in PutSubImage (dpy=dpy@entry=0x5776b8, d=d@entry=2097154, 
> gc=gc@entry=0x5a01e0, image=image@entry=0x5a2ca8, req_xoffset=0, 
> req_yoffset=req_yoffset@entry=0, x=0, y=y@entry=0, req_width=2096928, 
> req_height=req_height@entry=1, 
> dest_bits_per_pixel=dest_bits_per_pixel@entry=32, 
> dest_scanline_pad=dest_scanline_pad@entry=32) at ../../src/PutImage.c:920
> #4  0xf4f3e7a4 in PutSubImage (dpy=dpy@entry=0x5776b8, d=d@entry=2097154, 
> gc=gc@entry=0x5a01e0, image=image@entry=0x5a2ca8, req_xoffset=0, 
> req_yoffset=req_yoffset@entry=0, x=0, y=y@entry=0, req_width=2096928, 
> req_height=req_height@entry=1, 
> dest_bits_per_pixel=dest_bits_per_pixel@entry=32, 
> dest_scanline_pad=dest_scanline_pad@entry=32) at ../../src/PutImage.c:920
> #5  0xf4f3e7a4 in PutSubImage (dpy=dpy@entry=0x5776b8, d=d@entry=2097154, 
> gc=gc@entry=0x5a01e0, image=image@entry=0x5a2ca8, req_xoffset=0, 
> req_yoffset=req_yoffset@entry=0, x=0, y=y@entry=0, req_width=2096928, 
> req_height=req_height@entry=1, 
> dest_bits_per_pixel=dest_bits_per_pixel@entry=32, 
> dest_scanline_pad=dest_scanline_pad@entry=32) at ../../src/PutImage.c:920
> #6  0xf4f3e7a4 in PutSubImage (dpy=dpy@entry=0x5776b8, d=d@entry=2097154, 
> gc=gc@entry=0x5a01e0, image=image@entry=0x5a2ca8, req_xoffset=0, 
> req_yoffset=req_yoffset@entry=0, x=0, y=y@entry=0, req_width=2096928, 
> req_height=req_height@entry=1, 
> dest_bits_per_pixel=dest_bits_per_pixel@entry=32, 
> dest_scanline_pad=dest_scanline_pad@entry=32) at ../../src/PutImage.c:920
> #7  0xf4f3e7a4 in PutSubImage (dpy=dpy@entry=0x5776b8, d=d@entry=2097154, 
> gc=gc@entry=0x5a01e0, image=image@entry=0x5a2ca8, req_xoffset=0, 
> req_yoffset=req_yoffset@entry=0, x=0, y=y@entry=0, req_width=2096928, 
> req_height=req_height@entry=1, 
> dest_bits_per_pixel=dest_bits_per_pixel@entry=32, 
> dest_scanline_pad=dest_scanline_pad@entry=32) at ../../src/PutImage.c:920
> #8  0xf4f3e7a4 in PutSubImage (dpy=dpy@entry=0x5776b8, d=d@entry=2097154, 
> gc=gc@entry=0x5a01e0, image=image@entry=0x5a2ca8, req_xoffset=0, 
> req_yoffset=req_yoffset@entry=0, x=0, y=y@entry=0, req_width=2096928, 
> req_height=req_height@entry=1, 
> dest_bits_per_pixel=dest_bits_per_pixel@entry=32, 
> dest_scanline_pad=dest_scanline_pad@entry=32) at ../../src/PutImage.c:920
> #9  0x

Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1

[Roberto C. Sanchez]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

SRM,

In preparing the rustc 1.51 upload/backport (to support backports of the
latest firefox-esr and thunderbird packages) it has been suggested that
to avoid some issues associated with providing a significant new version
of rustc in the rustc binary package (along with the associated library
packages), that I prepare the 1.51 rustc package with a different name.
Following the model of what was done for gcc, nasm, and nodejs, I was
considering source package rustc-mozilla with a single binary package
(also rustc-mozilla) to ensure that rdeps don't end up getting surprised
by a new rustc.  Would this be considered acceptable for the bullseye
and buster uploads of rustc 1.51?

(I intend to file a separate bug for buster-pu once I receive some
direction via this bug.)

Regards,

- -Roberto


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEz9ERzDttUsU/BH8iLNd4Xt2nsg8FAmGdTOEACgkQLNd4Xt2n
sg+m+Q/7BN5tycR2w/9DjyOIHAlC/rrOOfsJraa1gORDKf5pT9GMk7J3oJanKLOI
YsWSUlC1a+4anQWGhGE+IMz50r5U01hZ7JhdnJhcSiLv+18gWY5LZB0fgbO/TvRG
2C95uubCYAePg7TTOd9fQRhuEBCgh+h0R+jN8EdNlJRRfEGZ7pkYQ3YOlkVJYztU
LQjWALZiMBbsh9ZxVq/zvys5nD2CO326M3PILGOFyqp/GFWrraEpppQlcjEqjemv
v7ygEzDvSJasv0AMAVIbQGrWWO/UeqMPAcwOVR0JGhz/06gDXxr5ubV53RbuhSai
Nwub60JaufIhm6clvbMmto+w0tTyeIM9IGTgyQq1j7ah9belvK43Rx2lScnfs+4c
kimppFDI4xei4aMzct+3/RgSBsijibH2cWfIPwiH6R8PuBZRDglAEaABsmT08WrS
EpVmT9gO+7Bkqo+v7uysvLQYlJ0R14WC4VB/yoWJSwmIqAg3yuHhdmJtSYbehFuA
Y5fKNwg4/hAvdTLwU9s9Q+cCEId2RWbnIKyS0wNgEStNTe12ue9P7POSFKGnXLGx
sVo4bg8FG+U2sJ12P0nVrRdxGT/OuKjqp5PpZZ+JF00sqKEArqkiphMiwnnkCnUD
k1YcSIn+E0xh+k8+GK1NxkJX8V9Vsteoba34SqadJ6LRvBF3Lz0=
=i90C
-END PGP SIGNATURE-

Bug#1000471: glewlwyd FTBFS can't find functions.

[peter green]

Package: glewlwyd
Version: 2.5.2-3
Severity: serious
Tags: ftbfs

Unfortunately it seems that even after the cross-fetch fix, glewlwyd still 
FTBFS as a
result of changes in iddawc/rhonabwy.


/usr/bin/cc -D_GNU_SOURCE -Dschememodoauth2_EXPORTS -I/include -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Werror -fPIC -Wextra -std=gnu99 -MD -MT 
CMakeFiles/schememodoauth2.dir/src/scheme/oauth2.c.o -MF 
CMakeFiles/schememodoauth2.dir/src/scheme/oauth2.c.o.d -o 
CMakeFiles/schememodoauth2.dir/src/scheme/oauth2.c.o -c /<>/src/scheme/oauth2.c
/<>/src/scheme/oauth2.c: In function 'complete_session_identify':
/<>/src/scheme/oauth2.c:265:32: error: implicit declaration of 
function 'i_load_userinfo'; did you mean 'i_get_userinfo'? 
[-Werror=implicit-function-declaration]
  265 | if ((res = i_load_userinfo(&i_session)) == I_OK && 
i_session.j_userinfo != NULL) {
  |^~~
  |i_get_userinfo
/<>/src/scheme/oauth2.c: In function 
'user_auth_scheme_module_init':
/<>/src/scheme/oauth2.c:1197:28: error: implicit declaration of 
function 'i_load_openid_config'; did you mean 'i_get_openid_config'? 
[-Werror=implicit-function-declaration]
 1197 | } else if (i_load_openid_config(&i_session) != I_OK) {
  |^~~~
  |i_get_openid_config
make  -f CMakeFiles/protocol_oidc.dir/build.make 
CMakeFiles/protocol_oidc.dir/depend

<---snip>

/usr/bin/cc -D_GNU_SOURCE -Dprotocol_register_EXPORTS -I/include -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Werror -fPIC -Wextra -std=gnu99 -MD -MT 
CMakeFiles/protocol_register.dir/src/plugin/register.c.o -MF 
CMakeFiles/protocol_register.dir/src/plugin/register.c.o.d -o 
CMakeFiles/protocol_register.dir/src/plugin/register.c.o -c 
/<>/src/plugin/register.c
/<>/src/plugin/protocol_oidc.c: In function 'check_parameters':
/<>/src/plugin/protocol_oidc.c:272:45: error: implicit declaration 
of function 'r_jwks_import_from_str'; did you mean 'r_jwks_import_from_uri'? 
[-Werror=implicit-function-declaration]
  272 | if (r_jwks_init(&jwks) != RHN_OK || r_jwks_import_from_str(jwks, 
json_string_value(json_object_get(j_params, "jwks-public"))) != RHN_OK) {
  | ^~
  | r_jwks_import_from_uri


I initially saw this on a raspbian bookworm-staging autobuilder, but I was also 
able to reproduce
it in a Debian sid chroot.

I found upstream patches fixing the above errors and applied them in raspbian 
bookworm-staging,
I also imported the cross-fetch fix into raspbian bookworm-staging from Debian 
sid. After doing
so I was able to get a successful build of glewlwyd. A debdiff should appear 
soon at
https://debdiffs.raspbian.org/main/g/glewlwyd

P.S. The cross-fetch fix also seems to be blocked from migrating to debian 
testing as a result
of an autopkgtest failure.

Bug#976603: Dropping fcitx4/5 coexistence

[Boyuan Yang]

Hi,

在 2021-11-23星期二的 13:38 +0100，Gunnar Hjalmarsson写道：
> On 2021-11-23 13:03, Gunnar Hjalmarsson wrote:
> > Looks like you can breathe a sigh of relief, Boyuan. ;)
> 
> Or not. I just run a package upgrade on Ubuntu's development version, 
> where both fcitx5 and fcitx4 are installed, and "apt full-upgrade" 
> resulted in the fcitx5 package being uninstalled.
> 
> Do the fcitx4 packages need to conflict with fcitx5, and not the other 
> way around?

I just uploaded fcitx/1:4.2.9.8-4 to add mutual conflict. The outcome of
uninstalling fcitx5 during "apt full-upgrade" (even with mutual conflict) is
somehow an undefined behavior of dependency resolver: when I use apt, it
suggests to uninstall fcitx5; when I use aptitude, the first solution is to
uninstall fcitx4. The end user will have to decide which fcitx to keep.

I believe there will be no more abrupt changes around fcitx4/5 beyond conflict
relationship before Ubuntu 22.04 release. Of course, the current one will need
to be tested by the Ubuntu Kylin side.

handsome_feng: let me know if any change is needed. The last resort would be
rolling back to the previous condition where mutual conflict does not exist,
and I hope that you can find a better solution than it.

Thanks,
Boyuan Yang

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Paul Gevers]

Hi Ondřej,

On 23-11-2021 11:52, Ondřej Surý wrote:

On 22. 11. 2021, at 22:28, David Prévot  wrote:

I’m happy to upload it if you or the release team agree. I don’t
mind if the transition gets started right now either (even if we
have no proper php8.1 as default in experimental to get a grasp of
expected issues). >

I’ve just uploaded a version with your fix.


Thanks a lot.


David, can we now agree on a timeframe when we start the transition?


As a Release Team member I value the input from David on this matter, 
but it's not up to him to decide. That said, I'd love the PHP community 
in Debian (I assume I can take Debian PHP Maintainers + Debian PHP PEAR 
Maintainers for that, please correct me if I'm wrong) to align on a 
transition plan and share that with us. As a Release Team member, I'd 
like to see a plan (maybe I outlined it below already) where we can hope 
for a reasonable short time where php-defaults in unstable and testing 
are out of sync. Practically that means that most of the issues need to 
be identified, and sufficient progress needs to be made, *before* the 
upload to unstable, which starts the transition. We can remove some 
packages where progress isn't reasonably achievable in a timely matter, 
but we can't remove half the reverse dependencies of php.


Experimental is the ideal place to find that out. I does require 
somebody to go through the regressions and file bug though, this doesn't 
happen magically. I think David offered help there. I (Release Team 
member hat *off*) am willing to help a bit too. I welcome everybody to 
file issues related to switching from php7.4 to php8.1 and add a block 
on this bug. That way, we can generate a good overview of where we 
stand. (The cacti issue seems to have been resolved with my latest 
upload; one issue down). David, I think you already said you wouldn't 
mind if the transition already started now, is that the stance of the 
Debian PHP PEAR Maintainers? How much of the broken reverse dependencies 
are outside that teams maintenance (approximately)?



And I would prefer if we roughly agree on a timeframe when we start
the transition to php8.2 - I can upload the 8.2.0~beta1 as soon as it
is ready upstream, so the ftp-masters have time, and keep uploading
rcN versions (this will usually take few months) and start the
transition right away when 8.2.0 is golden (December 2022). Would
that work?
The Release Team _very much_ welcomes staging/testing these things in 
experimental exactly as you propose. So by all means, upload early, 
including the relevant php-defaults too. Similar as for the current 
situation, if the amount of fall out has been identified, bugs filed and 
(most) solutions available we can go ahead. We can't commit to an ACK 
already (it really depends on the amount of open issues), but with the 
right preparation I'd say it's very doable. But it also depends a bit on 
the cooperation of the maintainers of your reverse dependencies and/or 
NMU actions. This takes time and coordination.


Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000469: no-code-sections shouldn't be an error

[Felix Lechner]

Hi Simon,

On Tue, Nov 23, 2021 at 11:36 AM Simon Josefsson  wrote:
>
> const char *some_public_variable = "foo";

Thanks for pointing that out.

> it seems to be about archives and not object files.

Thanks for pointing that out, too! How about we issue the tag only for
entire archives that contain no code, i.e. when there is no code in
any of the object files?

Kind regards
Felix Lechner

Bug#992927: mutt: Mutt 2.1.2 is available, fixing a potential data-loss IMAP bug

[Hannes von Haugwitz]

Hello,

Is there any progress with this bug?

Best regards

Hannes

Bug#1000470: RM: profphd -- ROM; Unmaintained upstream, unused and long pending RC bug

[Nilesh Patra]

Package: ftp.debian.org
Severity: normal

Please remove profphd from the archive. It has a long pending RC bug#942064
and upstream development has stopped.
The maintainer of the package (Andreas Tille) also ACK'd the removal, deets
on this thread[1]

[1]: https://lists.debian.org/debian-med/2021/11/msg00119.html

Regards,
Nilesh

Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")

[Christoph Biedl]

Julien Cristau wrote...

> Would you mind providing the old/new/proposed versions of http_parser.h?
> (this is me being lazy, sorry, if I'm being too much of a pain I can go
> and figure them out for myself, just let me know).

Not that much on my side, so find the files attached. The name for the
first (old version) might be a bit odd but this way tools meld "meld
*.h" will pick them in chronological order.

Christoph
/* Copyright Joyent, Inc. and other Node contributors. All rights reserved.
 *
 * Permission is hereby granted, free of charge, to any person obtaining a copy
 * of this software and associated documentation files (the "Software"), to
 * deal in the Software without restriction, including without limitation the
 * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
 * sell copies of the Software, and to permit persons to whom the Software is
 * furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be included in
 * all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
 * IN THE SOFTWARE.
 */
#ifndef http_parser_h
#define http_parser_h
#ifdef __cplusplus
extern "C" {
#endif

/* Also update SONAME in the Makefile whenever you change these. */
#define HTTP_PARSER_VERSION_MAJOR 2
#define HTTP_PARSER_VERSION_MINOR 8
#define HTTP_PARSER_VERSION_PATCH 1

#include 
#if defined(_WIN32) && !defined(__MINGW32__) && \
  (!defined(_MSC_VER) || _MSC_VER<1600) && !defined(__WINE__)
#include 
typedef __int8 int8_t;
typedef unsigned __int8 uint8_t;
typedef __int16 int16_t;
typedef unsigned __int16 uint16_t;
typedef __int32 int32_t;
typedef unsigned __int32 uint32_t;
typedef __int64 int64_t;
typedef unsigned __int64 uint64_t;
#else
#include 
#endif

/* Compile with -DHTTP_PARSER_STRICT=0 to make less checks, but run
 * faster
 */
#ifndef HTTP_PARSER_STRICT
# define HTTP_PARSER_STRICT 1
#endif

/* Maximium header size allowed. If the macro is not defined
 * before including this header then the default is used. To
 * change the maximum header size, define the macro in the build
 * environment (e.g. -DHTTP_MAX_HEADER_SIZE=). To remove
 * the effective limit on the size of the header, define the macro
 * to a very large number (e.g. -DHTTP_MAX_HEADER_SIZE=0x7fff)
 */
#ifndef HTTP_MAX_HEADER_SIZE
# define HTTP_MAX_HEADER_SIZE (80*1024)
#endif

typedef struct http_parser http_parser;
typedef struct http_parser_settings http_parser_settings;


/* Callbacks should return non-zero to indicate an error. The parser will
 * then halt execution.
 *
 * The one exception is on_headers_complete. In a HTTP_RESPONSE parser
 * returning '1' from on_headers_complete will tell the parser that it
 * should not expect a body. This is used when receiving a response to a
 * HEAD request which may contain 'Content-Length' or 'Transfer-Encoding:
 * chunked' headers that indicate the presence of a body.
 *
 * Returning `2` from on_headers_complete will tell parser that it should not
 * expect neither a body nor any futher responses on this connection. This is
 * useful for handling responses to a CONNECT request which may not contain
 * `Upgrade` or `Connection: upgrade` headers.
 *
 * http_data_cb does not return data chunks. It will be called arbitrarily
 * many times for each string. E.G. you might get 10 callbacks for "on_url"
 * each providing just a few characters more data.
 */
typedef int (*http_data_cb) (http_parser*, const char *at, size_t length);
typedef int (*http_cb) (http_parser*);


/* Status Codes */
#define HTTP_STATUS_MAP(XX) \
  XX(100, CONTINUE,Continue)\
  XX(101, SWITCHING_PROTOCOLS, Switching Protocols) \
  XX(102, PROCESSING,  Processing)  \
  XX(200, OK,  OK)  \
  XX(201, CREATED, Created) \
  XX(202, ACCEPTED,Accepted)\
  XX(203, NON_AUTHORITATIVE_INFORMATION,   Non-Authoritative Information)   \
  XX(204, NO_CONTENT,  No Content)  \
  XX(205, RESET_CONTENT,   Reset Content)   \
  XX(206, PARTIAL_CONTENT, Partial Content) \
  XX(207, MULTI_STATUS,Multi-Status)\
  XX(208, ALREADY_REPORTED,Alrea

Bug#1000452: please consider adding a warning for changelog in the past

[Marc Haber]

On Tue, Nov 23, 2021 at 05:13:35AM -0800, Felix Lechner wrote:
> Would it make more sense for 'dput' (or dupload) to issue the warning,
> or perhaps even for the archive to reject the upload?

I like the idea of dput, which would need to pull the changelog fragment
from the *.changes file since it doesn't unpack the package. The archive
rejecting the upload might be see a bit hostile (at least that's how my
subconsciousness usually reacts to ftpmaster rejections, even if they're
fully correct according to my rational part) to me.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#998057: transition: r-api-bioc-3.14

[Sebastian Ramacher]

Control: tags -1 = confirmed

On 2021-11-23 23:32:46, Nilesh Patra wrote:
> Hi Sebastian,
> 
> On Sun, 7 Nov 2021 17:46:56 +0100 Sebastian Ramacher  
> wrote:
> > > Hi,
> > > Bioconductor 3.14 was released [1].
> > > 
> > > [1] https://bioconductor.org/news/bioc_3_14_release/
> > > 
> > > Like for previous r-api-bioc transitions, all reverse dependencies
> > > need a manual upgrade to the new upstream releases, they are not
> > > binNMU-able. The Debian R Packages team will do so.
> > > 
> > > Please set up a tracker manually, since this is a transition of a
> > > virtual package name.
> > 
> > Let's do this one after gsl
> 
> Sorry to get on your nerves, but since it has been a little more than two 
> weeks since
> you sent this email, is there any update on gsl transition, or is it nearing 
> completion or so?
> Can bioc start sometime soon?

Please go ahead. If the two transitions need to be untangled, I'll
temporarily remove r-bioc-dirichletmultinomial and r-bioc-tfbstools from
testing.

Cheers

> 
> Let me know.
> 
> Regards,
> Nilesh



-- 
Sebastian Ramacher

Bug#959125: xdg-desktop-portal-gtk: does not provide implementations for org.freedesktop.impl.portal.{ScreenCast,RemoteDesktop}

[Jean-Marc]

hi Pedro,

On Wed, 29 Apr 2020 18:48:53 +0100 Simon McVittie  wrote:

Control: block -1 by 954022

On Wed, 29 Apr 2020 at 17:13:08 +0100, Pedro Ângelo wrote:
> looking upstream, there's an issue reported about xdg-desktop-portal-gtk not
> instantiating the ScreenCast and RemoteDesktop interfaces on Ubuntu

It needs a newer version of pipewire (see #954022).

> it seems to never return from the call to `createSession`

The error behaviour when not everything needed is available is also
not great (it should fail cleanly with an error rather than waiting
forever). I'm not sure whether that's an xdg-desktop-portal or
xdg-desktop-portal-gtk bug.

smcv


Simon said it needed a new pipewire version mentioning this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954022

This is fixed since 5/9/20.

Can you check if the bug persists ?

And close the bug if it is okay ?

Regards,

--
Jean-Marc


OpenPGP_signature
Description: OpenPGP digital signature

Bug#984166: hashdeep: diff for NMU version 4.4-7.1

[Adrian Bunk]

Control: tags 984166 + patch
Control: tags 984166 + pending

Dear maintainer,

I've prepared an NMU for hashdeep (versioned as 4.4-7.1) and uploaded
it to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru hashdeep-4.4/debian/changelog hashdeep-4.4/debian/changelog
--- hashdeep-4.4/debian/changelog	2021-02-02 18:41:47.0 +0200
+++ hashdeep-4.4/debian/changelog	2021-11-23 20:46:29.0 +0200
@@ -1,3 +1,10 @@
+hashdeep (4.4-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix for FTBFS with gcc 11. (Closes: #984166)
+
+ -- Adrian Bunk   Tue, 23 Nov 2021 20:46:29 +0200
+
 hashdeep (4.4-7) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru hashdeep-4.4/debian/patches/0001-Fix-errors-found-by-clang.patch hashdeep-4.4/debian/patches/0001-Fix-errors-found-by-clang.patch
--- hashdeep-4.4/debian/patches/0001-Fix-errors-found-by-clang.patch	1970-01-01 02:00:00.0 +0200
+++ hashdeep-4.4/debian/patches/0001-Fix-errors-found-by-clang.patch	2021-11-23 20:46:15.0 +0200
@@ -0,0 +1,32 @@
+From 6ef69a26126ee4e69a25392fd456b8a66c51dffd Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Tue, 15 Nov 2016 02:46:55 +
+Subject: Fix errors found by clang
+
+Fixes errors like
+
+../../git/src/hash.cpp:282:19: error: ordered comparison between pointer and zero ('const unsigned char *' and 'int')
+if(fdht->base>0){
+   ~~^~
+
+Signed-off-by: Khem Raj 
+---
+ src/hash.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/hash.cpp b/src/hash.cpp
+index 4216157..52f419b 100644
+--- a/src/hash.cpp
 b/src/hash.cpp
+@@ -279,7 +279,7 @@ void file_data_hasher_t::hash()
+ 		MAP_FILE|
+ #endif
+ 		MAP_SHARED,fd,0);
+-	if(fdht->base>0){		
++	if(fdht->base != (void *) -1){
+ 		/* mmap is successful, so set the bounds.
+ 		 * if it is not successful, we default to reading the fd
+ 		 */
+-- 
+2.20.1
+
diff -Nru hashdeep-4.4/debian/patches/series hashdeep-4.4/debian/patches/series
--- hashdeep-4.4/debian/patches/series	2021-02-02 18:41:47.0 +0200
+++ hashdeep-4.4/debian/patches/series	2021-11-23 20:46:29.0 +0200
@@ -1,2 +1,3 @@
 fix-manpages.patch
 fix-FTBFS-Hurd.patch
+0001-Fix-errors-found-by-clang.patch

Bug#1000468: ITP: mdnsd -- embeddable Multicast DNS Daemon

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: mdnsd
  Version : 0.10
  Upstream Authors: Jeremie Miller and Joachim Wiberg
* URL : https://github.com/troglobit/mdnsd
* License : BSD-3-Clause License
  Description : embeddable Multicast DNS Daemon
 This is a standalone mDNS-SD daemon for small systems. Although still
 limited in functionality it can announce services like FTP, HTTP, and
 SSH and respond to scanning (enumeration) requests from tools like
 mdns-scan.

This is similar like avahi-daemon but different.

Bug#1000467: rpm, autopkgtest failure on armhf

[peter green]

Package: rpm
Version: 4.17.0+dfsg1-1
Severity: serious

The new version of rpm added an autopkgtest, but unfortunately it's failing on 
armhf
and blocking the migration to testing (and hence blocking the fixes for two 
other rc bugs).

autopkgtest [04:40:50]: test rpmbuild: env PYTHONPATH="$(pwd)/debian/tests/src" 
python3 -B -u -m rpmtest -b /usr/bin -d debian/tests/data
autopkgtest [04:40:50]: test rpmbuild: [---
Using /tmp/tmpma2atafk as a temporary directory
Querying `rpm` for the target architecture
Unexpected `rpm --eval` output: '%{_arch}'
autopkgtest [04:40:51]: test rpmbuild: ---]
autopkgtest [04:40:51]: test rpmbuild:  - - - - - - - - - - results - - - - - - 
- - - -
rpmbuild FAIL non-zero exit status 1
autopkgtest [04:40:51]:  summary
rpmbuild FAIL non-zero exit status 1

Bug#1000466: phonopy: autopkgtest failure

[Adrian Bunk]

Source: phonopy
Version: 2.12.0-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/p/phonopy/16901578/log.gz

...
=== FAILURES ===
_ test_QHA_Si __

self = 
initial_parameters = [-43.375124, 1.0, 4.0, 163.32]

def fit(self, initial_parameters):
"""Fit."""
import logging
import sys
import warnings

try:
>   import scipy
E   ModuleNotFoundError: No module named 'scipy'

/usr/lib/python3/dist-packages/phonopy/qha/eos.py:133: ModuleNotFoundError

During handling of the above exception, another exception occurred:

def test_QHA_Si():
"""Test of QHA calculation by Si."""
indices = list(range(11))
>   phonopy_qha = PhonopyQHA(
volumes=ev_vs_v[indices, 0],
electronic_energies=ev_vs_v[indices, 1],
eos="vinet",
temperatures=temperatures,
free_energy=fe_phonon[:, indices],
cv=cv[:, indices],
entropy=entropy[:, indices],
t_max=1000,
verbose=True,
)

test/qha/test_QHA.py:154: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3/dist-packages/phonopy/api_qha.py:105: in __init__
self._bulk_modulus = BulkModulus(volumes, electronic_energies, eos=eos)
/usr/lib/python3/dist-packages/phonopy/qha/core.py:82: in __init__
) = fit_to_eos(volumes, self._energies, self._eos)
/usr/lib/python3/dist-packages/phonopy/qha/eos.py:101: in fit_to_eos
fit.fit([fe[len(fe) // 2], 1.0, 4.0, volumes[len(volumes) // 2]])
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = 
initial_parameters = [-43.375124, 1.0, 4.0, 163.32]

def fit(self, initial_parameters):
"""Fit."""
import logging
import sys
import warnings

try:
import scipy
from scipy.optimize import leastsq
except ImportError:
print("You need to install python-scipy.")
>   sys.exit(1)
E   SystemExit: 1

/usr/lib/python3/dist-packages/phonopy/qha/eos.py:137: SystemExit
- Captured stdout call -
You need to install python-scipy.
=== short test summary info 
FAILED test/qha/test_QHA.py::test_QHA_Si - SystemExit: 1
= 1 failed, 138 passed, 1 skipped in 62.19s (0:01:02) ==
autopkgtest [15:31:27]: test command1: ---]
autopkgtest [15:31:27]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -


python3-scipy is a !nocheck build dependency.

Bug#998706: git breaks mercurial autopkgtest: Failed test-convert-git.t: output changed

[Julien Cristau]

Control: reassign -1 mercurial 5.9.3-1
Control: close -1 mercurial/6.0~rc0-1

On Sat, Nov 06, 2021 at 09:57:34PM +0100, Paul Gevers wrote:
> Source: git, mercurial
> Control: found -1 git/1:2.33.1-1
> Control: found -1 mercurial/5.9.3-1
> Severity: serious
> Tags: sid bookworm
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> 
> Dear maintainer(s),
> 
> With a recent upload of git the autopkgtest of mercurial fails in
> testing when that autopkgtest is run with the binary packages of git
> from unstable. It passes when run with only packages from testing. In
> tabular form:
> 
>passfail
> gitfrom testing1:2.33.1-1
> mercurial  from testing5.9.3-1
> all others from testingfrom testing
> 
Fixed in mercurial 6.0 by https://www.mercurial-scm.org/repo/hg/rev/fd3d4b7f8e62

Cheers,
Julien

Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26

[Dirk Eddelbuettel]

On 22 November 2021 at 09:08, Patrick Alken wrote:
| Hi all, sorry for all this trouble. I will try to make a new GSL release 
| with the correct numbers.

Much appreciate it!

Sebastian, we'll then run a new transition with gsl 2.8 (or whichever version
number it will be) and its new somajor.

Dirk

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

Bug#998057: transition: r-api-bioc-3.14

[Nilesh Patra]

Hi Sebastian,

On Sun, 7 Nov 2021 17:46:56 +0100 Sebastian Ramacher  
wrote:
> > Hi,
> > Bioconductor 3.14 was released [1].
> > 
> > [1] https://bioconductor.org/news/bioc_3_14_release/
> > 
> > Like for previous r-api-bioc transitions, all reverse dependencies
> > need a manual upgrade to the new upstream releases, they are not
> > binNMU-able. The Debian R Packages team will do so.
> > 
> > Please set up a tracker manually, since this is a transition of a
> > virtual package name.
> 
> Let's do this one after gsl

Sorry to get on your nerves, but since it has been a little more than two weeks 
since
you sent this email, is there any update on gsl transition, or is it nearing 
completion or so?
Can bioc start sometime soon?

Let me know.

Regards,
Nilesh


signature.asc
Description: PGP signature

Bug#984158: grfcodec: diff for NMU version 6.0.6-5.1

[Adrian Bunk]

Control: tags 984158 + patch
Control: tags 984158 + pending

Dear maintainer,

I've prepared an NMU for grfcodec (versioned as 6.0.6-5.1) and uploaded 
it to DELAYED/15. Please feel free to tell me if I should cancel it, or
to use the changes for a maintainer upload instead.

cu
Adrian
diff -Nru grfcodec-6.0.6/debian/changelog grfcodec-6.0.6/debian/changelog
--- grfcodec-6.0.6/debian/changelog	2020-08-12 15:39:33.0 +0300
+++ grfcodec-6.0.6/debian/changelog	2021-11-23 19:42:54.0 +0200
@@ -1,3 +1,10 @@
+grfcodec (6.0.6-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream fixes for FTBFS with gcc 11. (Closes: #984158)
+
+ -- Adrian Bunk   Tue, 23 Nov 2021 19:42:54 +0200
+
 grfcodec (6.0.6-5) unstable; urgency=medium
 
   * [99dfb79] Fix FTBFS with gcc-10 (Closes: 957307)
diff -Nru grfcodec-6.0.6/debian/patches/0001-Fix-name-conflict-with-std-data-c-17.patch grfcodec-6.0.6/debian/patches/0001-Fix-name-conflict-with-std-data-c-17.patch
--- grfcodec-6.0.6/debian/patches/0001-Fix-name-conflict-with-std-data-c-17.patch	1970-01-01 02:00:00.0 +0200
+++ grfcodec-6.0.6/debian/patches/0001-Fix-name-conflict-with-std-data-c-17.patch	2021-11-23 19:42:17.0 +0200
@@ -0,0 +1,95 @@
+From 18ab320d97e2312f18f8fc69f9c610f86dd2ca05 Mon Sep 17 00:00:00 2001
+From: glx 
+Date: Fri, 29 Nov 2019 01:12:45 +0100
+Subject: Fix: name conflict with std::data (c++17)
+
+---
+ src/data.cpp | 26 +-
+ 1 file changed, 13 insertions(+), 13 deletions(-)
+
+diff --git a/src/data.cpp b/src/data.cpp
+index e319c40..0781240 100644
+--- a/src/data.cpp
 b/src/data.cpp
+@@ -1046,7 +1046,7 @@ struct dat{
+ #undef DATA
+ #undef DATA_FILE
+ #undef END_DATA
+-#define DATA() static const dat data[]={
++#define DATA() static const dat datafiles[]={
+ #define DATA_FILE(name)\
+ 	{(char*)_dat##name,"/.nforenum/" #name ".dat",sizeof(_dat##name)-1},\
+ 
+@@ -1126,11 +1126,11 @@ FILE*tryopen(const char*name,const char*mode,bool allownull=false){
+ }
+ 
+ FILE*_myfopen(files file, bool write){
+-	FILE*pFile=tryopen(data[file].name,"rb",true);
++	FILE*pFile=tryopen(datafiles[file].name,"rb",true);
+ 	if(pFile){
+-		if(fgetc(pFile)==data[file].data[0]&&fgetc(pFile)>=data[file].data[1]){
++		if(fgetc(pFile)==datafiles[file].data[0]&&fgetc(pFile)>=datafiles[file].data[1]){
+ 			if(file>datfeat && (uint)fgetc(pFile)(data[file].data), data[file].len, "rb");
++		pFile = fmemopen(const_cast(datafiles[file].data), datafiles[file].len, "rb");
+ 		if (pFile == NULL) {
+-			IssueMessage(0, DATAFILE_ERROR, OPEN, data[file].name + 1, ERRNO, errno);
++			IssueMessage(0, DATAFILE_ERROR, OPEN, datafiles[file].name + 1, ERRNO, errno);
+ 			perror(NULL);
+ 			assert(false);
+ 			exit(EDATA);
+@@ -1150,19 +1150,19 @@ FILE*_myfopen(files file, bool write){
+ 	} else
+ #endif /* WITH_FMEMOPEN */
+ 	{
+-		pFile = tryopen(data[file].name,"wb");
+-		if (fwrite(data[file].data, 1, data[file].len, pFile) != data[file].len) {
+-			IssueMessage(0, DATAFILE_ERROR, WRITE, data[file].name + 1, -1);
++		pFile = tryopen(datafiles[file].name,"wb");
++		if (fwrite(datafiles[file].data, 1, datafiles[file].len, pFile) != datafiles[file].len) {
++			IssueMessage(0, DATAFILE_ERROR, WRITE, datafiles[file].name + 1, -1);
+ 			assert(false);
+ 			exit(EDATA);
+ 		}
+ 		fclose(pFile);
+-		pFile = tryopen(data[file].name,"rb");
++		pFile = tryopen(datafiles[file].name,"rb");
+ 	}
+ 	fgetc(pFile);
+ 	fgetc(pFile);
+ 	if(file>datfeat && (uint)fgetc(pFile)
+Bug-Debian: https://bugs.debian.org/984158
+Forwarded: https://github.com/OpenTTD/grfcodec/commit/8ed61cfc3a1c97b221027b0a511e018768bac69d
+
+--- grfcodec-6.0.6.orig/Makefile
 grfcodec-6.0.6/Makefile
+@@ -96,7 +96,7 @@ FLAGS += -DWITH_PNG $(shell $(LIBPNG_CON
+ endif
+ endif
+ 
+-MY_CXXFLAGS ?= $(FLAGS) $(CXXFLAGS)
++MY_CXXFLAGS ?= $(FLAGS) $(CXXFLAGS) -std=gnu++11
+ 
+ # ===
+ #   setup verbose/non-verbose make process
diff -Nru grfcodec-6.0.6/debian/patches/series grfcodec-6.0.6/debian/patches/series
--- grfcodec-6.0.6/debian/patches/series	2020-08-12 15:39:33.0 +0300
+++ grfcodec-6.0.6/debian/patches/series	2021-11-23 19:42:49.0 +0200
@@ -1,3 +1,5 @@
 # Series of quilt patches
 endian_check_cpp_abort_on_ftbfs.patch
 gcc_10_ftbfs.patch
+cxx11.patch
+0001-Fix-name-conflict-with-std-data-c-17.patch

Bug#969463: rsync: fails reproducible but unexplained on a specific volume, breaks horribly when started by BackupPC

[Baptiste Jonglez]

Hello Bastian,

Many thanks for the link, it does indeed look like the exact same bug!

So, this turns out to be a longstanding bug in libfile-rsyncp-perl.  I see
two ways to fix this problem in Debian:

- update libfile-rsyncp-perl to 0.76 in buster.  This seems quite unlikely
  but I'm not 100% familiar with Debian policies.

- wait for upstream rsync to (possibly) revert the default behaviour of
  rsync, that is, disable --msgs2stderr by default.  And then wait for
  this updated version of rsync to land in bullseye.
  See https://github.com/WayneD/rsync/issues/95#issuecomment-700424731
  It also looks quite unlikely.

So I guess we need the workarounds for now :/

Baptiste

Bug#984382: vdr: diff for NMU version 2.4.1-4.2

[Adrian Bunk]

Control: tags 984382 + patch
Control: tags 984382 + pending

Dear maintainer,

I've prepared an NMU for vdr (versioned as 2.4.1-4.2) and uploaded
it to DELAYED/7. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru vdr-2.4.1/debian/changelog vdr-2.4.1/debian/changelog
--- vdr-2.4.1/debian/changelog	2020-07-19 20:22:51.0 +0300
+++ vdr-2.4.1/debian/changelog	2021-11-23 19:13:46.0 +0200
@@ -1,3 +1,10 @@
+vdr (2.4.1-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fixes for gcc 11. (Closes: #984382)
+
+ -- Adrian Bunk   Tue, 23 Nov 2021 19:13:46 +0200
+
 vdr (2.4.1-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru vdr-2.4.1/debian/patches/0001-Fixed-checking-the-return-value-of-the-Open-call-in-.patch vdr-2.4.1/debian/patches/0001-Fixed-checking-the-return-value-of-the-Open-call-in-.patch
--- vdr-2.4.1/debian/patches/0001-Fixed-checking-the-return-value-of-the-Open-call-in-.patch	1970-01-01 02:00:00.0 +0200
+++ vdr-2.4.1/debian/patches/0001-Fixed-checking-the-return-value-of-the-Open-call-in-.patch	2021-11-23 19:13:46.0 +0200
@@ -0,0 +1,28 @@
+From 515e34727df9aad10f91af8f359cbf65255ab341 Mon Sep 17 00:00:00 2001
+From: Klaus Schmidinger 
+Date: Wed, 16 Sep 2020 13:30:59 +0200
+Subject: Fixed checking the return value of the Open() call in
+ cFileName::SetOffset()
+
+---
+ recording.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/recording.c b/recording.c
+index 810ef809..045f14ed 100644
+--- a/recording.c
 b/recording.c
+@@ -3025,8 +3025,8 @@ cUnbufferedFile *cFileName::SetOffset(int Number, off_t Offset)
+}
+ // found a non existing file suffix
+ }
+- if (Open() >= 0) {
+-if (!record && Offset >= 0 && file && file->Seek(Offset, SEEK_SET) != Offset) {
++ if (Open()) {
++if (!record && Offset >= 0 && file->Seek(Offset, SEEK_SET) != Offset) {
+LOG_ERROR_STR(fileName);
+return NULL;
+}
+-- 
+2.20.1
+
diff -Nru vdr-2.4.1/debian/patches/0002-Now-using-__cplusplus-instead-of-DISABLE_TEMPLATES_C.patch vdr-2.4.1/debian/patches/0002-Now-using-__cplusplus-instead-of-DISABLE_TEMPLATES_C.patch
--- vdr-2.4.1/debian/patches/0002-Now-using-__cplusplus-instead-of-DISABLE_TEMPLATES_C.patch	1970-01-01 02:00:00.0 +0200
+++ vdr-2.4.1/debian/patches/0002-Now-using-__cplusplus-instead-of-DISABLE_TEMPLATES_C.patch	2021-11-23 19:13:46.0 +0200
@@ -0,0 +1,49 @@
+From 6ead2ee35e94e70fc464f48e69d6d06371fbd9af Mon Sep 17 00:00:00 2001
+From: Klaus Schmidinger 
+Date: Wed, 26 May 2021 13:37:53 +0200
+Subject: Now using __cplusplus instead of
+ DISABLE_TEMPLATES_COLLIDING_WITH_STL, and using std::min(), std::max() and
+ std::swap() if available
+
+---
+ tools.h | 20 +++-
+ 1 file changed, 11 insertions(+), 9 deletions(-)
+
+diff --git a/tools.h b/tools.h
+index 614130d0..6a016c70 100644
+--- a/tools.h
 b/tools.h
+@@ -51,19 +51,21 @@ template inline void DELETENULL(T *&p) { T *q = p; p = NULL; delete q;
+ #define CHECK(s) { if ((s) < 0) LOG_ERROR; } // used for 'ioctl()' calls
+ #define FATALERRNO (errno && errno != EAGAIN && errno != EINTR)
+ 
+-// In case some plugin needs to use the STL and gets an error message regarding one
+-// of these functions, you can #define DISABLE_TEMPLATES_COLLIDING_WITH_STL before
+-// including tools.h.
+-#if !defined(__STL_CONFIG_H) // for old versions of the STL
+-#if !defined(DISABLE_TEMPLATES_COLLIDING_WITH_STL) && !defined(_STL_ALGOBASE_H)
++#if __cplusplus >= 201103L
++// any gcc >= 4.8.1; we have swap, min, max
++#include  // std::min, std::max, (c++98: also swap)
++#include  // std::swap (since c++11)
++using std::min;
++using std::max;
++using std::swap;
++#else
++// no c++11 and old compiler, let's include our own templates
+ template inline T min(T a, T b) { return a <= b ? a : b; }
+ template inline T max(T a, T b) { return a >= b ? a : b; }
+-#endif
+-template inline int sgn(T a) { return a < 0 ? -1 : a > 0 ? 1 : 0; }
+-#if !defined(DISABLE_TEMPLATES_COLLIDING_WITH_STL) && !defined(_MOVE_H)
+ template inline void swap(T &a, T &b) { T t = a; a = b; b = t; }
+ #endif
+-#endif
++
++template inline int sgn(T a) { return a < 0 ? -1 : a > 0 ? 1 : 0; }
+ 
+ template inline T constrain(T v, T l, T h) { return v < l ? l : v > h ? h : v; }
+ 
+-- 
+2.20.1
+
diff -Nru vdr-2.4.1/debian/patches/series vdr-2.4.1/debian/patches/series
--- vdr-2.4.1/debian/patches/series	2020-07-19 20:22:51.0 +0300
+++ vdr-2.4.1/debian/patches/series	2021-11-23 19:13:40.0 +0200
@@ -7,3 +7,5 @@
 use-cpp-flags.patch
 configurable-pkg-config.patch
 glibc-stime.patch
+0001-Fixed-checking-the-return-value-of-the-Open-call-in-.patch
+0002-Now-using-__cplusplus-instead-of-DISABLE_TEMPLATES_C.patch

Bug#999658: ghostwriter: No HTML preview when offline

[Sebastien CHAVAUX]

I just tested on my side, with version 2.0.2 available in Sid and 
testing, it works.


Can you say more about your concern? Are there any pictures in the file? 
Is it just a file with text?


Is it possible to ask yourself if you have a file available 
(non-personal) that does not work and that I could test on my side?


Best regards.

Sebastien

Bug#1000464: journalctl --fac #just beeps

[Michael Biebl]

Control: retitle -1 missing bash completion for journalctl --facility
Control: forwarded -1 https://github.com/systemd/systemd/issues/21484

On 23.11.21 15:22, 積丹尼 Dan Jacobson wrote:

Package: systemd
Version: 249.7-1
Severity: minor
File: /usr/share/bash-completion/completions/journalctl

# journalctl --help|grep fac
  --facility=FACILITY...  Show entries with the specified facilities
# journalctl --fac #just beeps
$ grep -c fac /usr/share/bash-completion/completions/journalctl
0



https://github.com/systemd/systemd/commit/196dedd50300e600a0b053af46fdcde6cb2c3034




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000439: fcitx5: icons of individual input methods are not being displayed

[Shengjing Zhu]

Control: severity -1 serious

On Tue, Nov 23, 2021 at 4:57 PM Wenbin Lv  wrote:
>
> Package: fcitx5
> Version: 5.0.10-1
> Severity: normal
>
> Dear maintainer,
>
> In version 5.0.10-1, when an input method is activated, the icon of the
> activated input method is not being displayed correctly in notification
> area. In Xfce, the icon will be blank. In MATE the icon defaults to
> org.fcitx.Fcitx5.png. Below is the output of fcitx5-diagnose. There is
> nothing interesting in the output of fcitx5 --verbose 5, though.
>

This is because we begin to roll out reverting the fcitx5 icon patch (#976603).
Things will be settled when we have updated all fcitx5 packages.

I'm raising the severity so 5.0.10-1 won't migrate to testing, until
we have finished updating all fcitx5 packages.

--
Shengjing Zhu

Bug#999658: ghostwriter: No HTML preview when offline

[Sebastien CHAVAUX]

Hello Flössie;


On Sun, 14 Nov 2021 12:39:41 +0100 =?UTF-8?B?RmzDtnNzaWU=?= 
 wrote:


> Package: ghostwriter
> Version: 1.8.1-2
> Severity: normal
>
> Dear Maintainer,
>
> ghostwriter doesn't show or update the HTML preview when the
> computer is disconnected from the Internet. Looking at the
> network traffic when starting ghostwriter reveals connection
> attempts to "cdn.jsdelivr.net". This domain is referenced in
> the MathJax code in the "3rdparty" directory of the ghostwriter
> sources.
>
> AFAIK there is no hint on the ghostwriter site nor in the
> documents from Debian that an Internet connection is needed
> for this editor to properly work.
>
> Apart from the external JS sources obviously needed for the
> HTML preview there is no other traffic to the net, and the
> preview also works when disconnecting the computer after
> ghostwriter was started.
>
> HTH,
> Flössie
>
> -- System Information:
> Debian Release: 11.1
> APT prefers stable-security
> APT policy: (500, 'stable-security'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
> Locale: LANG=C, LC_CTYPE=C.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 ghostwriter depends on:
> ii libc6 2.31-13+deb11u2
> ii libgcc-s1 10.2.1-6
> ii libhunspell-1.7-0 1.7.0-3
> ii libqt5concurrent5 5.15.2+dfsg-9
> ii libqt5core5a 5.15.2+dfsg-9
> ii libqt5gui5 5.15.2+dfsg-9
> ii libqt5svg5 5.15.2-3
> ii libqt5webchannel5 5.15.2-2
> ii libqt5webengine5 5.15.2+dfsg-3
> ii libqt5webenginewidgets5 5.15.2+dfsg-3
> ii libqt5widgets5 5.15.2+dfsg-9
> ii libstdc++6 10.2.1-6
>
> ghostwriter recommends no packages.
>
> Versions of packages ghostwriter suggests:
> pn cmark 
> pn discount 
> ii hunspell-de-de [hunspell-dictionary] 20161207-9
> pn myspell-dictionary 
> pn pandoc 
> pn wkhtmltopdf 


Sorry for the response time, I just didn't see the bug report. I will go 
ask the question upstream and I will provide the answer here.Best regards.


Sebastien

Bug#1000464: journalctl --fac #just beeps

[積丹尼 Dan Jacobson]

Package: systemd
Version: 249.7-1
Severity: minor
File: /usr/share/bash-completion/completions/journalctl

# journalctl --help|grep fac
 --facility=FACILITY...  Show entries with the specified facilities
# journalctl --fac #just beeps
$ grep -c fac /usr/share/bash-completion/completions/journalctl
0

Bug#1000463: Please re-enable TLS support (even if only for a subset of architectures)

[Daniel Leidert]

Package: memcached
Version: 1.6.12+dfsg-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

during debugging some test failures with a Ruby gem we discovered that
memcached is built without TLS support. Now it seems you had it enabled, but
disabled it completely with one of your recent commits. However, the changelog
and commit message are not verbose about the why. I built memcached on my amd64
machine and it builds and tests just fine. The commit and changelog messages
also imply that TLS support may only be a problem for a subset of
architectures.

Would you be willing to re-enable TLS support? Maybe just for a subset of
architectures?

Regards, Daniel



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

Kernel: Linux 5.14.0-4-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 memcached depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libc62.32-4
ii  libevent-2.1-7   2.1.12-stable-1
ii  libsasl2-2   2.1.27+dfsg2-2
ii  libssl1.11.1.1l-1
ii  lsb-base 11.1.0
ii  perl 5.32.1-6

memcached recommends no packages.

Versions of packages memcached suggests:
pn  libanyevent-perl 
pn  libcache-memcached-perl  
pn  libmemcached 
ii  libterm-readkey-perl 2.38-1+b2
ii  libyaml-perl 1.30-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmGdGDcACgkQS80FZ8KW
0F2Hlw//dSX36rlVR0XwOSW7NFvP1jHMf86LHA8N/Oj36EJ5o5uqxhlDQyHE2GwD
wUT7xXph0sGNis7OiZTO1ud9cxYGIi5Weknan+lmIYzoZL090FY/TfJ781tmGndz
clEILfDe7YXloU4sUkHMie/KZU3Ltg2wBQhCAevdh32mBuquo+3/9q+IJZiNgtcz
cbWhQ7mlkW8r3mFrNGI4eD4V3c7aqjc6r/hJPPAQuKBO7nhggIwPLKuUwtfmFGw9
GwcygUFgLz8pScmuIEsVpdoa3iTsBw2pS3tY1rBWqFkZm+RBynphG1rTKcDIduVS
qgrgW5N5tu2abfpwbTtqdFDzl0LGuGX+F2jlhzPCeWVgVTuvaJ85Z2iMT58jqmBj
WjHoL1LxmYJ9ku+08CeMdkJd+6eFPRnk/mWAmRKYT87Pm7Rt+eVXRXGbLlcZsv9w
VvcknlYeCnF5IGCezYfAU/ARcsrDRVNyTQNya3dvU80ImAFgxGB0Y6JHQktQ5Hll
PZyszfIrch47PrikpaGgWfARuHjz+75YsgxIKD4lYlvxG8VZnkd+MQY9BuO/cMrR
18YBNT3AHeDhDfpOrv7iT/IsJ+PkzNctJAtpaPzcZZDAAgumCwnFqsGMzfh0bb7n
d9/dq4aTxYTGEBnla9mWpDnEVEo9tAvB0RjxgRufvrJr74WSme0=
=muJy
-END PGP SIGNATURE-

Bug#996752: (no subject)

[Sylvestre Ledru]

Le 23/11/2021 à 15:17, Victor Westerhuis a écrit :

It looks like this was fixed upstream: 
https://github.com/llvm/llvm-project/commit/f8cb78e99aae9aa3f89f7bfe667db2c5b767f21f


This patch is already in llvm-toolchain-13:
https://sources.debian.org/src/llvm-toolchain-13/1:13.0.0-9/lld/ELF/Writer.cpp/#L1091

So, might be a different issue

S

Bug#995015: dnsdiag: diff for NMU version 1.7.0-1.1

[Ana Custura]

Dear Adrian,

Thank you for the upload, this is appreciated as I don't have much time atm.

Ana

On 23/11/2021 16:19, Adrian Bunk wrote:

Control: tags 995015 + patch
Control: tags 995015 + pending

Dear maintainer,

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

cu
Adrian

Bug#1000365: pre-rebuild?

[Gordon Ball]

I _think_ this would expected with 22.3.0-1 and python 3.10, since that
package was built only for python 3.9.

Can you reproduce this with 22.3.0-1+b1 now the python 3.10 binNMUs have
(mostly) happened? I can certainly import `zmq` in python3.10 without
immediate errors.

Bug#996260: Bug#998693: btrbk: Regression with security mitigation for CVE-2021-38173

[Maximilian Stein]

On 23.11.21 16:30, Thorsten Alteholz wrote:

Hi Bart,

oh, no, I didn't know of that regression, sorry.
There is a new package [1] available. Can you please test whether 
things are better with it?


  Thorsten


[1] 
https://people.debian.org/~alteholz/packages/to-be-tested/btrbk_0.27.1-1+deb10u2/



Thanks for the quick fix! This works for me.

Maximilian




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")

[Julien Cristau]

On Mon, Nov 01, 2021 at 12:01:51AM +0100, Christoph Biedl wrote:
> Adam D. Barratt wrote...
> 
> > Do you already have a proposed new upload / debdiff?
> 
> After many more tests and some more discussion with Hilko, find attached
> a debdiff that in my opinion is ready for upload. The patch itself is
> unmodified, I just enhanced the description for posterity.
> 
> About next steps, I would do the upload in the next days. Let me know if
> you prefer other things to happen first or instead.
> 
Hi Christoph,

Would you mind providing the old/new/proposed versions of http_parser.h?
(this is me being lazy, sorry, if I'm being too much of a pain I can go
and figure them out for myself, just let me know).

Thanks,
Julien

Bug#995015: dnsdiag: diff for NMU version 1.7.0-1.1

[Adrian Bunk]

Control: tags 995015 + patch
Control: tags 995015 + pending

Dear maintainer,

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

cu
Adrian
diff -Nru dnsdiag-1.7.0/debian/changelog dnsdiag-1.7.0/debian/changelog
--- dnsdiag-1.7.0/debian/changelog	2020-02-08 20:16:44.0 +0200
+++ dnsdiag-1.7.0/debian/changelog	2021-11-23 17:49:52.0 +0200
@@ -1,3 +1,12 @@
+dnsdiag (1.7.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix for runtime warning with dnspython 2.
+(Closes: #995015)
+  * Build depend on python3, not python3-all.
+
+ -- Adrian Bunk   Tue, 23 Nov 2021 17:49:52 +0200
+
 dnsdiag (1.7.0-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru dnsdiag-1.7.0/debian/control dnsdiag-1.7.0/debian/control
--- dnsdiag-1.7.0/debian/control	2020-02-08 20:16:44.0 +0200
+++ dnsdiag-1.7.0/debian/control	2021-11-23 17:49:52.0 +0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Ana Custura 
 Uploaders: Debian Python Modules Team 
-Build-Depends: debhelper-compat (= 11), dh-python, python3-all, python3-setuptools, dh-exec
+Build-Depends: debhelper-compat (= 11), dh-python, python3, python3-setuptools, dh-exec
 Standards-Version: 4.4.1
 Homepage: https://dnsdiag.org/
 Vcs-Git: https://salsa.debian.org/python-team/modules/dnsdiag.git
diff -Nru dnsdiag-1.7.0/debian/patches/0001-Adapt-new-dnspython-v2.0.0.patch dnsdiag-1.7.0/debian/patches/0001-Adapt-new-dnspython-v2.0.0.patch
--- dnsdiag-1.7.0/debian/patches/0001-Adapt-new-dnspython-v2.0.0.patch	1970-01-01 02:00:00.0 +0200
+++ dnsdiag-1.7.0/debian/patches/0001-Adapt-new-dnspython-v2.0.0.patch	2021-11-23 17:48:29.0 +0200
@@ -0,0 +1,82 @@
+From 3d9eb79e0037837586be5e3d01ffecbe3c442065 Mon Sep 17 00:00:00 2001
+From: Babak Farrokhi 
+Date: Thu, 20 Aug 2020 23:47:11 +0200
+Subject: Adapt new dnspython v2.0.0
+
+- Adapt new resolve() function (Fixes #67)
+- Update dependency to newer dnspython
+---
+ dnseval.py   | 4 ++--
+ dnsping.py   | 4 ++--
+ dnstraceroute.py | 2 +-
+ requirements.txt | 2 +-
+ setup.py | 2 +-
+ 5 files changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/dnseval.py b/dnseval.py
+index d3d0afb..63820c6 100755
+--- a/dnseval.py
 b/dnseval.py
+@@ -172,8 +172,8 @@ def dnsping(host, server, dnsrecord, timeout, count, use_tcp=False, use_edns=Fal
+ fqdn = host
+ 
+ stime = time.perf_counter()
+-answers = resolver.query(fqdn, dnsrecord, tcp=use_tcp,
+- raise_on_no_answer=False)  # todo: response validation in future
++answers = resolver.resolve(fqdn, dnsrecord, tcp=use_tcp,
++   raise_on_no_answer=False)  # todo: response validation in future
+ 
+ except (dns.resolver.NoNameservers, dns.resolver.NoAnswer):
+ break
+diff --git a/dnsping.py b/dnsping.py
+index 6845cdb..a243ab5 100755
+--- a/dnsping.py
 b/dnsping.py
+@@ -186,8 +186,8 @@ def main():
+ 
+ try:
+ stime = time.perf_counter()
+-answers = resolver.query(hostname, dnsrecord, source_port=src_port, source=src_ip, tcp=use_tcp,
+- raise_on_no_answer=False)
++answers = resolver.resolve(hostname, dnsrecord, source_port=src_port, source=src_ip, tcp=use_tcp,
++   raise_on_no_answer=False)
+ etime = time.perf_counter()
+ except dns.resolver.NoNameservers as e:
+ if not quiet:
+diff --git a/dnstraceroute.py b/dnstraceroute.py
+index 8a58e40..44a4770 100755
+--- a/dnstraceroute.py
 b/dnstraceroute.py
+@@ -194,7 +194,7 @@ def ping(resolver, hostname, dnsrecord, ttl, src_ip, use_edns=False):
+ resolver.use_edns(edns=0, payload=8192, ednsflags=dns.flags.edns_from_text('DO'))
+ 
+ try:
+-resolver.query(hostname, dnsrecord, source=src_ip, raise_on_no_answer=False)
++resolver.resolve(hostname, dnsrecord, source=src_ip, raise_on_no_answer=False)
+ 
+ except dns.resolver.NoNameservers as e:
+ if not quiet:
+diff --git a/requirements.txt b/requirements.txt
+index 7fe56ca..f1238bd 100644
+--- a/requirements.txt
 b/requirements.txt
+@@ -1,2 +1,2 @@
+-dnspython>=1.16.0
++dnspython>=2.0.0
+ cymruwhois>=1.6
+diff --git a/setup.py b/setup.py
+index 39233d2..2db02ca 100644
+--- a/setup.py
 b/setup.py
+@@ -5,7 +5,7 @@ setup(
+ version="1.7.0",
+ packages=find_packages(),
+ scripts=["dnseval.py", "dnsping.py", "dnstraceroute.py"],
+-install_requires=['dnspython>=1.16.0', 'cymruwhois>=1.6'],
++install_requires=['dnspython>=2.0.0', 'cymruwhois>=1.6'],
+ 
+ classifiers=[
+ "Topic :: System :: Networking",
+-- 
+2.20.1
+
diff -Nru dnsdiag-1.7.0/debian/patches/series dnsdiag-1.7.0/debian/patches/series
--- dnsdiag-1.7.0/debian/patches/series	2020-02-08 19:52:07.00

Bug#1000462: Acknowledgement (libjpeg-turbo-progs: Outdated tjbench man page)

[Mathieu Malaterre]

Control: tags -1 patch

Let me know if you want a complete debdiff. But the basic idea can be
borrowed from:

https://salsa.debian.org/debian/dumpasn1/-/blob/master/debian/rules#L20

So help2man is called during build time:

override_dh_install: debian/dumpasn1.1
debian/dumpasn1.1: debian/dumpasn1.1.in
[...]help2man[...]

Bug#1000460: tf does not trap errors from make

[Helmut Grohne]

Source: tf
Version: 1:4.0s1-21
Severity: serious
Justification: policy 4.6

When building tf fails, the failure is not propagated and debian/rules
proceeds with dh_auto_install after a failed dh_auto_build. Such
behaviour violates policy section 4.6 and thus this issue deserves
rc-severity.

At least one cause is unix/Makefile line 25.
https://sources.debian.org/src/tf/1:4.0s1-21/unix/Makefile/#L25

There, the result of the sub-make is ignored.

Helmut

Bug#1000462: libjpeg-turbo-progs: Outdated tjbench man page

[Mathieu Malaterre]

Package: libjpeg-turbo-progs
Version: 1:2.0.6-4
Severity: normal

Dear Maintainer,

The man page for tjbench states:

[...]
   -yuvencode

  Encode RGB input as planar YUV rather than compressing as JPEG

   -yuvdecode

  Decode JPEG image to planar YUV rather than RGB
[...]

However, here is what I see in the output:

$ tjbench
[...]
-yuv = Test YUV encoding/decoding functions
[...]

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

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

Versions of packages libjpeg-turbo-progs depends on:
ii  libc62.31-13+deb11u2
ii  libjpeg62-turbo  1:2.0.6-4
ii  libturbojpeg01:2.0.6-4

libjpeg-turbo-progs recommends no packages.

libjpeg-turbo-progs suggests no packages.

-- no debconf information

Bug#1000461: add support for gcc-12

[Helmut Grohne]

Package: cross-gcc-dev
Version: 245
User: helm...@debian.org
Usertags: rebootstrap

Hi Dima,

can you add gcc-12 support? If you're short on time, just copy the
gcc-11 patches to gcc-12. If you have more time, you can try rebasing.

Helmut

Bug#1000459: gcc-12: cross-install-location.diff does not apply

[Helmut Grohne]

Source: gcc-12
Version: 12-2027-1
Tags: patch
User: helm...@debian.org
Usertags: ftcbfs

cross-install-location.diff does not apply due to changes in gcc. I'm
attaching a patch to fix that. Can you apply it? I plan to send more
fixes. Would you like to receive them in a different form (e.g. salsa
merge requests)?

Helmut
--- a/debian/patches/cross-install-location.diff
+++ b/debian/patches/cross-install-location.diff
@@ -17,7 +17,7 @@
 @@ -724,7 +724,7 @@ gcc_version := $(shell @get_gcc_base_ver
  @LIBGFOR_USE_SYMVER_GNU_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_dep = $(srcdir)/gfortran.map
  @LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_dep = gfortran.map-sun
- gfor_c_HEADERS = $(srcdir)/ISO_Fortran_binding.h
+ gfor_c_HEADERS = ISO_Fortran_binding.h
 -gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include
 +gfor_cdir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/include
  LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS)) \
@@ -43,7 +43,7 @@
 @@ -31,7 +31,7 @@ version_dep =
  endif
  
- gfor_c_HEADERS = $(srcdir)/ISO_Fortran_binding.h
+ gfor_c_HEADERS = ISO_Fortran_binding.h
 -gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include
 +gfor_cdir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/include
  

Bug#1000450: Please package latest versions of modemmanager 1.18.2 (also libmbim, libqmi)

[Arnaud Ferraris]

Hi Christoph,

Le 23/11/2021 à 16:30, Christoph Biedl a écrit :
> Christoph Biedl wrote...
> 
>> [I] will have to rebuild all this manually now.
> 
> It's noteworthy that upgrading to newer versions not only resolved the
> issues I had seen, it also was almost painless, even for stable.
> 
> To avoid duplicated work and in the hope it's helpful, I am attaching
> the diffs. They are mostly about the symbol definitions, the versioned
> dependencies might be incompletete.

modemmanager and its dependencies are now maintained by the
DebianOnMobile team[1]. We have libqmi and libmbim ready to be uploaded
(should happen anytime soon now), and modemmanager will follow once
those reach unstable.

Cheers,
Arnaud

[1] https://salsa.debian.org/DebianOnMobile-team

> 
> Cheers,
> 
> Christoph
> 

Bug#1000458: bullseye-pu: package wget/1.21-1+deb11u1

[plugwash]

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

When downloading a file greater than 2GB on a 32-bit system wget on bullseye
will truncate it to 2GB. No error is reported, the length of the file is simply
reported as less than it's true length. This was reported to me by raspberry pi
staff, but I can reproduce it in a Debian i386 environment, so it's not
raspberry pi, raspbian or arm specific.

I confirmed that the issue did not affect bookworm and after some searching
found the upstream commit and bug report that fix it. 
https://gitlab.com/gnuwget/wget/-/commit/90631a6fe54eabd9c80ede5c70bc916719e76cfe

I have rated this issue as important, being unable to download large files (for
example OS images) is a significant restriction on the usefulness of wget. There
is a possible argument that it deserves grave severity based on "non-serious
data loss" (for example if someone used wget to copy a file to another system
before deleting the original) but I think that argument is tenuous, so I decided
to stick with important.

I filed this as bug 999744 in Debian  on the 15th November and have not received
a maintainer response, hence I am starting the PU process myself. I have tested
the fix in raspbian bullseye and also in a debian bullsyeye i386 chroot. I have
also released the fix to raspbian bullseye.
diff -Nru wget-1.21/debian/changelog wget-1.21/debian/changelog
--- wget-1.21/debian/changelog  2021-01-02 10:58:25.0 +
+++ wget-1.21/debian/changelog  2021-11-23 14:34:25.0 +
@@ -1,3 +1,11 @@
+wget (1.21-1+deb11u1) bullseye-staging; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply upstream patch to fix downloads over 2GB on 32-bit systems.
+closes: bug#999744
+
+ -- Peter Michael Green   Tue, 23 Nov 2021 14:34:25 +
+
 wget (1.21-1) unstable; urgency=medium
 
   * new upstream release from 2020-12-31
diff -Nru wget-1.21/debian/patches/fix-large-downloads-on-32-bit 
wget-1.21/debian/patches/fix-large-downloads-on-32-bit
--- wget-1.21/debian/patches/fix-large-downloads-on-32-bit  1970-01-01 
00:00:00.0 +
+++ wget-1.21/debian/patches/fix-large-downloads-on-32-bit  2021-11-23 
14:31:49.0 +
@@ -0,0 +1,26 @@
+Debian patch based on the upstream commit below, defuzzed
+in the context of the debian package.
+
+commit 90631a6fe54eabd9c80ede5c70bc916719e76cfe
+Author: Tim Rühsen 
+Date:   Sun Apr 11 12:53:16 2021 +0200
+
+* src/wget.h: Use strtoll() for str_to_wgint
+
+This fixes a regression reported at https://savannah.gnu.org/bugs/?60353.
+
+Reported-by: Michal Ruprich
+
+Index: wget-1.21/src/wget.h
+===
+--- wget-1.21.orig/src/wget.h
 wget-1.21/src/wget.h
+@@ -144,7 +144,7 @@ typedef int64_t wgint;
+ #define WGINT_MAX INT64_MAX
+ typedef wgint SUM_SIZE_INT;
+ 
+-#define str_to_wgint strtol
++#define str_to_wgint strtoll
+ 
+ #include "options.h"
+ 
diff -Nru wget-1.21/debian/patches/series wget-1.21/debian/patches/series
--- wget-1.21/debian/patches/series 2019-07-20 16:10:06.0 +
+++ wget-1.21/debian/patches/series 2021-11-23 14:31:49.0 +
@@ -1,3 +1,4 @@
 wget-doc-remove-usr-local-in-sample.wgetrc
 wget-doc-remove-usr-local-in-wget.texi
 wget-passive_ftp-default
+fix-large-downloads-on-32-bit

Bug#1000450: Please package latest versions of modemmanager 1.18.2 (also libmbim, libqmi)

[Christoph Biedl]

Christoph Biedl wrote...

> [I] will have to rebuild all this manually now.

It's noteworthy that upgrading to newer versions not only resolved the
issues I had seen, it also was almost painless, even for stable.

To avoid duplicated work and in the hope it's helpful, I am attaching
the diffs. They are mostly about the symbol definitions, the versioned
dependencies might be incompletete.

Cheers,

Christoph
diff --git a/debian/control b/debian/control
index 155c7e1..b061cc5 100644
--- a/debian/control
+++ b/debian/control
@@ -14,8 +14,8 @@ Build-Depends: debhelper-compat (= 10),
libgudev-1.0-dev (>= 147),
libsystemd-dev (>= 209),
libpolkit-gobject-1-dev (>= 0.97),
-   libqmi-glib-dev (>= 1.28.6~),
-   libmbim-glib-dev (>= 1.24.0~),
+   libqmi-glib-dev (>= 1.20.2~),
+   libmbim-glib-dev (>= 1.26.0~),
libglib2.0-doc,
python3-dbus,
python3-gi,
diff --git a/debian/libmm-glib0.symbols b/debian/libmm-glib0.symbols
index 9a57bf9..120ba13 100644
--- a/debian/libmm-glib0.symbols
+++ b/debian/libmm-glib0.symbols
@@ -1,6 +1,30 @@
 libmm-glib.so.0 libmm-glib0 #MINVER#
+ mm_3gpp_profile_cmp@Base 1.18.2
+ mm_3gpp_profile_consume_string@Base 1.18.2
+ mm_3gpp_profile_consume_variant@Base 1.18.2
+ mm_3gpp_profile_get_allowed_auth@Base 1.18.2
+ mm_3gpp_profile_get_apn@Base 1.18.2
+ mm_3gpp_profile_get_apn_type@Base 1.18.2
+ mm_3gpp_profile_get_dictionary@Base 1.18.2
+ mm_3gpp_profile_get_ip_type@Base 1.18.2
+ mm_3gpp_profile_get_password@Base 1.18.2
+ mm_3gpp_profile_get_profile_id@Base 1.18.2
+ mm_3gpp_profile_get_type@Base 1.18.2
+ mm_3gpp_profile_get_user@Base 1.18.2
+ mm_3gpp_profile_new@Base 1.18.2
+ mm_3gpp_profile_new_from_dictionary@Base 1.18.2
+ mm_3gpp_profile_new_from_string@Base 1.18.2
+ mm_3gpp_profile_set_allowed_auth@Base 1.18.2
+ mm_3gpp_profile_set_apn@Base 1.18.2
+ mm_3gpp_profile_set_apn_type@Base 1.18.2
+ mm_3gpp_profile_set_ip_type@Base 1.18.2
+ mm_3gpp_profile_set_password@Base 1.18.2
+ mm_3gpp_profile_set_profile_id@Base 1.18.2
+ mm_3gpp_profile_set_user@Base 1.18.2
  mm_bearer_allowed_auth_build_string_from_mask@Base 0.7.991
  mm_bearer_allowed_auth_get_type@Base 0.7.991
+ mm_bearer_apn_type_build_string_from_mask@Base 1.18.2
+ mm_bearer_apn_type_get_type@Base 1.18.2
  mm_bearer_connect@Base 0.7.991
  mm_bearer_connect_finish@Base 0.7.991
  mm_bearer_connect_sync@Base 0.7.991
@@ -11,11 +35,14 @@ libmm-glib.so.0 libmm-glib0 #MINVER#
  mm_bearer_dup_path@Base 0.7.991
  mm_bearer_get_bearer_type@Base 1.10.0
  mm_bearer_get_connected@Base 0.7.991
+ mm_bearer_get_connection_error@Base 1.18.2
  mm_bearer_get_interface@Base 0.7.991
  mm_bearer_get_ip_timeout@Base 0.7.991
  mm_bearer_get_ipv4_config@Base 0.7.991
  mm_bearer_get_ipv6_config@Base 0.7.991
+ mm_bearer_get_multiplexed@Base 1.18.2
  mm_bearer_get_path@Base 0.7.991
+ mm_bearer_get_profile_id@Base 1.18.2
  mm_bearer_get_properties@Base 0.7.991
  mm_bearer_get_stats@Base 1.5.993
  mm_bearer_get_suspended@Base 0.7.991
@@ -40,6 +67,9 @@ libmm-glib.so.0 libmm-glib0 #MINVER#
  mm_bearer_ip_family_get_type@Base 0.7.991
  mm_bearer_ip_method_get_string@Base 0.7.991
  mm_bearer_ip_method_get_type@Base 0.7.991
+ mm_bearer_multiplex_support_get_string@Base 1.18.2
+ mm_bearer_multiplex_support_get_type@Base 1.18.2
+ mm_bearer_peek_connection_error@Base 1.18.2
  mm_bearer_peek_ipv4_config@Base 0.7.991
  mm_bearer_peek_ipv6_config@Base 0.7.991
  mm_bearer_peek_properties@Base 0.7.991
@@ -50,22 +80,30 @@ libmm-glib.so.0 libmm-glib0 #MINVER#
  mm_bearer_properties_get_allow_roaming@Base 0.7.991
  mm_bearer_properties_get_allowed_auth@Base 0.7.991
  mm_bearer_properties_get_apn@Base 0.7.991
+ mm_bearer_properties_get_apn_type@Base 1.18.2
  mm_bearer_properties_get_dictionary@Base 0.7.991
  mm_bearer_properties_get_ip_type@Base 0.7.991
+ mm_bearer_properties_get_multiplex@Base 1.18.2
  mm_bearer_properties_get_number@Base 0.7.991
  mm_bearer_properties_get_password@Base 0.7.991
+ mm_bearer_properties_get_profile_id@Base 1.18.2
  mm_bearer_properties_get_rm_protocol@Base 0.7.991
  mm_bearer_properties_get_type@Base 0.7.991
  mm_bearer_properties_get_user@Base 0.7.991
  mm_bearer_properties_new@Base 0.7.991
  mm_bearer_properties_new_from_dictionary@Base 0.7.991
+ mm_bearer_properties_new_from_profile@Base 1.18.2
  mm_bearer_properties_new_from_string@Base 0.7.991
+ mm_bearer_properties_peek_3gpp_profile@Base 1.18.2
  mm_bearer_properties_set_allow_roaming@Base 0.7.991
  mm_bearer_properties_set_allowed_auth@Base 0.7.991
  mm_bearer_properties_set_apn@Base 0.7.991
+ mm_bearer_properties_set_apn_type@Base 1.18.2
  mm_bearer_properties_set_ip_type@Base 0.7.991
+ mm_bearer_properties_set_multiplex@Base 1.18.2
  mm_bearer_properties_set_number@Base 0.7.991
  mm_bearer_properties_set_password@Base 0.7.991
+ mm_bearer_properties_set_profile_id@Base 1.18.2
  mm_bearer_properties_set_rm_protocol@Base 0.7.991
  mm_bearer_properties

Bug#997627: pixmap: FTBFS: ar: libdeps specified more than once

[Paul Slootman]

On Sat 23 Oct 2021, Lucas Nussbaum wrote:

> Source: pixmap
> Version: 2.6pl4-20
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20211023 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

> > rm -f libXgnu.a
> > ar clq libXgnu.a SelFile.o Path.o Dir.o Draw.o
> > ar: libdeps specified more than once
> > make[2]: *** [Makefile:1062: libXgnu.a] Error 1

This seems related to #981072 binutils: 'ar clq' does not longer work in
latest binutils.
With binutils 2.35.2 it works.

I suspect that this will affect all packages that use Imake, see also
#997628 and #994276.

Not that much that I can do about it until xutils-dev gets patched.
(Besides patching the output of Imake which is just papering over the
binutils screwup.)


Paul

Bug#949450: [pkg-apparmor] Bug#949450: thunderbird: tb not usable with apparmor profile enabled.

[Thomas Guyot-Sionnest]

Hi,

Is this bug still valid? I'm getting the same errors since I upgraded to
Debian Bullseye, however Thunderbird seems to be in enforce mode by
default and so some things are just not working anymore.

Trying to open links leads to:

Nov 23 09:57:43 debian thunderbird.desktop[392093]:
[392095:392095:1123/095743.933650:FATAL:double_fork_and_exec.cc(131)]
execv /opt/google/chrome/chrome_crashpad_handler: Permission denied (13)
Nov 23 09:57:43 debian kernel: audit: type=1400
audit(1637679463.930:453): apparmor="DENIED" operation="exec"
profile="thunderbird//sanitized_helper"
name="/opt/google/chrome/chrome_crashpad_handler" pid=392095
comm="chrome" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

I also get similar GPG errors (I can send the exact lines if needed),
though I haven't even tried using GPG yet.

I don't recall ever changing apparmor config... I did run a
"dpkg-reconfigure apparmor" and it only asked about additional homedir
locations - which I have - but that didn't help anyway.

Regards,

--
Thomas

Bug#1000457: virtualbox: Outdated dependency on libgsoap-2.8.104

[Diego Caraffini]

Package: virtualbox
Version: 6.1.28-dfsg-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Trying to upgrade virtualbox to Version: 6.1.28-dfsg-1 aptitude was not
able to resolve dependencies. I uninstalled the previous version and
then tryed to install again, but foud that virtualbox depends on
libgsoap-2.8.104, that is not available in unstable.

Proposed solution:
  depend on libgsoap-2.8.117


Thank you for maintaining the package.


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

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

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


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

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

Versions of packages virtualbox depends on:
ii  adduser   3.118
ii  iproute2  5.15.0-1
ii  libc6 2.32-4
ii  libcurl3-gnutls   7.79.1-2
ii  libdevmapper1.02.12:1.02.175-2.1
ii  libgcc-s1 11.2.0-10
ii  libgl11.3.4-2+b1
pn  libgsoap-2.8.104  
ii  liblzf1   3.6-3
ii  libopus0  1.3.1-0.1
ii  libpng16-16   1.6.37-3
ii  libpython3.9  3.9.9-1
ii  libsdl1.2debian   1.2.15+dfsg2-6
ii  libssl1.1 1.1.1l-1
ii  libstdc++611.2.0-10
ii  libvncserver1 0.9.13+dfsg-3
ii  libvpx6   1.10.0-2
ii  libx11-6  2:1.7.2-2+b1
ii  libxcursor1   1:1.2.0-2
ii  libxml2   2.9.12+dfsg-5+b1
ii  libxt61:1.2.0-1
ii  procps2:3.3.17-5
ii  python3   3.9.7-1
ii  python3.9 3.9.9-1
ii  virtualbox-dkms [virtualbox-modules]  6.1.28-dfsg-1~fto11+1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages virtualbox recommends:
ii  libqt5core5a5.15.2+dfsg-13
ii  libqt5gui5  5.15.2+dfsg-13
ii  libqt5opengl5   5.15.2+dfsg-13
ii  libqt5widgets5  5.15.2+dfsg-13
ii  libxcb1 1.14-3
ii  libxext62:1.3.4-1
pn  virtualbox-qt   

Versions of packages virtualbox suggests:
pn  vde2
pn  virtualbox-guest-additions-iso  

Bug#1000438:

[attilio giuseppe carolillo]

Thanks for the quickly reply, it has a so simple solution. It is solved now.

When you call "source" of corruption, do you mean the debs repo i use 
(http://ftp.it.debian.org/debian/) or something in my PC?
It is the first time i get a issue like this.
Thanks

Bug#996752: (no subject)

[Victor Westerhuis]

It looks like this was fixed upstream: 
https://github.com/llvm/llvm-project/commit/f8cb78e99aae9aa3f89f7bfe667db2c5b767f21f

Bug#1000456: deluged listen ports syntax error

[Scott Bender]

Package: deluged
Version: 2.0.3-3.1

After upgrading to bullseye from buster, deluged refused to download any 
torrents.  After enabling logs I was seeing:



21:34:27 [DEBUG   ][deluge.core.alertmanager  :130 ] 
listen_failed_alert: listening on 0.0.0.0:0 (device: 
192.168.1.10:26800192.168.1.10:26801192.168.1.10:26802192.168.1.10:26803192.168.1.10:26804192.168.1.10:26805192.168.1.10:26806192.168.1.10:26807192.168.1.10:26808192.168.1.

10:26809192.168.1.10:26810192.168.1.10:26811192.168.1.10:26812192.168.1.10:26813192.168.1.10:26
21:34:27 [DEBUG   ][deluge.core.alertmanager  :130 ] 
listen_failed_alert: listening on 0.0.0.0:0 (device: 
192.168.1.10:26800192.168.1.10:26801192.168.1.10:26802192.168.1.10:26803192.168.1.10:26804192.168.1.10:26805192.168.1.10:26806192.168.1.10:26807192.168.1.10:26808192.168.1.

10:26809192.168.1.10:26810192.168.1.10:26811192.168.1.10:26812192.168.1.10:26813192.168.1.10:26
21:34:27 [DEBUG   ][deluge.core.alertmanager  :130 ] 
listen_failed_alert: listening on 0.0.0.0:0 (device: 
192.168.1.10:26800192.168.1.10:26801192.168.1.10:26802192.168.1.10:26803192.168.1.10:26804192.168.1.10:26805192.168.1.10:26806192.168.1.10:26807192.168.1.10:26808192.168.1.

10:26809192.168.1.10:26810192.168.1.10:26811192.168.1.10:26812192.168.1.10:26813192.168.1.10:26

This patch fixed it for me: https://dev.deluge-torrent.org/ticket/3337

--- preferencesmanager.py
+++ preferencesmanager.py
@@ -231,7 +231,7 @@
 self.core.apply_session_settings(
 {
 'listen_system_port_fallback': 
self.config['listen_use_sys_port'],
-'listen_interfaces': ''.join(interfaces),
+'listen_interfaces': ','.join(interfaces),
 }
 )



root@oberon:/var/lib/deluge/.config/deluge# uname -a
Linux oberon 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 
GNU/Linux


root@oberon:/var/lib/deluge/.config/deluge# cat /etc/debian_version
11.1

Thanks,

Scott Bender

Bug#1000455: virt-manager: stuck at "connecting to graphical console", dependency missing

[Dimitris]

Package: virt-manager
Version: 1:3.2.0-3
Severity: normal

Hey,

error/description as upstream bug : 
https://github.com/virt-manager/virt-manager/issues/253
couldn't connect to any vm (qemu+ssh). gui only shows "connecting to 
graphical console" but never really opening console.
also not sure when this happened, probably some time in the last few 
weeks (probably related to qemu upgrade on 14/11?).
installing python3-tqdm package (as suggested upstream) solves issue, so 
maybe this package should be added as a dependency.


thanks,
d.

-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 5 (daedalus/ceres)
Release:5
Codename:   daedalus ceres
Architecture: x86_64

Kernel: Linux 5.15.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-2
ii  gir1.2-gtk-3.0   3.24.30-3
ii  gir1.2-gtk-vnc-2.0   1.0.0-1+b1
ii  gir1.2-gtksource-4   4.8.2-1
ii  gir1.2-libosinfo-1.0 1.8.0-1
ii  gir1.2-libvirt-glib-1.0  4.0.0-2
ii  gir1.2-vte-2.91  0.66.1-1
ii  python3  3.9.8-1
ii  python3-dbus 1.2.18-3+b1
ii  python3-gi   3.42.0-2+b1
ii  python3-gi-cairo 3.42.0-2+b1
ii  python3-libvirt  7.0.0-2
ii  virtinst 1:3.2.0-3

Versions of packages virt-manager recommends:
ii  gir1.2-ayatanaappindicator3-0.1  0.5.5-3
ii  gir1.2-spiceclientglib-2.0   0.39-3
ii  gir1.2-spiceclientgtk-3.00.39-3
ii  libvirt-daemon-system7.6.0-1+devuan1

Versions of packages virt-manager suggests:
ii  gir1.2-secret-1  0.20.4-2
ii  gnome-keyring40.0-3
pn  python3-guestfs  
pn  ssh-askpass  
ii  virt-viewer  7.0-2+b1

Versions of packages virt-manager is related to:
ii  libvirt-clients  7.6.0-1+devuan1
ii  libvirt-daemon   7.6.0-1+devuan1
ii  libvirt0 7.6.0-1+devuan1
ii  osinfo-db0.20211013-1

-- no debconf information