Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries

[Helge Deller]

This bug affects the hppa buildd servers as well.

Helge

Bug#982482: libnettle8: chacha breakage on ppc64(el)

[Andreas Metzler]

On 2021-02-10 Andreas Metzler  wrote:
> Package: libnettle8
> Version: 3.7-1
> Severity: serious
> Tags: upstream patch fixed-upstream

> nettle 3.7 breaks GnuTLS testsuite on ppc64(el). I had forwarded this
> upstream
> https://lists.lysator.liu.se/pipermail/nettle-bugs/2021/009418.html and
> there is now a fix (+ testsuite coverage) in nettle GIT master.
[...]

Find attached a proposed debdiff.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
diff -Nru nettle-3.7/debian/changelog nettle-3.7/debian/changelog
--- nettle-3.7/debian/changelog	2021-02-01 00:01:59.0 +0100
+++ nettle-3.7/debian/changelog	2021-02-13 08:34:20.0 +0100
@@ -1,3 +1,12 @@
+nettle (3.7-2.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix chacha breakage on ppc64(el). Closes: #982482
++ 0001-Improve-chacha-test-coverage.patch
++ 0002-Fix-chacha-counter-update-for-_4core-variants.patch
+
+ -- Andreas Metzler   Sat, 13 Feb 2021 08:34:20 +0100
+
 nettle (3.7-2) unstable; urgency=low
 
   * Adjust libnettle8.symbols.
diff -Nru nettle-3.7/debian/patches/0001-Improve-chacha-test-coverage.patch nettle-3.7/debian/patches/0001-Improve-chacha-test-coverage.patch
--- nettle-3.7/debian/patches/0001-Improve-chacha-test-coverage.patch	1970-01-01 01:00:00.0 +0100
+++ nettle-3.7/debian/patches/0001-Improve-chacha-test-coverage.patch	2021-02-13 08:29:19.0 +0100
@@ -0,0 +1,910 @@
+From dd1867efa005704fbac438896369694a44fd474b Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Niels=20M=C3=B6ller?= 
+Date: Wed, 10 Feb 2021 10:26:52 +0100
+Subject: [PATCH 1/2] Improve chacha test coverage.
+
+---
+ ChangeLog   |  12 +
+ testsuite/chacha-test.c | 746 ++--
+ 2 files changed, 504 insertions(+), 254 deletions(-)
+
+ a/ChangeLog
+ b/ChangeLog
+ 2021-02-10  Niels Möller  
+
+	* testsuite/chacha-test.c (test_chacha_rounds): New function, for
+	tests with non-standard round count. Extracted from _test_chacha.
+	(_test_chacha): Deleted rounds argument. Reorganized crypt/crypt32
+	handling. When testing message prefixes of varying length, also
+	encrypt the remainder of the message, to catch errors in counter
+	value update.
+	(test_main): Add a few tests with large messages (16 blocks, 1024
+	octets), to improve test coverage for _nettle_chacha_crypt_4core
+	and _nettle_chacha_crypt32_4core.
+
+diff --git a/testsuite/chacha-test.c b/testsuite/chacha-test.c
+index 5efe4ee2..8bbdd4ad 100644
+--- a/testsuite/chacha-test.c
 b/testsuite/chacha-test.c
+@@ -121,119 +121,140 @@ test_chacha_core(void)
+ }
+ }
+ 
++/* For tests with non-standard number of rounds, calling
++   _nettle_chacha_core directly. */
+ static void
+-_test_chacha(const struct tstring *key, const struct tstring *nonce,
+-	 const struct tstring *expected, unsigned rounds,
+-	 const struct tstring *counter)
++test_chacha_rounds(const struct tstring *key, const struct tstring *nonce,
++		   const struct tstring *expected, unsigned rounds)
+ {
+   struct chacha_ctx ctx;
++  uint32_t out[_CHACHA_STATE_LENGTH];
++  ASSERT (expected->length == CHACHA_BLOCK_SIZE);
+ 
+   ASSERT (key->length == CHACHA_KEY_SIZE);
+   chacha_set_key (, key->data);
+ 
+-  if (rounds == 20)
++  ASSERT (nonce->length == CHACHA_NONCE_SIZE);
++  chacha_set_nonce(, nonce->data);
++
++  _nettle_chacha_core (out, ctx.state, rounds);
++
++  if (!MEMEQ(CHACHA_BLOCK_SIZE, out, expected->data))
+ {
+-  uint8_t *data = xalloc (expected->length + 2);
+-  size_t length;
+-  data++;
++  printf("Error, expected:\n");
++  tstring_print_hex (expected);
++  printf("Got:\n");
++  print_hex(CHACHA_BLOCK_SIZE, (uint8_t *) out);
++  FAIL ();
++}
+ 
+-  for (length = 1; length <= expected->length; length++)
+-	{
+-	  data[-1] = 17;
+-	  memset (data, 0, length);
+-	  data[length] = 17;
+-	  if (nonce->length == CHACHA_NONCE_SIZE)
+-	chacha_set_nonce(, nonce->data);
+-	  else if (nonce->length == CHACHA_NONCE96_SIZE)
+-	{
+-	  chacha_set_nonce96(, nonce->data);
+-	  /* Use initial counter 1, for
+-		 draft-irtf-cfrg-chacha20-poly1305-08 test cases. */
+-	  ctx.state[12]++;
+-	}
+-	  else
+-	die ("Bad nonce size %u.\n", (unsigned) nonce->length);
++  if (verbose)
++{
++  printf("Result after encryption:\n");
++  print_hex(CHACHA_BLOCK_SIZE, (uint8_t *) out);
++}
++}
+ 
+-	  if (counter)
+-	{
+-	  if (counter->length == CHACHA_COUNTER_SIZE)
+-		{
+-		  ASSERT (nonce->length == CHACHA_NONCE_SIZE);
+-		  chacha_set_counter(, counter->data);
+-		}
+-	  else if (counter->length == CHACHA_COUNTER32_SIZE)
+-		{
+-		  ASSERT (nonce->length == CHACHA_NONCE96_SIZE);
+-		  chacha_set_counter32(, counter->data);
+-		}
+-	}
++static void
++_test_chacha(const struct tstring *key, const struct tstring *nonce,
++	 const struct tstring *expected, const struct 

Bug#979838: twisted: autopkgtest regression in testing: No such file or directory: 'ckeygen'

[Sergio Durigan Junior]

On Monday, January 11 2021, Paul Gevers wrote:

> autopkgtest [09:30:22]: test unit-tests-3: [---
> Traceback (most recent call last):
>   File
> "/usr/lib/python3/dist-packages/twisted/conch/test/test_ckeygen.py",
> line 86, in test_keygeneration
> self._testrun('ecdsa', '384')
>   File
> "/usr/lib/python3/dist-packages/twisted/conch/test/test_ckeygen.py",
> line 75, in _testrun
> subprocess.call(args)
>   File "/usr/lib/python3.9/subprocess.py", line 349, in call
> with Popen(*popenargs, **kwargs) as p:
>   File "/usr/lib/python3.9/subprocess.py", line 947, in __init__
> self._execute_child(args, executable, preexec_fn, close_fds,
>   File "/usr/lib/python3.9/subprocess.py", line 1819, in _execute_child
> raise child_exception_type(errno_num, err_msg, err_filename)
> builtins.FileNotFoundError: [Errno 2] No such file or directory: 'ckeygen'
> Traceback (most recent call last):
>   File
> "/usr/lib/python3/dist-packages/twisted/conch/test/test_ckeygen.py",
> line 105, in test_runBadKeytype
> subprocess.check_call(
>   File "/usr/lib/python3/dist-packages/twisted/trial/_synctest.py", line
> 352, in __exit__
> self._testCase.fail(
> twisted.trial.unittest.FailTest: builtins.FileNotFoundError raised
> instead of CalledProcessError:
>  Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/twisted/trial/_asynctest.py",
> line 111, in _run
> d = defer.maybeDeferred(
>   File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line
> 151, in maybeDeferred
> result = f(*args, **kw)
>   File "/usr/lib/python3/dist-packages/twisted/internet/utils.py", line
> 217, in runWithWarningsSuppressed
> result = f(*a, **kw)
>   File
> "/usr/lib/python3/dist-packages/twisted/conch/test/test_ckeygen.py",
> line 105, in test_runBadKeytype
> subprocess.check_call(
> ---  ---
>   File
> "/usr/lib/python3/dist-packages/twisted/conch/test/test_ckeygen.py",
> line 105, in test_runBadKeytype
> subprocess.check_call(
>   File "/usr/lib/python3.9/subprocess.py", line 368, in check_call
> retcode = call(*popenargs, **kwargs)
>   File "/usr/lib/python3.9/subprocess.py", line 349, in call
> with Popen(*popenargs, **kwargs) as p:
>   File "/usr/lib/python3.9/subprocess.py", line 947, in __init__
> self._execute_child(args, executable, preexec_fn, close_fds,
>   File "/usr/lib/python3.9/subprocess.py", line 1819, in _execute_child
> raise child_exception_type(errno_num, err_msg, err_filename)
> builtins.FileNotFoundError: [Errno 2] No such file or directory: 'ckeygen'
>

After some hours debugging/backporting fixes from upstream, I have
something that finally works.

Instead of going ahead and just uploading, I decided to open a MR first
because of the soft freeze (and also because the changes are
non-trivial).  Here's the link:

https://salsa.debian.org/python-team/packages/twisted/-/merge_requests/4

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#982669: buster-pu: package portaudio19/19.6.0-1

[Thorsten Glaser]

Dixi quod…

>built. Without the crash fix backporting polyphone makes
>no sense

I must correct myself here: polyphone is usable without
it *if* the user manually starts jackd first. (It will
still crash upon terminating, but that’s after saving
all data. I’m documenting this.)

>[ Tests ]
>No automated tests but without it applied, polyphone
>crashes after a bit, maybe a minute or two, of using.

I’m uploading the backport so this can be tested more
easily. To test, start Polyphone, open a soundfont and
click around a bit (maybe try to play back one of the
samples). Soundfonts in Debian are installed under
/usr/share/sounds/sf2/ and timgm6mb-soundfont is the
smallest package with one to test with.

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...

Bug#981005: [Bug 210681] kernel: Bluetooth: hci0: don't support firmware rome 0x31010000

[Salvatore Bonaccorso]

Hi 

On Tue, Dec 29, 2020 at 10:50:10AM +, bugzilla-dae...@bugzilla.kernel.org 
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=210681
> 
> Bradley Jarvis (b...@pocketinnovations.com.au) changed:
> 
>What|Removed |Added
> 
>  CC||b...@pocketinnovations.com.
>||au
> 
> --- Comment #10 from Bradley Jarvis (b...@pocketinnovations.com.au) ---
> Created attachment 294393
>   --> https://bugzilla.kernel.org/attachment.cgi?id=294393=edit
> fix hci0: don't support firmware rome error
> 
> Avoid returning error code when bluetooth version match is not made from
> qca_devices_table and version high is set.
> 
> This reverts an error check that was removed to support WCN6855 which does 
> have
> the high version set. The fix is to move the check after the table is scanned
> and no version match is made.
> 
> This fix will still produce the error message for example (for ATK3K 13d3:3402
> IMC Networks Bluetooth USB Host Controller)
> 
> Bluetooth: hci0: don't support firmware rome 0x1020200
> 
> But the bluetooth hardware still works as it used to

Several people have reported that since b40f58b97386 ("Bluetooth:
btusb: Add Qualcomm Bluetooth SoC WCN6855 support") they have issues
with their Bluetooth adapter stopping working. It was reported at
bugzilla[1].

Bradley Jarvis posted/attached a patch which seems to resolve the
issue, Moreno has added an alternative patch.

 [1] https://bugzilla.kernel.org/show_bug.cgi?id=210681

But there is another report at

 [2] https://bugzilla.kernel.org/show_bug.cgi?id=211571

and that last one was applied to bluetooth-next tree according to
https://lore.kernel.org/linux-bluetooth/ca2c8796-11ca-4e6f-a603-ae764516c...@holtmann.org/

Regards,
Salvatore

Bug#982669: buster-pu: package portaudio19/19.6.0-1

[Thorsten Glaser]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@mirbsd.de

I would like to upload the contents of portaudio19 19.6.0-1.1
to buster.

[ Reason ]
The current library makes applications crash. Please see
Debian #944509 for the bugreport, but this is also seen
e.g. when testing a polyphone backport which I’ve just
built. Without the crash fix backporting polyphone makes
no sense, and since it is a rather important fix entering
via stable-updates seems sensible (instead of via bpo).

[ Impact ]
Applications using portaudio randomly crash.

[ Tests ]
No automated tests but without it applied, polyphone
crashes after a bit, maybe a minute or two, of using.

[ Risks ]
The patch is rather small and “obvious enough”, so I
consider this zero risk. It has been tested in unstable
and testing for 7 months now.

[ 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

[ Changes ]
Apply a patch from the upstream mailing list to fix the crash.

[ Other info ]
The resulting package is, except for the changelog difference
and being recompiled in buster, identical to the one in
bullseye/sid.
diff -Nru portaudio19-19.6.0/debian/changelog 
portaudio19-19.6.0/debian/changelog
--- portaudio19-19.6.0/debian/changelog 2016-12-25 22:08:34.0 +0100
+++ portaudio19-19.6.0/debian/changelog 2021-02-13 07:42:27.0 +0100
@@ -1,3 +1,9 @@
+portaudio19 (19.6.0-1+deb10u1) buster; urgency=medium
+
+  * Apply crash fix patch (Closes: #944509)
+
+ -- Thorsten Glaser   Sat, 13 Feb 2021 07:42:27 +0100
+
 portaudio19 (19.6.0-1) unstable; urgency=medium
 
   * New upstream release v190600_20161030
diff -Nru portaudio19-19.6.0/debian/patches/944509-crash.patch 
portaudio19-19.6.0/debian/patches/944509-crash.patch
--- portaudio19-19.6.0/debian/patches/944509-crash.patch1970-01-01 
01:00:00.0 +0100
+++ portaudio19-19.6.0/debian/patches/944509-crash.patch2020-07-30 
16:26:55.0 +0200
@@ -0,0 +1,59 @@
+Description: handle EPIPE from alsa_snd_pcm_poll_descriptors
+ was: pa_linux_alsa.c:3636 Assertion failed
+Origin: https://lists.columbia.edu/pipermail/portaudio/2019-July/001888.html
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944509
+Forwarded: not-needed
+Justification: taken from upstream dev mailing list post
+Author: Sam Mason 
+Reviewed-by: Norbert Preining 
+Applied-Upstream: no
+
+--- a/src/hostapi/alsa/pa_linux_alsa.c
 b/src/hostapi/alsa/pa_linux_alsa.c
+@@ -3633,12 +3633,18 @@ error:
+ 
+ /** Fill in pollfd objects.
+  */
+-static PaError PaAlsaStreamComponent_BeginPolling( PaAlsaStreamComponent* 
self, struct pollfd* pfds )
++static PaError PaAlsaStreamComponent_BeginPolling( PaAlsaStreamComponent* 
self, struct pollfd* pfds, int *xrunOccurred )
+ {
+ PaError result = paNoError;
+ int ret = alsa_snd_pcm_poll_descriptors( self->pcm, pfds, self->nfds );
+-(void)ret;  /* Prevent unused variable warning if asserts are turned off 
*/
+-assert( ret == self->nfds );
++if( -EPIPE == ret )
++{
++  *xrunOccurred = 1;
++}
++else
++{
++  assert( ret == self->nfds );
++}
+ 
+ self->ready = 0;
+ 
+@@ -3799,17 +3805,22 @@ static PaError PaAlsaStream_WaitForFrame
+ if( pollCapture )
+ {
+ capturePfds = self->pfds;
+-PA_ENSURE( PaAlsaStreamComponent_BeginPolling( >capture, 
capturePfds ) );
++PA_ENSURE( PaAlsaStreamComponent_BeginPolling( >capture, 
capturePfds,  ) );
+ totalFds += self->capture.nfds;
+ }
+ if( pollPlayback )
+ {
+ /* self->pfds is in effect an array of fds; if necessary, index 
past the capture fds */
+ playbackPfds = self->pfds + (pollCapture ? self->capture.nfds : 
0);
+-PA_ENSURE( PaAlsaStreamComponent_BeginPolling( >playback, 
playbackPfds ) );
++PA_ENSURE( PaAlsaStreamComponent_BeginPolling( >playback, 
playbackPfds,  ) );
+ totalFds += self->playback.nfds;
+ }
+ 
++if ( xrun )
++{
++  break;
++}
++
+ #ifdef PTHREAD_CANCELED
+ if( self->callbackMode )
+ {
diff -Nru portaudio19-19.6.0/debian/patches/series 
portaudio19-19.6.0/debian/patches/series
--- portaudio19-19.6.0/debian/patches/series2016-12-25 21:37:53.0 
+0100
+++ portaudio19-19.6.0/debian/patches/series2021-02-13 07:42:08.0 
+0100
@@ -1 +1,2 @@
 audacity-portmixer.patch
+944509-crash.patch

Bug#972570: ROM-RM node-lightgallery ?

[Yadd]

Hi,

node-lightgallery won't be part of Bullseye. I propose to remove it from
Debian. Its place is perhaps in non-free section but not here under JS
Team umbrella in main section.

Cheers,
Xavier

Bug#982668: ITP: ocaml-luv -- a OCaml binding to libuv

[Andy Li]

Package: wnpp
Severity: wishlist
Owner: Andy Li 

* Package name: ocaml-luv
  Version : 0.5.6
  Upstream Author : Anton Bachin 
* URL : https://github.com/aantron/luv
* License : MIT
  Programming Lang: OCaml
  Description : a OCaml binding to libuv

 Luv is a binding to libuv, the cross-platform C library that does
 asynchronous I/O in Node.js and runs its main loop.

 Besides asynchronous I/O, libuv also supports multiprocessing and
 multithreading. Multiple event loops can be run in different
 threads. libuv also exposes a lot of other functionality, amounting
 to a full OS API, and an alternative to the standard module Unix.


This is a dependency of haxe 4.2.0 and will be maintained under the
OCaml team.

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

[Bruno]

On Thu, 28 Jan 2021 00:44:29 +0100 Pelle  wrote:
> [20170.264703] Bluetooth: hci0: don't support firmware rome
0x3101

I've had this same error on 5.10. No adapters found, It's a problem
with the drivers/bluetooth/btusb.c file. Easiest solution for me was to
add a single line of code to the file.

This was reported at the kernel's bugzilla but seems to be officially
unsolved yet.

https://bugzilla.kernel.org/show_bug.cgi?id=210681
https://bugzilla.kernel.org/attachment.cgi?id=294393

The second link leads to the patch file I've used to make it work
again.

Bug#941131: Confirm your subscription for The Little White Farmhouse

[The Little White Farmhouse]

Hi Love!

Thank you recently followed my blog's posts!! This means you will receive each 
new post by email.

To activate, click confirm below. If you believe this is an error, just ignore 
this message.



Blog Name: The Little White Farmhouse
URL: https://chckgeek.com

Confirm Follow: 
https://subscribe.wordpress.com/?key=df633cf1ef5c97e26bae62f249b85096=941131%40bugs.debian.org=4565f86a7bcc5c65a2b0afba31fe6b47

If you don't want to receive these emails any more:
https://subscribe.wordpress.com/?key=df633cf1ef5c97e26bae62f249b85096=941131%40bugs.debian.org

If you want to see all of the blogs and posts you follow on the web in one easy
place, sign up for a WordPress.com account. 
(http://wordpress.com/signup/?ref=lof)

Bug#982667: ITP: monitoring-plugin-systemd -- systemd plugin for nagios compatible monitoring systems

[Louis-Philippe Véronneau]

Package: wnpp
Severity: wishlist
Owner: po...@debian.org

* Package name : monitoring-plugin-systemd
  Version : 2.3.0
  Upstream Author : Josef Friedrich 
* URL : https://github.com/Josef-Friedrich/check_systemd
* License : LGPL-2.1+
  Programming Lang: Python
  Description : systemd plugin for nagios compatible monitoring systems

I intend to package this in the Python Team.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature

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

[Amit]

Just chiming in here. I see this issue on Debian Testing with
fwupd-1.5.3.-2. Removing DynamicUser=yes resolves the issue.

Bug#982666: migrationtools: Add symlink to migrate_common.ph in /usr/share/perl5

[Logan Rosen]

Package: migrationtools
Version: 47-9
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Hi,

Could you please consider adding a symlink to migrate_common.ph in
/usr/share/perl5? This allows the scripts in /usr/share/migrationtools
to be run from any directory, not just by being in the same directory.

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

- d/links: Add symlink for migrate_common.ph in /usr/share/perl5 instead
  of /usr/share/migrationtools so that scripts can be run from any
  directory.

Thanks for considering the patch.

Logan
diff -Nru migrationtools-47/debian/links migrationtools-47/debian/links
--- migrationtools-47/debian/links  2013-12-27 20:58:29.0 -0500
+++ migrationtools-47/debian/links  2020-09-07 10:46:07.0 -0400
@@ -1 +1 @@
-etc/migrationtools/migrate_common.ph usr/share/migrationtools/migrate_common.ph
+etc/migrationtools/migrate_common.ph usr/share/perl5/migrate_common.ph

Bug#982665: golang-github-hashicorp-memberlist: Please increase the timeout for TestMemberlist_SendTo

[Logan Rosen]

Package: golang-github-hashicorp-memberlist
Version: 0.2.2-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Hi,

TestMemberlist_SendTo fails in Ubuntu's autopkgtest infrastructure
because of a timing issue; the messages don't arrive within 3
milliseconds, so we increased the timeout to 12 milliseconds, which
seems to work reliably.

Can you please consider making the same change in Debian?

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

- d/p/fix-TestMemberlist_SendTo.patch: due to a timing issue this test fails
  in Ubuntu autopkgtest infrastructure. Wait more time to let messages
  arrive before checking for them.

Thanks for considering the patch.

Logan
diff -Nru 
golang-github-hashicorp-memberlist-0.2.2/debian/patches/fix-TestMemberlist_SendTo.patch
 
golang-github-hashicorp-memberlist-0.2.2/debian/patches/fix-TestMemberlist_SendTo.patch
--- 
golang-github-hashicorp-memberlist-0.2.2/debian/patches/fix-TestMemberlist_SendTo.patch
 1969-12-31 19:00:00.0 -0500
+++ 
golang-github-hashicorp-memberlist-0.2.2/debian/patches/fix-TestMemberlist_SendTo.patch
 2020-07-09 10:29:42.0 -0400
@@ -0,0 +1,19 @@
+Description: Fix TestMemberlist_SendTo in Ubuntu autopkgtest env
+ For some reason there is a timing issue where it needs to wait more time than
+ in Debian to receive the messages sent. From my tests 12 milliseconds seems
+ enough.
+Author: Lucas Kanashiro 
+Forwarded: not-needed
+Last-Updated: 2020-07-08
+
+--- a/memberlist_test.go
 b/memberlist_test.go
+@@ -1062,7 +1062,7 @@
+   }
+ 
+   // Wait for a little while
+-  time.Sleep(3 * time.Millisecond)
++  time.Sleep(12 * time.Millisecond)
+ 
+   msgs1 := d1.getMessages()
+   msgs2 := d2.getMessages()
diff -Nru golang-github-hashicorp-memberlist-0.2.2/debian/patches/series 
golang-github-hashicorp-memberlist-0.2.2/debian/patches/series
--- golang-github-hashicorp-memberlist-0.2.2/debian/patches/series  
2019-10-23 11:17:10.0 -0400
+++ golang-github-hashicorp-memberlist-0.2.2/debian/patches/series  
2020-10-06 11:16:25.0 -0400
@@ -1,2 +1,3 @@
 01-Vendor-sean--seed.patch
 test--skip_TestShuffleNodes.patch
+fix-TestMemberlist_SendTo.patch

Bug#982664: golang-github-fsouza-go-dockerclient: Please build-depend on golang-golang-x-crypto-dev

[Logan Rosen]

Package: golang-github-fsouza-go-dockerclient
Version: 1.6.6-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Hi,

golang-golang-x-crypto-dev is required for the buildtime tests to
succeed, but it is not an explicit build dependency. While it gets
pulled in transitively in Debian, it does not in Ubuntu. Could you
please add it as a build dependency accordingly?

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

- d/control: Add missing golang-golang-x-crypto-dev build-dependency,
  needed for build-time tests.

Thanks for considering the patch.

Logan
diff -Nru golang-github-fsouza-go-dockerclient-1.6.6/debian/control 
golang-github-fsouza-go-dockerclient-1.6.6/debian/control
--- golang-github-fsouza-go-dockerclient-1.6.6/debian/control   2020-11-30 
16:57:13.0 -0500
+++ golang-github-fsouza-go-dockerclient-1.6.6/debian/control   2021-02-12 
22:14:27.0 -0500
@@ -15,6 +15,7 @@
 #   golang-github-opencontainers-runc-dev,
 golang-github-sirupsen-logrus-dev,
 golang-github-stretchr-testify-dev,
+golang-golang-x-crypto-dev,
 golang-golang-x-net-dev,
 golang-golang-x-sys-dev,
 Homepage: https://github.com/fsouza/go-dockerclient

Bug#982645: CVE-2018-3640 on N3160

[Henrique de Moraes Holschuh]

On Fri, Feb 12, 2021, at 17:15, Kurt Roeckx wrote:
> Package: intel-microcode
> Version: 3.20201118.1~deb10u1

...

> spectre-meltdown-checker reports:
> CVE-2018-3640 aka 'Variant 3a, rogue system register read'
> * CPU microcode mitigates the vulnerability:  NO
> > STATUS:  VULNERABLE  (an up-to-date CPU microcode is needed to mitigate 
> > this vulnerability)

...

> [2.012058] microcode: sig=0x406c4, pf=0x1, revision=0x411

This is the latest public release of microcode for this processor, and none 
newer has been observed in the field.

> Can you clarify if a microcode update is missing, just not available
> or that spectre-meltdown-checker is wrong?

That's the latest update.

I don't know if that celeron N is vulnerable to spectre 3a. You'd need to try 
an exploit to know for sure, the Intel microcode guide is not that detailed.

Rev. 0x410 and later are supposed to mitigate meltdown as much as possible for 
that processor according to the public information released by Intel at the 
time.

-- 
  Henrique de Moraes Holschuh 

Bug#982663: trapperkeeper-scheduler-clojure: testsuite hangs on buildds

[Louis-Philippe Véronneau]

Package: src:trapperkeeper-scheduler-clojure
Version: 1.1.3-3
Severity: normal

The testsuite hangs on buildds and this can be reproduced using pbuilder
(not using sbuild though).

See #981441 for more details.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982662: python3-jarabe: Language control panel hangs Sugar

[James Cameron]

Package: python3-jarabe
Version: 0.118-1
Severity: normal

Dear Maintainer,

Selecting the Language control panel in My Settings leads to a hang of the 
desktop, requiring a system reset or restart.

It is caused by new version of Python package removing a deprecated API.

This is a known problem with a fix available;
https://github.com/sugarlabs/sugar/commit/63885ed7b98beeb2e7cae7448c5cabeabf947c5a

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

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

Versions of packages python3-jarabe depends on:
ii  gir1.2-gdkpixbuf-2.0   2.42.2+dfsg-1
ii  gir1.2-glib-2.01.66.1-1+b1
ii  gir1.2-gstreamer-1.0   1.18.3-1
ii  gir1.2-gtk-3.0 3.24.24-1
ii  gir1.2-gtksource-3.0   3.24.11-2
ii  gir1.2-pango-1.0   1.46.2-3
ii  gir1.2-sugarext-1.00.118-3
ii  gir1.2-telepathyglib-0.12  0.24.1-3
ii  gir1.2-webkit2-4.0 2.30.4-1
ii  gir1.2-wnck-3.03.36.0-1
ii  gir1.2-xkl-1.0 5.4-4
ii  metacity   1:3.38.0-2
ii  policykit-10.105-30
ii  python33.9.1-1
ii  python3-cairo  1.16.2-4+b2
ii  python3-dbus   1.2.16-5
ii  python3-gwebsockets0.7-2
ii  python3-sugar3 0.118-3
ii  python3-xapian 1.4.18-1

Versions of packages python3-jarabe recommends:
ii  avahi-autoipd 0.8-5
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-1
ii  dbus-x11 [dbus-session-bus]   1.12.20-1
ii  libpam-systemd247.3-1
ii  modemmanager  1.14.10-0.1
ii  network-manager   1.28.0-2+b1
ii  openssh-client1:8.4p1-3
ii  python3-carquinyol0.118-1
ii  xdg-user-dirs 0.17-2

Versions of packages python3-jarabe suggests:
ii  sugar-session  0.118-1

-- no debconf information

Bug#982661: mame: Crash on startup

[Celelibi]

Package: mame
Version: 0.227+dfsg.1-1
Severity: important

Dear Maintainer,

After an upgrade, mame started crashing on startup. I think it's
unlikely that it's mame's fault, but I'll let you decide to forward to
bug to libsdl2 or something else of needed.

Here is a run in gdb with a full stack trace.

--
$ gdb mame
Reading symbols from mame...
Reading symbols from 
/usr/lib/debug/.build-id/6b/74368acfb3eea244cebfc8fb10056378166e6c.debug...
(gdb) directory code/debsrc/mesa-20.3.4/debian
Source directories searched: 
/home/celelibi/code/debsrc/mesa-20.3.4/debian:$cdir:$cwd
(gdb) run
Starting program: /usr/games/mame
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Error opening translation file English
[Detaching after fork from child process 698623]
[New Thread 0x7fffea0b8700 (LWP 698740)]
[New Thread 0x7fffe9762700 (LWP 698741)]
[New Thread 0x7fffe8f61700 (LWP 698742)]
[New Thread 0x7fffe3fff700 (LWP 698743)]
[New Thread 0x7fffe37fe700 (LWP 698744)]

Thread 1 "mame" received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x70edb23f in cso_destroy_context (ctx=0x6b27a9e0) at 
../src/gallium/auxiliary/cso_cache/cso_context.c:419
#2  0x709f7704 in st_destroy_context_priv (st=st@entry=0x6b279020, 
destroy_pipe=destroy_pipe@entry=true) at 
../src/mesa/state_tracker/st_context.c:471
#3  0x709f8a94 in st_destroy_context (st=0x6b279020) at 
../src/mesa/state_tracker/st_context.c:1150
#4  0x709da95e in dri_destroy_context (cPriv=) at 
../src/gallium/frontends/dri/dri_context.c:247
#5  0x70ed9903 in driDestroyContext (pcp=0x6b06aa00) at 
../src/mesa/drivers/dri/common/dri_util.c:533
#6  0x722515af in dri2_destroy_context (context=0x6b06a870) at 
../src/glx/dri2_glx.c:123
#7  0x7223fe49 in glXDestroyContext (ctx=0x6b06a870, 
dpy=0x6afe9bf0) at ../src/glx/glxcmds.c:510
#8  glXDestroyContext (dpy=0x6afe9bf0, ctx=0x6b06a870) at 
../src/glx/glxcmds.c:491
#9  0x77ed56ed in X11_GL_InitExtensions (_this=0x6afeb890) at 
./src/video/x11/SDL_x11opengl.c:464
#10 X11_GL_LoadLibrary (_this=0x6afeb890, path=) at 
./src/video/x11/SDL_x11opengl.c:238
#11 0x77eaf116 in SDL_GL_LoadLibrary_REAL (path=path@entry=0x0) at 
./src/video/SDL_video.c:3012
#12 0x77eb1771 in SDL_CreateWindow_REAL 
(title=title@entry=0x77f246b5 "OpenGL test", x=x@entry=-32, y=y@entry=-32, 
w=w@entry=32, h=h@entry=32, flags=flags@entry=10) at 
./src/video/SDL_video.c:1489
#13 0x77eb1fff in ShouldUseTextureFramebuffer () at 
./src/video/SDL_video.c:225
#14 SDL_VideoInit_REAL (driver_name=, driver_name@entry=0x0) at 
./src/video/SDL_video.c:545
#15 0x77e0af47 in SDL_InitSubSystem_REAL (flags=16416) at 
./src/SDL.c:216
#16 0x5ee925c8 in sdl_osd_interface::init(running_machine&) ()
#17 0x63894f79 in running_machine::start() ()
#18 0x63896c29 in running_machine::run(bool) ()
#19 0x5ef8cf85 in mame_machine_manager::execute() ()
#20 0x5f037d36 in cli_frontend::start_execution(mame_machine_manager*, 
std::vector, 
std::allocator >, std::allocator, std::allocator > > > const&) ()
#21 0x5f03800e in 
cli_frontend::execute(std::vector, std::allocator >, 
std::allocator, 
std::allocator > > >&) ()
#22 0x5ef8a876 in emulator_info::start_frontend(emu_options&, 
osd_interface&, std::vector, std::allocator >, 
std::allocator, 
std::allocator > > >&) ()
#23 0x5a221fcb in main ()
(gdb) frame 1
#1  0x70edb23f in cso_destroy_context (ctx=0x6b27a9e0) at 
../src/gallium/auxiliary/cso_cache/cso_context.c:419
419ctx->pipe->set_shader_buffers(ctx->pipe, sh, 0, maxssbo, 
ssbos, 0);
(gdb) p ctx->pipe->set_shader_buffers
$1 = (void (*)(struct pipe_context *, enum pipe_shader_type, unsigned int, 
unsigned int, const struct pipe_shader_buffer *, unsigned int)) 0x0
--

I doubt the crash has anything to do with the error about the English
translation, since it crashes during the initialization of the video
subsystem.

Best regards,
Celelibi



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

Kernel: Linux 5.9.0-5-amd64 (SMP w/2 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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mame depends on:
ii  libc6  2.31-9
ii  libexpat1  2.2.10-1
ii  libflac8   1.3.3-2
ii  libfontconfig1 2.13.1-4.2
ii  libgcc-s1  10.2.1-6
ii  libgl1 1.3.2-1
ii  

Bug#979840: dns-root-data: autopkgtest regression in testing: failed to query server 127.0.0.1@53

[Daniel Kahn Gillmor]

Thanks Paul for reviewing this, and Robert for looking into it further.
I think my conclusions differ a little bit from Robert's.

On Thu 2021-02-11 22:22:18 -0500, Robert Edmonds wrote:
> I have investigated this report. The purpose of the dns-root-data
> package is to ship, as static content, the list of IANA DNS root
> nameserver IP addresses, and the IANA DNSSEC root zone trust anchor.
> According to
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation:
>
> It can be appropriate to file an RC bug against the depended-on
> package, if the regression amounts to an RC bug in the depending
> package, and to keep it open while the matter is investigated. That
> will prevent migration of an RC regression.
>
> I have confirmed that the current version of the package (2019052802) is
> shipping the correct root nameserver hints and root zone trust anchor
> content and that no RC regression exists, so I am lowering the severity
> of this bug report.
>
> The problem seems to be that the test depends on the Knot Resolver's
> kresd daemon, whose service unit is masked and is not started after
> installing the knot-resolver package. I would guess something like the
> following would fix the regression in the test:

hmm, kresd.service is masked, because kresd is managed via the
kresd@.service template (to enable cheap and easily-supervised
multi-process parallelism).

The problem seems to be that kresd isn't starting up automatically on
package installation:

Feb 12 20:23:01 alice systemd[1]: Stopping Knot Resolver daemon...
Feb 12 20:23:01 alice systemd[382608]: kresd@1.service: Changing to the 
requested working directory failed: No such file or directory
Feb 12 20:23:01 alice systemd[382608]: kresd@1.service: Failed at step CHDIR 
spawning /usr/bin/env: No such file or directory
Feb 12 20:23:01 alice systemd[1]: kresd@1.service: Control process exited, 
code=exited, status=200/CHDIR
Feb 12 20:23:01 alice systemd[1]: kresd@1.service: Failed with result 
'exit-code'.
Feb 12 20:23:01 alice systemd[1]: Stopped Knot Resolver daemon.
Feb 12 20:23:17 alice systemd[1]: /lib/systemd/system/kresd@.service:25: Failed 
to assign slice system-kresd.slice to unit kresd@1.service, ignoring: Device or 
resource busy

I've updated the autopkgtest script to try to manually ensure that the
kresd@1 service is started and released a new version of dns-root-data
to try to cover it.

Meanwhile, I've also reported #982660 against knot-resolver for this
strange startup situation.

--dkg


signature.asc
Description: PGP signature

Bug#982660: knot-resolver: fails to start

[Daniel Kahn Gillmor]

Package: knot-resolver
Version: 5.2.1-1
Severity: normal
Control: blocks -1 979840
Control: affects -1 dns-root-data

When i "apt install knot-resolver" on an otherwise clean system running
systemd, the default configuration should start a listener on port 53 on
127.0.0.1.

However, that listener often fails to start.  This leads to failures in
autopkgtests that depend on the kresd package producing such a
functioning listener, like dns-root-data, which is suffering from
#979840 as a result.


Here's an example transcript of the installation (note "failed to load 
properly"):

```
The following NEW packages will be installed:
  knot-resolver
0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded.
Need to get 292 kB of archives.
After this operation, 976 kB of additional disk space will be used.
Get:1 http://ftp.debian.org/debian bullseye/main amd64 knot-resolver amd64 
5.2.1-1 [292 kB]
Fetched 292 kB in 0s (790 kB/s)   
Preconfiguring packages ...
Selecting previously unselected package knot-resolver.
(Reading database ... 447962 files and directories currently installed.)
Preparing to unpack .../knot-resolver_5.2.1-1_amd64.deb ...
Unpacking knot-resolver (5.2.1-1) ...
Setting up knot-resolver (5.2.1-1) ...
Failed to try-restart kresd@1.service: Unit kresd@1.service failed to load 
properly: Device or resource busy.
See system logs and 'systemctl status kresd@1.service' for details.
Created symlink /etc/systemd/system/kresd.target.wants/kres-cache-gc.service → 
/lib/systemd/system/kres-cache-gc.service.
Created symlink /etc/systemd/system/multi-user.target.wants/kresd.target → 
/lib/systemd/system/kresd.target.
Processing triggers for man-db (2.9.3-2) ...
Processing triggers for libc-bin (2.31-9) ...
```

The reason that it failed to start is that the working director doesn't
appear to exist:

```
Feb 12 20:23:01 alice systemd[1]: Stopping Knot Resolver daemon...
Feb 12 20:23:01 alice systemd[382608]: kresd@1.service: Changing to the 
requested working directory failed: No such file or directory
Feb 12 20:23:01 alice systemd[382608]: kresd@1.service: Failed at step CHDIR 
spawning /usr/bin/env: No such file or directory
Feb 12 20:23:01 alice systemd[1]: kresd@1.service: Control process exited, 
code=exited, status=200/CHDIR
Feb 12 20:23:01 alice systemd[1]: kresd@1.service: Failed with result 
'exit-code'.
Feb 12 20:23:01 alice systemd[1]: Stopped Knot Resolver daemon.
```

Interestingly, the service *does* start successfully if you just do:

```
systemctl start kresd@1.service
```

after the "apt install" has finished running.

here's the systemd unit:

```
# /lib/systemd/system/kresd@.service
# SPDX-License-Identifier: CC0-1.0
[Unit]
Description=Knot Resolver daemon
Documentation=man:kresd.systemd(7)
Documentation=man:kresd(8)
Wants=kres-cache-gc.service
Before=kres-cache-gc.service
Wants=network-online.target
After=network-online.target

[Service]
Type=notify
Environment="SYSTEMD_INSTANCE=%i"
WorkingDirectory=/var/lib/knot-resolver
ExecStart=/usr/sbin/kresd -c /usr/lib/x86_64-linux-gnu/knot-resolver/distro-pre>
ExecStopPost=/usr/bin/env rm -f "/run/knot-resolver/control/%i"
User=knot-resolver
Group=knot-resolver
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SETPCAP
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_SETPCAP
TimeoutStopSec=10s
WatchdogSec=10s
Restart=on-abnormal
LimitNOFILE=524288
Slice=system-kresd.slice

[Install]
WantedBy=kresd.target
```

Seems like this might be an issue of postinst script ordering or
something, but i don't fully understand it.  how is
/var/lib/knot-resolver supposed to change ownership to kresd?  I can see
that /etc/init.d/kresd does a chown, but i wouldn't expect that to be
executed at all on a systemd system.

I'm a bit stumped on this, and would welcome help figuring out why the
startup fails.

--dkg


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

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

Versions of packages knot-resolver depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.74
ii  dns-root-data  2019052802
ii  libc6  2.31-9
ii  libdnssec8 3.0.4-2
ii  libedit2   3.1-20191231-2+b1
ii  libfstrm0  0.6.0-1+b1
ii  libgcc-s1  10.2.1-6
ii  libgnutls303.7.0-5
ii  libknot11  3.0.4-2
ii  liblmdb0   0.9.24-1
ii  libluajit-5.1-22.1.0~beta3+dfsg-5.3
ii  libnghttp2-14  1.42.0-1
ii  libprotobuf-c1 1.3.3-1+b2
ii  libstdc++6 10.2.1-6
ii  libsystemd0247.3-1
ii  libuv1   

Bug#980641: nml: builds with patch

[Phil Morrell]

Control: tags -1 +patch

Upstream have re-exported the pcx files and I can confirm nml now builds
correctly with these 3 files copied into place before tests.

https://github.com/OpenTTD/nml/pull/188/commits/a4b37e0e3eacd1f370abea8f116c9c6c51aaeb3b


signature.asc
Description: PGP signature

Bug#959881: Fwd: libssh2-1: Please upgrade to 1.9: ECDSA and memory leaks

[Nicolas Mora]

Hello,

Le 2021-02-09 à 10 h 45, Benjamin Riefenstahl a écrit :


Sorry for taking so long, I just now found the time to test this.  Sad
to say that both the memory leak and the problem with ECDSA still exist,
when I run our test in a container with Debian testing and libssh2-1
1.9.0-2.

I'm especially puzzled by the ECDSA key failure.  The OpenSSH server
seems to ok with the key (although it does say "Postponed publickey"
after "Accepted key"), so maybe this is a problem on the client side.
 From libcurl I get the CURL error code 67 "Login denied".  I'm not sure
how to debug this, libcurl's debugging facilities do not give any output
here.  Is it possible to use libssh2_trace with libcurl and the Debian
packages?


Can you provide a sample code so I can reproduce the errors?

Therefore I can see the problem by myself and the bugs can be forwarded 
upstream if necessary.


Thanks in advance

/Nicolas


OpenPGP_0xFE82139440BD22B9.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#982648: RFP: filius -- Filius is a tool for enhancing computer science lessons on networks.

[Philipp Marek]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: phil...@marek.priv.at

* Package name: filius
  Version : 1.11.0
  Upstream Author : University Siegen, Germany
* URL : https://gitlab.com/filius1/filius
* License : GPL2, GPL3
  Programming Lang: Java
  Description : Filius is a tool for enhancing computer science lessons on 
networks.

The homepage is at https://www.lernsoftware-filius.de/Startseite; 
excerpt from the English Introduction at 
https://www.lernsoftware-filius.de/downloads/Introduction_Filius.pdf:

FILIUS
was initially developed by the University Siegen, Germany, to 
provide a tool for enhancing computer science lessons on networks. 
The main target group are students of secondary schools but with its 
wide range of applications it can be interesting for learners of any 
age. The software especially promotes explorative learning and is 
very helpful to teach students about the internet and its various 
applications.


I saw it when my daughter asked me and I think it's really cool; it has
routers, switches, endpoints, servers, and all the details on ethernet 
and TCP/IP:

- MAC addresses
- ARP
- TCP/IP with subnets
- routing (so gateway definitions are necessary)
- simulation - you can see cables blinking and get a list of packets
  (like ARP, ICMP, etc.)
- provides standard services (mail, DNS, http) and console windows on
  the endpoints with commands like ping, traceroute, etc.

See eg. 
https://www.inf-schule.de/kommunikation/netze/module/filius/internet/erkundung_dns
 
for a few screenshots, like a router with multiple interfaces at 
https://www.inf-schule.de/content/6_kommunikation/1_netze/3_module/10_filius/4_internet/4_erkundung_dns/netz_dns.png


It would be really great to have that available as easily as possible, 
ie. with a simple "apt-get".


Thanks a lot!

Bug#982658: ITP: org-tree-slide -- presentation tool for org-mode

[Martin]

Package: wnpp
Severity: wishlist
Owner: Martin 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-emac...@lists.debian.org

* Package name: org-tree-slide
  Version : 2.8.16
  Upstream Author : Takaaki ISHIKAWA 
* URL : https://github.com/takaxp/org-tree-slide
* License : GPL3+
  Programming Lang: Emacs-Lisp
  Description : presentation tool for org-mode

The main purpose of this elisp is to handle each tree in an org
buffer as a slide by simple narrowing. This emacs lisp is a
minor mode for Emacs Org-mode.

Main features:
 - Live editable presentation
 - Fast switching of narrowing/widen
 - TODO pursuit with narrowing
 - Displaying the current number of slides in mode line
 - CONTENT view during a presentation
 - Slide-in effect
 - Slide header from org file’s header
 - Countdown timer

Bug#982659: ITP: elpa-darkroom -- remove visual distractions and focus on writing

[Martin]

Package: wnpp
Severity: wishlist
Owner: Martin 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-emac...@lists.debian.org

* Package name: elpa-darkroom
  Version : 0.3
  Upstream Author : João Távora 
* URL : http://elpa.gnu.org/packages/darkroom.html
* License : GPL3+
  Programming Lang: Emacs-Lisp
  Description : remove visual distractions and focus on writing

darkroom-mode makes visual distractions disappear: the mode-line
is temporarily elided, text is enlarged and margins are adjusted
so that it's centered on the window.

Bug#982657: /usr/bin/debdiff: debdiff: writes wrong patched-file filenames if they contain nōn-ASCII characters

[Thorsten Glaser]

Package: devscripts
Version: 2.20.5
Severity: normal
File: /usr/bin/debdiff
X-Debbugs-Cc: t...@mirbsd.de

x=screen_4.8.0-5wtf1.dsc; 
After doing…

TMPDIR=/var/tmp debdiff \
screen_4.8.0-5.dsc \
screen_4.8.0-5wtf1.dsc \
>screen_4.8.0-5wtf1.debdiff

… the created debdiff contains correct…

diff -Nru 
screen-4.8.0/debian/patches/9997_segfault.patch 
screen-4.8.0/debian/patches/9997_segfault.patch
--- screen-4.8.0/debian/patches/9997_segfault.patch 
1970-01-01 01:00:00.0 +0100
+++ screen-4.8.0/debian/patches/9997_segfault.patch 
2021-02-13 01:28:34.0 +0100
@@ -0,0 +1,13 @@

… and incorrect patches:

diff -Nru 
"/var/tmp/io4vcduSrR/screen-4.8.0/debian/patches/9998_yt\303\274t\303\274.patch"
 
"/var/tmp/K7wrDpUt7q/screen-4.8.0/debian/patches/9998_yt\303\274t\303\274.patch"
--- 
"/var/tmp/io4vcduSrR/screen-4.8.0/debian/patches/9998_yt\303\274t\303\274.patch"
1970-01-01 01:00:00.0 +0100
+++ 
"/var/tmp/K7wrDpUt7q/screen-4.8.0/debian/patches/9998_yt\303\274t\303\274.patch"
2020-06-20 02:31:33.0 +0200
@@ -0,0 +1,41 @@

Apparently, debdiff fails to fix up the pathnames if the file contains umlauts.

-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
DEBCHANGE_AUTO_NMU=no
DEBCHANGE_MAINTTRAILER=no
DEBCHANGE_MULTIMAINT_MERGE=yes

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages devscripts depends on:
ii  dpkg-dev  1.20.7.1
ii  fakeroot  1.25.3-1.1
ii  file  1:5.39-3
ii  gnupg 2.2.27-1
ii  gnupg22.2.27-1
ii  gpgv  2.2.27-1
ii  libc6 2.31-9
ii  libfile-dirlist-perl  0.05-2
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.11-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.004004-1
ii  libwww-perl   6.52-1
ii  patchutils0.4.2-1
ii  perl  5.32.1-2
ii  python3   3.9.1-1
ii  sensible-utils0.0.14
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.1.20
ii  curl7.74.0-1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2020.12.24
ii  dput1.1.0
ii  equivs  2.3.1
pn  libdistro-info-perl 
ii  libdpkg-perl1.20.7.1
ii  libencode-locale-perl   1.05-1.1
pn  libgit-wrapper-perl 
pn  libgitlab-api-v4-perl   
ii  liblist-compare-perl0.55-1
ii  liblwp-protocol-https-perl  6.10-1
pn  libsoap-lite-perl   
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 5.07-1
pn  licensecheck
ii  lintian 2.104.0
ii  man-db  2.9.4-1
ii  patch   2.7.6-7
ii  pristine-tar1.49
ii  python3-apt 2.1.7
ii  python3-debian  0.1.39
ii  python3-magic   2:0.4.20-3
ii  python3-requests2.25.1+dfsg-2
pn  python3-unidiff 
pn  python3-xdg 
ii  strace  5.10-1
ii  unzip   6.0-26
ii  wget1.21-1+b1
ii  xz-utils5.2.5-1.0

Versions of packages devscripts suggests:
ii  adequate  0.15.4
ii  at3.1.23-1.1
pn  autopkgtest   
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20180807cvs-2
ii  build-essential   12.9
pn  check-all-the-things  
pn  cvs-buildpackage  
ii  debhelper 13.3.3
pn  devscripts-el 
ii  diffoscope166
pn  disorderfs
pn  dose-extra
pn  duck  
pn  faketime  
pn  gnuplot   
pn  how-can-i-help
pn  libauthen-sasl-perl

Bug#982656: wims-lti: [INTL:pt] Portuguese translation - debconf messages

[Américo Monteiro]

Package: wims-lti
Version: 0.4.4-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for wims-lti's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


wims-lti_0.4.4-1_pt.po.gz
Description: application/gzip

Bug#982630: marked as pending in lintian

[Daniel Kahn Gillmor]

Thanks for the rapid followup, Felix!  I really appreciate your ongoing
attention to detail with lintian.  It's a very useful tool.

On Fri 2021-02-12 19:21:39 +, Felix Lechner wrote:
> Based on the information we have, the unversioned /usr/bin/python is
> going away in the upcoming 'bullseye' release. The corresponding
> changes were made in response to this merge request
>
> https://salsa.debian.org/lintian/lintian/-/merge_requests/334
>
> in this and surrounding commits:
>
> 
> https://salsa.debian.org/lintian/lintian/-/commit/69d52d7b4c9dbf391b23dced6e6de920905f54ac
>
> Please file a bug for the unversioned Python interpreter to be
> recognized as valid, if the information we have about the 'bullseye'
> release is incorrect.

I don't have any more information than you do about the specific plan
for python in bullseye -- but what you're suggesting seems both
plausible and reasonable to me.

I was worried about the intended semantics for what "python" means, but
https://www.python.org/dev/peps/pep-0394/#recommendation has this
recommendation for distributors:

>>> When packaging third party Python scripts, distributors are
>>> encouraged to change less specific shebangs to more specific
>>> ones. This ensures software is used with the latest version of
>>> Python available, and it can remove a dependency on Python 2. The
>>> details on what specifics to set are left to the distributors;
>>> though. Example specifics could include:
>>>
>>> - Changing python shebangs to python3 when Python 3.x is supported.

So this is probably something I should be fixing when packaging gpgme
itself.  Perhaps lintian could include a pointer to this reference in
the description text for example-unusual-interpreter.

Regards,

   --dkg


signature.asc
Description: PGP signature

Bug#982640: [d-i] finish-install: improve understandability of reboot screen

[Holger Wansing]

Hi,

John Paul Adrian Glaubitz  wrote (Fri, 12 Feb 
2021 21:08:14 +0100):
> On 2/12/21 9:00 PM, Holger Wansing wrote:
> > I have prepared a small patch, to improve the understandability of the 
> > screen.
> 
> "+ Then, choose  to reboot."
> 
> I think that sentence sounds a bit weird.
> 
> It's probably better to write just "Please choose  to reboot."

Yes, maybe.
Thanks


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#982655: scrub-obsolete: replace dependencies on transitional or removed packages

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.92
Severity: wishlist

scrub-obsolete should update any build-dependencies, test-dependencies or other
dependencies on either:

 * packages that are transitional and for which the replacement can be derived
 * packages that have been removed but were present in the past and
   that have a single current package that Provides: them


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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.20.5
ii  python3  3.9.1-1
ii  python3-breezy   3.1.0-8
ii  python3-debian   0.1.39
ii  python3-debmutate0.19
ii  python3-distro-info  1.0
ii  python3-dulwich  0.20.15-1
ii  python3-iniparse 0.4-3
ii  python3-ruamel.yaml  0.16.12-2

Versions of packages lintian-brush recommends:
ii  decopy   0.2.4.4-0.1
ii  dos2unix 7.4.1-1
ii  gpg  2.2.27-1
ii  libdebhelper-perl13.3.3
ii  lintian  2.104.0
ii  python3-asyncpg  0.21.0-1+b2
ii  python3-bs4  4.9.3-1
ii  python3-levenshtein  0.12.1-1
ii  python3-pyinotify0.9.6-1.3
ii  python3-toml 0.10.1-1

Versions of packages lintian-brush suggests:
pn  breezy-debian  
pn  gnome-pkg-tools
ii  po-debconf 1.0.21+nmu1
ii  postgresql-common  225

-- no debconf information

Bug#982639: [Pkg-ayatana-devel] Bug#982639: Having an autopkgtest would be useful

[Mike Gabriel]

Hi,

On  Fr 12 Feb 2021 20:51:19 CET, Sebastien Bacher wrote:


Package: ayatana-ido
Version: 0.8.2-1

The package has no autopkgtest, having at least a simple testbuild from
a small example would be useful
(it would also help in getting the stack promoted in Ubuntu)

Thanks,


would it suffice from your PoV if we built examples/menus.c (and  
possibly tried to execute it)?


Mike
--

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

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



pgpaepP3SR2Qs.pgp
Description: Digitale PGP-Signatur

Bug#982654: RFS: qtractor/0.9.20-1 - MIDI/Audio multi-track sequencer application

[Dennis Braun]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: qtractor
   Version : 0.9.20-1
   Upstream Author : Rui Nuno Capela 
 * URL : https://qtractor.sourceforge.io/
 * License : GPL-2+, other, FSFAP
 * Vcs : https://salsa.debian.org/multimedia-team/qtractor
   Section : sound

It builds those binary packages:

  qtractor - MIDI/Audio multi-track sequencer application

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/q/qtractor/qtractor_0.9.20-1.dsc

Changes since the last upload:

 qtractor (0.9.20-1) unstable; urgency=medium
 .
   * New upstream version 0.9.20
 + Fix FTCBFS (Closes: #982462)
   * d/copyright: Update year and add myself
   * Drop gtk Depends for now, gtk3 still not supported
   * Fix build without gtk2

Regards,
Dennis

Bug#982464: subversion: CVE-2020-17525: Remote unauthenticated denial-of-service in Subversion mod_authz_svn

[James McCoy]

On Thu, Feb 11, 2021 at 06:21:08AM +0100, Salvatore Bonaccorso wrote:
> Hi James,
> 
> On Wed, Feb 10, 2021 at 08:49:39PM -0500, James McCoy wrote:
> > On Wed, Feb 10, 2021 at 09:21:54PM +0100, Salvatore Bonaccorso wrote:
> > > Hi James,
> > > 
> > > On Wed, Feb 10, 2021 at 03:20:22PM -0500, James McCoy wrote:
> > > > On Wed, Feb 10, 2021 at 03:36:11PM +0100, Salvatore Bonaccorso wrote:
> > > > > The following vulnerability was published for subversion.
> > > > > 
> > > > > CVE-2020-17525[0]:
> > > > > | Remote unauthenticated denial-of-service in Subversion mod_authz_svn
> > > > 
> > > > I'll have uploads ready for this tonight to both sid and buster.  I'll
> > > > send the debdiff for review before uploading to buster-security.
> > > 
> > > Ack, thank you!
> > 
> > Buster debdiff attached.
> 
> Looks good to me. Did you got an explicit chance to test the issue
> triggering setup?

I was able to verify with a new test upstream provided.  Backporting and
enabling that test in this upload is too disruptive, though.

I'll look into doing that for future sid uploads, as I see that the
current packaging is missing protocol specific runs of the test suite.

> In any case please feel free to upload to
> security-master.

Uploaded.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#982640: [d-i] finish-install: improve understandability of reboot screen

[Holger Wansing]

Package: finish-install
Severity: wishlist
Tags: patch


Hi,

Jeffrey Walton  wrote (Tue, 9 Feb 2021 04:27:46 -0500):
> Hi Everyone,
> 
> I was trying to follow John Paul Adrian Glaubitz instructions for
> installing Debian 10 on a PowerMac G5. The instructions are at
> https://lists.debian.org/debian-powerpc/2021/02/msg00011.html. The
> instructions say to forgo the reboot after installation and perform
> some extra steps.
> 
> At the end of the installation, the last screen told me a reboot was
> needed. The last screen gave me two choices -  or .
> I selected  because I had the extra steps to perform. I
> planned on reboot after performing the extra steps.
> 
>  unexpectedly rebooted the machine and I lost the chance to
> perform the extra steps. (Now I'm stuck at an OpenFirmware prompt that
> results in a kernel load failure/corrupt image error message for every
> command I enter. Sigh...)
> 
> >From a UX perspective, the last screen has a lot of opportunity for
> improvement. There's no indication what  does or where it
> "goes back" to. It is also not clear that "going back" does not undo
> the most recent steps performed by the installer. Finally, there's no
> indication  will immediately reboot the machine.
> 
> I believe the last screen should say something like:
> 
> Installation is complete. A reboot is required.
> If you select  then a reboot will happen now.
> If you select  then you will have to manually
> reboot later.
> 
> Would you like to Reboot now?
> 
> 
> 
> Changing the text on the last screen will dramatically improve the UX
> experience. It tells the user what is going to happen. It also offers
> the user a chance to avoid the reboot .

I have prepared a small patch, to improve the understandability of the screen.

And turning this into a bugreport against finish-install.


Holger




-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/debian/changelog b/debian/changelog
index 6db2eef..0f83c47 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+finish-install (2.104) UNRELEASED; urgency=medium
+
+  * Improve understandability of reboot screen.
+
+ -- Holger Wansing   Fri, 12 Feb 2021 20:53:45 +0100
+
 finish-install (2.103) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/finish-install.templates b/debian/finish-install.templates
index 40f25d2..57e5de6 100644
--- a/debian/finish-install.templates
+++ b/debian/finish-install.templates
@@ -37,11 +37,13 @@ _Description: Rebooting into your new system...
 
 Template: finish-install/reboot_in_progress
 Type: note
+# Translators: translate  identical to the translation of the button!
 # :sl1:
 _Description: Installation complete
  Installation is complete, so it is time to boot into your new system.
  Make sure to remove the installation media, so that
  you boot into the new system rather than restarting the installation.
+ Then, choose  to reboot.
 
 Template: finish-install/keep-consoles
 Type: boolean

Bug#971019: accidental chaining of debconf commands

[Cyril Brulebois]

Control: severity -1 important

(cc-ing Paul for information, due to interest in RC bugs)

Hello Wilco,

Wilco Baan Hofman  (2020-09-26):
> Package: cdebconf
> Version: 0.249
> Severity: critical
> 
> I have a problem with the debian installer, at the finish-install
> stage in the udeb clock-setup.

I can't replicate it with a current-ish installation image
(debian-10.7.0-amd64-netinst.iso)

> The interaction in the syslog during install (manually copied from screen):
> finish-install: info: Running /usr/lib/finish-install.d/10clock-setup
> debconf: --> FGET clock-setup/utc seen
> debconf: <-- 0 true
> debconf: --> SET clock-setup/utc true INPUT low clock-setup/utc
> debconf: <-- 0 value set
> debconf: --> GO
> debconf: <-- 0 ok
> debconf: --> GET clock/setup/utc
> debconf: <-- 0 true INPUT low clock-setup/utc
> debconf: --> GET clock-setup/system-time-changed
> debconf: <-- 0 false
> finish-install: /usr/lib/finish-install.d/10clock-setup: return: line
> 46: illegal number: INPUT
> finish-install: warning: /usr/lib/finish-install.d/10clock-setup
> returned error code 2

> For reproducing the error if that's required:
> This is a preseeded Debian Buster install on VMWare ESXi, relevant
> preseed config:

I don't have VMWare ESXi, but I couldn't replicate this on bullseye's
QEMU.

> ### Clock and timezone setup
> # Controls whether or not the hardware clock is set to UTC.
> d-i clock-setup/utc boolean true
> 
> # You may set this to any valid setting for $TZ; see the contents of
> # /usr/share/zoneinfo/ for valid values.
> d-i time/zone string Europe/Amsterdam
> 
> # Controls whether to use NTP to set the clock during the install
> d-i clock-setup/ntp boolean true
> # NTP server to use. The default is almost always fine here.
> #d-i clock-setup/ntp-server string ntp.example.org

I've added a few variables on my own, just to make sure I wouldn't have
to answer too many questions. The full file is attached for reference.

d-i started from the “Automated Graphical Install” menu with the
following additions on the kernel command line:

url=https://mraw.org/~kibi/preseed.cfg DEBCONF_DEBUG=developer

with a 5G qemu-img-created as hda disk, and the iso as a cdrom.

> I can't really see why this path would be hit, "db_fget
> clock-setup/utc seen" should return true and this whole thing should
> be skipped, but somehow that is not how it works out.. and the debconf
> confmodule just chains 2 commands together without any separation or
> wait time, causing an error during finish-install, effectively halting
> all installs.
> 
> seems like either a clear separator is missing (newline?) or a buffer
> must be flushed after every SET..

That's quite surprising, given that's not exactly a new feature, or a
fast-paced changing codebase…

I'm lowering severity for the time being, I think we'd need a way to
reproduce this before proceeding any further (that wouldn't involve a
proprietary hypervisor as far as I'm concerned).


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


signature.asc
Description: PGP signature

Bug#982632: 0.1.0 release is outdated and incompatible with podman 3.0

[Dmitry Smirnov]

On Saturday, 13 February 2021 4:38:31 AM AEDT Faidon Liambotis wrote:
> As discussed recently in debian-devel, nomad-driver-podman 0.1.0 works
> with the podman Varlink API, which does not exist anymore in podman 3.0,
> making this package unusable for all users (at least AIUI).
> 
> A new upstream release of nomad-driver-podman, 0.2.0, however, was
> released with its main feature being support for the HTTP API.
> 
> Dmitry, I know you know this, but just filing this RC bug to avoid us
> collectively forgetting about this and releasing bullseye with a package
> combination that isn't functional for users. Hope this is helpful!

Yes, no worries. Thanks for opening this, Faidon.

-- 
Best wishes,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Do your duty as you see it, and damn the consequences.
-- George S. Patton

---[ COVID-19(84) ]---

A study on infectivity of asymptomatic SARS-CoV-2 carriers, concludes weak
transmission. "The median contact time for patients was four days and that
for family members was five days."
-- https://pubmed.ncbi.nlm.nih.gov/32513410/


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

Bug#982653: ansible-lint: Switch dependency from ansible to ansible-base?

[Guillem Jover]

Package: ansible-lint
Version: 4.3.7-1
Severity: wishlist

Hi!

The ansible package has been split into ansible (where all the
collections can be found, and which is rather heavy), and
ansible-base where the core of ansible can be found.

It seems to me that ansible-lint can work with just ansible-lint?
If so it would be nice to change the dependency to not require the
heavy ansible package.

Thanks,
Guillem

Bug#982610: mark lmodern Multi-Arch: foreign

[Hilmar Preuße]

Am 12.02.2021 um 14:31 teilte Helmut Grohne mit:

Hi,


Please consider applying the attached patch.


Fixed in our repository.

Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#982620: texinfo has mailcap entries with quoted %-escapes

[Hilmar Preuße]

Am 12.02.2021 um 15:56 teilte Marriott NZ mit:

Hi,


Dear Maintainer,
the texinfo package has mailcap entries with quoted %-escapes. That
is considered unsafe. Proper escaping should be left to the programs
using the entry.

Fixed in our repo, many thanks! Should I make an upload before bullseye 
for this?


Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#980583: ruby-coffee-rails: FTBFS: tests failed

[Ivo De Decker]

Control: tags -1 patch

Hi,

On Wed, Jan 20, 2021 at 08:24:51PM +0100, Lucas Nussbaum wrote:
> > Failure:
> > AssetsTest#test_coffee-script.js_is_included_in_Sprockets_environment 
> > [/<>/test/assets_test.rb:29]:
> > Expected /CoffeeScript\ Compiler/ to match
[long line truncated]

> > rails test test/assets_test.rb:25

Looking at the timing of the failure on
https://tests.reproducible-builds.org/debian/history/ruby-coffee-rails.html
I suspect this is triggered by the coffeescript upload.

This can be fixed by this obvious patch:

diff --git a/test/assets_test.rb b/test/assets_test.rb
index e125eac..9953a7c 100644
--- a/test/assets_test.rb
+++ b/test/assets_test.rb
@@ -26,7 +26,7 @@ class AssetsTest < ActiveSupport::TestCase
 @app.assets["coffee-script"].write_to("#{tmp_path}/coffee-script.js")
 
 assert_match "/lib/assets/javascripts/coffee-script.js.erb", 
@app.assets["coffee-script"].pathname.to_s
-assert_match "CoffeeScript Compiler", 
File.open("#{tmp_path}/coffee-script.js").read
+#assert_match "CoffeeScript Compiler", 
File.open("#{tmp_path}/coffee-script.js").read
   end
 
   def tmp_path


It might be useful to replace the match with something else to detect
coffeescript.

Cheers,

Ivo

Bug#930005: regina-rexx: rexxutil error

[Alen Zekulic]

On Fri, Feb 12, 2021 at 13:25:23 +0100, Agustin Martin wrote:

> Alen, I plan to upload a NMU with this changes and may be some minor
> issues. Even if I have not written rexx for years I think it would be
> a pity to have this package with this open bug.

I agree, please go ahead!

> Also, one issue with this package is that Debian build system is
> ancient, even pre-debhelper. This makes everything a nightmare. I
> have been playing with a migration to traditional (no dh sequencer)
> debhelper. This should fix another bug report about build
> reproduciibility. I am aware that this is a rather invasive change,
> but I think is required to make contributors life easier, let me know
> your POV.

I planed to migrate my debian/rules to debhelper too.

> Other thing I noticed is that this package has no repo under
> salsa. I can prepare a git repo with regina history and put it under
> salsa/debian group. Alen, please tell me if you object to this, I
> consider it important and will proceed unless you object explicitly.

Any help is greatly appreciated, I have no objection, quite the
contrary!

> By the way, upstream is active and there are new versions available,
> although I will focus on current upstream version in Debian.

Mark and I are in contact. We plan to roll out the latest releases of
Regina REXX (3.9.4) and The Hessling Editor (3.3) as soon as possible.

Thanks,

-- 
Alen Zekulic 

Bug#982652: apt: ship systemd.timer disabled by default

[Jochen Sprickerhof]

Package: apt
Version: 2.1.20
Severity: wishlist

Hi,

please ship apt-daily.timer and apt-daily-upgrade.timer disabled by
default and have unattended-upgrades enable them in postinst.

As just discussed in #debian-devel.

Thanks!

Bug#917851: Failed build for seqan2 on i386

[Aaron M. Ucko]

Andreas Tille  writes:

> But other 32bit architectures like armel and armhf are passing[2].  So I
> fail to see why exactly i386 is failing.  Is this possibly an effect of
> bug #917851?

Probably not; dropping the bug to a Bcc.  Experimentation in an i386
chroot reveals the problem to be specifically with yara_mapper, which
https://salsa.debian.org/med-team/seqan2/-/blob/master/debian/patches/skip-some-apps-on-some-archs
explicitly excludes (along with yara_indexer) on several other 32-bit
platforms.  We could go the same route for i386, but AFAICT it suffices
to drop the optimization level back down to -O2 for this specific
application, by adding

# Drop back from global -O3 on i386 to avoid
# "virtual memory exhausted: Operation not permitted"
if ("$ENV{DEB_BUILD_ARCH}" STREQUAL "i386")
target_compile_options (yara_mapper PRIVATE "-O2")
endif ()

to apps/yara/CMakeLists.txt following the add_executable call for
yara_mapper.  (If and when debian/rules honors noopt, we should further
conditionalize this call accordingly, but I'm not familiar enough with
cmake to come up with the correct syntax offhand.)  We could perhaps try
doing the same for other affected platforms in an upload to
experimental.

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

Bug#978440: RFS: paperwork/2.0.2-1 -- Personal document manager

[Jérémy Lal]

Hi Thomas,

i've successfully built paperwork 2.0.2 in a clean sid chroot,
using gbp buildpackage (and sbuild).
The package is lintian clean.

However, i don't quite understand the usefulness of these packages:
- openpaperwork-core
- openpaperwork-core-doc
- openpaperwork-gtk
- openpaperwork-gtk-doc

I've installed openpaperwork-gtk and it seems it doesn't depend on
paperwork-gtk,
but maybe i'm missing some documentation, and the long package description
of
openpaperwork-gtk
doesn't help either.

Manually i had to do
dpkg -i paperwork-gtk_2.0.2-1_all.deb paperwork-backend_2.0.2-1_all.deb
 openpaperwork-core_2.0.2-1_all.deb
to get it, and that somehow looks wrong.

On the other hand, once installed, it seems to be working all right. I'll
try to do actual scanning with it later.

Jérémy

PS:

i really think it would be a bonus to Bullseye to have paperwork 2.
Maybe debian-release will allow it if we ensure the debian packaging is all
right very quickly.

Bug#963319: ruby-em-synchrony: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

[Ivo De Decker]

Hi,

On Fri, Feb 05, 2021 at 01:46:46PM +0100, Ivo De Decker wrote:
> error: 'Access denied for user 'root'@'localhost''
> 2021-01-21 13:20:47 5 [Warning] Access denied for user 'root'@'localhost'
> ERROR 1698 (28000): Access denied for user 'root'@'localhost'

Note that this seems very similar to #978251. As described in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978251#16
the issue is probably caused by running the tests under fakeroot.

> It seems ruby-em-synchrony is only used as a build-dependency for
> ruby-faraday. That build-dependency can be removed by disabling the
> em-synchrony tests (and updating the coverage settings). Maybe that should be
> done, to allow em-synchrony to be removed from bullseye?

Cheers,

Ivo

Bug#982146: generating an initrd yields multiple "dracut-install: No SOURCE argument given" errors

[Thomas Lange]

I cannot confirm this problem.
It works without problems on a bullseye VM.

Maybe you can strace the dracut call and see which parameters are
given to the dracut-install call.

-- 
viele Grüße Thomas

Bug#982598: incomplete logs for autopkg tests

[Holger Levsen]

On Fri, Feb 12, 2021 at 08:35:11PM +0100, Paul Gevers wrote:
> Unfortunately, we're hitting infrastructure issues if we don't cap the
> logs [1]. However, I think we should save the last part (and not the
> first part) if we have to cap, because normally the failure happens in
> the end.

I'd keep a bit from the beginning and a bigger bit from the end. Often the
beginning is useful too.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄


signature.asc
Description: PGP signature

Bug#982650: mark golang-github-dcso-fluxline-dev Multi-Arch: foreign

[Helmut Grohne]

Package: golang-github-dcso-fluxline-dev
Version: 0.0~git20200907.78686e5-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:ethflux src:fever

The affected packages cannot satisfy their cross Build-Depends, because
their dependency on golang-github-dcso-fluxline-dev is not satisfiable.
In general, Architecture: all packages can never satisfy cross
Build-Depends unless marked Multi-Arch: foreign or annotated :native. In
this case, the foreign marking is reasonable, because
golang-github-dcso-fluxline-dev entirely lacks maintainer scripts and
all of its dependencies are already marked Multi-Arch: foreign. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru 
golang-github-dcso-fluxline-0.0~git20200907.78686e5/debian/changelog 
golang-github-dcso-fluxline-0.0~git20200907.78686e5/debian/changelog
--- golang-github-dcso-fluxline-0.0~git20200907.78686e5/debian/changelog
2020-09-07 09:02:12.0 +0200
+++ golang-github-dcso-fluxline-0.0~git20200907.78686e5/debian/changelog
2021-02-12 18:04:00.0 +0100
@@ -1,3 +1,10 @@
+golang-github-dcso-fluxline (0.0~git20200907.78686e5-1.1) UNRELEASED; 
urgency=medium
+
+  * Non-maintainer upload.
+  * Mark golang-github-dcso-fluxline-dev Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 12 Feb 2021 18:04:00 +0100
+
 golang-github-dcso-fluxline (0.0~git20200907.78686e5-1) unstable; 
urgency=medium
 
   * New upstream snapshot.
diff --minimal -Nru 
golang-github-dcso-fluxline-0.0~git20200907.78686e5/debian/control 
golang-github-dcso-fluxline-0.0~git20200907.78686e5/debian/control
--- golang-github-dcso-fluxline-0.0~git20200907.78686e5/debian/control  
2020-09-06 17:20:58.0 +0200
+++ golang-github-dcso-fluxline-0.0~git20200907.78686e5/debian/control  
2021-02-12 18:03:59.0 +0100
@@ -17,6 +17,7 @@
 
 Package: golang-github-dcso-fluxline-dev
 Architecture: all
+Multi-Arch: foreign
 Depends: ${shlibs:Depends},
  ${misc:Depends},
  golang-github-showmax-go-fqdn-dev

Bug#982649: golang-github-hanwen-usb-dev: drop unnecessary golang-any runtime dependency

[Helmut Grohne]

Package: golang-github-hanwen-usb-dev
Version: 0.0~git20141217.69aee45-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:go-mtpfs

go-mtpfs cannot be cross built from source, because its dependency on
golang-github-hanwen-usb-dev cannot be satisfied. Long story short, it
cannot be annotated Multi-Arch: foreign due to the golang-any runtime
dependency. This dependency seems to be cruft and should not be required
for golang-*-dev packages. Instead consumers should issue their own
go compiler dependency. Please consider applying the attached patch to
drop the dependency.

Helmut
diff --minimal -Nru 
golang-github-hanwen-usb-0.0~git20141217.69aee45/debian/changelog 
golang-github-hanwen-usb-0.0~git20141217.69aee45/debian/changelog
--- golang-github-hanwen-usb-0.0~git20141217.69aee45/debian/changelog   
2021-01-28 00:25:44.0 +0100
+++ golang-github-hanwen-usb-0.0~git20141217.69aee45/debian/changelog   
2021-02-12 22:11:08.0 +0100
@@ -1,3 +1,10 @@
+golang-github-hanwen-usb (0.0~git20141217.69aee45-2.1) UNRELEASED; 
urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unnecessary golang-any runtime dependency. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 12 Feb 2021 22:11:08 +0100
+
 golang-github-hanwen-usb (0.0~git20141217.69aee45-2) unstable; urgency=medium
 
   [ Jelmer Vernooij ]
diff --minimal -Nru 
golang-github-hanwen-usb-0.0~git20141217.69aee45/debian/control 
golang-github-hanwen-usb-0.0~git20141217.69aee45/debian/control
--- golang-github-hanwen-usb-0.0~git20141217.69aee45/debian/control 
2021-01-28 00:25:44.0 +0100
+++ golang-github-hanwen-usb-0.0~git20141217.69aee45/debian/control 
2021-02-12 22:11:06.0 +0100
@@ -17,7 +17,7 @@
 
 Package: golang-github-hanwen-usb-dev
 Architecture: all
-Depends: golang-any, ${misc:Depends}, ${shlibs:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: CGO bindings for libusb
  These are CGO bindings for libusb, created and tested on Linux.
  .

Bug#978251: ruby-mysql2: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

[Ivo De Decker]

Hi,

On Sat, Dec 26, 2020 at 10:48:36PM +0100, Lucas Nussbaum wrote:
> Source: ruby-mysql2
> Version: 0.5.3-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201226 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > + cleanup
> > + /usr/bin/mysqladmin --user=root --socket=/tmp/tmp.g8cXe135ad/mysql.sock 
> > shutdown
> > 2020-12-26 15:17:41 9 [Warning] Access denied for user 'root'@'localhost'
> > /usr/bin/mysqladmin: connect to server at 'localhost' failed
> > error: 'Access denied for user 'root'@'localhost''

It looks like the tests don't work anymore under fakeroot. When trying to
connect using mysqladmin under fakeroot, this fails. I tried connecting
without fakeroot, which works.

Looking at the timing of the failure on
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-mysql2.html
I suspect that this is triggered by mariadb 10.5.

I'm not sure what needs to be changed to make it work under fakeroot. One
option is to start mysqld with --skip-grant-tables to disable permission
checks. This seems to work for many tests, but the tests that actually test
permissions and expect 'permission denied' fail in that case. Maybe it works
when doing a network connection and users with login/pw.

Cheers,

Ivo

Bug#971019: accidental chaining of debconf commands

[Paul Gevers]

Hi,

Excuse me if I totally got this wrong, but to an outsider this looks
like a typo...

On Sat, 26 Sep 2020 12:17:13 +0200 Wilco Baan Hofman
 wrote:
> debconf: --> FGET clock-setup/utc seen ^ hyphen
> debconf: <-- 0 true
> debconf: --> SET clock-setup/utc true INPUT low clock-setup/utc   
>  ^ hyphen   ^ hyphen
> debconf: <-- 0 value set
> debconf: --> GO
> debconf: <-- 0 ok
> debconf: --> GET clock/setup/utc
^ slash
> debconf: <-- 0 true INPUT low clock-setup/utc
 ^ hyphen
> debconf: --> GET clock-setup/system-time-changed
> debconf: <-- 0 false

> For reproducing the error if that's required:
> This is a preseeded Debian Buster install on VMWare ESXi, relevant
> preseed config:
> 
> ### Clock and timezone setup
> # Controls whether or not the hardware clock is set to UTC.
> d-i clock-setup/utc boolean true
   ^ hyphen
Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#924482:

[Arndt Roth]

This bug is definitely still open. I ran into the same exact issue today.

Bug#982640: [d-i] finish-install: improve understandability of reboot screen

[Brian Potkin]

On Fri 12 Feb 2021 at 21:26:50 +0100, Holger Wansing wrote:

> John Paul Adrian Glaubitz  wrote (Fri, 12 Feb 
> 2021 21:08:14 +0100):
> > On 2/12/21 9:00 PM, Holger Wansing wrote:
> > > I have prepared a small patch, to improve the understandability of the 
> > > screen.
> > 
> > "+ Then, choose  to reboot.".
> >
> > I think that sentence sounds a bit weird.

The comma isn't needed

> > It's probably better to write just "Please choose  to reboot."

Yes, but why change anything?   
  

  
  ...Installation is complete, so it is time to boot into your  
  
  new system.   
  

  
Isn't that clear enough? The only other choice is .

> Yes, maybe.

The link the OP quoted also has 
  

  
  Switch to another console...  
  

  
I find that very clear too.

-- 
Brian.

Bug#982647: spyder-reports FTBFS with Spyder 4.2.1

[Adrian Bunk]

Source: spyder-reports
Version: 0.1.1-4
Severity: serious
Tags: ftbfs

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

...
 ERRORS 
_ ERROR at setup of test_basic_initialization __

obj = 
name = 'initialize_plugin', ann = 'spyder_reports.reportsplugin.ReportsPlugin'

def annotated_getattr(obj: object, name: str, ann: str) -> object:
try:
>   obj = getattr(obj, name)
E   AttributeError: type object 'ReportsPlugin' has no attribute 
'initialize_plugin'

/usr/lib/python3/dist-packages/_pytest/monkeypatch.py:83: AttributeError

The above exception was the direct cause of the following exception:

qtbot = 
monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 0x7fee78219310>

@pytest.fixture
def setup_reports(qtbot, monkeypatch):
"""Set up the Reports plugin."""
>   monkeypatch.setattr(
'spyder_reports.reportsplugin.ReportsPlugin.initialize_plugin',
lambda self: None)

spyder_reports/tests/test_plugin.py:23: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3/dist-packages/_pytest/monkeypatch.py:101: in derive_importpath
annotated_getattr(target, attr, ann=module)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

obj = 
name = 'initialize_plugin', ann = 'spyder_reports.reportsplugin.ReportsPlugin'

def annotated_getattr(obj: object, name: str, ann: str) -> object:
try:
obj = getattr(obj, name)
except AttributeError as e:
>   raise AttributeError(
"{!r} object at {} has no attribute {!r}".format(
type(obj).__name__, ann, name
)
) from e
E   AttributeError: 'wrappertype' object at 
spyder_reports.reportsplugin.ReportsPlugin has no attribute 'initialize_plugin'

/usr/lib/python3/dist-packages/_pytest/monkeypatch.py:85: AttributeError

--- coverage: platform linux, python 3.9.1-final-0 ---
Name Stmts   Miss  Cover   
Missing
--
spyder_reports/__init__.py   4  0   100%
spyder_reports/_version.py   3  0   100%
spyder_reports/reportsplugin.py18212929%   
44-45, 60-61, 65-66, 104-132, 137, 141, 145-162, 166-172, 176, 180, 188-193, 
199-203, 207-208, 212-218, 233-268, 272-276, 280-300, 312-355
spyder_reports/tests/__init__.py 1  0   100%
spyder_reports/tests/test_plugin.py17815016%   
26-39, 50-53, 58-61, 66-82, 87-91, 96-102, 107-116, 121-153, 158-177, 182-201, 
207-230, 235-239, 244-251, 260-304, 312-315, 320-332, 336
spyder_reports/utils/__init__.py 3  0   100%
spyder_reports/widgets/__init__.py   1  0   100%
spyder_reports/widgets/reportsgui.py   115 8724%   34, 
42-84, 88-111, 115-122, 131-136, 145-147, 160-165, 169-171, 175-182, 186-187, 
191-194, 209
spyder_reports/widgets/tests/__init__.py 1  0   100%
spyder_reports/widgets/tests/test_report_widget.py 114 8922%   
23-33, 39-41, 47-52, 58-68, 73, 82-90, 95-107, 117-133, 138-151, 156-163, 
168-179, 184-186, 191-206, 210
--
TOTAL  60245524%

= slowest 10 durations =
0.93s setup
.pybuild/cpython3_3.9_spyder-reports/build/spyder_reports/tests/test_plugin.py::test_basic_initialization

(1 durations < 0.005s hidden.  Use -vv to show these durations.)
!! stopping after 1 failures !!!
=== 1 error in 3.67s ===
E: pybuild pybuild:353: test: plugin distutils failed with: exit code=1: cd 
/build/1st/spyder-reports-0.1.1/.pybuild/cpython3_3.9_spyder-reports/build; 
python3.9 -m pytest 
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 
returned exit code 13
make: *** [debian/rules:10: binary] Error 25

Bug#982646: routine-update errors out with message "E: Uscan did not return tarball name"

[Rogério Brito]

Package: routine-update
Version: 0.0.6
Severity: normal

Dear people,

I'm using routine-update to automate some packaging of mine and, while I'm
still adapting, it works great.

That being said, I'm getting the following error message when I invoke
routine-update on a package where I'm working:

,[ routine-update  ]
| gbp:info: Fetching from default remote for each branch
| gbp:info: Branch 'master' is already up to date.
| gbp:info: Branch 'upstream' is already up to date.
| 6b28db3bf21694f2dff16e367e17d19cefe2470e
| E: Uscan did not return tarball name
`

In fact, I have already run routine-update, but stopped to change some stuff
manually (nothing that I believe that would affect the way that it works)
and routine-update had already imported the newest version of the tarball.

The output that I get from uscan is:

,[ uscan --report-status ]
| uscan info: uscan (version 2.20.5) See uscan(1) for help
| uscan info: Scan watch files in .
| uscan info: Check debian/watch and debian/changelog in .
| uscan info: package="jbig2enc" version="0.29+dfsg1-1~1.gbp7c61b3" (as seen in 
debian/changelog)
| uscan info: package="jbig2enc" version="0.29+dfsg1" (no epoch/revision)
| uscan info: ./debian/changelog sets package="jbig2enc" version="0.29+dfsg1"
| uscan info: Process watch file at: debian/watch
| package = jbig2enc
| version = 0.29+dfsg1
| pkg_dir = .
| uscan info: opts: 
dversionmangle=s/\+dfsg\d*$//,repacksuffix=+dfsg1,filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/jbig2enc-$1\.tar\.gz/
| uscan info: line: https://github.com/agl/jbig2enc/tags .*/v?(\d\S+)\.tar\.gz
| uscan info: Parsing dversionmangle=s/\+dfsg\d*$//
| uscan info: Parsing repacksuffix=+dfsg1
| uscan info: Parsing 
filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/jbig2enc-$1\.tar\.gz/
| uscan info: line: https://github.com/agl/jbig2enc/tags .*/v?(\d\S+)\.tar\.gz
| uscan info: Last orig.tar.* tarball version (from debian/changelog): 
0.29+dfsg1
| uscan info: Last orig.tar.* tarball version (dversionmangled): 0.29
| uscan info: Requesting URL:
|https://github.com/agl/jbig2enc/tags
| uscan info: Matching pattern:
|(?:(?:https://github.com)?\/agl\/jbig2enc\/)?.*/v?(\d\S+)\.tar\.gz
| uscan info: Found the following matching hrefs on the web page (newest first):
|https://github.com/agl/jbig2enc/archive/0.29.tar.gz (0.29) index=0.29-1 
|https://github.com/agl/jbig2enc/archive/0.29.tar.gz (0.29) index=0.29-1 
|https://github.com/agl/jbig2enc/archive/0.28-dist.tar.gz (0.28-dist) 
index=0.28-dist-1 
|https://github.com/agl/jbig2enc/archive/0.28-dist.tar.gz (0.28-dist) 
index=0.28-dist-1 
|https://github.com/agl/jbig2enc/archive/0.28.tar.gz (0.28) index=0.28-1 
|https://github.com/agl/jbig2enc/archive/0.28.tar.gz (0.28) index=0.28-1 
|https://github.com/agl/jbig2enc/archive/0.27.tar.gz (0.27) index=0.27-1 
|https://github.com/agl/jbig2enc/archive/0.27.tar.gz (0.27) index=0.27-1 
|https://github.com/agl/jbig2enc/archive/0.26.tar.gz (0.26) index=0.26-1 
|https://github.com/agl/jbig2enc/archive/0.26.tar.gz (0.26) index=0.26-1 
|https://github.com/agl/jbig2enc/archive/0.23.tar.gz (0.23) index=0.23-1 
|https://github.com/agl/jbig2enc/archive/0.23.tar.gz (0.23) index=0.23-1 
|https://github.com/agl/jbig2enc/archive/0.22.tar.gz (0.22) index=0.22-1 
|https://github.com/agl/jbig2enc/archive/0.22.tar.gz (0.22) index=0.22-1 
|https://github.com/agl/jbig2enc/archive/0.21.tar.gz (0.21) index=0.21-1 
|https://github.com/agl/jbig2enc/archive/0.21.tar.gz (0.21) index=0.21-1 
|https://github.com/agl/jbig2enc/archive/0.2.tar.gz (0.2) index=0.2-1 
|https://github.com/agl/jbig2enc/archive/0.2.tar.gz (0.2) index=0.2-1 
|https://github.com/agl/jbig2enc/archive/0.1.tar.gz (0.1) index=0.1-1 
|https://github.com/agl/jbig2enc/archive/0.1.tar.gz (0.1) index=0.1-1 
| uscan info: Looking at $base = https://github.com/agl/jbig2enc/tags with
| $filepattern = .*/v?(\d\S+)\.tar\.gz found
| $newfile = https://github.com/agl/jbig2enc/archive/0.29.tar.gz
| $newversion  = 0.29
| $lastversion = 0.29+dfsg1
| uscan info: Matching target for downloadurlmangle: 
https://github.com/agl/jbig2enc/archive/0.29.tar.gz
| uscan info: Upstream URL(+tag) to download is identified as
https://github.com/agl/jbig2enc/archive/0.29.tar.gz
| uscan info: Matching target for filenamemangle: 
https://github.com/agl/jbig2enc/archive/0.29.tar.gz
| uscan info: Filename (filenamemangled) for downloaded file: 
jbig2enc-0.29.tar.gz
| uscan info: Newest version of jbig2enc on remote site is 0.29, local version 
is 0.29+dfsg1
|  (mangled local version is 0.29)
| uscan info:  => Package is up to date from:
|  => https://github.com/agl/jbig2enc/archive/0.29.tar.gz
| uscan info: Scan finished
`

Is there anything that can be done to fix this? Am I using the tool
incorrectly?


Thanks,

Rogério Brito.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: 

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Bernhard Übelacker]

Am 12.02.21 um 16:06 schrieb Drew Parsons:


That could be the mismatch, if gmsh used its own copy of eigen different 
from 3.3.9.  Alternatively if libdolfinx-dev was built against an older 
version of eigen then it might make a discrepancy.


Dolfinx has just been updated in unstable. Bernhard, you could check if 
the rebuild for this new version fixes your problem.  But likely we'll 
want to apply Christophe's flag to the gmsh build.


Drew




Hello Drew,
I updated just all dolfinx packages to 2019.2.0~git20210130.c14cb0a-3.
(That drew updates for libbasix0 and libpetsc.)

But the fault does appear there too.

Kind regards,
Bernhard




# dpkg -l | grep -E "dolfinx|eigen3|gmsh" | LANG=C sort -k3b,3b -k2b,2b
ii  dolfinx-doc2019.2.0~git20210130.c14cb0a-3 all   
   Documentation and demo programs for DOLFIN
ii  libdolfinx-dev 2019.2.0~git20210130.c14cb0a-3 all   
   Shared links and header files for DOLFIN
ii  libeigen3-dev  3.3.9-2all   
   lightweight C++ template library for linear algebra
ii  gmsh   4.7.1+ds1-2amd64 
   Three-dimensional finite element mesh generator


$ python3 /usr/share/dolfinx/demo-python/gmsh/demo_gmsh.py
double free or corruption (out)
[debian:89745] *** Process received signal ***

(rr) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f5a72be4537 in __GI_abort () at abort.c:79
#2  0x7f5a72c3d768 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f5a72d4be31 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x7f5a72c44a5a in malloc_printerr (str=str@entry=0x7f5a72d4e210 "double free 
or corruption (out)") at malloc.c:5347
#4  0x7f5a72c46088 in _int_free (av=0x7f5a72d7db80 , p=0x1df8070, 
have_lock=) at malloc.c:4314
#5  0x7f5a6304fad8 in Eigen::internal::aligned_free (ptr=) 
at ./contrib/eigen/Eigen/src/Core/util/Memory.h:177
#6  Eigen::internal::conditional_aligned_free (ptr=) at 
./contrib/eigen/Eigen/src/Core/util/Memory.h:230
#7  Eigen::internal::conditional_aligned_delete_auto (size=, ptr=) at ./contrib/eigen/Eigen/src/Core/util/Memory.h:416
#8  Eigen::DenseStorage::~DenseStorage (this=0x7ffc1434ab18, 
__in_chrg=) at ./contrib/eigen/Eigen/src/Core/DenseStorage.h:542

Bug#982645: CVE-2018-3640 on N3160

[Kurt Roeckx]

Package: intel-microcode
Version: 3.20201118.1~deb10u1

Hi,

spectre-meltdown-checker reports:
CVE-2018-3640 aka 'Variant 3a, rogue system register read'
* CPU microcode mitigates the vulnerability:  NO
> STATUS:  VULNERABLE  (an up-to-date CPU microcode is needed to mitigate this 
> vulnerability)

/proc/cpuinfo says:
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 76
model name  : Intel(R) Celeron(R) CPU  N3160  @ 1.60GHz
stepping: 4
microcode   : 0x411
cpu MHz : 700.500
cache size  : 1024 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 11

dmesg reports:
[0.00] microcode: microcode updated early to revision 0x411, date = 
2019-04-23
[...]
[2.012058] microcode: sig=0x406c4, pf=0x1, revision=0x411

Can you clarify if a microcode update is missing, just not available
or that spectre-meltdown-checker is wrong?


Kurt

Bug#982580: netty: CVE-2021-21290

[Salvatore Bonaccorso]

hey Markus,

[Adding CC to t...@s.do so we can better distribute load on requests]

On Fri, Feb 12, 2021 at 08:31:11PM +0100, Markus Koschany wrote:
> Control: owner -1 !
> 
> Hi Salvatore,
> 
> Am Freitag, den 12.02.2021, 07:42 +0100 schrieb Salvatore Bonaccorso:
> > Source: netty
> > Version: 1:4.1.48-1
> > Severity: important
> > Tags: security upstream
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team <
> > t...@security.debian.org>
> > Control: found -1 1:4.1.33-1+deb10u1
> > Control: found -1 1:4.1.33-1
> > 
> > Hi,
> > 
> > The following vulnerability was published for netty.
> 
> Thanks for the report. I'll take care of unstable. Did Chris contact you for a
> Buster update already or shall I prepare one as well?

Thanks for the unstable part!

For buster: not so far. netty indeed warrants a DSA and we listed it
already in dsa-needed list. If you want to take care of it, can you as
well please look at the other open issues for buster-security and pick
those up as well?

Regards,
Salvatore

Bug#982613: [Pkg-utopia-maintainers] Bug#982613: Debian Python Team

[Michael Biebl]

Hi Adrian

Am 12.02.21 um 15:22 schrieb Adrian Bunk:


Traceback (most recent call last):
   File 
"/tmp/autopkgtest-lxc.bwcca9__/downtmp/build.HQy/src/tests/test_networkmanager.py",
 line 171, in test_one_wifi_with_accesspoints
 subprocess.check_call(['nmcli', 'dev', 'wifi', 'connect', 'AP_3', 
'password', 's3kr1t'])
   File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
 raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['nmcli', 'dev', 'wifi', 'connect', 'AP_3', 
'password', 's3kr1t']' died with .

--
Ran 19 tests in 3.200s

FAILED (errors=1)
autopkgtest [05:28:01]: test upstream: ---]
autopkgtest [05:28:01]: test upstream:  - - - - - - - - - - results - - - - - - 
- - - -
upstream FAIL non-zero exit status 1


Fwiw, this is a result of pre-releases (like rc1) being built with 
more_asserts_default=100
The final 1.30.0 release will have more_asserts_default=0, i.e. will not 
trigger this assert. That said, we (i.e. upstream included in person of 
Thomas Haller) are currently investigating this, to see if there is a 
real bug in either NM or python-dbusmock.


Michael




OpenPGP_signature
Description: OpenPGP digital signature

Bug#969473: Please don't close bugs automatically, move them to enchant 2

[Boyuan Yang]

clone 704110 -1
reassign -1 enchant-2 2.2.7+repack1-1
clone 546418 -2
reassign -2 enchant-2 2.2.7+repack1-1
clone 233905 -3
reassign -3 enchant-2 2.2.7+repack1-1
clone 500234 -4
reassign -4 enchant-2 2.2.7+repack1-1
thanks

> Enchant 2 is just a new version of Enchant, only a separate package
> for ease of transition, so please reassign bugs to it rather than
> mass closing.
> (I'm the upstream maintainer!)
> 
> -- 
> https://rrt.sc3d.org

Thanks for the info. I am cloning and reassigning all relavant bugs
here. Feel free to examine the result later.

-- 
Thanks,
Boyuan Yang




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

Bug#978440: RFS: paperwork/2.0.2-1 -- Personal document manager

[Thomas Perret]

Hi,

Sorry I only checked (and answered) to your comment on mentors.d.n. I 
just saw now you left the same message here.


First, thanks for reviewing my package.

The sphinxdoc debhelper extension[1] helps to install documentation 
build with sphinx (python3-sphinx package).
Can you check you installed all build dependencies, especially 
python3-sphinx which depends on sphinx-common which itself provides the 
dh_sphinxdoc command?


Well, I guess that now Bullseye soft freeze is gone, it's less urgent 
matter.


Best regards,
Thomas

[1]: https://manpages.debian.org/buster/sphinx-common/dh_sphinxdoc.1.en.html

Bug#982442: udiskie: zsh completion function is installed outside zsh's default fpath

[Gianfranco Costamagna]

control: forwarded -1 https://github.com/coldfix/udiskie/pull/216
control: tags -1 patch pending

thanks!

G.

Bug#982639: Having an autopkgtest would be useful

[Sebastien Bacher]

Package: ayatana-ido
Version: 0.8.2-1

The package has no autopkgtest, having at least a simple testbuild from
a small example would be useful
(it would also help in getting the stack promoted in Ubuntu)

Thanks,

Bug#982638: Wrong vcs information

[Sebastien Bacher]

Package: ayatana-ido
Version: 0.8.2-1

The debian/control has
Vcs-Browser: https://salsa.debian.org/debian-edu-ayatana-team/ayatana-ido

but the url doesn't exist?

Bug#982148: frama-c: autopkgtest failure: nothing logged

[Gianfranco Costamagna]

control: tags -1 patch pending

I'm uploading to let the package transition to testing.

G.

Bug#982542: RFS: flowblade/2.8-1 -- non-linear video editor

[Boyuan Yang]

Hi,

On Thu, 11 Feb 2021 12:54:11 +0100 =?UTF-8?Q?G=C3=BCrkan_Myczko?=
 wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "flowblade":
> 
>   * Package name    : flowblade
> Version : 2.8-1
> Upstream Author : https://github.com/jliljebl/flowblade/issues
>   * URL : https://github.com/jliljebl/flowblade
>   * License : GPL-3+, GPL-2+, CC-BY-3.0
>   * Vcs :
https://salsa.debian.org/multimedia-team/flowblade
> Section : video
> 
> It builds those binary packages:
> 
>    flowblade - non-linear video editor
> 
> To access further information about this package, please visit the 
> following URL:
> 
>    https://mentors.debian.net/package/flowblade/
> 
> Alternatively, one can download the package with dget using this 
> command:
> 
>    dget -x 
>
https://mentors.debian.net/debian/pool/main/f/flowblade/flowblade_2.8-1.dsc
> 
> Changes since the last upload:
> 
>   flowblade (2.8-1) experimental; urgency=medium
>   .
> * New upstream version.
> * Bump standards version to 4.5.1.
> * d/control: added Rules-Requires-Root.
> * d/upstream/metadata: added.
> * d/copyright: update paths.

Please also consider fixing https://bugs.debian.org/980219 , merging
https://salsa.debian.org/multimedia-team/flowblade/-/commit/45cd180a40d8263ceb58cd7270f33fdaf351574b
and
https://salsa.debian.org/multimedia-team/flowblade/-/commit/72801397d1c257b62d4f39c32707b36ce011d09d
. Thanks!

Best,
Boyuan Yang


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

Bug#982392: ssh-copy-id: create ~/.ssh with default SELinux context

[Colin Watson]

On Tue, Feb 09, 2021 at 05:55:00PM +0100, Christian Göttsche wrote:
> ssh-copy-id(1) does create the directory ~/.ssh if it not already
> exists. It also runs later, if available, restorecon(8) on the
> directory, to correct the SELinux context of it.
> It would however be idiomatic to create the directory already with the
> default SELinux context, to prepare for restorecon failures and avoid
> potential races.

This code is run on the remote system.  Therefore, won't this break
ssh-copy-id against remote systems that lack mkdir -Z, such as systems
with coreutils < 8.22 (released towards the end of 2013, which is
certainly a while ago now but there are still systems in extended
support that lack it, such as Ubuntu 14.04), or indeed systems with
non-GNU versions of mkdir?

I think it has to be done this way for portability, even if it's less
idiomatic on systems with modern GNU coreutils.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#982598: incomplete logs for autopkg tests

[Paul Gevers]

reassign -1 debci

Hi Matthias,

On 12-02-2021 10:54, Matthias Klose wrote:
> Package: release.debian.org

It's not the release team that runs ci.debian.net. Reassigning
appropriately.

> As seen with glibc autopkg tests [1], the Debian CI infrastructure doesn't 
> store
> complete build logs, cutting these to 20MB (uncompressed), resulting in ~450k
> compressed logs.  This might not be important for successful tests, but it
> doesn't provide any information for failed tests, as the summary at the end is
> always cut.  Looking at the Ubuntu CI testers, you see that the glibc log for 
> a
> successful test can reach 150MB, compressed 3.5GB [2].  With a glibc patch to
> not stop on test failures with the first pass [3], logs for failed tests can
> also reach that size.
> 
> The outcome of tests is used by the release team to make decisions about the
> upcoming release [4].  Pointing out to a failed log which doesn't provide 
> useful
> information is not helpful, and does cost volunteer time to analyze.  In this
> case it turned out to be the flaky test infrastructure, and retries resulted 
> in
> a successful test.  Good luck with that for a real regression ...
> 
> As pointed out in another context, "machine time is cheap, volunteer time is
> not" [5], as well as machine storage is cheap compared to volunteer time, so
> please stop cutting the autopkg test logs.

Unfortunately, we're hitting infrastructure issues if we don't cap the
logs [1]. However, I think we should save the last part (and not the
first part) if we have to cap, because normally the failure happens in
the end.

Paul

[1]
https://salsa.debian.org/ci-team/debci/-/commit/9240d93a3e8a017c303d4d1604808fbc1d0f



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982580: netty: CVE-2021-21290

[Markus Koschany]

Control: owner -1 !

Hi Salvatore,

Am Freitag, den 12.02.2021, 07:42 +0100 schrieb Salvatore Bonaccorso:
> Source: netty
> Version: 1:4.1.48-1
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team <
> t...@security.debian.org>
> Control: found -1 1:4.1.33-1+deb10u1  
> Control: found -1 1:4.1.33-1
> 
> Hi,
> 
> The following vulnerability was published for netty.

Thanks for the report. I'll take care of unstable. Did Chris contact you for a
Buster update already or shall I prepare one as well?

Regards,

Markus



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

Bug#982618: man-db has mailcap entries with quoted %-escapes

[Colin Watson]

On Fri, Feb 12, 2021 at 03:51:44PM +0100, Marriott NZ wrote:
> the man-db package has mailcap entries with quoted %-escapes. That is
> considered unsafe. Proper escaping should be left to the programs
> using the entry.

Thanks for the reminder - I'd been meaning to get round to fixing this
Lintian tag for a while, but hadn't quite got round to it.  I've applied
your patch and it'll be in my next upload.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#976094: buster-pu: package grub2/2.02+dfsg1-20+deb10u3

[Colin Watson]

On Fri, Feb 12, 2021 at 08:16:46PM +0100, Romain Francoise wrote:
> On Mon, Jan 11, 2021 at 03:57:10PM +0100, Cyril Brulebois wrote:
> > If I'm getting this right, the udeb part shouldn't be much of an issue,
> > but the change regarding the fresh install vs. grub-install /could/ have
> > side effects. As documented, the installer /should/ be doing the right
> > thing already (via grub-installer), but checking (if only for peace of
> > mind) would be best.
> 
> For the record, 2.02+dfsg1-20+deb10u3 broke a custom cloud installation
> system at $work which relied on the fact that grub-pc would DTRT in its
> postinst when preseeded with the device to install on. Fixing that issue
> isn't particularly hard (adding the missing grub-install + mkconfig),
> however I'm surprised that such a behavior change was deemed appropriate
> for a stable release update.

CCing Dimitri for comment, since this was their change.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#982637: apt-listchanges: [INTL:de] updated German man page translation

[Helge Kreutzmann]

Package: apt-listchanges
Version: 3.23
Severity: wishlist
Tags: patch l10n

Please find the updated German man page translation for apt-listchanges
attached.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# Translation of aptlistchanges to German.
# Copyright (C) 2016 Robert Luberda, 2010-1015 Sandro Tosi,
# 2005-2010 Pierre Habouzit, 2000-2005 Matt Zimmerman.
# This file is distributed under the same license as the 
# apt-listchanges package.
# Copyright of this file Chris Leick , 2017, 2019.
# Helge Kreutzmann , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: apt-listchanges 3.23\n"
"Report-Msgid-Bugs-To: apt-listchan...@packages.debian.org\n"
"POT-Creation-Date: 2021-02-04 21:01+0100\n"
"PO-Revision-Date: 2021-02-12 19:16+0100\n"
"Last-Translator: Chris Leick \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. type: Content of: 
#: apt-listchanges.xml:24
msgid "apt-listchanges"
msgstr "apt-listchanges"

#. type: Content of: 
#: apt-listchanges.xml:25
msgid "1"
msgstr "1"

#. type: Content of: 
#: apt-listchanges.xml:30
msgid "Show new changelog entries from Debian package archives"
msgstr "zeigt neue Changelog-Einträge von Debian-Paketarchiven."

#. type: Content of: 
#: apt-listchanges.xml:34
msgid ""
"apt-listchanges  options   "
"--apt package."
"deb "
msgstr ""
"apt-listchanges  Optionen   "
"--apt Paket."
"deb "

#. type: Content of: 
#: apt-listchanges.xml:47
msgid "DESCRIPTION"
msgstr "BESCHREIBUNG"

#. type: Content of: 
#: apt-listchanges.xml:49
msgid ""
"apt-listchanges is a tool to show what has been changed "
"in a new version of a Debian package, as compared to the version currently "
"installed on the system."
msgstr ""
"apt-listchanges ist ein Werkzeug, das zeigt, was in einer "
"neuen Version eines Debian-Pakets verglichen mit der derzeit auf dem System "
"installierten Version geändert wurde."

#. type: Content of: 
#: apt-listchanges.xml:54
msgid ""
"It does this by extracting the relevant entries from both the NEWS.Debian "
"and changelog.Debian files, usually found in /"
"usr/share/doc/package, from Debian "
"package archives."
msgstr ""
"Es tut dies, indem es die relevanten Einträge aus den beiden Dateien NEWS."
"Debian und changelog.Debian extrahiert. Sie sind "
"normalerweise in den Debian-Paketarchiven in /usr/share/doc/Paket zu finden."

#. type: Content of: 
#: apt-listchanges.xml:60
msgid ""
"Please note that in the default installation if apt-listchanges is run during upgrades as an APT plugin, it displays NEWS.Debian "
"entries only. This can be changed with the --which option."
msgstr ""
"Bitte beachten Sie, dass in der Standardinstallation, falls apt-"
"listchanges während Upgrades als APT-Erweiterung ausgeführt wird, "
"es nur NEWS.Debian-Einträge anzeigt. Dies kann mit der Option --"
"which geändert werden."

#. type: Content of: 
#: apt-listchanges.xml:66
msgid ""
"If changelog entries are displayed and the package does not contain changelog.Debian file, "
"apt-listchanges calls apt-get changelog command to download the changelog from network. This behavior can "
"be disabled with the --no-network option."
msgstr ""
"Falls Changelog-Einträge angezeigt werden und das Paket keine changelog.Debian-Datei enthält, ruft "
"apt-listchanges den Befehl apt-get changelog auf, um das Changelog aus dem Netzwerk herunterzuladen. Dieses "
"Verhalten kann mit der Option --no-network deaktiviert "
"werden."

#. type: Content of: 
#: apt-listchanges.xml:75
msgid ""
"Given a set of filenames as arguments (or read from apt when using --"
"apt), apt-listchanges will scan the files "
"(assumed to be Debian package archives) for the relevant changelog entries, "
"and display them all in a summary grouped by source package.  The groups are "
"sorted by the urgency of the most urgent change, and than by the package "
"name.  Changes within each package group are displayed in the order of their "
"appearance in the changelog files, i.e. starting from the latest to the "
"oldest; the --reverse option can be used to alter this "
"order."
msgstr ""
"Mit einer angegebenen Zusammenstellung von Dateinamen als Argument (oder von "
"APT mittels --apt gelesen) wird Apt-listchanges die Dateien "
"(unter der Annahme, dass es sich um Debian-Paketarchive handelt) nach den "
"maßgeblichen Changelog-Einträgen durchsuchen und sie alle in einer nach "
"Quellpaketen gruppierten Zusammenstellung anzeigen. Die Gruppen werden nach "
"der maximalen Dringlichkeit und dann nach dem Paketnamen sortiert. "
"Änderungen innerhalb jeder Paketgruppe werden in der Reihenfolge ihres "
"Erscheinens in den Changelog-Dateien angezeigt, d.h. beginnend mit dem "
"Neusten bis zum Ältesten. Die Option --reverse kann zum "
"Ändern dieser 

Bug#982591: grub-pc can't be updated non-interactively on debian/buster64

[Emmanuel Kasper]

Le 12/02/2021 à 19:14, Evgeni Golov a écrit :
> On Fri, Feb 12, 2021 at 06:55:35PM +0100, Emmanuel Kasper wrote:
>> Le 12/02/2021 à 12:36, Evgeni Golov a écrit :
>>> On Fri, Feb 12, 2021 at 10:03:08AM +0100, Thomas Lange wrote:
 This behaviour was also reported as #982182
>>>
>>> Interesting, thanks!
>>>
>>> To me the GRUB change seems reasonable, even if a tad unexpected in a
>>> point release.
>>>
>>> You change to FAI [1] looks pretty much how I would envision a correct
>>> fix in the Vagrant box too, just executed at a different time.
>>>
>>> Thanks!
>>>
>>> [1] 
>>> https://github.com/faiproject/fai-config/commit/bf90f3048f552f2dc1a0f50766646dff9f67aef9
>>>
>>
>> Thanks Thomas for the pointer to #982182.
>> The bug on the Vagrant box is similar but the root cause is different.
>> On the latest buster box:
>>
>> vagrant ssh -- sudo debconf-show grub-pc | grep grub-pc/install_devices:
>> * grub-pc/install_devices: /dev/vda
>>
>> This is because the box is built with packer which uses virtio-blk from
>> qemy by default and create such devices.
>>
>> So for the vagrant side of this, at least for buster we should switch
>> the default disk driver to virtio-scsi, which creates during the install
>> a /dev/sda debconf entry, which is the same device name grub sees on
>> VirtualBox and its sata controller.
> 
> This would break here, as my Vagrant uses virtio-blk too (and I think
> that's the default these days in libvirt).
> 
> However here (albeit on 10.4, see #982592),
>   debconf-show grub-pc | grep grub-pc/install_devices
> yields empty, and this is also probably the reason why it fails to
> upgrade to 10.8.

ah you're using the libvirt box
these boxes are built with vmdebootstrap which is unmaintained:/

there is work in progress to replace vmdebootstrap with fai-diskimage at
https://salsa.debian.org/cloud-team/debian-vagrant-images  which should
fix this. Until then I am afraid we have to live with manually setting

echo 'grub-pc grub-pc/install_devices multiselect /dev/vda' | sudo
debconf-set-selections

before doing an apt upgrade

Bug#976094: buster-pu: package grub2/2.02+dfsg1-20+deb10u3

[Romain Francoise]

On Mon, Jan 11, 2021 at 03:57:10PM +0100, Cyril Brulebois wrote:
> If I'm getting this right, the udeb part shouldn't be much of an issue,
> but the change regarding the fresh install vs. grub-install /could/ have
> side effects. As documented, the installer /should/ be doing the right
> thing already (via grub-installer), but checking (if only for peace of
> mind) would be best.

For the record, 2.02+dfsg1-20+deb10u3 broke a custom cloud installation
system at $work which relied on the fact that grub-pc would DTRT in its
postinst when preseeded with the device to install on. Fixing that issue
isn't particularly hard (adding the missing grub-install + mkconfig),
however I'm surprised that such a behavior change was deemed appropriate
for a stable release update.

Bug#982636: cheese: creates invalid and extremely long video files

[Sergio Villar Senin]

For reference I think it's likely the same issue as this one reported
in the RedHat bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1884260

Bug#982636: cheese: creates invalid and extremely long video files

[Sergio Villar Senin]

Package: cheese
Version: 3.38.0-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

Open cheese and record a video.

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

Record a video. Stop the recording. Double click on the thumbnail to
play the video.

   * What was the outcome of this action?

1. During the recording the video freezes after some seconds.
2. The video length shown in the UI is nonsensical, after some seconds
it shows 19 minutes.
3. The generated video is absurdly long (like the 19 minutes mentioned
before) and it's empty, it shows nothing.

   * What outcome did you expect instead?

Recording should be fine.

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

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

Versions of packages cheese depends on:
ii  cheese-common  3.38.0-3
ii  gnome-video-effects0.5.0-1
ii  libc6  2.31-5
ii  libcanberra-gtk3-0 0.30-7
ii  libcheese-gtk253.38.0-3
ii  libcheese8 3.38.0-3
ii  libclutter-1.0-0   1.26.4+dfsg-2
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libgdk-pixbuf-2.0-02.40.0+dfsg-8
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-8
ii  libglib2.0-0   2.66.3-2
ii  libgnome-desktop-3-19  3.38.2-1
ii  libgstreamer1.0-0  1.18.1-1
ii  libgtk-3-0 3.24.23-3

Versions of packages cheese recommends:
ii  gvfs  1.46.1-1
ii  yelp  3.38.2-1

Versions of packages cheese suggests:
ii  gnome-video-effects-frei0r  0.5.0-1

-- no debconf information

Bug#979840: dns-root-data: autopkgtest regression in testing: failed to query server 127.0.0.1@53

[Paul Gevers]

Control: severity -1 serious

Hi Robert,

On 12-02-2021 04:22, Robert Edmonds wrote:
> I have confirmed that the current version of the package (2019052802) is
> shipping the correct root nameserver hints and root zone trust anchor
> content and that no RC regression exists, so I am lowering the severity
> of this bug report.

But the Release Team policy [1] says:
"""
6. Quality Assurance checks

  (a) autopkgtest

Package are encouraged to implement autopkgtests. These tests must
test at least one of its own installed binary packages in some
non-trivial way, or must be marked as superficial. Examples of
superficial tests include calling executables with --version or
--help, testing for existence of files in binary packages, and
$(python3 -c "import foo"). Failing tests on amd64 and arm64 are
RC. Test regressions on release architectures are RC.
Ref: RT
"""

> The problem seems to be that the test depends on the Knot Resolver's
> kresd daemon, whose service unit is masked and is not started after
> installing the knot-resolver package. I would guess something like the
> following would fix the regression in the test:
> 
> --- dns-root-data-2019052802/debian/tests/baseline.orig   2021-02-11 
> 22:08:17.857773156 -0500
> +++ dns-root-data-2019052802/debian/tests/baseline2021-02-11 
> 22:13:28.483653604 -0500
> @@ -2,6 +2,9 @@
>  
>  set -e
>  
> -kdig @127.0.0.1 -t ns . +dnssec > root-nameservers-result
> +kresd --noninteractive --addr=127.53.53.53@53053 &
> +
> +kdig -p 53053 @127.53.53.53 -t ns . +dnssec > root-nameservers-result
>  cat root-nameservers-result
>  head -n1 < root-nameservers-result | grep -q '^;; ->>HEADER<<- opcode: 
> QUERY; status: NOERROR; id: '
> +head -n2 < root-nameservers-result | tail -1 | grep -q '^;; Flags: qr rd ra 
> ad;'

Please fix your autopkgtest. If the root cause of the problem lies
elsewhere, please file appropriate bugs (e.g. by cloning and
reassigning) to get it fixed and disable the test for the time being.

Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982633: Support separate libtirpc

[Iain Lane]

On Fri, Feb 12, 2021 at 05:49:44PM +, Iain Lane wrote:
> Once I get a bug number back I'll attach the patch. Upstream doesn't
> seem that alive, and I don't have a SF account, so I've not forwarded -
> if you could help me do that that would be super useful.

Here you go!

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]
diff -Nru netatalk-3.1.12~ds/debian/changelog 
netatalk-3.1.12~ds/debian/changelog
--- netatalk-3.1.12~ds/debian/changelog 2020-12-16 22:11:11.0 +
+++ netatalk-3.1.12~ds/debian/changelog 2021-02-11 11:05:14.0 +
@@ -1,3 +1,13 @@
+netatalk (3.1.12~ds-9) UNRELEASED; urgency=medium
+
+  * Build agianst libtirpc:
++ debian/patches/allow-use-of-tirpc: Fixes quota support being disabled
+  where this isn't available.
++ debian/rules: Pass --with-libtirpc to enable this new support.
++ debian/control: BD on libtirpc-dev.
+
+ -- Iain Lane   Thu, 11 Feb 2021 11:05:14 +
+
 netatalk (3.1.12~ds-8) unstable; urgency=medium
 
   * update patch 105 to support cross-compilation;
diff -Nru netatalk-3.1.12~ds/debian/control netatalk-3.1.12~ds/debian/control
--- netatalk-3.1.12~ds/debian/control   2020-12-16 21:32:17.0 +
+++ netatalk-3.1.12~ds/debian/control   2021-02-11 11:05:13.0 +
@@ -25,6 +25,7 @@
  libssl-dev,
  libtalloc-dev,
  libtdb-dev,
+ libtirpc-dev,
  libtracker-miner-2.0-dev,
  libtracker-sparql-2.0-dev,
  libwrap0-dev,
diff -Nru netatalk-3.1.12~ds/debian/patches/107_allow_use_of_tirpc.patch 
netatalk-3.1.12~ds/debian/patches/107_allow_use_of_tirpc.patch
--- netatalk-3.1.12~ds/debian/patches/107_allow_use_of_tirpc.patch  
1970-01-01 01:00:00.0 +0100
+++ netatalk-3.1.12~ds/debian/patches/107_allow_use_of_tirpc.patch  
2021-02-11 11:05:14.0 +
@@ -0,0 +1,97 @@
+Description: Support building against libtirpc as separate from glibc
+Author: Iain Lane 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982633
+
+unchanged:
+Index: b/macros/quota-check.m4
+===
+--- a/macros/quota-check.m4
 b/macros/quota-check.m4
+@@ -4,23 +4,37 @@
+ AC_DEFUN([AC_NETATALK_CHECK_QUOTA], [
+   AC_ARG_ENABLE(quota,
+   [  --enable-quota   Turn on quota support (default=auto)])
++  AC_ARG_WITH([libtirpc], [AS_HELP_STRING([--with-libtirpc], [Use 
libtirpc as RPC implementation (instead of sunrpc)])])
+ 
+   if test x$enable_quota != xno; then
+-  QUOTA_LIBS=""
+-  netatalk_cv_quotasupport="yes"
+-  AC_CHECK_LIB(rpcsvc, main, [QUOTA_LIBS="-lrpcsvc"])
+-  AC_CHECK_HEADERS([rpc/rpc.h rpc/pmap_prot.h rpcsvc/rquota.h],[],[
+-  QUOTA_LIBS=""
+-  netatalk_cv_quotasupport="no"
+-  AC_DEFINE(NO_QUOTA_SUPPORT, 1, [Define if quota support should 
not compiled])
+-  ])
+-  AC_CHECK_LIB(quota, getfsquota, [QUOTA_LIBS="-lquota -lprop -lrpcsvc"
+-  AC_DEFINE(HAVE_LIBQUOTA, 1, [define if you have libquota])], [], 
[-lprop -lrpcsvc])
++  if test "x$with_libtirpc" = xyes; then
++  PKG_CHECK_MODULES([TIRPC],
++  [libtirpc],
++  [QUOTA_CFLAGS=$TIRPC_CFLAGS
++  QUOTA_LIBS=$TIRPC_LIBS
++  netatalk_cv_quotasupport="yes"
++  AC_DEFINE(NEED_RQUOTA, 1, [Define various xdr 
functions])],
++  [AC_MSG_ERROR([libtirpc requested, but library 
not found.])]
++  )
++  else
++  QUOTA_CFLAGS=""
++  QUOTA_LIBS=""
++  netatalk_cv_quotasupport="yes"
++  AC_CHECK_LIB(rpcsvc, main, [QUOTA_LIBS="-lrpcsvc"])
++  AC_CHECK_HEADERS([rpc/rpc.h rpc/pmap_prot.h 
rpcsvc/rquota.h],[],[
++  QUOTA_LIBS=""
++  netatalk_cv_quotasupport="no"
++  AC_DEFINE(NO_QUOTA_SUPPORT, 1, [Define if quota 
support should not compiled])
++  ])
++  AC_CHECK_LIB(quota, getfsquota, [QUOTA_LIBS="-lquota 
-lprop -lrpcsvc"
++  AC_DEFINE(HAVE_LIBQUOTA, 1, [define if you have 
libquota])], [], [-lprop -lrpcsvc])
++  fi
+   else
+   netatalk_cv_quotasupport="no"
+   AC_DEFINE(NO_QUOTA_SUPPORT, 1, [Define if quota support should 
not compiled])
+   fi
+ 
++  AC_SUBST(QUOTA_CFLAGS)
+   AC_SUBST(QUOTA_LIBS)
+ ])
+ 
+Index: b/etc/afpd/Makefile.am
+===
+--- a/etc/afpd/Makefile.am
 b/etc/afpd/Makefile.am
+@@ -51,7 +51,7 @@
+ afpd_LDFLAGS = -export-dynamic
+ 
+ afpd_CFLAGS 

Bug#982591: grub-pc can't be updated non-interactively on debian/buster64

[Evgeni Golov]

On Fri, Feb 12, 2021 at 06:55:35PM +0100, Emmanuel Kasper wrote:
> Le 12/02/2021 à 12:36, Evgeni Golov a écrit :
> > On Fri, Feb 12, 2021 at 10:03:08AM +0100, Thomas Lange wrote:
> >> This behaviour was also reported as #982182
> > 
> > Interesting, thanks!
> > 
> > To me the GRUB change seems reasonable, even if a tad unexpected in a
> > point release.
> > 
> > You change to FAI [1] looks pretty much how I would envision a correct
> > fix in the Vagrant box too, just executed at a different time.
> > 
> > Thanks!
> > 
> > [1] 
> > https://github.com/faiproject/fai-config/commit/bf90f3048f552f2dc1a0f50766646dff9f67aef9
> > 
> 
> Thanks Thomas for the pointer to #982182.
> The bug on the Vagrant box is similar but the root cause is different.
> On the latest buster box:
> 
> vagrant ssh -- sudo debconf-show grub-pc | grep grub-pc/install_devices:
> * grub-pc/install_devices: /dev/vda
> 
> This is because the box is built with packer which uses virtio-blk from
> qemy by default and create such devices.
> 
> So for the vagrant side of this, at least for buster we should switch
> the default disk driver to virtio-scsi, which creates during the install
> a /dev/sda debconf entry, which is the same device name grub sees on
> VirtualBox and its sata controller.

This would break here, as my Vagrant uses virtio-blk too (and I think
that's the default these days in libvirt).

However here (albeit on 10.4, see #982592),
  debconf-show grub-pc | grep grub-pc/install_devices
yields empty, and this is also probably the reason why it fails to
upgrade to 10.8.

Bug#982635: debhelper: Provide a way for debhelper tools to register files to be cleaned (make tools like mh_clean redundant)

[Niels Thykier]

Package: debhelper
Severity: wishlist

Add-ons cannot be made conditional if they need to alter the clean
sequence.  An example is maven-repo-helper, which provides a mh_clean
tool which basically removes files and directories created by other
maven-repo-helper tools.  This in turn prevents us from moving
maven-repo-helper to Build-Depends-Indep (and thus break/reduce
build-dependency circles).


I think this calls of a generalization of mh_clean and implement that in
dh_clean (or at least debhelper's own clean sequence).

Side note: It is a non-goal to remove the need for jh_clean that calls
other tools (unless they happen to be replaceable by "pre-registering
files to be deleted)

~Niels

Bug#971681: r-cran-openmx regression on arm, will not migrate to testing due to failing autopkgtests

[Joshua N Pritikin]

On Sat, Jan 30, 2021 at 08:31:51AM -0500, Joshua N Pritikin wrote:
> On Sat, Jan 30, 2021 at 06:32:48PM +0530, Nilesh Patra wrote:
> > Many thanks for fixes,
> >
> > The freeze has started and soft freeze time is near as well.(2 weeks 
> > from now) OpenMx has removals of a bunch of packages from testing.
> > 
> > Hence, please consider doing a new upstream release if it looks okay 
> > to you.
> 
> I submitted a new release to CRAN yesterday. It usually takes a few days 
> to correct any lingering issues and get it approved.

CRAN peeps said that v2.19.1 is accepted. I know the package info page 
isn't updated yet, but I expect that to happen soon.

Bug#982591: grub-pc can't be updated non-interactively on debian/buster64

[Emmanuel Kasper]

Le 12/02/2021 à 12:36, Evgeni Golov a écrit :
> On Fri, Feb 12, 2021 at 10:03:08AM +0100, Thomas Lange wrote:
>> This behaviour was also reported as #982182
> 
> Interesting, thanks!
> 
> To me the GRUB change seems reasonable, even if a tad unexpected in a
> point release.
> 
> You change to FAI [1] looks pretty much how I would envision a correct
> fix in the Vagrant box too, just executed at a different time.
> 
> Thanks!
> 
> [1] 
> https://github.com/faiproject/fai-config/commit/bf90f3048f552f2dc1a0f50766646dff9f67aef9
> 

Thanks Thomas for the pointer to #982182.
The bug on the Vagrant box is similar but the root cause is different.
On the latest buster box:

vagrant ssh -- sudo debconf-show grub-pc | grep grub-pc/install_devices:
* grub-pc/install_devices: /dev/vda

This is because the box is built with packer which uses virtio-blk from
qemy by default and create such devices.

So for the vagrant side of this, at least for buster we should switch
the default disk driver to virtio-scsi, which creates during the install
a /dev/sda debconf entry, which is the same device name grub sees on
VirtualBox and its sata controller.

Bug#982633: Support separate libtirpc

[Iain Lane]

Package: src:netatalk
Version: 3.1.12~ds-8
Severity: normal
Tags: upstream patch

Hiya,

I noticed on Ubuntu that the autopkgtest is failing[0]:

  #   Failed test 'Quota support'

I think it's because:

  #  Quota support: No

quota support is disabled. After a lot of digging around I found it's
because the Sun RPC support is gone there[1].

I'd *guess* that once 2.32 comes to Debian we'll start seeing the same
issues here.

I've got a patch to start building against the replacement external
libtirpc. It works in as far as building, keeping the quota support
enabled, and the tests finishing successfully.

Once I get a bug number back I'll attach the patch. Upstream doesn't
seem that alive, and I don't have a SF account, so I've not forwarded -
if you could help me do that that would be super useful.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]

[0] 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/n/netatalk/20210212_152746_09e47@/log.gz
[1] https://lists.ubuntu.com/archives/ubuntu-devel/2020-October/041241.html

Bug#982634: xtrlock: allow numpad Enter key to enter password

[Steve Ward]

Package: xtrlock
Version: 2.8+deb10u1+b1
Severity: wishlist

Dear Maintainer,

I often use the numpad Enter key to enter my password, but xtrlock allows only 
the regular Enter key to be used.

In xtrlock.c at line 306, please add a case for XK_KP_Enter where XK_Linefeed 
and XK_Return are handled.


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

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

Versions of packages xtrlock depends on:
ii  libc6 2.28-10
ii  libx11-6  2:1.6.7-1+deb10u1
ii  libxi62:1.7.9-1

xtrlock recommends no packages.

xtrlock suggests no packages.

-- no debconf information

Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic

[Julien Cristau]

On Thu, Feb 11, 2021 at 09:59:42PM +0100, Raphaël Hertzog wrote:
> Those files are not really meant to be immutable:
> - signing keys can expire and be revoked, upstream might want to update
>   signatures of already released tarballs
> - the set of "upstream release managers" might evolve over time and the
>   official signature to use might change...
> 
As far as we're concerned they are immutable, they are the signature of
the tarball at the time that tarball was uploaded to debian.  There's no
reason for that to change without the tarball itself changing, at which
point both filenames change.

Cheers,
Julien

Bug#982631: gnome-nibbles: aborts on assertion failure at end of game

[John Scott]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnome-nibbles/-/issues/51
Control: tags -1 fixed-upstream patch

Sorry for jumping the gun on this report; it seems it's an off-by-one
error fixed upstream in 3.38.2, and that this patch and translation
updates are the only substantive changes:
https://gitlab.gnome.org/GNOME/gnome-nibbles/-/commit/060c03ad

Could this make it into Bullseye? I could send a MR if you'd prefer it
to be patched.


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

Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic

[gregor herrmann]

On Fri, 12 Feb 2021 15:41:09 +0100, Raphael Hertzog wrote:

> On Fri, 12 Feb 2021, Peter Pentchev wrote:
> > > Yeah, it would go a long way if pristine-tar would store the associated
> > > signature and restore it as well. It's easy to forget to include it
> > > when the uploads are not done by the same person.
> > 
> > It can, since version 1.41:
> > 
> > debcheckout confget
> > cd confget
> > git checkout pristine-tar
> > git checkout master
> > git checkout debian/master
> > pristine-tar checkout -s ../confget_2.3.4.orig.tar.xz.asc 
> > ../confget_2.3.4.orig.tar.xz
> 
> Well, then I assume that the git-buildpackage integration doesn't do
> this automatically. Honestly, you should not have to specify that you
> want to check out the associated signature at the same time or maybe with
> a generic option --include-associated-files that would not fail if
> there's no associated file.

From the changelog and the manpage of gbp-buildpackage, there's

   --git-upstream-signatures=[auto|on|off]
  Whether to export the upstream tarball with signatures.

which defaults to 'auto' … and after checking out pristine-tar it
does what it says on the tin:

gbp:info: Tarballs 'confget_2.3.4.orig.tar.xz' not found at '../tarballs/'
gbp:info: Creating /home/gregoa/tmp/build-area/confget_2.3.4.orig.tar.xz
[no message about the *.asc here]
…
[but it's there:]
dpkg-source: info: building confget using existing ./confget_2.3.4.orig.tar.xz
dpkg-source: info: building confget using existing 
./confget_2.3.4.orig.tar.xz.asc

and also in the output directory:

% ll ../build-area/*orig*
-rw-rw-r-- 1 gregoa gregoa 34724 Feb 12 18:36 
../build-area/confget_2.3.4.orig.tar.xz
-rw-rw-r-- 1 gregoa gregoa   833 Feb 12 18:36 
../build-area/confget_2.3.4.orig.tar.xz.asc


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#982631: aborts on assertion failure at end of game

[John Scott]

Package: gnome-nibbles
Version: 1:3.38.1-1
Severity: normal

When you run out of lives at the end of the game, instead of showing
the scores or some more user-friendly behavior, the window immediately
closes with an assertion failure:

ERROR:linkedlist.c:1169:gee_linked_list_real_get: assertion failed: (index < 
this._size)
Bail out! ERROR:linkedlist.c:1169:gee_linked_list_real_get: assertion failed: 
(index < this._size)

The game feels rather pointless without being able to see previous
scores. Here's the backtrace:
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x76ef2537 in __GI_abort () at abort.c:79
#2  0x77961dcc in g_assertion_message
(domain=, file=0x77150366 "linkedlist.c", 
line=, func=, message=)
at ../../../glib/gtestutils.c:2937
#3  0x779bf2cb in g_assertion_message_expr
(domain=domain@entry=0x0, file=file@entry=0x77150366 "linkedlist.c", 
line=line@entry=1169, func=func@entry=0x77149970 <__func__.15217> 
"gee_linked_list_real_get", expr=expr@entry=0x771494f8 "index < 
this._size") at ../../../glib/gtestutils.c:2963
#4  0x770fea81 in gee_linked_list_real_get (base=0x55dfa650 
[GeeLinkedList], index=) at linkedlist.c:1169
#5  0x55571eb1 in player_score_box_update_lives 
(self=self@entry=0x55c592f0 [PlayerScoreBox], lives_left=lives_left@entry=0 
'\000')
at src/gnome-nibbles.p/scoreboard.c:575
#6  0x555720a7 in player_score_box_update (lives_left=0 '\000', 
score=, self=0x55c592f0 [PlayerScoreBox])
at src/gnome-nibbles.p/scoreboard.c:526
#7  scoreboard_update (self=) at 
src/gnome-nibbles.p/scoreboard.c:278
#11 0x77aa2c3f in 
(instance=instance@entry=0x55de4530, signal_id=, 
detail=) at ../../../gobject/gsignal.c:3551
#8  0x77a8a0a2 in g_closure_invoke
(closure=0x55f26a00, return_value=return_value@entry=0x0, 
n_param_values=2, param_values=param_values@entry=0x7fffdb60, 
invocation_hint=invocation_hint@entry=0x7fffdae0) at 
../../../gobject/gclosure.c:810
#9  0x77a9c413 in signal_emit_unlocked_R
(node=node@entry=0x555a8c00, detail=detail@entry=2012, 
instance=instance@entry=0x55de4530, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fffdb60) at 
../../../gobject/gsignal.c:3739
#10 0x77aa26cf in g_signal_emit_valist
(instance=, signal_id=, detail=, var_args=var_args@entry=0x7fffdd00)
at ../../../gobject/gsignal.c:3495
#12 0x77a8e804 in g_object_dispatch_properties_changed 
(object=0x55de4530 [Worm], n_pspecs=, pspecs=)
at ../../../gobject/gobject.c:1206
#13 0x77a907ca in g_object_notify_by_spec_internal (pspec=, object=0x55de4530 [Worm])
at ../../../gobject/gobject.c:1299
#14 g_object_notify_by_pspec (object=0x55de4530 [Worm], pspec=) at ../../../gobject/gobject.c:1409
#15 0x5557620e in worm_lose_life (self=0x55de4530 [Worm]) at 
src/gnome-nibbles.p/worm.c:1469
#16 worm_reset (self=self@entry=0x55de4530 [Worm], board=0x55b85800, 
board_length1=92, board_length2=66) at src/gnome-nibbles.p/worm.c:1489
#17 0x55563f64 in nibbles_game_move_worms (self=) at 
src/gnome-nibbles.p/nibbles-game.c:2028
#18 nibbles_game_main_loop_cb (self=) at src/gnome-nibbles.p/nibbles-game.c:1253
#19 __lambda5_ (self=) at 
src/gnome-nibbles.p/nibbles-game.c:1062
#20 ___lambda5__gsource_func (self=) at src/gnome-nibbles.p/nibbles-game.c:1070
#21 0x779978c4 in g_timeout_dispatch (source=0x568b9d30, 
callback=, user_data=) at 
../../../glib/gmain.c:4877
#22 0x77996d3f in g_main_dispatch (context=0x555b50d0) at 
../../../glib/gmain.c:3325
#23 g_main_context_dispatch (context=0x555b50d0) at 
../../../glib/gmain.c:4043
#24 0x779970e8 in g_main_context_iterate 
(context=context@entry=0x555b50d0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4119
#25 0x7799719f in g_main_context_iteration 
(context=context@entry=0x555b50d0, may_block=may_block@entry=1) at 
../../../glib/gmain.c:4184
#26 0x77d2c545 in g_application_run 
(application=application@entry=0x555b3100 [Nibbles], argc=-8060, 
argc@entry=1, argv=argv@entry=0x7fffe1e8) at 
../../../gio/gapplication.c:2559
#27 0x55561468 in nibbles_main (args=0x7fffe1e8, args_length1=1) at 
src/gnome-nibbles.p/gnome-nibbles.c:194
#28 0x76ef3d0a in __libc_start_main (main=0xd4b0 , 
argc=1, argv=0x7fffe1e8, init=, fini=, 
rtld_fini=, stack_end=0x7fffe1d8) at ../csu/libc-start.c:308
#29 0xd4ea in _start ()

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_USER, 

Bug#982632: 0.1.0 release is outdated and incompatible with podman 3.0

[Faidon Liambotis]

Package: nomad-driver-podman
Version: 0.1.0-2
Severity: grave

As discussed recently in debian-devel, nomad-driver-podman 0.1.0 works
with the podman Varlink API, which does not exist anymore in podman 3.0,
making this package unusable for all users (at least AIUI).

A new upstream release of nomad-driver-podman, 0.2.0, however, was
released with its main feature being support for the HTTP API.

Dmitry, I know you know this, but just filing this RC bug to avoid us
collectively forgetting about this and releasing bullseye with a package
combination that isn't functional for users. Hope this is helpful!

Best,
Faidon

Bug#982617: drop-seq: autopkgtest regression

[Pierre Gruet]

Control: tags -1 confirmed pending

Hi,


On Fri, 12 Feb 2021 16:43:24 +0200 Adrian Bunk  wrote:
> Source: drop-seq
> Version: 2.4.0+dfsg-5
> Severity: serious
>
> 
https://ci.debian.net/data/autopkgtest/testing/amd64/d/drop-seq/10416045/log.gz

>
> ...
> autopkgtest [07:18:29]: test run-unit-test: [---
> Test 1
> dpkg-architecture: warning: cannot determine CC system type, falling 
back to default (native compilation)
> Error: Could not find or load main class 
org.broadinstitute.dropseqrna.cmdline.DropSeqMain
> Caused by: java.lang.NoClassDefFoundError: 
picard/cmdline/PicardCommandLine

> autopkgtest [07:18:34]: test run-unit-test: ---]
> autopkgtest [07:18:34]: test run-unit-test: - - - - - - - - - - 
results - - - - - - - - - -

> run-unit-test FAIL non-zero exit status 1
>
>

This is a classpath issue, I'm fixing this and preparing an upload.

Best,
Pierre

Bug#982530: libpam-modules: unable to login when using pam_tally2 after upgrade to libpam-modules >1.4.0

[Martin Schurz]

I had another talk with someone more familiar with debian. In this talk
we came up with following approach. If you like this better, I can
submit a patch for this.

Approach:
First look into /usr/share/pam-configs for any config including
pam_tally. If something is found, disable it with pam-auth-update.
Also emit a message to the user, that pam_tally is deprecated and
the user should switch to pam_faillock.

At this point the system should be in a good state, if the user
did not manually configure something in /etc/pam.d.

Just to be sure, we do an additional check for pam_tally in all
files in /etc/pam.d. If this comes up negative we can assume
everything is ok and continue the installation. If it finds an
occurence of pam_tally, we generate a pam config without
pam_tally and use ucf to let the user choose how merge our
changes. Additionally we emit an error message about really
making sure the pam config is in order.

Bug#982627: schleuder: fails with more recent versions of gpg

[Daniel Kahn Gillmor]

On Fri 2021-02-12 11:47:07 -0500, Daniel Kahn Gillmor wrote:
> When GnuPG was upgraded to 2.2.27-1, schleuder's autopkgtests broke:

I've applied the proposed patch and uploaded it as an NMU for 3.6.0-1.1.
I pushed the relevant changes (and a tag) to a fork of the salsa repo,
and submitted a merge request here:
https://salsa.debian.org/ruby-team/schleuder/-/merge_requests/1

(i don't have push privileges for the ruby-team/schleuder repo or i
would have pushed the changes directly there)

Hopefully this addresses the concerns with GnuPG 2.2.27.

  --dkg

Bug#982625: fails to authenticate with "TypeError: sequence item 2: expected str instance, bytes found" error

[Sudip Mukherjee]

On Fri, Feb 12, 2021 at 5:19 PM Stefano Zacchiroli  wrote:
>
> Hi Sudip, thanks for your reply,
>
> On Fri, Feb 12, 2021 at 05:00:04PM +, Sudip Mukherjee wrote:
> > Thanks for the report. Can you please paste your offlineimaprc file
> > after removing any sensitive information, and I can try to reproduce
> > the error in my setup.
>
> in fact, it turns out this is a duplicate of #981063, which I failed to
> identify initially because it didn't have the actual final error in the
> message. The workaround in that bug report worked for me.

Thanks for confirming, I was expecting that.

>
> I've tried to merge the bugs, but it failed with an error on locking a
> spool file on the BTS server. (I've just tried again.)
>
> FWIW, I think #981063 should be severity serious and fixed in time for
> bullseye.

Yes, I have raised a PR to upstream with a proper fix and will wait
till Monday before uploading here.
https://github.com/OfflineIMAP/offlineimap3/pull/51


-- 
Regards
Sudip

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Bernhard Übelacker]

Am 12.02.21 um 12:12 schrieb Drew Parsons:

Version mismatch could cause problems.

Bernhard, can you provide the versions of each of the packages you're 
reporting on

(dolfinx, eigen3, gmsh) ?


Hello,
these are the versions I have used in this test VM.

Would it be possible that libgmsh should use
the Memory.h below /usr instead of ./contrib ?

Kind regards,
Bernhard


# dpkg -l | grep -E "dolfinx|eigen3|gmsh" | LANG=C sort -k3b,3b -k2b,2b
ii  dolfinx-doc2019.2.0~git20201109.17bda9f-6 all   
   Documentation and demo programs for DOLFIN
ii  libdolfinx-dev 2019.2.0~git20201109.17bda9f-6 all   
   Shared links and header files for DOLFIN
ii  libdolfinx-real-dev:amd64  2019.2.0~git20201109.17bda9f-6 amd64 
   Shared links and header files for DOLFIN (real numbers)
ii  libdolfinx-real2019.2-dbgsym:amd64 2019.2.0~git20201109.17bda9f-6 amd64 
   debug symbols for libdolfinx-real2019.2
ii  libdolfinx-real2019.2:amd642019.2.0~git20201109.17bda9f-6 amd64 
   Shared libraries for DOLFIN
ii  python3-dolfinx-real   2019.2.0~git20201109.17bda9f-6 amd64 
   Python interface for DOLFIN (Python 3)
ii  python3-dolfinx:amd64  2019.2.0~git20201109.17bda9f-6 amd64 
   Python interface for DOLFIN (Python 3)
ii  libeigen3-dev  3.3.9-2all   
   lightweight C++ template library for linear algebra
ii  gmsh   4.7.1+ds1-2amd64 
   Three-dimensional finite element mesh generator
ii  gmsh-doc   4.7.1+ds1-2all   
   Three-dimensional finite element mesh generator documentation
ii  libgmsh4-dbgsym:amd64  4.7.1+ds1-2amd64 
   debug symbols for libgmsh4
ii  libgmsh4:amd64 4.7.1+ds1-2amd64 
   Three-dimensional finite element mesh generator shared library
ii  python3-gmsh   4.7.1+ds1-2all   
   Three-dimensional finite element mesh generator Python 3 wrapper

Bug#982625: fails to authenticate with "TypeError: sequence item 2: expected str instance, bytes found" error

[Stefano Zacchiroli]

Hi Sudip, thanks for your reply,

On Fri, Feb 12, 2021 at 05:00:04PM +, Sudip Mukherjee wrote:
> Thanks for the report. Can you please paste your offlineimaprc file
> after removing any sensitive information, and I can try to reproduce
> the error in my setup.

in fact, it turns out this is a duplicate of #981063, which I failed to
identify initially because it didn't have the actual final error in the
message. The workaround in that bug report worked for me.

I've tried to merge the bugs, but it failed with an error on locking a
spool file on the BTS server. (I've just tried again.)

FWIW, I think #981063 should be severity serious and fixed in time for
bullseye.

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#982630: lintian: example-unusual-interpreter is confused/confusing when example script has #!/usr/bin/env python

[Daniel Kahn Gillmor]

Package: lintian
Version: 2.104.0
Control: affects -1 python3-gpg

This is a peculiar error message: lintian seems confused about what the
interpreter is for an example python script shipped in python3-gpg:

$ lintian python3-gpg_1.14.0-1+b2_amd64.deb | head -n1
P: python3-gpg: example-unusual-interpreter 
usr/share/doc/python3-gpg/examples/assuan.py #!python
$ head -n1 /usr/share/doc/python3-gpg/examples/assuan.py 
#!/usr/bin/env python
$

lintian's warning completely elides the "/usr/bin/env" part of the
interpreter, which makes it look like lintian doesn't know what the
actual interpreter is.  If that's the case, then lintian is confused.

If lintian is in fact trying to complain about "python" vs "python3" (if
we're trying to ensure that we don't have anything pointing to
"python"), that is a sufficiently important, specific situation that it
should offer a dedicated tag for it.

Either way, the warning message shouldn't omit /usr/bin/env if it's
present in the file in question, as the mismatch between the warning and
the file is a distraction from the intent of the message.

fwiw, i don't know whether upstream would change these examples to have
a python3 shebang line, and i'm not inclined to ask them to do so --
i've got bigger fish to fry, and technically /usr/bin/python is supposed
to be used for things that are both py3- and py2-compatible (which
hopefully these examples all are).

Thanks for maintaining lintian!

   --dkg


signature.asc
Description: PGP signature

Bug#982629: prometheus-smokeping-prober: [INTL:de] initial German debconf translation

[Helge Kreutzmann]

Package: prometheus-smokeping-prober
Version: 0.4.1-2
Severity: wishlist
Tags: patch l10n

Please find the initial German debconf translation for 
prometheus-smokeping-prober
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the 
prometheus-smokeping-prober package.
# Helge Kreutzmann , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: prometheus-smokeping-prober 0.4.1-2\n"
"Report-Msgid-Bugs-To: prometheus-smokeping-pro...@packages.debian.org\n"
"POT-Creation-Date: 2021-02-03 15:43+0100\n"
"PO-Revision-Date: 2021-02-12 17:26+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Enable additional network privileges for ICMP probing?"
msgstr "Zusätzliche Netzwerk-Privilegien für ICMP-Sondierungen aktivieren?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"/usr/bin/prometheus-smokeping-prober requires the CAP_NET_RAW capability to "
"be able to send out crafted packets to targets for ICMP probing."
msgstr ""
"/usr/bin/prometheus-smokeping-prober benötigt die Capability CAP_NET_RAW, "
"damit es angefertigte Pakte für die Ziele der ICMP-Sondierungen aussenden "
"kann."

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"ICMP probing will not work unless this option is enabled, or prometheus-"
"smokeping-prober runs as root."
msgstr ""
"Die ICMP-Sondierung funktioniert nur, wenn diese Option gesetzt ist, "
"es sei denn, prometheus-smokeping-prober wird als root ausgeführt."

Bug#982628: virtuoso-opensource: [INTL:de] updated German debconf translation

[Helge Kreutzmann]

Package: virtuoso-opensource
Version: 7.2.5.1+dfsg-3
Severity: wishlist
Tags: patch l10n

Please find the updated German debconf translation for virtuoso-opensource
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# Translation of the virtuoso-opensource debconf templates to German
# This file is distributed under the same license as the virtuoso-opensource
# package.
#
# Martin Eberhard Schauer , 2010.
# Helge Kreutzmann , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: virtuoso-opensource 7.2.5.1+dfsg-3\n"
"Report-Msgid-Bugs-To: virtuoso-opensou...@packages.debian.org\n"
"POT-Creation-Date: 2018-08-24 07:47+0200\n"
"PO-Revision-Date: 2021-02-12 17:19+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team:  German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: password
#. Description
#: ../virtuoso-opensource-7.templates:2001
msgid "Password for DBA and DAV users:"
msgstr "Passwort für die Benutzerkonten DBA und DAV:"

#. Type: password
#. Description
#: ../virtuoso-opensource-7.templates:2001
msgid ""
"Following installation, users and passwords in Virtuoso can be managed using "
"the command line tools (see the full documentation) or via the Conductor web "
"application which is installed by default at http://localhost:8890/conductor.;
msgstr ""
"Nach der Installation können Benutzerkonten und Passwörter für Virtuoso mit "
"den Kommandozeilenwerkzeugen (siehe die vollständige Dokumentation) oder mit "
"der Web-Anwendung Conductor verwaltet werden. Conductor wird per "
"Voreinstellung unter http://localhost:8890/conductor installiert."

#. Type: password
#. Description
#: ../virtuoso-opensource-7.templates:2001
msgid ""
"Two users (\"dba\" and \"dav\") are created by default, with administrative "
"access to Virtuoso. Secure passwords must be chosen for these users in order "
"to complete the installation."
msgstr ""
"Standardmäßig werden zwei Benutzer (»dba« und »dav«) erzeugt, die zur "
"Verwaltung von Virtuoso berechtigt sind. Sie müssen für diese Benutzer "
"sichere Passwörter festlegen, um die Installation abzuschließen."

#. Type: password
#. Description
#: ../virtuoso-opensource-7.templates:2001
msgid ""
"If you leave this blank, the daemon will be disabled unless a non-default "
"password already exists."
msgstr ""
"Wenn Sie hier nichts eingeben, wird der Daemon deaktiviert. Es sei denn, es "
"existiert schon ein von der Vorgabe abweichendes Passwort."

#. Type: password
#. Description
#: ../virtuoso-opensource-7.templates:3001
msgid "Administrative users password confirmation:"
msgstr "Bestätigung des Passworts für den Benutzer mit Administrator-Rechten:"

#. Type: error
#. Description
#: ../virtuoso-opensource-7.templates:4001
msgid "Password mismatch"
msgstr "Die Passwörter stimmen nicht überein"

#. Type: error
#. Description
#: ../virtuoso-opensource-7.templates:4001
msgid ""
"The two passwords you entered were not the same. Please enter a password "
"again."
msgstr ""
"Die von Ihnen eingegebenen Passwörter waren unterschiedlich. Bitte geben Sie "
"noch einmal ein Passwort ein."

#. Type: note
#. Description
#: ../virtuoso-opensource-7.templates:5001
msgid "No initial password set, daemon disabled"
msgstr "Es wurde kein anfängliches Passwort festgesetzt, Daemon deaktiviert."

#. Type: note
#. Description
#: ../virtuoso-opensource-7.templates:5001
msgid ""
"For security reasons, the default Virtuoso instance is disabled because no "
"administration password was provided."
msgstr ""
"Aus Sicherheitsgründen wurde die Standard-Instanz von Virtuoso deaktiviert, "
"weil kein Verwaltungs-Passwort eingegeben wurde."

#. Type: note
#. Description
#: ../virtuoso-opensource-7.templates:5001
msgid "The default DBA user password will then be \"dba\"."
msgstr "Das Standrd DBA Nutzer Passwort wird dann \"dba\" sein."

#. Type: error
#. Description
#: ../virtuoso-opensource-7.templates:6001
msgid "Unable to set password for the Virtuoso DBA user"
msgstr "Festlegung eines Passworts für das Virtuoso-Konto DBA nicht möglich."

#. Type: error
#. Description
#: ../virtuoso-opensource-7.templates:6001
msgid ""
"An error occurred while setting the password for the Virtuoso administrative "
"user. This may have happened because the account already has a password, or "
"because of a communication problem with the Virtuoso server."
msgstr ""
"Beim Setzen des Passworts für den Virtuoso-Verwalter ereignete sich ein "
"Fehler. Mögliche Gründe sind ein bereits bestehendes Passwort für das Konto "
"oder ein Kommunikationsproblem mit dem Virtuoso-Server."

#. Type: error
#. Description
#: ../virtuoso-opensource-7.templates:6001
msgid ""
"If the database already 

Bug#982625: fails to authenticate with "TypeError: sequence item 2: expected str instance, bytes found" error

[Sudip Mukherjee]

Hi Stefano,

On Fri, Feb 12, 2021 at 3:30 PM Stefano Zacchiroli  wrote:
>
> Package: offlineimap
> Version: 7.3.3+dfsg1-1+0.0~git20210105.00d395b+dfsg-2
> Severity: serious
>
> In Debian testing offlineimap plain authentication over SSL started to fail 
> for
> me in the following way:

Thanks for the report. Can you please paste your offlineimaprc file
after removing any sensitive information, and I can try to reproduce
the error in my setup.


-- 
Regards
Sudip