Bug#935027: closing 935027

[Salvatore Bonaccorso]

Hi Dmitry,

On Sat, Jan 30, 2021 at 10:36:12AM +1100, Dmitry Smirnov wrote:
> On Saturday, 30 January 2021 7:18:58 AM AEDT Salvatore Bonaccorso wrote:
> > Unless mistaken this has now been fixed (in 5.0.0rc1) and is included in
> > 1:5.0.7+dfsg-1. Dmitry is this correct?
> 
> I think it was fixed in 5.0.6rc1. All good.
> Thanks for closing.

Perfect, thanks a lot for double-checking and confirming!

Regards,
Salvatore

Bug#981371: arduino-mighty-1284p: Depends on package 'arduino-core' needs to get updated to 'arduino'

[Carsten Schoenert]

Package: arduino-mighty-1284p
Version: 1-4
Severity: important

Dear Maintainer,

the src package of arduino got after several years of trying an update
to the current most recent version 1.8.13.
This update requires a droping of the old package arduino-core, the
content of this package is now melted into arduino.

Please update the old dependency on 'arduino-core' to 'arduino' so users
can user your package also in the future. Thanks!

Regrads
Carsten

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

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

Bug#981232: unblock: perl/5.32.1-1

[Paul Gevers]

Hi,

On 28-01-2021 22:36, Dominic Hargreaves wrote:
>> Would you have also asked us if you wouldn't have needed the binNMU's?
> 
> Yes, since https://release.debian.org/bullseye/freeze_policy.html says
> changes to build-essential may only be made with pre-approval...

Right. Thank you, I should learn that list by heart.

The pseudo excuses [1] report quite some autopkgtest regressions. Can
you please check them, fix them if relevant or explain why they are not
relevant for bullseye (e.g. unstable only)?

Paul

[1] https://release.debian.org/britney/pseudo-excuses-experimental.html#perl



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980727: RFS: grap/1.46-1 [QA] -- program for typesetting graphs

[Leandro Cunha]

Em sex., 29 de jan. de 2021 às 20:25, Sergio Durigan Junior <
sergi...@debian.org> escreveu:
>
> Control: owner -1 !
>
> On Tuesday, January 26 2021, Leandro Cunha wrote:
>
> > Control: owner -1 !
>
> Please don't change the owner.  The reviewer should be the bug owner.

It hasn't been changed, it's set for you. As the email didn't arrive, I
copied
and pasted it and I forgot to put the header with the control command of
BTS as a quote. It was my mistake that was fixed. Sorry.

> >>* Added debian/upstream/metadata.
> >>* Added debian/docs.
> >>
> >> While at it, please add a newline at the end of d/docs.
> >
> > Done.
>
> This is wrong.  You added an empty line, but that's not what I
> requested.  Anyway, I fixed the file for you.  Please take a look to see
> what I meant.
>

You say newline at the end of d/docs. I understood that it would be an
empty line. I think I got it wrong then. Sorry.

> >>* debian/copyright:
> >>  - Added Upstream-Contact optional field according DEP-5.
> >
> >> Thanks,
> >>
> >> --
> >> Sergio
> >> GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
> >> Please send encrypted e-mail if possible
> >> https://sergiodj.net/
> >
> > Please send me a copy by e-mail. I didn't even see the message if I
> > hadn't accessed
> > this bug. Thanks!
>
> I don't understand this part.  My original reply included you in the
> Cc.

You did include my email, but it didn't reach me. I found that strange.

> > [1] https://salsa.debian.org/leandrocunha/grap
>
> If you have a git repository containing all the history, then why not
> put it under the debian namespace and use the proper Vcs-* fields on
> debian/control?

I am not the maintainer of the package, it would be interesting in the
Debian
group on Salsa, as the package is from the project's QA group, as there are
other packages that are in that group that belong to the QA team as well.
I migrated everything after opening this RFS, was working on an incomplete
repository.

> Anyway, I uploaded the package as-is, with the empty-line problem fixed.

Thank you very much.

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

--
Cheers,
Leandro Cunha
Debian Contributor and developer.
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9

Bug#981370: CVE - critical security bug - Exploitable overflow in Libgcrypt 1.9.0

[Patrick Schleizer]

Package: libgcrypt20
Severity: important
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

Quote Werner Koch [1]:

> We have to announce the availability of Libgcrypt version 1.9.1.
This version fixes a *critical security bug* in the recently released
version 1.9.0.  If you are already using 1.9.0 please update immediately
to 1.9.1.

> On 2021-01-28 Tavis Ormandy contacted us to report a severe bug in
1.9.0 which he found while testing GnuPG:

>> There is a heap buffer overflow in libgcrypt due to an incorrect
assumption in the block buffer management code. Just decrypting some
data can overflow a heap buffer with attacker controlled data, no
verification or signature is validated before the vulnerability occurs.

> A CVE-id has not yet been assigned.

> We track this bug at https://dev.gnupg.org/T5275

Cheers,
Patrick

[1] https://lists.gnupg.org/pipermail/gnupg-announce/2021q1/000456.html
[2] https://dev.gnupg.org/T5275

Bug#601856: gkrellm: fans are not always detected on startup

[Sandro Tosi]

control: tags -1 +moreinfo

> I run gkrellm from my .xsession file, and often, gkrellm does not detect
> all three fans in my computer, but only two of them. After one or two
> minutes of being run, I can usually click on the fan menu where the
> third fan now appears, deselected. Then I can activate the monitoring of
> the fan and see the fan's status. I'd just like gkrellm to come up with
> all three fans all of the time.
>
> I have a sysfs mounted on /sys, and mbmon running "for ages".

This bug has been reported a looong time ago, but upstream recently
suggested these steps:

```
Does this still happen with recent versions (i.e. 2.3.10 or 2.3.11) in Debian?
The Debian package enabled libsensors support in 2.3.5-1 so chances
are that fans detected since then are more reliable.

If that is not the case please try starting gkrellm as gkrellm -d 0x80.
The (extensive) sensor log output should show which sensors are seen
on startup and which sensors appear later on.
```

can you follow up please?

Bug#965240: gkrellm: Gkrellm crashes at startup

[Sandro Tosi]

control: tags -1 +moreinfo

> `gkrellm` stopped working a while back for me (can't say for sure when it 
> started).
> It crashes soon after displaying its window for me.  The error message is:
>
> % /usr/bin/gkrellm --sync
> The program 'gkrellm' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadPixmap (invalid Pixmap parameter)'.
>   (Details: serial 5672 error_code 4 request_code 56 minor_code 0)
>   (Note to programmers: normally, X errors are reported asynchronously;
>that is, you will receive the error a while after causing it.
>To debug your program, run it with the --sync command line
>option to change this behavior. You can then get a meaningful
>backtrace from your debugger if you break on the gdk_x_error() 
> function.)
> %
>
> I tried starting it under `gdb`, setting a breakpoint on `gdk_x_error`
> and starting it with `--sync` but the breakpoint is never hit (and it
> seems this gdk function is never even defined).
>
> This occurs on all of my machines running Debian testing.

upstream suggested these steps:

```
Does moving/renaming $HOME/.gkrellm2 avoid the crash?
I think I have seen crashes before with certain older gkrellm themes,
starting with a fresh configuration would avoid that.

Another try would be to start gkrellm with all debug logging enabled
from a terminal and see how far it gets, i.e. gkrellm -d 32767
```

can you try them and let this bug report know? thanks

Bug#838416: alternative roughtime client

[Patrick Schleizer]

Dear Debian Developer,

thank you for your consideration of packaging roughtime for Debian!

Would an (alternative) roughtime client be more suitable, easier for
packaging?

I've created a simple list with information about roughtime including a
roughtime client list. Will expand that list as other roughtime clients
are discovered.

https://www.whonix.org/wiki/Dev/TimeSync#roughtime

Copying the the roughtime client list here for convenience.

* https://roughtime.googlesource.com/roughtime
* https://github.com/cloudflare/roughtime
* https://github.com/int08h/roughenough
* https://github.com/int08h/roughenough-fuzz
* https://github.com/ffledgling/python-roughtime
* https://github.com/dansarie/pyroughtime
* https://github.com/Merovius/notary/tree/master/roughtime
* https://github.com/nahojkap/craggy
* https://github.com/tajchert/securetime
* https://github.com/topics/roughtime
* https://github.com/bnoordhuis/node-roughtime

Kind regards,
Patrick

Bug#981369: libinput10: Suspend/Resume breaks tap to click on Thinkpad X1 2nd gen under wayland

[Russell Stuart]

Package: libinput10
Version: 1.16.4-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

After a suspend/resume cycle on a it becomes very difficult to make tap
to click register a tap.  Immediately after power cycle tap to click
never fails for me.  I suspect it takes a longer / harder tap, but its
hard to say as the range of acceptable values looks to be small as I
rarely hit it.

Environment:

  Bullseye
  Hardware: Thankpad X1 2nd generation
  Compositor: metacity 1:3.38.0-2


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

Kernel: Linux 5.10.0-2-amd64 (SMP w/12 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 libinput10 depends on:
ii  libc6 2.31-9
ii  libevdev2 1.10.1+dfsg-1
ii  libinput-bin  1.16.4-3
ii  libmtdev1 1.1.6-1
ii  libudev1  247.2-5
ii  libwacom2 1.7-1

libinput10 recommends no packages.

libinput10 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZqiOeH6lCkTWvjmorNSfiF5UUm4FAmAUzREACgkQrNSfiF5U
Um4pUQ/+P6wSLv6HcHfCDWAxuHIoq7XRo65Sbve4+adcqLLmlyrfK0Kx8u5MNFLf
nc279IvPRvRxNhyWLwInQyAUpRDWOCDZkE0W6GGKlnxYL/Beq0LhQ1M87FEJ67bL
ICXJg4F6kEp3rsuQAs/7EtmOEjmgjO4Wfm0hdsC4wQeKiNzxm0hXX07xQF1mQQqK
7iPwv84/SaI6VuiNhwV2rnTSmr5zwy8SsHh+f4leh7BnZ6Ihlc7fQ8ZUTSw3LL1A
5hbv21jJ5gdboAu8sWsoUR49ftxkOBrIXbnyDllm9GDn+0Vl1W4YEH19Y7UYu6JA
nMokvo23ndyXNIecIdvVMYexOrMXXqHnrTCwgDieFWNfzRtKh0IkarwuucxAR6zq
wpGYXQ3Kdh5a+GOFUea8/2FIyvPrDMa7pErJ18jooMWJCnwrD24khLtAtO6hGX6I
+PNfsa01AnF377juXdfA/piTVu6kKI999rNRuU9aaOqkQGy0wcLPEiXCfJpp3bhf
iY4LSn5ihtyeY9DuEL/o0XkxRj9Mtj/UYt4HKDoQdqii4AGMb/0n4xHrgOaSEJrK
N/au9nokXSCdTEMZqdtVbZzzWna3l1jVVy1i+/Q/eb6y4siPfz1OJifUno+7FXon
0B5xXjNBWGTYC+kBSlZbx0JxuRj6hq3hLathhpDN0nOWZ1CKvMU=
=XUOe
-END PGP SIGNATURE-

Bug#970501: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Sunil Mohan Adapa]

tag 970501 + patch
thanks

Hello,

It appears that newer JavaScript versions supported by Rhino cause Dojo
to throw an exception during tests for shrinksafe module. When using an
older JavaScript version 1.7, the error goes away. The attached patch
fixes build and autopkgtest problems.

Please consider applying the patch to ensure that Dojo and its
dependents like tt-rss, used in FreedomBox are available in Bullseye.

Thanks,

-- 
Sunil
>From c92570f765d73aa6c1d717376f81aafa529964c2 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Fri, 29 Jan 2021 17:51:10 -0800
Subject: [PATCH] Fix shrinksafe tests with newer rhino by setting JS version

Signed-off-by: Sunil Mohan Adapa 
---
 .../0004-Fix-shrinksafe-tests-with-new-rhino.patch | 10 ++
 debian/patches/series  |  1 +
 2 files changed, 11 insertions(+)
 create mode 100644 debian/patches/0004-Fix-shrinksafe-tests-with-new-rhino.patch

diff --git a/debian/patches/0004-Fix-shrinksafe-tests-with-new-rhino.patch b/debian/patches/0004-Fix-shrinksafe-tests-with-new-rhino.patch
new file mode 100644
index ..486f939a
--- /dev/null
+++ b/debian/patches/0004-Fix-shrinksafe-tests-with-new-rhino.patch
@@ -0,0 +1,10 @@
+Index: dojo/util/shrinksafe/tests/runner.sh
+===
+--- dojo.orig/util/shrinksafe/tests/runner.sh
 dojo/util/shrinksafe/tests/runner.sh
+@@ -1,4 +1,4 @@
+ #!/bin/sh
+ 
+ cd ../../doh
+-java -classpath ../shrinksafe/js.jar:../shrinksafe/shrinksafe.jar org.mozilla.javascript.tools.shell.Main ../../dojo/dojo.js baseUrl=../../dojo load=doh test=util/shrinksafe/tests/module testUrl=../shrinksafe/tests/module.js
++java -classpath ../shrinksafe/js.jar:../shrinksafe/shrinksafe.jar org.mozilla.javascript.tools.shell.Main -version 170 ../../dojo/dojo.js baseUrl=../../dojo load=doh test=util/shrinksafe/tests/module testUrl=../shrinksafe/tests/module.js
diff --git a/debian/patches/series b/debian/patches/series
index f39e7f29..c75b2155 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 0001-Compatibility-patch-for-newer-rhino.patch
 0002-Do-notrun-test-suite-in-build.patch
 0003-Disable-flash-storage.patch
+0004-Fix-shrinksafe-tests-with-new-rhino.patch
-- 
2.29.2

Bug#981301: elvish: please document where you want tab completion directives installed

[Daniel Kahn Gillmor]

On Fri 2021-01-29 12:47:53 +0800, Shengjing Zhu wrote:
> It doesn't support global completion files yet. Author just says he will
> consider this after 0.15.

OK, thanks for the heads-up!

When you know where the global completion files are likely to be looked
for (even if the upstream version is not released yet), please follow up
on this ticket.  That way, we can ship the files in the right place in
debian, and when elvish gains that capability, there will already be
some completion files available.

(also, if there's a known place to ship .elv files, then elvish users in
the meantime can copy them into wherever their local completion files
are supposed to go, right?)

All the best,

--dkg


signature.asc
Description: PGP signature

Bug#981367: ruby-kramdown-rfc2629 new upstream version 1.3.24 is available

[Daniel Kahn Gillmor]

Package: src:ruby-kramdown-rfc2629
Version: 1.3.9-1

Looks like ruby-kramdown-rfc2629 upstream version 1.3.24 is available,
with a series of fairly minor bugfixes.  It'd be great to have that
up-to-date in debian.

I can NMU it if necessary, but i'd also be happy not to :)

  --dkg


signature.asc
Description: PGP signature

Bug#953288: /usr/lib/python3/dist-packages/mpmath/ctx_mp_python.py: SyntaxWarning: "is" with a literal. Did you mean "=="?

[Sandro Tosi]

> On Wednesday, January 20, 2021 1:12:43 PM EST Sandro Tosi wrote:
> > there's probably a new mpmath release happening soon (check
> > https://github.com/fredrik-johansson/mpmath/issues/565) so i'm gonna
> > wait for that
> Do you intend for that to make it into Bullseye?

yes

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

Bug#981355: RFS: cramfsswap/1.4.2 [QA] -- swap endianness of a cram filesystem (cramfs)

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: cramfsswap
   Version : 1.4.2
   Upstream Author :
 * URL :
 * License : GPL-2
 * Vcs :
   Section : utils

It builds those binary packages:

  cramfsswap - swap endianness of a cram filesystem (cramfs)

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/c/cramfsswap/cramfsswap_1.4.2.dsc

Changes since the last upload:

 cramfsswap (1.4.2) unstable; urgency=medium
 .
   * QA upload.
   * Change back to native version Closes: #953595
   * Use source format 3.0 native
   * d/dirs: Remove empty directory
   * d/control:
 - Fix spelling error in description Closes: #543208, #684790
 - Set Debian QA as maintainer. see #981049
 - Change to debhelper-compat
 - Bump debhelper to 12
 - Change Priority field from extra to optional
 - Add misc:Depends to support debhelper
 - Add Rules-Requires-Root
 - Change architecture to linux-any
 - Update Standards-Version to 4.5.1
   * d/rules: Change to dh-sequencer
   * d/copyright: Change to DEP-5 format
   .
   * Add CFLAGS, CPPFLAGS and LDFLAGS in makefile
   * Fix typo in man-page

Regards,

Bug#934843: parsedatetime: FTBFS in stretch

[Santiago Vila]

On Thu, 14 Nov 2019, Harlan Lieberman-Berg wrote:

> tag 934843 +unreproducible
> thanks
> 
> On Thu, 15 Aug 2019 19:12:49 + Santiago Vila  wrote:
> > I tried to build this package in stretch but it failed:
> 
> Hello!
> 
> This is quite strange.  I've tried rebuilding it several times in my
> stretch sbuild, and it worked every time without error.  I also
> re-triggered the build on reproducible-builds, and it's now clean
> there as well.
> 
> One possibility that comes to mind is locales -- what locales are you
> compiling under? It's possible there's a bug in one of the
> locale-specific parsers that's not getting exercised on my sbuild,
> through, I admit to not being sure how reproducible-builds could have
> been affected by the same thing.  Otherwise, maybe a difference in one
> of the deps that was fixed in the last... day?

Sprry for the late reply.

I reported this in 2019-08 and the first reply came in 2019-11.
By that time, the package built ok again in my autobuilders according
to my build history:

Status: successful  parsedatetime_2.1-3+deb9u1_amd64-20190216T184806.957Z
Status: successful  parsedatetime_2.1-3+deb9u1_amd64-20190319T030404.993Z
Status: failed  parsedatetime_2.1-3+deb9u1_amd64-20190812T104812.785Z
Status: failed  parsedatetime_2.1-3+deb9u1_amd64-20190812T115932.874Z
Status: failed  parsedatetime_2.1-3+deb9u1_amd64-20190812T115928.188Z
Status: failed  parsedatetime_2.1-3+deb9u1_amd64-20190812T115932.124Z
Status: failed  parsedatetime_2.1-3+deb9u1_amd64-20190812T115937.789Z
Status: failed  parsedatetime_2.1-3+deb9u1_amd64-20190812T115954.716Z
Status: failed  parsedatetime_2.1-3+deb9u1_amd64-20190812T120006.211Z
Status: failed  parsedatetime_2.1-3+deb9u1_amd64-20190812T115946.514Z
Status: failed  parsedatetime_2.1-3+deb9u1_amd64-20190812T120019.561Z
Status: failed  parsedatetime_2.1-3+deb9u1_amd64-20190812T115949.086Z
Status: failed  parsedatetime_2.1-3+deb9u1_amd64-20190812T120022.496Z
Status: successful  parsedatetime_2.1-3+deb9u1_amd64-20191018T145214.267Z
Status: successful  parsedatetime_2.1-3+deb9u1_amd64-20191018T172715.052Z
Status: successful  parsedatetime_2.1-3+deb9u1_amd64-20200210T050524.951Z
Status: successful  parsedatetime_2.1-3+deb9u1_amd64-20200305T171505.547Z
Status: successful  parsedatetime_2.1-3+deb9u1_amd64-20200720T162707.522Z

However, by looking at the build log and the kind of error, I believe
it's the kind of date-related bug in the test suite which only happens
in certain times of the year. Does this make sense?

Why would this happen if not?

Result:
(time.struct_time(tm_year=2019, tm_mon=8, tm_mday=22,
tm_hour=3, tm_min=26, tm_sec=0,
+tm_wday=0, tm_yday=224, tm_isdst=-1), 3)

Expected:
(time.struct_time(tm_year=2020, tm_mon=8, tm_mday=22,
tm_hour=3, tm_min=26, tm_sec=0,
+tm_wday=5, tm_yday=235, tm_isdst=-1), 3)


I have not tested myself, but if this were my package I would try to
built it in 2019-08 (using "libfaketime" or something similar), as the
failure in the test suite seems to depend on the date on which it's
built.

(I'm not reopening the bug, but I believe this little extra
information belongs to the bug report).

Thanks.

Bug#953288: /usr/lib/python3/dist-packages/mpmath/ctx_mp_python.py: SyntaxWarning: "is" with a literal. Did you mean "=="?

[John Scott]

Control: affects -1 sagemath cantor-backend-sage

On Wednesday, January 20, 2021 1:12:43 PM EST Sandro Tosi wrote:
> there's probably a new mpmath release happening soon (check
> https://github.com/fredrik-johansson/mpmath/issues/565) so i'm gonna
> wait for that
Do you intend for that to make it into Bullseye? I've found that this 
adversely affects Cantor's SageMath backend on first use, so if not, I'd really 
appreciate it being patched around.



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

Bug#981153: [Pkg-rust-maintainers] Bug#981153: cargo: Please package new upstream (blocks Firefox 85)

[Amy Kos]

Control: severity -1 wishlist


Understood. Thanks for the explanation.

Cheers,
Amy

Bug#935027: closing 935027

[Dmitry Smirnov]

On Saturday, 30 January 2021 7:18:58 AM AEDT Salvatore Bonaccorso wrote:
> Unless mistaken this has now been fixed (in 5.0.0rc1) and is included in
> 1:5.0.7+dfsg-1. Dmitry is this correct?

I think it was fixed in 5.0.6rc1. All good.
Thanks for closing.

-- 
Kind regards,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

If everybody is thinking alike, then somebody isn't thinking.
-- George S. Patton

---

And how long a lockdown is enough? If we open now, will lockdown recur in
autumn? Next year? Whenever authoritarianism so wishes? No dictatorship
could imagine a better precedent for absolute control.
-- https://www.bmj.com/content/369/bmj.m1924.long
:: BMJ 2020;369:m1924 "Should governments continue lockdown to slow the 
spread of covid-19?"


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

Bug#981171: [PATCH 6/6] Use subsection for environment

[roucaries . bastien]

From: Bastien Roucariès 

In order to improve readability create four subsections:
-  POSIX defined core environment variables, for variables defined by POSIX that
modify the general behavior of a program
- Internationalization environment variables for variables related to 
internationalization
- User customization environment variables for personnalizing application to 
user taste.
- Other common environment variables for other common variables

Move USER to other because this variable is not defined by POSIX

Signed-off-by: Bastien Roucariès 
---
 man7/environ.7 | 123 ++---
 1 file changed, 66 insertions(+), 57 deletions(-)

diff --git a/man7/environ.7 b/man7/environ.7
index 9fd3f727f..45204438f 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -138,38 +138,20 @@ to not conflict with the variables specified in the next 
sections.
 Environment variables specific to a particular program or library function
 are documented in the ENVIRONMENT section of the appropriate manual page.
 .SH ENVIRONMENT
-Common examples of environment variables are:
-.TP
-.B USER
-The name of the logged-in user (used by some BSD-derived programs).
-Set at login time, see section NOTES below.
+.SS POSIX defined core environment variables
+Common examples of environment variables defined by POSIX that may modify the 
general
+behavior of a program, are defined in the following section.
+Conforming applications shall not set these environment variables to have
+meanings other than as described.
 .TP
 .B LOGNAME
-The name of the logged-in user (used by some System-V derived programs).
+The name of the logged-in user.
 Set at login time, see section NOTES below.
 .TP
 .B HOME
 A user's login directory, set a login time.
 Set at login time, see section NOTES below.
 .TP
-.B LANG
-The name of a locale to use for locale categories when not overridden
-by
-.B LC_ALL
-or more specific environment variables such as
-.BR LC_COLLATE ,
-.BR LC_CTYPE ,
-.BR LC_MESSAGES ,
-.BR LC_MONETARY ,
-.BR LC_NUMERIC ,
-and
-.BR LC_TIME
-(see
-.BR locale (7)
-for further details of the
-.BR LC_*
-environment variables).
-.TP
 .B PATH
 The sequence of directory prefixes that
 .BR sh (1)
@@ -207,6 +189,62 @@ Set at login time, see section NOTES below.
 .TP
 .B TERM
 The terminal type for which output is to be prepared.
+.SS Internationalization environment variables
+.TP
+.B LANG
+The name of a locale to use for locale categories when not overridden
+by
+.B LC_ALL
+or more specific environment variables such as
+.B LC_COLLATE ,
+.B LC_CTYPE ,
+.B LC_MESSAGES ,
+.B LC_MONETARY ,
+.B LC_NUMERIC ,
+and
+.BR LC_TIME.
+See
+.BR catopen (3),
+.BR gettext (3),
+.BR locale (7)
+for further details of the
+.B LANG
+and
+.B LC_*
+environment variables.
+.TP
+.BR TZ/TZDIR
+.B TZ
+variable (in association with
+.B TZDIR)
+gives timezone information used by
+.BR tzset (3)
+and through that by functions like
+.BR ctime (3),
+.BR localtime (3),
+.BR mktime (3),
+.BR strftime (3).
+See also
+.BR tzselect (8).
+.SS User customization environment variables
+The following variables are commonly used for personalizing
+applications used by the user:
+.\" .TP
+.\" .B BROWSER
+.\" The user's preferred utility to browse URLs. Sequence of colon-separated
+.\" browser commands. See http://www.catb.org/\(tiesr/BROWSER/ .
+.TP
+.B COLUMNS/LINES
+The
+.B COLUMNS " and " LINES
+variables
+tell applications about the window size, possibly overriding the actual size.
+.TP
+.BR EDITOR / VISUAL
+The user's preferred utility to edit text files.
+Any string acceptable as a command_string operand to the
+.I sh\ \-c
+command shall be valid.
 .TP
 .B PAGER
 The user's preferred utility to display text files.
@@ -218,30 +256,11 @@ variable is null or not set,
 command could fallback
 .B more (1)
 or any suitable paging utility default defined system-wise.
-.TP
-.BR EDITOR / VISUAL
-The user's preferred utility to edit text files.
-Any string acceptable as a command_string operand to the
-.I sh\ \-c
-command shall be valid.
-.\" .TP
-.\" .B BROWSER
-.\" The user's preferred utility to browse URLs. Sequence of colon-separated
-.\" browser commands. See http://www.catb.org/\(tiesr/BROWSER/ .
-.PP
+.SS Other common environment variables
 Note that the behavior of many programs and library routines is
 influenced by the presence or value of certain environment variables.
 Examples include the following:
 .IP * 3
-The variables
-.BR LANG ", " LANGUAGE ", " NLSPATH ", " LOCPATH ,
-.BR LC_ALL ", " LC_MESSAGES ,
-and so on influence locale handling; see
-.BR catopen (3),
-.BR gettext (3),
-and
-.BR locale (7).
-.IP *
 .B TMPDIR
 influences the path prefix of names created by
 .BR tempnam (3)
@@ -272,23 +291,13 @@ gives the name of a file containing aliases
 to be used with
 .BR gethostbyname (3).
 .IP *
-.BR TZ " and " TZDIR
-give timezone information used by
-.BR tzset (3)
-and through that by functions like
-.BR ctime (3),
-.BR localtime (3),
-.BR mktime 

Bug#981171: [PATCH 5/6] Create a section ENVIRONMENT

[roucaries . bastien]

From: Bastien Roucariès 

According to man-page (7):
 ENVIRONMENT
  A list of all environment variables that affect the program or 
function and how they affect it.

Therefore push the list of variables to an ENVIRONMENT section.

Reorder also how to set environment variables to DESCRIPTION instead of after 
the ENVIRONMENT section
in order to improve readability.

Signed-off-by: Bastien Roucariès 
---
 man7/environ.7 | 95 +++---
 1 file changed, 52 insertions(+), 43 deletions(-)

diff --git a/man7/environ.7 b/man7/environ.7
index d1e86ee8d..9fd3f727f 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -87,7 +87,58 @@ The value can be anything that can be represented as a 
string.
 The name and the value may not contain an embedded null byte (\(aq\e0\(aq),
 since this is assumed to terminate the string.
 .PP
-Common examples are:
+Environment variables may be placed in the shell's environment by the
+.I export
+command in
+.BR sh (1),
+or by the
+.I setenv
+command if you use
+.BR csh (1).
+.PP
+The initial environment of the shell is populated in various ways,
+such as definitions from
+.IR /etc/environment
+that are processed by
+.BR pam_env (8)
+for all users at login time (on systems that employ
+.BR pam (8)).
+In addition, various shell initialization scripts, such as the system-wide
+.IR /etc/profile
+script and per-user initializations script may include commands
+that add variables to the shell's environment;
+see the manual page of your preferred shell for details.
+.PP
+Bourne-style shells support the syntax
+.PP
+NAME=value command
+.PP
+to create an environment variable definition only in the scope
+of the process that executes
+.IR command .
+Multiple variable definitions, separated by white space, may precede
+.IR command .
+.PP
+Arguments may also be placed in the
+environment at the point of an
+.BR exec (3).
+A C program can manipulate its environment using the functions
+.BR getenv (3),
+.BR putenv (3),
+.BR setenv (3),
+and
+.BR unsetenv (3).
+.PP
+What follows is a list of environment variables typically seen on a
+system.
+This list is incomplete and includes only common variables seen
+by average users in their day-to-day routine.
+Care should be taken
+to not conflict with the variables specified in the next sections.
+Environment variables specific to a particular program or library function
+are documented in the ENVIRONMENT section of the appropriate manual page.
+.SH ENVIRONMENT
+Common examples of environment variables are:
 .TP
 .B USER
 The name of the logged-in user (used by some BSD-derived programs).
@@ -178,48 +229,6 @@ command shall be valid.
 .\" The user's preferred utility to browse URLs. Sequence of colon-separated
 .\" browser commands. See http://www.catb.org/\(tiesr/BROWSER/ .
 .PP
-Names may be placed in the shell's environment by the
-.I export
-command in
-.BR sh (1),
-or by the
-.I setenv
-command if you use
-.BR csh (1).
-.PP
-The initial environment of the shell is populated in various ways,
-such as definitions from
-.IR /etc/environment
-that are processed by
-.BR pam_env (8)
-for all users at login time (on systems that employ
-.BR pam (8)).
-In addition, various shell initialization scripts, such as the system-wide
-.IR /etc/profile
-script and per-user initializations script may include commands
-that add variables to the shell's environment;
-see the manual page of your preferred shell for details.
-.PP
-Bourne-style shells support the syntax
-.PP
-NAME=value command
-.PP
-to create an environment variable definition only in the scope
-of the process that executes
-.IR command .
-Multiple variable definitions, separated by white space, may precede
-.IR command .
-.PP
-Arguments may also be placed in the
-environment at the point of an
-.BR exec (3).
-A C program can manipulate its environment using the functions
-.BR getenv (3),
-.BR putenv (3),
-.BR setenv (3),
-and
-.BR unsetenv (3).
-.PP
 Note that the behavior of many programs and library routines is
 influenced by the presence or value of certain environment variables.
 Examples include the following:
-- 
2.29.2

Bug#981171: [PATCH 4/6] Better documentation of the environment mechanism

[roucaries . bastien]

From: Bastien Roucariès 

Document the purpose of the envirment mechanism, compared to the
command line argument of a program. Document particularly that
the environment is shared by many programs and is inherited.

Define also the so called process environment and "the environment"
concept that are used in other manpages.

Signed-off-by: Bastien Roucariès 
---
 man7/environ.7 | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/man7/environ.7 b/man7/environ.7
index 3c2769bfb..d1e86ee8d 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -43,6 +43,32 @@ The variable
 .I environ
 points to an array of pointers to strings called the "environment".
 The last pointer in this array has the value NULL.
+.PP
+At time of execution, a program receive context information by two mechanisms.
+The first way is the program arguments, represented by the arguments of
+.I main
+function,
+.I argc
+and
+.I argv
+variables. The second way, is the
+.I environ
+variable as discuted in this manual.
+.PP
+The program arguments are typically used to pass so-called command-line 
argument specific to
+a particular use of the program being invoked, thus changing the program 
behavior to an use case.
+The environment, on the other hand, keeps track of information that is shared 
by many programs and
+rarely changes.
+For example, a running process can query the value of the
+.B TMPDIR
+environment variable to discover a suitable location to store temporary files.
+.PP
+Standard environment variables are used for information about the user’s home 
directory,
+current language,...
+An user can define additional variables for other purposes.
+The set of all environment variables that have values is collectively known as
+the process environment or simply the environment.
+.PP
 This array of strings is made available to the process by the
 .BR execve (2)
 call when a new program is started.
-- 
2.29.2

Bug#981171: [PATCH 2/6] Document PATH resolution

[roucaries . bastien]

From: Bastien Roucariès 

Document PATH resolution, particularly null sequence and empty PATH

Document also that since POSIX.1-2001 null sequence for . are deprecated.

Signed-off-by: Bastien Roucariès 
---
 man7/environ.7 | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/man7/environ.7 b/man7/environ.7
index e33dcc754..9ac86f357 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -97,16 +97,28 @@ environment variables).
 The sequence of directory prefixes that
 .BR sh (1)
 and many other
-programs apply in searching for a file known by an incomplete pathname.
+programs using
+.BR execlp (3)
+apply in searching for a file known by an incomplete pathname.
 The prefixes are separated by \(aq\fB:\fP\(aq.
-(Similarly one has
+When a non-zero-length prefix is applied to this pathname, a \(aq\fB/\fP\(aq
+(slash) shall be inserted between the prefix and the filename if the prefix
+did not end in
+\(aq\fB\(sl\fP\(aq (slash).
+A zero length prefix is a legacy sequence that indicate the current directory 
or
+\(aq\fB.\fP\(aq (see section BUGS below).
+The list of prefixes shall be searched from beginning to end, applying the
+pathname to each prefix, until an executable file with the specified name
+and appropriate execution permissions is found.
+.IP
+Similarly one has
 .B CDPATH
 used by some shells to find the target
 of a change directory command,
 .B MANPATH
 used by
 .BR man (1)
-to find manual pages, and so on)
+to find manual pages, and so on.
 .TP
 .B PWD
 The current working directory.
@@ -323,6 +335,14 @@ The authors of
 .I gzip
 should consider renaming their option to
 .BR GZIP_OPT .
+.PP
+.B PATH
+zero lengh sequence,
+that appears as two adjacent colons \(aq\fB::\fP\(aq, as a initial colon
+\(aq\fB:\fP\(aq preceding the rest of the list,
+or as a trailing colon \(aq\fB:\fP\(aq following the rest of the list,
+shall be replaced by implicit \(aq\fB.\fP\(aq, in order to be portable
+and strictly conformant to POSIX.1-2001.
 .SH SEE ALSO
 .BR bash (1),
 .BR csh (1),
-- 
2.29.2

Bug#981171: [PATCH 3/6] Improve pager section by pointing to more

[roucaries . bastien]

From: Bastien Roucariès 

More is the default pager according to mailx manual page of POSIX.1-2001 to
POSIX.1-2017. Mention it.
---
 man7/environ.7 | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/man7/environ.7 b/man7/environ.7
index 9ac86f357..3c2769bfb 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -135,7 +135,12 @@ The terminal type for which output is to be prepared.
 The user's preferred utility to display text files.
 Any string acceptable as a command_string operand to the
 .I sh\ \-c
-command shall be valid.
+command shall be valid. If the
+.B PAGER
+variable is null or not set,
+command could fallback
+.B more (1)
+or any suitable paging utility default defined system-wise.
 .TP
 .BR EDITOR / VISUAL
 The user's preferred utility to edit text files.
@@ -348,6 +353,7 @@ and strictly conformant to POSIX.1-2001.
 .BR csh (1),
 .BR env (1),
 .BR login (1),
+.BR more (1),
 .BR printenv (1),
 .BR sh (1),
 .BR su (1),
-- 
2.29.2

Bug#981171: [PATCH 0/6][V2] environement (7)

[roucaries . bastien]

Please review and apply

[PATCH 1/6] Document that means at login time for HOME, LOGNAME,
[PATCH 2/6] Document PATH resolution
[PATCH 3/6] Improve pager section by pointing to more
[PATCH 4/6] Better documentation of the environment mechanism
[PATCH 5/6] Create a section ENVIRONMENT
[PATCH 6/6] Use subsection for environment

Bug#981171: [PATCH 1/6] Document that means at login time for HOME, LOGNAME, SHELL, USER

[roucaries . bastien]

From: Bastien Roucariès 

Clearly document that HOME, LOGNAME, SHELL and USER are set at login time
by program like login (1).

Document also that using su could result in a mixed environment, and point to
su manual.

Signed-off-by: Bastien Roucariès 
---
 man7/environ.7 | 34 ++
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/man7/environ.7 b/man7/environ.7
index 8f89ba86b..e33dcc754 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -65,15 +65,15 @@ Common examples are:
 .TP
 .B USER
 The name of the logged-in user (used by some BSD-derived programs).
+Set at login time, see section NOTES below.
 .TP
 .B LOGNAME
 The name of the logged-in user (used by some System-V derived programs).
+Set at login time, see section NOTES below.
 .TP
 .B HOME
-A user's login directory, set by
-.BR login (1)
-from the password file
-.BR passwd (5).
+A user's login directory, set a login time.
+Set at login time, see section NOTES below.
 .TP
 .B LANG
 The name of a locale to use for locale categories when not overridden
@@ -114,6 +114,7 @@ Set by some shells.
 .TP
 .B SHELL
 The absolute pathname of the user's login shell.
+Set at login time, see section NOTES below.
 .TP
 .B TERM
 The terminal type for which output is to be prepared.
@@ -260,6 +261,30 @@ The
 and
 .B PR_SET_MM_ENV_END
 operations can be used to control the location of the process's environment.
+.PP
+The
+.B HOME,
+.B LOGNAME,
+.B SHELL
+and
+.B USER
+variables are only set when an user is changing using
+session management interface, typically by program
+.B login(1)
+from user database (for instance, but not limited, by using
+.B password (5)
+database).
+Particularly,
+.BR setuid (2)
+family of function
+does not set theses variables. Notes that as documented,
+going to root by
+.BR su (8)
+may result in a mixed environment where
+.B LOGNAME
+and
+.B USER
+are retained from old user.
 .SH BUGS
 Clearly there is a security risk here.
 Many a system command has been
@@ -305,6 +330,7 @@ should consider renaming their option to
 .BR login (1),
 .BR printenv (1),
 .BR sh (1),
+.BR su (1),
 .BR tcsh (1),
 .BR execve (2),
 .BR clearenv (3),
-- 
2.29.2

Bug#981366: python3-stdeb: New upstream release

[Andreas Henriksson]

Package: python3-stdeb
Version: 0.8.5-3
Severity: wishlist

Dear Maintainer,

Several new upstream releases has been shipped since the one that's
currently in testing/unstable. The latest at this time is 0.10.0.

There are many bugs in the current package that in my opinion more
or less makes it completly unusable! The problems seems to have
been fixed upstream.

I've attempted to update the packaging myself and you can find the
result in my repo forked from the Vcs-Git stdeb repo:
https://salsa.debian.org/ah/stdeb

I've tested my updated package doing both:
- pypi-download tox
- py2dsc-deb -d deb_tox tox*
which worked (after installing all the python3-* needed by the tox
testsuite).

Please however beware that I'm nowhere near qualified in python,
but it seemed like the result couldn't end up much more broken then
the current situation.

If you're too busy to handle this please feel free to tell me to NMU!
If I'm not mistaken I think I have commit access to the python repos
on salsa already.

Regards,
Andreas Henriksson

Bug#932461: src:libfm: archivers.list fix xarchiver command

[Amy Kos]

Hi,

January 29, 2021 12:05 PM, "Andrew Lee" mailto:ajq...@debian.org?to=%22Andrew%20Lee%22%20)> wrote:
@Amy Kos (mailto:a...@disroot.org) Thanks for trying so hard and already put 
your name in the changelog entry.
Are you intend to become one of the maintainers or you only need a NMU or a 
sponsor upload?
I have to learn much more before even considering to become a maintainer.
As far as I understand, NMU is only for developers or maintainers of other 
packages.
Sponsored upload at mentors.debian.net would probably work, but it may not be 
necessary.
I've removed my name from changelog, it was rather meant as a placeholder.

Those patches will be obsolete as soon upstream merge:
https://github.com/lxde/libfm/pull/69

@Ingo Brückl 
May I ask you to do a pull request for libfm-qt too?
https://github.com/lxqt/libfm-qt

Cheers,
Amy

Bug#919233: Install Guide vs. Secure Boot

[Lou Poppler]

Hopefully this is already changed in the Bullseye install guide, but if not, I
don't think I will learn how to make edits before Bullseye releases.

The Buster install guide says in Section 3.6.3 
https://www.debian.org/releases/stable/amd64/ch03s06.en.html#UEFI

   Another UEFI-related topic is the so-called “secure boot”
   mechanism.  Secure boot means a function of UEFI implementations that
   allows the firmware to only load and execute code that is
   cryptographically signed with certain keys and thereby blocking any
   (potentially malicious) boot code that is unsigned or signed with
   unknown keys.  In practice the only key accepted by default on most
   UEFI systems with secure boot is a key from Microsoft used for signing
   the Windows bootloader.  As the boot code used by debian-installer is not 
   signed by Microsoft, booting the installer requires prior deactivation of
   secure boot in case it is enabled.

My test on a recent weekly-build testing netinst seems to show that the above is
no longer correct -- it booted fine for me in UEFI/SecureBoot mode.  I thought I
remembered reading (somewhere) that all recent debian installers (and live
systems??) can boot in legacy BIOS mode or UEFI mode with or without secure
boot.  

Bug#980600: getdp: FTBFS: ld: /usr/lib/x86_64-linux-gnu/libslepc.so: undefined reference to `MPIU_SUM'

[s3v]

Dear Maintainer,

I tried to build your package in a sid chroot
environment and no problems occurred.

Please see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980751

Kind Regards

Bug#980900: debian/watch doesn't find upstream releases

[John Scott]

> As mentioned, I'm not sure the watch file should show all tagged
> versions of Graphviz.
My bad; I didn't realize Graphviz had such a versioning scheme. Their most 
recent release announcement, mentioning that they were moving their location 
for tarballs, left me with the impression it was stable. Feel free to close 
this bug then if the watch file is fine as-is.

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

Bug#979422: Sv: Bug#979422: Acknowledgement (minicom does not consider port busy if lockfile isn't readable (existence isn't enough))

[Adam Lackorzynski]

Hi Björn,

On Fri Jan 29, 2021 at 09:35:45 +, Björn Wiberg wrote:
> Hello Adam!
> 
> Thank you for your reply!
> 
> On Sun, 24 Jan 2021 20:44:23 +0100 Adam Lackorzynski 
> wrote: 
> > I improved the handling in minicom upstream to consider this case. 
> 
> Thanks a lot!
> 
> > Still, minicom creates the lockfile such that it is readable by 
> > everyone. In your case, has the lockfile been created by minicom or 
> > someone else? 
> 
> The lockfile was created by another software (socat).
> 
> It (socat) appears to have problems both with the format (reported separately 
> in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979445), and, as noted, 
> with the permissions (reported separately in 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979506).

Ah, this explains it then. Thanks for letting us know!


Adam

Bug#937194: opencaster: Python2 removal in sid/bullseye

[Thorsten Alteholz]

Hi Moritz,

On Fri, 29 Jan 2021, Moritz Mühlenhoff wrote:

opencaster seems dead upstream, should it be removed or are
you planning to port it to Python 3 yourself?


I don't plan to do the porting myself, so I think at the moment it should 
be better removed.


  Thorsten

Bug#981230: Unrecoverable split.

[Maurizio Cimaschi]

Hello Feri,

On Fri, Jan 29, 2021 at 02:59:05PM +0100, wf...@niif.hu wrote:
> To my best understanding this issue was actually in Kronosnet.  Can you
> reproduce the problem with the backports version (1.16-2~bpo10+1)
> installed?

The issue was not deterministic, so it was difficult to reproduce. Besides
I've installed the backports' version of Kronosnet. The issue have not
showed up itself since then. 

> I'll certainly consider backporting Corosync if really needed.

Thank you for your kindness.

Regards.

Bug#981171: [PATCH 06/13] Improve pager section by pointing to more

[Bastien ROUCARIES]

Le ven. 29 janv. 2021 à 12:28, Michael Kerrisk (man-pages)
 a écrit :
>
> On Fri, 29 Jan 2021 at 12:00, Bastien Roucariès
>  wrote:
> >
> > Le jeudi 28 janvier 2021, 09:31:00 UTC Michael Kerrisk (man-pages) a écrit :
> > > On 1/27/21 4:48 PM, roucaries.bast...@gmail.com wrote:
> > > > From: Bastien Roucariès 
> > > >
> > > > More is the default pager in a lot of system mention it
> > >
> > > Really "more" and not "less"?
> >
> > Yes, debian distribution have been patched to fallback to pager that is less
> > by default. But it is not the standard
>
> I use Fedora. The default is "less" on the applications I looked at.
> When you say "it is not the standard", can you say more precisely what
> you mean?

According to POSIX mailx manual:
PAGER
Determine a string representing an output filtering or pagination
command for writing the output to the terminal. Any string acceptable
as a command_string operand to the sh -c command shall be valid. When
standard output is a terminal device, the message output shall be
piped through the command if the mailx internal variable crt is set to
a value less the number of lines in the message; see Internal
Variables in mailx. If the PAGER variable is null or not set, the
paginator shall be either more or another paginator utility documented
in the system documentation. The effects of this variable are
unspecified if the User Portability Utilities option is not supported.

So it is up to the distribution to use less,
>
> Thanks,
>
> Michael
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/

Bug#981365: linux-image-5.10.0-2-amd64: HP EliteBook x360 1040 G6 crashing since 5.10.0-1

[Cervinko]

Package: src:linux
Version: 5.10.9-1
Severity: critical
Justification: breaks the whole system
X-Debbugs-Cc: filzstift2...@gmail.com

Dear Maintainer,
since kernel 5.10.0-1 debian is very unstable on my HP EliteBook x360 1040 G6. 
It freezes after some minutes or hours after boot. When it freezes i can only 
move the mouse pointer but can't do anything else.

dmesg gets flooded with "retire_capture_urb: x callbacks suppressed"
messages. and sound via usb interface is crackling. Overall usb devices
work very unreliable. 

I already had some "retire_capture_urb: x callbacks suppressed" messages
in older kernel version. but very rarely and the system never crashed.
Kernel version 5.9 works fine for me.

i am using a thunderbolt docking station


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

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-2-amd64 
root=UUID=04c8fa04-e284-48d4-b385-624f3a9cb08b ro quiet

** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[   50.170866] input: Unicomp  Endura Pro Keyboard  Consumer Control as 
/devices/pci:00/:00:1c.4/:02:00.0/:03:04.0/:39:00.0/:3a:02.0/:3b:00.0/usb5/5-1/5-1.3/5-1.3.1/5-1.3.1:1.1/0003:17F6:0905.0008/input/input37
[   50.188545] usb 6-1.3.3: New USB device found, idVendor=0bda, 
idProduct=8153, bcdDevice=31.00
[   50.188548] usb 6-1.3.3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=6
[   50.188550] usb 6-1.3.3: Product: USB 10/100/1000 LAN
[   50.188551] usb 6-1.3.3: Manufacturer: Realtek
[   50.188553] usb 6-1.3.3: SerialNumber: 00167F690
[   50.227862] input: Unicomp  Endura Pro Keyboard  System Control as 
/devices/pci:00/:00:1c.4/:02:00.0/:03:04.0/:39:00.0/:3a:02.0/:3b:00.0/usb5/5-1/5-1.3/5-1.3.1/5-1.3.1:1.1/0003:17F6:0905.0008/input/input38
[   50.227997] hid-generic 0003:17F6:0905.0008: input,hidraw3: USB HID v1.10 
Mouse [Unicomp  Endura Pro Keyboard ] on usb-:3b:00.0-1.3.1/input1
[   50.239354] usbcore: registered new interface driver r8152
[   50.247329] usbcore: registered new interface driver cdc_ether
[   50.267791] usb 5-1.4.2: new low-speed USB device number 6 using xhci_hcd
[   50.381520] usb 5-1.4.2: New USB device found, idVendor=1267, 
idProduct=0210, bcdDevice=22.70
[   50.381525] usb 5-1.4.2: New USB device strings: Mfr=0, Product=2, 
SerialNumber=0
[   50.381528] usb 5-1.4.2: Product: PS/2+USB Mouse
[   50.390702] input: PS/2+USB Mouse as 
/devices/pci:00/:00:1c.4/:02:00.0/:03:04.0/:39:00.0/:3a:02.0/:3b:00.0/usb5/5-1/5-1.4/5-1.4.2/5-1.4.2:1.0/0003:1267:0210.0009/input/input39
[   50.390902] hid-generic 0003:1267:0210.0009: input,hidraw4: USB HID v1.00 
Mouse [PS/2+USB Mouse] on usb-:3b:00.0-1.4.2/input0
[   50.479769] usb 5-1.3.4: new high-speed USB device number 7 using xhci_hcd
[   50.832189] usb 6-1.3.3: reset SuperSpeed Gen 1 USB device number 5 using 
xhci_hcd
[   50.858418] r8152 6-1.3.3:1.0: firmware: direct-loading firmware 
rtl_nic/rtl8153b-2.fw
[   50.877463] r8152 6-1.3.3:1.0: load rtl8153b-2 v1 10/23/19 successfully
[   50.909350] r8152 6-1.3.3:1.0 eth0: v1.11.11
[   50.936063] usb 5-1.4.3: new high-speed USB device number 8 using xhci_hcd
[   51.035760] usb 5-1.3.4: New USB device found, idVendor=0bda, 
idProduct=49a7, bcdDevice= 0.04
[   51.035766] usb 5-1.3.4: New USB device strings: Mfr=3, Product=1, 
SerialNumber=0
[   51.035770] usb 5-1.3.4: Product: USB Audio
[   51.035773] usb 5-1.3.4: Manufacturer: Generic
[   51.039984] usb 5-1.4.3: New USB device found, idVendor=0424, 
idProduct=2422, bcdDevice= 0.a0
[   51.039990] usb 5-1.4.3: New USB device strings: Mfr=0, Product=0, 
SerialNumber=0
[   51.044322] hub 5-1.4.3:1.0: USB hub found
[   51.044395] hub 5-1.4.3:1.0: 1 port detected
[   51.055094] input: Generic USB Audio Consumer Control as 
/devices/pci:00/:00:1c.4/:02:00.0/:03:04.0/:39:00.0/:3a:02.0/:3b:00.0/usb5/5-1/5-1.3/5-1.3.4/5-1.3.4:1.3/0003:0BDA:49A7.000A/input/input40
[   51.112429] input: Generic USB Audio as 
/devices/pci:00/:00:1c.4/:02:00.0/:03:04.0/:39:00.0/:3a:02.0/:3b:00.0/usb5/5-1/5-1.3/5-1.3.4/5-1.3.4:1.3/0003:0BDA:49A7.000A/input/input41
[   51.112917] hid-generic 0003:0BDA:49A7.000A: input,hiddev0,hidraw5: USB HID 
v1.11 Device [Generic USB Audio] on usb-:3b:00.0-1.3.4/input3
[   51.123705] usb 5-1.4.4: new high-speed USB device number 9 using xhci_hcd
[   51.225238] usb 5-1.4.4: New USB device found, idVendor=1235, 
idProduct=8202, bcdDevice= 4.1b
[   51.225242] usb 5-1.4.4: New USB device strings: Mfr=1, Product=3, 
SerialNumber=0
[   51.225245] usb 5-1.4.4: Product: Scarlett 2i2 USB
[   51.225246] usb 5-1.4.4: Manufacturer: Focusrite
[   51.332097] usb 5-1.4.3.1: new high-speed USB device number 

Bug#981360: yodl: drop unused Build-Depends: texlive-fonts-recommended

[tony mancill]

Hello Helmut,

Thank you for looking into this and the bug report.  I will prepare an
upload now.

Cheers,
tony

On Fri, Jan 29, 2021 at 07:41:59AM +0100, Helmut Grohne wrote:
> Source: yodl
> Version: 4.03.02-1
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> yodl participates in dependency loops relevant to architecture
> bootstrap. Rather than look into such a difficult problem, I looked into
> easily droppable dependencies and noticed that dropping
> texlive-fonts-recommended does not break the build nor change output
> artifacts in any way. All other texlive dependencies really are
> required. Please consider applying the attached patch.


signature.asc
Description: PGP signature

Bug#971622: Please update before Debian 11

[Amr Ibrahim]

Please update before Debian 11.

Bug#981364: subunit: annotate test dependencies

[Helmut Grohne]

Source: subunit
Version: 1.4.0-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: rebootstrap

subunit cannot be cross built from source, because its Build-Depends are
not cross satisfiable. Instead of looking into such a difficult problem,
I looked into easily droppable dependencies and found that
python3-testscenarios and python3-testtools (both of which are
unsatisfiable) are only used for testing. As such they can be annotated
 to make them irrelevant to cross building (and
bootstrapping). Please consider applying the attached patch.

Helmut
diff --minimal -Nru subunit-1.4.0/debian/changelog 
subunit-1.4.0/debian/changelog
--- subunit-1.4.0/debian/changelog  2020-10-14 14:10:12.0 +0200
+++ subunit-1.4.0/debian/changelog  2021-01-29 19:05:49.0 +0100
@@ -1,3 +1,10 @@
+subunit (1.4.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Annotate test dependencies . (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 29 Jan 2021 19:05:49 +0100
+
 subunit (1.4.0-2) unstable; urgency=medium
 
   * Fixed watch file.
diff --minimal -Nru subunit-1.4.0/debian/control subunit-1.4.0/debian/control
--- subunit-1.4.0/debian/control2020-10-14 14:10:12.0 +0200
+++ subunit-1.4.0/debian/control2021-01-29 19:05:47.0 +0100
@@ -17,8 +17,8 @@
  pkg-config,
  python3-all,
  python3-setuptools,
- python3-testscenarios,
- python3-testtools,
+ python3-testscenarios ,
+ python3-testtools ,
 Build-Depends-Indep:
  perl,
 Standards-Version: 4.1.4

Bug#981363: gettext: reduce Build-Depends

[Helmut Grohne]

Source: gettext
Version: 0.21-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

gettext participates in dependency loops relevant to architecture
bootstrap and already supports some build profiles to support that
cause. I've looked into easily droppable dependencies anyhow and found
some. For starters, the g++ dependency hampers cross builds and is
satisfied in stable. Next, I looked into fastjar, libglib2.0-dev and
libncurses-dev. I failed to figure out what these could be used for. I
compared a build log of a regular build with one where these are turned
into Build-Conflicts. The resulting artifacts did not change as gettext
is normally reproducible. I've also compared the build logs and couldn't
find any steps or tests that were skipped as a consequence of reducing
these dependencies. As such, I think that is quite safe to just drop
them. Please consider applying the attached patch.

Helmut
diff --minimal -Nru gettext-0.21/debian/changelog gettext-0.21/debian/changelog
--- gettext-0.21/debian/changelog   2020-12-20 17:44:00.0 +0100
+++ gettext-0.21/debian/changelog   2021-01-29 07:11:15.0 +0100
@@ -1,3 +1,12 @@
+gettext (0.21-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Drop g++ dependency satisfied in stable.
++ Drop unused fastjar, libglib2.0-dev, libncurses-dev.
+
+ -- Helmut Grohne   Fri, 29 Jan 2021 07:11:15 +0100
+
 gettext (0.21-3) unstable; urgency=medium
 
   * Install libintl.jar in /usr/share/maven-repo. Closes: #976738.
diff --minimal -Nru gettext-0.21/debian/control gettext-0.21/debian/control
--- gettext-0.21/debian/control 2020-12-20 16:00:00.0 +0100
+++ gettext-0.21/debian/control 2021-01-29 07:11:15.0 +0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Santiago Vila 
 Standards-Version: 4.5.0
-Build-Depends: debhelper-compat (= 13), dh-exec (>= 0.13), dh-elpa, g++ (>= 
4:7), bison, file, help2man, xz-utils, default-jdk , maven-repo-helper 
, fastjar , libglib2.0-dev, libncurses5-dev, 
libunistring-dev, libxml2-dev, groff
+Build-Depends: debhelper-compat (= 13), dh-exec (>= 0.13), dh-elpa, bison, 
file, help2man, xz-utils, default-jdk , maven-repo-helper , 
libunistring-dev, libxml2-dev, groff
 Homepage: https://www.gnu.org/software/gettext/
 Rules-Requires-Root: no
 

Bug#981362: vulkan-loader: build from source

[Helmut Grohne]

Source: vulkan-loader
Version: 1.2.162.0-1
Tags: patch

I was looking into reducing vulkan-loader's build-depends and found that
python3 was reported as unused. That struck me as odd and I looked into
why. It turns out that the sources in loader/generated/ are not rebuilt
during package build. Rather than drop the presently unused python3
dependency, I propose actually rebuiling these files. Please consider
applying the attached patch if you agree.

Helmut
diff --minimal -Nru vulkan-loader-1.2.162.0/debian/changelog 
vulkan-loader-1.2.162.0/debian/changelog
--- vulkan-loader-1.2.162.0/debian/changelog2021-01-07 08:34:46.0 
+0100
+++ vulkan-loader-1.2.162.0/debian/changelog2021-01-29 18:54:15.0 
+0100
@@ -1,3 +1,10 @@
+vulkan-loader (1.2.162.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Actually build from source. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 29 Jan 2021 18:54:15 +0100
+
 vulkan-loader (1.2.162.0-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru vulkan-loader-1.2.162.0/debian/clean 
vulkan-loader-1.2.162.0/debian/clean
--- vulkan-loader-1.2.162.0/debian/clean1970-01-01 01:00:00.0 
+0100
+++ vulkan-loader-1.2.162.0/debian/clean2021-01-29 18:54:15.0 
+0100
@@ -0,0 +1 @@
+loader/generated/*
diff --minimal -Nru vulkan-loader-1.2.162.0/debian/rules 
vulkan-loader-1.2.162.0/debian/rules
--- vulkan-loader-1.2.162.0/debian/rules2021-01-07 08:12:16.0 
+0100
+++ vulkan-loader-1.2.162.0/debian/rules2021-01-29 18:54:15.0 
+0100
@@ -28,6 +28,10 @@
-DVulkanHeaders_INCLUDE_DIR=../vulkan-headers/include \
-DVulkanRegistry_DIR=../vulkan-headers/registry
 
+override_dh_auto_build:
+   dh_auto_build -- VulkanLoader_generated_source
+   dh_auto_build
+
 override_dh_auto_test:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
(cd build; tests/run_all_tests.sh || \

Bug#981361: xfsprogs: drop unused dh-python from Build-Depends

[Helmut Grohne]

Source: xfsprogs
Version: 5.10.0-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

xfsprogs participates in dependency loops relevant to architecture
bootstrap. Instead of looking into such a difficult problem, I looked
into easily droppable dependencies and found that xfsprogs does not use
dh-python in any way. Please consider applying the attached patch to
drop it.

Helmut
diff --minimal -Nru xfsprogs-5.10.0/debian/changelog 
xfsprogs-5.10.0/debian/changelog
--- xfsprogs-5.10.0/debian/changelog2021-01-14 18:59:14.0 +0100
+++ xfsprogs-5.10.0/debian/changelog2021-01-29 19:02:30.0 +0100
@@ -1,3 +1,10 @@
+xfsprogs (5.10.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused dh-python from Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 29 Jan 2021 19:02:30 +0100
+
 xfsprogs (5.10.0-2) unstable; urgency=low
 
   * Team upload
diff --minimal -Nru xfsprogs-5.10.0/debian/control 
xfsprogs-5.10.0/debian/control
--- xfsprogs-5.10.0/debian/control  2021-01-14 18:59:14.0 +0100
+++ xfsprogs-5.10.0/debian/control  2021-01-29 19:02:15.0 +0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: XFS Development Team 
 Uploaders: Nathan Scott , Anibal Monsalve Salazar 
, Bastian Germann 
-Build-Depends: libinih-dev, uuid-dev, dh-autoreconf, debhelper (>= 5), 
gettext, libtool, libedit-dev, libblkid-dev (>= 2.17), linux-libc-dev, 
libdevmapper-dev, libattr1-dev, libicu-dev, dh-python, pkg-config
+Build-Depends: libinih-dev, uuid-dev, dh-autoreconf, debhelper (>= 5), 
gettext, libtool, libedit-dev, libblkid-dev (>= 2.17), linux-libc-dev, 
libdevmapper-dev, libattr1-dev, libicu-dev, pkg-config
 Standards-Version: 4.0.0
 Homepage: https://xfs.wiki.kernel.org/
 

Bug#981360: yodl: drop unused Build-Depends: texlive-fonts-recommended

[Helmut Grohne]

Source: yodl
Version: 4.03.02-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

yodl participates in dependency loops relevant to architecture
bootstrap. Rather than look into such a difficult problem, I looked into
easily droppable dependencies and noticed that dropping
texlive-fonts-recommended does not break the build nor change output
artifacts in any way. All other texlive dependencies really are
required. Please consider applying the attached patch.

Helmut
diff --minimal -Nru yodl-4.03.02/debian/changelog yodl-4.03.02/debian/changelog
--- yodl-4.03.02/debian/changelog   2021-01-22 13:38:52.0 +0100
+++ yodl-4.03.02/debian/changelog   2021-01-29 07:39:16.0 +0100
@@ -1,3 +1,10 @@
+yodl (4.03.02-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused Build-Depends: texlive-fonts-recommended. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 29 Jan 2021 07:39:16 +0100
+
 yodl (4.03.02-1) unstable; urgency=low
 
   * Upstream removed superfluous .tar.gz extensions from the man-pages
diff --minimal -Nru yodl-4.03.02/debian/control yodl-4.03.02/debian/control
--- yodl-4.03.02/debian/control 2021-01-22 13:38:52.0 +0100
+++ yodl-4.03.02/debian/control 2021-01-29 07:39:14.0 +0100
@@ -10,7 +10,6 @@
 texlive-latex-base,
 texlive-plain-generic,
 texlive-latex-recommended,
-texlive-fonts-recommended,
 texlive-latex-extra,
 ghostscript
 Standards-Version: 4.5.1

Bug#981359: dbus-c++: reduce Build-Depends

[Helmut Grohne]

Source: dbus-c++
Version: 0.9.0-8.2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: block -1 by 865139

dbus-c++ participates in dependency loops relevant to architecture
bootstrap. Instead of looking into such a difficult problem, I looked
into easily droppable dependencies. Beyond #865139, this turned up
libgtkmm-2.4-dev, which is only used for building examples that are not
otherwise installed into any package. It can thus be considered a test
case and annotated . Please consider applying the attached
patch to fix both bugs.

Helmut
diff --minimal -Nru dbus-c++-0.9.0/debian/changelog 
dbus-c++-0.9.0/debian/changelog
--- dbus-c++-0.9.0/debian/changelog 2020-04-30 19:10:39.0 +0200
+++ dbus-c++-0.9.0/debian/changelog 2021-01-29 07:48:46.0 +0100
@@ -1,3 +1,13 @@
+dbus-c++ (0.9.0-8.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Drop automake1.11 alternative as it uses automake aka 1.16 anyway.
++ Annotate libgtkmm-2.4-dev  as it is only used for building
+  examples that are not installed.
+
+ -- Helmut Grohne   Fri, 29 Jan 2021 07:48:46 +0100
+
 dbus-c++ (0.9.0-8.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru dbus-c++-0.9.0/debian/control dbus-c++-0.9.0/debian/control
--- dbus-c++-0.9.0/debian/control   2020-04-30 19:10:39.0 +0200
+++ dbus-c++-0.9.0/debian/control   2021-01-29 07:48:38.0 +0100
@@ -4,7 +4,7 @@
 Maintainer: Vincent Cheng 
 Build-Depends:
  autoconf (>= 2.59),
- automake1.11 | automake (>= 1:1.11),
+ automake (>= 1:1.11),
  debhelper (>= 9),
  dh-autoreconf,
  doxygen,
@@ -14,7 +14,7 @@
  libefl-all-dev,
  libexpat1-dev,
  libglib2.0-dev,
- libgtkmm-2.4-dev (>= 1:2.24.4-2~),
+ libgtkmm-2.4-dev (>= 1:2.24.4-2~) ,
  libtool
 Standards-Version: 3.9.6
 Homepage: http://sourceforge.net/projects/dbus-cplusplus/

Bug#981358: mark golang-github-showmax-go-fqdn-dev Multi-Arch: foreign

[Helmut Grohne]

Package: golang-github-showmax-go-fqdn-dev
Version: 1.0.0-3
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 depenencies,
because their transitive dependency on golang-github-showmax-go-fqdn-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 as
this is a pure go module with no dependencies or maintainer scripts.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru golang-github-showmax-go-fqdn-1.0.0/debian/changelog 
golang-github-showmax-go-fqdn-1.0.0/debian/changelog
--- golang-github-showmax-go-fqdn-1.0.0/debian/changelog2020-09-14 
18:58:45.0 +0200
+++ golang-github-showmax-go-fqdn-1.0.0/debian/changelog2021-01-29 
12:24:24.0 +0100
@@ -1,3 +1,10 @@
+golang-github-showmax-go-fqdn (1.0.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark golang-github-showmax-go-fqdn-dev Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 29 Jan 2021 12:24:24 +0100
+
 golang-github-showmax-go-fqdn (1.0.0-3) unstable; urgency=medium
 
   * Disable tests that need Internet access.
diff --minimal -Nru golang-github-showmax-go-fqdn-1.0.0/debian/control 
golang-github-showmax-go-fqdn-1.0.0/debian/control
--- golang-github-showmax-go-fqdn-1.0.0/debian/control  2020-09-06 
18:44:31.0 +0200
+++ golang-github-showmax-go-fqdn-1.0.0/debian/control  2021-01-29 
12:24:22.0 +0100
@@ -16,6 +16,7 @@
 
 Package: golang-github-showmax-go-fqdn-dev
 Architecture: all
+Multi-Arch: foreign
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Description: Golang library to provide local machine FQDN

Bug#870395: hydrogen: Segmentation fault when creating or modifying drumkits

[Roberto]

Hi, thank you for adopting Hydrogen :)

Yes, it still happens with 0.9.7-6 (not tried upstream git sources).

Maybe the severity can be lowered, I've been using Hydrogen with the
workaround of choosing samples in advance, never deleting layers when
building an instrument, and it works. It seems that deleting a layer is
the most risky task, probably when the sound is still playing.

Can't you reproduce it? It only took a few seconds to crash it, just a
minute before writing this email. If this only happens to me, we could
close the bug, though I wonder why are only my computers triggering the
crash :/

Bug#981357: python3-django: needs python3-mysqldb >=1.3.13 which is not in backports

[Jens Reinsberger]

Package: python3-django
Version: 2:2.2.17-2~bpo10+1
Severity: normal

Dear Maintainer,

since the stable version of python3-django is utterly out of date and
not maintained anymore upstream, I wanted to use the backports version.

Unfortunately it needs python3-mysqldb >= 1.3.13 in order to work with
MySQL/MariaDB, which is not available in backports.

Could you provide the current testing version of python3-mysqldb as backports?

In essence, this is the backports version of #935394.

With kind regards,
Jens Reinsberger

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

Versions of packages python3-django depends on:
ii  python3   3.7.3-1
ii  python3-sqlparse  0.2.4-1
ii  python3-tz2019.1-1

Versions of packages python3-django recommends:
ii  libjs-jquery  3.3.1~dfsg-3

Versions of packages python3-django suggests:
…
pn  python3-mysqldb

-- no debconf information

Bug#981347: [debian-mysql] Bug#981347: mariadb-10.5 FTBFS on kfreebsd

[Otto Kekäläinen]

Hello!

I don't have time to run kfreebsd build tests any time soon.

Would you like to do a merge request at
https://salsa.debian.org/mariadb-team/mariadb-10.5 if you know how to
fix this?

- Otto

Bug#981176: Rename the doas package as opendoas package

[Goffredo Baroncelli]

opendoas is a derived project from the openbsd doas project. The differences 
are quite important from a security point of view: it comes to me the pam and 
persistent support.

Several other projects are derived from the original doas, like:
- https://github.com/multiplexd/doas
- https://github.com/slicer69/doas

Each one has a different implementation either of pam or persistent support.

In order to reduce the confusion, I think that it does make sense to rename the 
doas debian package in opendoas, to highlight the project from which the 
package is built.

This would help also the tracking of the security issues.

Regards
Goffredo

--
gpg @keyserver.linux.it: Goffredo Baroncelli 
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Bug#981356: jq: the manpage table definitions are broken

[Marc Chantreux]

Package: jq
Version: 1.6-2.1
Severity: normal

Dear Maintainer,

i read the jq manpage to a vim buffer (:r !man jq) to test examples
and realized i got those errors:

   Optional Object Idtbl::2170: unrecognised format 'T'
tbl::2170: giving up on this table
tbl::2178: unrecognised format '\'
tbl::2178: giving up on this table
tbl::2184: unrecognised format 'o'
tbl::2184: giving up on this table
tbl::2188: unrecognised format '('
tbl::2188: giving up on this table
tbl::2194: unrecognised format '('
tbl::2194: giving up on this table

so tables are not rendered. this is because all the table headers are
missing. example

.TS
allbox;
This example should show the difference between \'=\' and \'=\':
.TE

should be

.TS
allbox;
l l.
This example should show the difference between \'=\' and \'=\':
.TE

so i wrote a patch

2169a2170
> l l.
2177a2179
> l l.
2183a2186
> l l.
2187a2191
> l l.
2193a2198
> l l l.

in general, the manpage quality is very poor and broken patterns appears
regulary so i suspect it was generated from a tool the authors should
avoid.

i'll be happy to help writting a decent manpage (maybe using mandoc?).

regards
marc

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

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.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 jq depends on:
ii  libc6   2.31-9
ii  libjq1  1.6-2.1

jq recommends no packages.

jq suggests no packages.

-- no debconf information

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

[Bernd Zeimetz]

Hi,

I just did some last fixes and uploaded doas to unstable. Thanks for
your work!

but fyi: I failed a bit, I've enabled PAM, but uploaded before testing
it. It will need a source only upload to migrate to testing anyway, I'll
do that as soon as it is trough new.

The version i ngit is working just fine.

If you have some time, please add an autopkgtest. Something like:
- creating a config for some user and for root
- as root: doas -u someuser doas -u root whoami | grep root

better ideas welcome, the CI should happily run your tests normally, but
it is broken due to some ssl issues at the moment.


Bernd


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

Bug#976286: dlt-viewer: new version available

[Stefan Potyra]

Hi,

first off, sorry for the delay.

Since I didn't hear any objections so far, I'd say it's about time to welcome
you to the maintainers of dlt-viewer.

So please go ahead, and feel free to make and upload any changes that you want
to do.

Oh, I've just added you as admin to the dlt-viewer project on salsa, so feel
free to push your changes there. Of course I'm also happy if you want to use a
different location (e.g. your fork on salsa or maybe there is something like the
old collab-maint available). Just go ahead ;).

Cheers and thanks very much for your efforts and help,
  Stefan.


signature.asc
Description: PGP signature

Bug#347279: hydrogen: Comments while listening to the included demos

[積丹尼 Dan Jacobson]

I am kind of in retirement village so cannot help further.

Bug#932461: src:libfm: archivers.list fix xarchiver command

[Andriy Grytsenko]

Hello!

Andrew Lee has written on Friday, 29 January, at 19:05:
>What's your opinion on this MR? I'll accept related MR for libfm-qt if you
>accept this here for libfm.

I thought if we should make it more flexible in a way to test for version
and use one or other switch to command but couldn't find a reliable and
simple way to test for version (command to retrieve version was changed
by the author too, you know). Although it was so much time passed since
that dramatic change made by xarchiver author that it might be mostly
safe now to use it even in upstream sources despite the fact it might
cause some problems for those who have older version of xarchiver. All
the blames should come to the author who never thought about its users
though. Being also upstream author I'll make it a release 1.3.2 which
includes this change this week-end then so will make it packaged, updated
and uploaded to Debian as well.

With best regards,
Andriy.

Bug#932461: src:libfm: archivers.list fix xarchiver command

[Ingo Brückl]

Amy Kos wrote on Fri, 29 Jan 2021 19:20:57 +:

> @Ingo Brückl
> May I ask you to do a pull request for libfm-qt too?

Done: https://github.com/lxqt/libfm-qt/pull/621

Ingo

Bug#979818: python-dlt: FTBFS in sid

[Gianfranco Costamagna]

control: forwarded -1 https://github.com/bmwcarit/python-dlt/issues/26

G.

Bug#981329: [20210129] ftp.belnet.be: syncscript

[Belnet FTP Maintainer - Pascal Panneels]

Hello Julien

I've changed our mirror script to use ftpsync instead of simple rsync,
it is currently running, so I guess it will be ok soon.

Change was due to a migration to another ftp server with some
modification in the used tools to mirror.

With best regards,

Pascal

Le 29/01/21 à 13:48, Julien Cristau a écrit :
> Package: mirrors
> Severity: normal
> X-Debbugs-Cc: ftpma...@belnet.be
> User: mirr...@packages.debian.org
> Usertags: mirror-problem
>
> Hi,
>
> I was checking some things in the Debian mirror universe and noticed
> a problem with your mirror:
>
> o The tracefile
>   http://ftp.belnet.be/debian/project/trace/ftp.belnet.be
>   suggests that you are not using ftpsync.
>
>   Please use our ftpsync script to mirror Debian.
>
>   It should produce better trace files, and do the mirroring in a way that
>   ensures the mirror is in a consistent state even during updates.
>
>   http://ftp.belnet.be/debian/project/ftpsync/ftpsync-current.tar.gz
>
> Cheers,
> Julien
-- 
*Pascal Panneels*
System Architect
Belnet - Services
WTC III
Simon Bolivarlaan 30 Boulevard Simon Bolivar
Brussel 1000 Bruxelles
België - Belgique
T: +32 2 790 33 33
*www.belnet.be *

Bug#347279: hydrogen: Comments while listening to the included demos

[Nicholas D Steeves]

Control: tag -1 moreinfo

Hi Dan,

On Tue, Jan 10, 2006 at 03:25:41AM +0800, Dan Jacobson wrote:
> Package: hydrogen
> Version: 0.9.2final-2
> Severity: wishlist
> 
> Comments while listening to the included demos:
> 
> Song editor should show on the X axis where we are in listening to the
> demos, not just on the y axis. In fact, why not color in which square
> we are on.
> 
> The pattern editor should jump to what pattern we are listening to,
> not just be stuck in 1 unless given manual help.
> 
> Extraneous instruments should be squeezed out to so nothing goes
> beyond the window.
> 

I recently adopted Hydrogen for Debian, and see that no one followed
up on this bug.

What behaviour should occur when two patterns play simultaneously?  In
this case, I don't see how Hydrogen could switch the pattern editor
pane to the right pattern.  It seems to me that Hydrogen is doing the
right thing already.

Without further communications I plan to close this bug as wontfix in
six months, or after bullseye is released, whichever is later.

Thank you,
Nicholas


signature.asc
Description: PGP signature

Bug#981341: bup split does not honor the -q flag

[Brian Minton]

Package: bup
Version: 0.32~git20201223-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


I tried to use bup split with the -q option, which I expected would
produce no output.  Instead, some output was produced.


lab.bjmgeek.science:~$ bup init
Initialized empty Git repository in /home/bminton/.bup/
lab.bjmgeek.science:~$ echo test | bup split -q -n test
lab.bjmgeek.science:~$ /3 objects)



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

Kernel: Linux 3.16.0-1062.12.1.vz7.131.10 (SMP w/1 CPU thread)
Kernel taint flags: TAINT_WARN
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 bup depends on:
ii  git   1:2.29.2-1
ii  libacl1   2.2.53-9
ii  libc6 2.31-9
ii  libreadline8  8.1-1
ii  par2  0.8.1-1
ii  python3   3.9.1-1
ii  python3-pylibacl  0.6.0-1+b1
ii  python3-pyxattr   0.7.2-1+b1

Versions of packages bup recommends:
ii  bup-doc  0.31-2
ii  python3-fuse 2:1.0.1-1
ii  python3-tornado  6.1.0-1+b1

bup suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQQE0+0m5wetBkPrp+xE817bNV1SagUCYBQm3QAKCRBE817bNV1S
aj5lAQCTAZpLMKIsXfoyPP3M+Jha1HLRx7hrclWMNK19g2Qi9wEAoPW6whWys5xz
MPZcqNIG3MQOXvPsD1x2Ssgv9KTHvgM=
=axJI
-END PGP SIGNATURE-

Bug#979865: m2crypto FTBFS on IPV6-only buildds

[Sebastian Andrzej Siewior]

control: found -1 0.31.0-1

On 2021-01-24 23:08:27 [+0200], Adrian Bunk wrote:
> 
> The release team considers these bugs release critical.

it would be easier to enforce to have all buildds configured equally so
the package does not fail on a random buildd.

> > and let it migrate to
> > testing. After all this bug did not first appear in 0.37.1-1,
> >...
> 
> If this is true, then the proper action would be a found indicating the 
> first broken version.

Ah. Looking at all the ipv6 testsuite bugs I saw so far, all of them
were there from the very beginning. My guess is that it isn't any
different here.
I reassigned it to the first upload of 31 which is in stable because
0.31.0-4+deb10u1 failed to build on amd64 for the same reason. A retry
passed.

> cu
> Adrian

Sebastian

Bug#870395: hydrogen: Segmentation fault when creating or modifying drumkits

[Nicholas D Steeves]

Control: tag -1 moreinfo

Hi Roberto,

On Tue, Aug 01, 2017 at 06:11:09PM +0200, Roberto wrote:
> Package: hydrogen
> Version: 0.9.7-1+b1
> Severity: important
> 
> I get frequent segmentation faults when trying to create a new drumkit or
> modyfing parameters in current Debian stable Hydrogen. Adding/deleting sample
> layers seems to have a high probability of crashing. It could be a race
> condition when one thread tries to access a buffer that has been deleted by
> another thread. This is what I get when running under gdb:
> 
> 
> Thread 7 "hydrogen" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffda63e700 (LWP 2158)]

I recently adopted Hydrogen for Debian, and see that no one followed
up on this bug.  0.9.7-1+b1 from Debian 9 (stretch) is the oldest
supported release, but the oldest version I am able to test is
0.9.7-6, and I was not able to trigger this crash there.

Would you please confirm if you can trigger this segfault in hydrogen
0.9.7-6 or newer?  Without any communication I plan to close this bug
in six months, or when Debian 11 (bullseye) is released.

Thank you,
Nicholas


signature.asc
Description: PGP signature

Bug#642014: hydrogen: effect plugins are not usable with instruments

[Nicholas D Steeves]

Control: tag -1 moreinfo

On Sun, Sep 18, 2011 at 04:59:33PM +0200, Thorsten Alteholz wrote:
> Package: hydrogen
> Version: 0.9.4.1-1+b1
> Severity: normal
> 
> *** Please type your report below this line ***
> I can choose a LADSPA plugin in the FX rack of the mixer. After that I cannot
> use the four "pre-fader FX send knobs" below the balance knob of the
> corresponding instrument. Normally I would expect to choose how much of this
> instrument will be sent to the effect plugin in the FX rack (at least that
> is
> written in the manual). As the default value of these knobs are 0, no plugin
> has any effect.
> Or do I miss anything?
>

I recently adopted Hydrogen for Debian, and see that no one followed
up on this bug.  0.9.7-1+b1 from Debian 9 (stretch) is the oldest
supported release, but the oldest version I am able to test is
0.9.7-6, and I was not able to trigger this crash there.

Please confirm if the issue still exists in a supported version.
Without any communication I plan to close this bug in six months, or
when Debian 11 (bullseye) is released.

Thank you,
Nicholas


signature.asc
Description: PGP signature

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

[Sebastian Andrzej Siewior]

On 2021-01-28 00:28:03 [+0100], Kurt Roeckx wrote:
> On Thu, Jan 14, 2021 at 07:03:37PM +0100, Kurt Roeckx wrote:
> > There are a whole bunch of other issues and pull requests related to
> > this. I hope this is the end of the regressions in the X509 code.
> 
> So there is something else now:
> https://github.com/openssl/openssl/issues/13931
> https://github.com/openssl/openssl/pull/13982

So what is the plan here? Upload to unstable and prepare a pu once it
migrate to testing or right away?

> Kurt

Sebastian

Bug#794042: hydrogen: Hydrogen segfault on adding from sound library

[Nicholas D Steeves]

Control: tag -1 moreinfo

On Wed, Jul 29, 2015 at 11:08:48PM -0400, Robbie Harwood wrote:
> Package: hydrogen
> Version: 0.9.6.1-1
> Severity: important
> 
> Dear Maintainer,
> 
> Sporadically, hydrogen will crash.  This seems to be co-incident with adding
> instruments to the current loop.  Here is a traceback:
> 
> Program received signal SIGABRT, Aborted.

I recently adopted Hydrogen for Debian, and see that no one followed
up on this bug.  0.9.7-1+b1 from Debian 9 (stretch) is the oldest
supported release, but the oldest version I am able to test is
0.9.7-6, and I was not able to trigger this crash there.

Please confirm if the issue still exists.  Without any communication I
plan to close this bug in six months, or when Debian 11 (bullseye) is
released.

Thank you,
Nicholas


signature.asc
Description: PGP signature

Bug#586087: hydrogen: Jack Time-Master enabled and NO pattern selected causes a crash.

[Nicholas D Steeves]

Control: tag -1 + moreinfo
Hi Jose!

On Wed, Jun 16, 2010 at 11:56:43AM +0200, Jose Lencioni wrote:
> Package: hydrogen
> Version: 0.9.4.1-1
> Severity: important
> 
> Hi.
> 
> I get this crash avery time i play with Hydrogen as jackd TimeMaster, and 
> there
> is no pattern sequence selected in the song editor.
> I attach this gdb output. Please make me know if you need more information.
> 

I recently adopted Hydrogen for Debian, and see that no one followed
up on this bug.  0.9.4.1-1 is from Debian 8 (jessie), which is no
longer supported.  0.9.7-1+b1 from Debian 9 (stretch) is the oldest
supported release, but the oldest version I am able to test is
0.9.7-6, and I was not able to trigger this crash there.

Please confirm if the issue still exists.  Without any communication I
plan to close this bug in six months, or when Debian 11 (bullseye) is
released.

Thank you,
Nicholas


signature.asc
Description: PGP signature

Bug#980962: buster-pu: package intel-microcode/3.20201118.1~deb10u1

[Henrique de Moraes Holschuh]

On Fri, 29 Jan 2021, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> On Fri, 2021-01-29 at 13:27 -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 24 Jan 2021, Henrique de Moraes Holschuh wrote:
> > The 3.20201118.1~deb10u1 version of the package (the one I am
> > > proposing for the stable update) contains changes not (yet?) in
> > > unstable to address the Skylake D0/R0 issue: they had their updates
> > > frozen to the same revision currently in Debian stable.
> > 
> > I better explain that in a more direct, clear way:
> 
> Thanks.
> 
> Please feel free to upload, bearing in mind that the window for 10.8
> closes during this weekend.

Uploaded (source, i386, amd64).

Thank you!

-- 
  Henrique Holschuh

Bug#981289: closed by Debian FTP Masters (reply to Alastair McKinstry ) (Bug#981289: fixed in udunits 2.2.28-3)

[Paul Gevers]

Control: reassign -1 src:udunits 2.2.28-2
Control: affects -1 src:gnudatalanguage

Hi,

On 29-01-2021 14:09, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the udunits package:
> 
> #981289: udunits breaks gnudatalanguage autopkgtest
> 
> It has been closed by Debian FTP Masters  
> (reply to Alastair McKinstry ).

Unfortunately, the bts doesn't handle bugs assigned to two packages
perfectly yet. Updating the meta info to reflect the current understanding.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#937194: opencaster: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

Am Fri, Aug 30, 2019 at 07:29:17AM + schrieb Matthias Klose:
> Package: src:opencaster
> Version: 3.2.2+dfsg-1.1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

Hi Thorsten,
opencaster seems dead upstream, should it be removed or are
you planning to port it to Python 3 yourself?

Cheers,
Moritz

Bug#981354: agda-stdlib: problems compiling agda source with agda-stdlib import

[schneider . moritz]

Package: agda-stdlib
Version: 0.17-1
Severity: important

Dear Maintainer,

I try to compile the hello world example from the agda documentation
(file hello-world.agda) with the agda-bin and agda-stdlib provided by
debian buster.

> module hello-world where
> 
> open import IO
> 
> main = run (putStrLn "Hello, World!")

If I try to compile it with no other arguments, the compilation will
fail instantly, because it does not find the std library:

> Failed to find source of module IO in any of the following
> locations:
>   /home/moschneider/test/agda/IO.agda
>   /home/moschneider/test/agda/IO.lagda
>   /usr/share/libghc-agda-dev/lib/prim/IO.agda
>   /usr/share/libghc-agda-dev/lib/prim/IO.lagda
> when scope checking the declaration
>   open import IO

So I tried o make it work. Unfortunately the agda-stdlib package does
not contain the "standard-library.agda-lib" file from the upstream
agda-stdlib repo. I think that shi´ould be shiped with the agda-stdlib
Debian package!
But I created my own one in ~/.agda/standard-library.agda-lib:

> name: standard-library
> include: /usr/share/agda-stdlib/

And created a libraries file as described in
https://agda.readthedocs.io/en/v2.5.4.1/tools/package-system.html;
~/.agda/libraries:

> ~/.agda/standard-library.agda-lib

and a defaults file to include the stdlib by default;
~/.agda/defaults:

> standard-library

With these changes agda will compile the stdlib files, but
the whole process will still exit with an error:

> agda: /usr/share/libghc-agda-dev/MAlonzo/src:
> getDirectoryContents:openDirStream: does not exist (No such file or directory)

So I cannot get agda to work together with agda-stdlib.

By the way Haskell was installed by the haskell-platform Debian package.

Here again the relevant package versions (everything is from Debian
Buster):
agda: 2.5.4.1-3
agda-stdlib: 0.17-1
ghc: 8.4.4+dfsg1-3

Kind regards
Moritz Schneider


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

Kernel: Linux 5.9.0-0.bpo.2-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.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 agda-stdlib depends on:
ii  libghc-agda-dev  2.5.4.1-3+b1

agda-stdlib recommends no packages.

agda-stdlib suggests no packages.

-- no debconf information

Bug#980809: log on s390x

[Paul Gevers]

On request of Graham I ran the autopkgtest on 390x manually to speed up
the results.

Please find the output attached.

Paul


r-cran-glmmtmb@s390x.tar.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#981339: buster-pu: package device-tree-compiler/1.4.7-4

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2021-01-29 at 16:31 +0100, Cyril Brulebois wrote:
> I'd like to propose a fix for a dtc segfault in buster, which can
> prevent people from checking what their device-tree looks like,
> making it harder to debug why device-tree overlays don't work:
>   https://bugs.debian.org/981033
> 

Please go ahead, thanks.

Regards,

Adam

Bug#981351: X rendered wrong

[Axel Beckert]

Control: tag -1 + confimed upstream

Hi Jidanni,

積丹尼 Dan Jacobson wrote:
> (Please tell upstream:)

Will do. Although I think, upstream reads Debian bug reports, too. :-)

> Lynx has a big bug.

Depends on the point of view. At least from my point of view, the
 tag is not really widespread. But it is clearly a bug, yes.

> lynx says:
> 
>[DEL: :DEL]
> 
>AAA
> 
>BBB

Can confirm, thanks!

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

Bug#980962: buster-pu: package intel-microcode/3.20201118.1~deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2021-01-29 at 13:27 -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 24 Jan 2021, Henrique de Moraes Holschuh wrote:
> The 3.20201118.1~deb10u1 version of the package (the one I am
> > proposing for the stable update) contains changes not (yet?) in
> > unstable to address the Skylake D0/R0 issue: they had their updates
> > frozen to the same revision currently in Debian stable.
> 
> I better explain that in a more direct, clear way:

Thanks.

Please feel free to upload, bearing in mind that the window for 10.8
closes during this weekend.

Regards,

Adam

Bug#981353: Please use generic "debian" version during build instead of specifying the exact version

[Louis-Philippe Véronneau]

Package: src:leiningen-clojure
Version: 2.9.1-4
Severity: wishlist

Hi!

It seems a lot of dependencies in the "project.clj" files used to build
the different lein parts are using specific dependencies versions.

Sadly, that means that when one of them is updated in Debian, lein FTBFS
since it can't find that version anymore.

Would it be possible to use "debian" versions in all the places where
it's possible? It would surely make the build process more robust.

Cheers!

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#981337: tomcat9: cannot set JAVA_HOME in /etc/default/tomcat9 when using systemd service unit

[Giuseppe Sacco]

Package: tomcat9
Version: 9.0.31-1~deb10u3
Severity: normal

Dear Maintainer,
on a debian stable new installation, changing the JAVA_HOME property in
/etc/default/tomcat9 does not work, i.e. the java used is the default one.
In order to set a non default JAVA_HOME I had to add the lines:

[Service}
Environment="JAVA_HOME=/usr/lib/jvm/adoptopenjdk-8-hotspot-amd64"

in its override file, i.e. 
/etc/systemd/system/tomcat9.service.d/00_javahome.conf .

Thank you,
Giuseppe


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

Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=it_IT.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 tomcat9 depends on:
ii  lsb-base10.2019051400
ii  systemd 241-7~deb10u5
ii  tomcat9-common  9.0.31-1~deb10u3
ii  ucf 3.0038+nmu1

Versions of packages tomcat9 recommends:
ii  libtcnative-1  1.2.21-1

Versions of packages tomcat9 suggests:
pn  tomcat9-admin 
pn  tomcat9-docs  
pn  tomcat9-examples  
pn  tomcat9-user  

-- no debconf information

Bug#981345: buster-pu: package systemd/241-7~deb10u6

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

Hi,

On Fri, 2021-01-29 at 17:47 +0100, Michael Biebl wrote:
> I'd like to make a stable upload for systemd fixing #975561:
> 
>   journal: do not trigger assertion when journal_file_close() get
> NULL
> 
> The rest is autopkgtest updates, as the current state is a bit sad
> [1] on stable.

That looks fine to me, thanks.

> 
> CCed kibi/debian-boot, as usual.
> The udev package should not be affected, as the above change only
> affects the journal, which is not used in d-i.

CCed and tagged for completeness.

Regards,

Adam

Bug#981323: usbutils not installed by default anymore

[Aurelien Jarno]

control: retitle -1 Please change usbutils priority to standard
control: reassign -1 ftp.debian.org

On 2021-01-29 11:51, Laurent Bigonville wrote:
> Package: usbutils
> Version: 1:013-3
> Severity: normal
> 
> Hello,
> 
> I think we already discussed that on IRC, but usbutils is apparently not
> installed by default anymore.
> 
> As a user I would expect to have that package installed (like pciutils),
> all physical machines have USB today (and desktop VM's also)
> 
> util-linux is already pulling libudev1. The only extra dependency that
> usbutils is adding is libusb-1.0-0.

Reassigning the bug so that the ftp-masters can do the change.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#974996: Raising severity and offering to NMU package

[Simon Josefsson]

tis 2021-01-26 klockan 19:25 +0100 skrev Bruno Kleinert:
> On Mon, 23 Nov 2020 20:15:52 +0100 Simon Josefsson <
> si...@josefsson.org> wrote:
> > severity 975030 serious
> > severity 974997 serious
> > severity 974996 serious
> > severity 974995 serious
> > severity 974994 serious
> > severity 974993 serious
> > thanks
> > 
> > It was suggested to me on IRC that the severity of this could be
> > serious because the build-dependency libidn2-0-dev is going to be
> > removed from Debian.  I'm volunteering to do NMU these packages to
> fix
> > the bug, and could look into that in a couple of weeks -- if you
> give
> > me permission to do it before, I'd start directly.  If I'm mistaken
> > that this is not a valid justification for a serious bug, downgrade
> the
> > bug and let me know, as I'm not sure what the best way to get an
> > obsolete deprecated transition package removed from Debian when
> build-
> > deps remain.
> > 
> > /Simon
> > 
> 
> Hi,
> 
> looking at the RC bugs list I stumbled across this one and added a
> merge request on salsa: 
> https://salsa.debian.org/debian/curl/-/merge_requests/9

Thank you!

I am beginning to think that we are too late in the process for
bullseye to see this completed though, but doing NMU's to fix this
would indeed be welcome -- I won't have time in the next few weeks for
this though, so volunteers welcome.

/Simon


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

Bug#981352: "VPN Connections" menu entry moves around and is frustrating to click

[Enrico Zini]

Package: network-manager-openvpn-gnome
Version: 1.8.10-1
Severity: normal

Hello,

thank you for maintaning Network Manager!

The "VPN Connections" submenu in the NM applet appears after the WIFI
connections list, and the WIFI connections list tends to often refresh
once the menu is open. ISTR opening the menu triggers a rescan?

The result is that often I want to turn on a VPN, open the menu, and
before I managed to click on the VPN I want to activate, everything has
suddenly moved, and I end up either activating a different VPN, or
clicking somewhere else.

Ideally, moving the "VPN Connections" submenu above the available
networks list would work around this issue.

More generally, I guess the part of the applet popup that refreshes
while the popup is open should go right at the bottom.

Even more generally, the menu refreshing while open is still tricky, as
a badly timed refresh could still cause me to connect to a wifi network
I didn't intend to connect. I guess the applet could use an invariant
that options can appear at the end, or get grayed out, but not change
position?

But yeah, it would be plenty enough to me if I could reliably hit the
VPN I want to connect to. It frustrates me multiple times during a work
day :(


Enrico


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

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

Versions of packages network-manager-openvpn-gnome depends on:
ii  libc62.28-10
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk-3-0   3.24.5-1
ii  libnm0   1.14.6-2+deb10u1
ii  libnma0  1.8.20-1.1
ii  libsecret-1-00.18.7-1
ii  network-manager-openvpn  1.8.10-1

network-manager-openvpn-gnome recommends no packages.

network-manager-openvpn-gnome suggests no packages.

-- no debconf information

Bug#981351: X rendered wrong

[積丹尼 Dan Jacobson]

Package: lynx
Version: 2.9.0dev.6-1

(Please tell upstream:) Lynx has a big bug.
It can't render the first two correctly. Only the last two.
No other browser has this problem!


 AAA

 BBB



 XXX



 YYY


lynx says:

   [DEL: :DEL]

   AAA

   BBB

   [DEL: XXX :DEL]

   [DEL: YYY :DEL]


w3m says:

[DEL:

AAA

BBB

:DEL]

[DEL:XXX:DEL]

[DEL:YYY:DEL]

www.w3.org/TR/1999/REC-html401-19991224/struct/text.html#edef-del says:

INS and DEL are used to markup sections of the document that have been
inserted or deleted with respect to a different version of a document
(e.g., in draft legislation where lawmakers need to view the changes).

These two elements are unusual for HTML in that they may serve as either
block-level or inline elements (but not both). They may contain one or
more words within a paragraph or contain one or more block-level
elements such as paragraphs, lists and tables.

Bug#981350: openvswitch-common: openvswitch with kvm/libvirt vm's loses the vm's network connections

[Jasper Wallace]

Package: openvswitch-common
Version: 2.10.6+ds1-0+deb10u1
Severity: important

Dear Maintainer,

We run some VM's under kvm/libvirt/virsh with openvswitch for networking.

The ovs bridge is configured by /etc/network/interfaces.d/br0, which contains:

# Ansible managed

# one of the physical interfaces
allow-bond0 eno1
iface eno1 inet manual
ovs_type OVSPort
ovs_bonds bond0

# the other one
allow-bond0 eno2
iface eno2 inet manual
ovs_type OVSPort
ovs_bonds bond0

# bond them together with LACP
# XXX the old config had "bond-xmit-hash-policy layer2", needed?
auto bond0
allow-br0 bond0
iface bond0 inet manual
ovs_bridge br0
ovs_type OVSBond
ovs_bonds eno1 eno2
ovs_options bond_mode=balance-tcp lacp=active other_config:lacp-time=fast
up ifup eno1
up ifup eno2

# and add the bond to the bridge
# XXX the old config might of had spanning tree on
# but I don't think we need it really.
auto br0
allow-ovs br0
iface br0 inet static
address 192.168.7.41/24
gateway 192.168.7.1
ovs_type OVSBridge
ovs_ports bond0

Then when the libvirt/kvm VM's are created there ports get added to br0.

After the security upgrade of ovs on the 23rd the switch was
re-created but all the ports connected to the vm's where lost.

I'm not sure how to resolve this situtaion other then rebooting the
machine - is there some way make the OVS DB be persist over restarts?

Should we be configuring OVS some other way?

Thanks,

Jasper

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

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

Versions of packages openvswitch-common depends on:
ii  iproute2 4.20.0-2
ii  libatomic1   8.3.0-6
ii  libc62.28-10
ii  libssl1.11.1.1d-0+deb10u4
ii  openssl  1.1.1d-0+deb10u4
ii  python3  3.7.3-1
ii  python3-six  1.12.0-1

openvswitch-common recommends no packages.

Versions of packages openvswitch-common suggests:
pn  ethtool  

-- no debconf information

-- 
Your hydrogen & fuel cell partner
Arcola Energy Ltd, 24 Ashwin Street, 
London E8 3DL. www.arcolaenergy.com  / +44 
20 7503 1386
Registered in England and Wales, Company Number 7257863, VAT 
Number 110085273. Copyright 2020. Confidential and Proprietary. Not to be 
disseminated or copied in full or in part.

Bug#964438: apt-listbugs: dns error when running from cron job

[Francesco Poli]

On Fri, 29 Jan 2021 18:33:23 +0100 Michael Biebl wrote:

> On Mon, 27 Jul 2020 23:26:52 +0200 Francesco Poli
>  wrote:
> > 
> > But there must be a way to set a timer that does *not* catch up with
> > missed runs, during both downtime and sleep time!
> > 
> > If there isn't, then I would call this a missing feature.
> > And I would say that this can be reported upstream as a feature
> request.
>  
> 
> Let's treat it like that: Please report this as an upstream feature
> request, if you want such a functionality.
> The upstream bug tracker is at
> https://github.com/systemd/systemd/issues

Could you please report the feature request upstream on my behalf?
Thanks for your helpfulness.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpS_pdZlSVm0.pgp
Description: PGP signature

Bug#966052: spyder-kernels: Uses old name of sip module

[Drew Parsons]

Source: spyder-kernels
Followup-For: Bug #966052

spyder-kernels' use of sip is conditional to having environment
variable QT_API='pyqt', corresponding to PyQt 2 as I understand it.
It is only referenced in spyder_kernels/customize/spydercustomize.py
(lines 170, 172)

So it will not be accessed in a PyQt5 environment (where QT_API is not
set to 'pyqt').

spyder-kernels 1.10.1 applies other tests for PyQt5, but using
PyQt5.QtWidgets not .sip.

I think we don't need to patch anything in spyder-kernels. It's
already accounting for PyQt5. I think we can close this bug.

Bug#981349: kde/plasma does not start under wayland (solved)

[Antonio]

Package: plasma-workspace-wayland
Version: 4:5.20.5-3
Severity: normal

Dear Maintainer,
I recently tried to start a kde/plasma session on wayland server, via 
sddm+nouveau, but it return error "kwin_wayland failed backend".
To work I had to modify the file 
"/usr/share/wayland-sessions/plasmawayland.desktop" by inserting 
additional parameters:


original: 
Exec=/usr/lib/x86_64-linux-gnu/libexec/plasma-dbus-run-session-if-needed/usr/bin/startplasma-wayland


modified: 
Exec="/usr/lib/x86_64-linux-gnu/libexec/plasma-dbus-run-session-if-needed 
/usr/bin/startplasma-wayland --drm --libinput --xwayland plasmashell"


The question is: why are these parameters, necessary for its works, not 
already included in plasmawayland.desktop? (or could this be a problem 
with my configuration?)

Thank you,
Antonio

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'stable-updates'), (500, 
'stable'), (100, 'experimental')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.11-custom (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=ISO-8859-1) 
(ignored: LC_ALL set to it_IT), LANGUAGE=it

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages plasma-workspace-wayland depends on:
ii  kwayland-integration  5.20.5-1
ii  kwin-wayland  4:5.20.5-1
ii  libc6 2.31-9
ii  libkf5configcore5 5.78.0-3
ii  libkf5coreaddons5 5.78.0-2
ii  libkworkspace5-5  4:5.20.5-3
ii  libqt5core5a  5.15.2+dfsg-3
ii  libqt5dbus5   5.15.2+dfsg-3
ii  libstdc++6    10.2.1-6
ii  plasma-workspace  4:5.20.5-3
ii  qtwayland5    5.15.2-2

Bug#979765: this problem is realted to CPU

[kazimierz01]

I can confirm, that the bug occurs on HP T5550 only.
On very similar HP T510 it does not - and since both computers share 
same motherboard, it must be the CPU. So the problem occurs only on VIA 
Nano u3500 and does not on VIA Eden X2 U4200.


What other informations can I gather, to help solve this issue?

Thanks,
Kazimierz

Bug#978955: last update disables socket activation

[Marc Haber]

close #978955
end

Hi,

On Fri, Jan 29, 2021 at 05:51:12PM +0100, Michael Biebl wrote:
> Marc, any news here?

this only happens during upgades and is not reproducible. The behavior
might be a corollary of #934663 which is not going to be fixed for
bullseye.

I will finally roll out a local fix for that and reopen #978955 is the
issue stays.

Greetings
Marc

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

Bug#973474: Same problem here

[Marcin Owsiany]

severity 973474 grave
thanks

Upgrading the bug severity since it requires killing one's session to
recover from, taking all unsaved work with it.

I installed Debian testing today in a VM and have the same problem in the
GNOME+X11 session.
When I type the wrong password in the lock screen, there is a spinner and
after a few seconds an error message.
When I type the correct password, it *immediately* goes back to asking for
the password.
I can CTRL+ALT+F2 to log in at a text console to debug this, but I'm not
sure how to go about this. "DISPLAY=:0 xlsclients" does not show a
screensaver process running. Is the locking done by gnome-shell itself
these days?
I do not see anything related in syslog. Attaching a screenshot of what was
logged while I switched to the locked session, attempted a login, and
switched back to text console, in case someone wants to take a look.

Bug#883126: darkice cannot connect to IPv6 icecast server

[Kevin Otte]

I finally had a chance to chase this down and filed the issue upstream:
https://github.com/rafael2k/darkice/issues/166

I have also submitted a PR to try and fix the issue:
https://github.com/rafael2k/darkice/pull/167

Bug#981348: smokeping: page constantly refreshes while zoomed in, making UI unusable

[Michael Gebetsroither]

Package: smokeping
Version: 2.7.3-2
Severity: important
Tags: upstream patch

Dear Maintainer,

The UI of smokeping automatically refreshes the page when zoomed in on some
graphs (every 10s here) making it completely unusable (or actually higly
annoying) using it.

The bug report upstream is from 2012
https://github.com/oetiker/SmokePing/issues/5

and there is finally a fix for it that's also merged upstream.
https://github.com/oetiker/SmokePing/pull/170

Please consider applying it in debian.

I've tested the patch in a vanilla smokeping installation and also in
our infrastructure and it indeed fixes the problem.

Patch reference:

commit ef1a7eac0a2f0baaf2cf1dc47703a73cdd936752
Author: n0rc 
Date:   Wed Mar 13 15:35:48 2019 +0100

disabled page refresh while zooming (#5)

diff --git a/htdocs/js/smokeping.js b/htdocs/js/smokeping.js
index 59410cc..eb34e5e 100644
--- a/htdocs/js/smokeping.js
+++ b/htdocs/js/smokeping.js
@@ -26,12 +26,20 @@ var EndEpoch = 0;

 function changeRRDImage(coords,dimensions){

+// disable reloading the RRD image while zoomed in
+try {
+window.stop();
+} catch (exception) {
+// fallback for IE
+document.execCommand('Stop');
+}
+
 var SelectLeft = Math.min(coords.x1,coords.x2);

 var SelectRight = Math.max(coords.x1,coords.x2);

 if (SelectLeft == SelectRight)
- return; // abort if nothing is selected.
+return; // abort if nothing is selected.

 var RRDLeft  = 67;// difference between left border of 
RRD image and content
 var RRDRight = 26;// difference between right border 
of RRD image and content

I've removed all included information as it is from another system and
is not related to this bug report.

ps.: trying to include secrets into a public bugreport is not nice...

best regards,
gebi

Bug#981347: mariadb-10.5 FTBFS on kfreebsd

[Laurent Bigonville]

Source: mariadb-10.5
Version: 1:10.5.8-3
Severity: important
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hello,

ATM, mariadb-10.5 FTBFS on kfreebsd with the following error:

cd /<>/builddir/sql && /usr/bin/c++ -DDBUG_TRACE -DHAVE_CONFIG_H 
-DHAVE_EVENT_SCHEDULER -DHAVE_OPENSSL -DHAVE_POOL_OF_THREADS -DMYSQL_SERVER 
-I/<>/wsrep-lib/include -I/<>/wsrep-lib/wsrep-API/v26 
-I/<>/builddir/include -I/<>/include 
-I/<>/sql -I/<>/builddir/sql -I/<>/tpool 
-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time 
-D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector --param=ssp-buffer-size=4 -O2 
-g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing 
-Wno-uninitialized -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall 
-Wextra -Wformat-security -Wno-format-truncation -Wno-init-self 
-Wno-nonnull-compare -Wno-unused-parameter -Woverloaded-virtual 
-Wnon-virtual-dtor -Wvla -Wwrite-strings   -Wdate-time -D_FORTIFY_SOURCE=2 
-std=gnu++11 -o CMakeFiles/sql.dir/rpl_tblmap.cc.o -c 
/<>/sql/rpl_tblmap.cc
/<>/storage/maria/libmarias3/src/marias3.c: In function 
‘curl_needs_openssl_locking’:
/<>/storage/maria/libmarias3/src/marias3.c:71:37: error: 
‘RTLD_DEFAULT’ undeclared (first use in this function)
   71 | openssl_set_id_callback = dlsym(RTLD_DEFAULT, 
"CRYPTO_set_id_callback");
  | ^~~~
/<>/storage/maria/libmarias3/src/marias3.c:71:37: note: each 
undeclared identifier is reported only once for each function it appears in

This is happening because #define _GNU_SOURCE is not defined for that
platforme (see dlopen() manpage)

the CMake scripts are only defining it in case of Linux or GNU.

Could you please try to define this in the kfreebsd (glibc)?

Kind regards,
Laurent Bigonville


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

Kernel: Linux 5.10.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#981213: debrepro: fusermount -u fails in chroots

[Stephan Sürken]

Rehi,

On Wed, 27 Jan 2021 19:29:00 +0100 =?utf-8?q?Stephan_S=C3=BCrken?= <
abs...@debian.org> wrote:
> Package: devscripts
> Version: 2.20.5
> Severity: normal
> 
> Dear Maintainer,
> 
> any chrooted run debrepro fails on cleanup with s.th. like:
> ---
> rm: cannot remove '/tmp/debrepro.WdTfiXpiIP/second/source': Device or
resource busy
> ---

some more info: The behaviour is as described under (at least) linux
5.9.15.

Running with our current kernel (5.10.9) however, everything seems
fine.

If this really is gone for good with 5.10, I will just close this
eventually.

Hth,

S

Bug#981346: partman-base: partman still overwrites u-boot on some systems

[harry88]

Package: partman-base
Version: 214
Severity: important
Tags: d-i patch

Dear Debian Install System Team,

This is a follow-on from bug #770666 in which some systems had their firmware
overwritten by partman.  The patch there provided a function to detect the
affected systems by looking for their manufacturer names in /proc/cpuinfo,
so that partman would know not to overwrite in those cases.

Unfortunately, affected arm64 systems don't contain a suitable string in
/proc/cpuinfo, so their firmware still ends up getting overwritten.

My suggestion is to use /proc/device-tree/compatible instead of /proc/cpuinfo.
By searching the list there for an entry beginning with "allwinner," or
"fsl,imx6" or "ti,am33xx", we will hopefully match the same systems as the
current search for "Allwinner", "Freescale" or "AM33XX" would have found.

I've included a suggested patch below.

Thank you for considering it,
Harold.


diff --git a/parted_server.c b/parted_server.c
index 41784b70..4e7a0ead 100644
--- a/parted_server.c
+++ b/parted_server.c
@@ -1334,30 +1334,51 @@ command_dump()
 oprintf("OK\n");
 }

-/* Check whether we are running on a sunxi-based, freescale-based, or
-   AM33XX (beaglebone black) system. */
+/* Decide whether this system stores firmware on disk by looking up
+ * machine type in device tree. If Allwinner (bug #751704) or
+ * i.MX6 or AM33xx (bug #770666), assume yes, otherwise no.
+ */
-int
+bool
 is_system_with_firmware_on_disk()
 {
-int cpuinfo_handle;
-int result = 0;
+int dt_handle;
+int close_ret;
+char *cur;
 char buf[4096];
 int length;

-if ((cpuinfo_handle = open("/proc/cpuinfo", O_RDONLY)) != -1) {
-length = read(cpuinfo_handle, buf, sizeof(buf)-1);
-if (length > 0) {
-buf[length]='\0';
-if (strstr(buf, "Allwinner") != NULL)
-result = 1;
-else if (strstr(buf, "Freescale") != NULL)
-result = 1;
-else if (strstr(buf, "AM33XX") != NULL)
-result = 1;
-}
-close(cpuinfo_handle);
-}
-return result;
+dt_handle = open("/proc/device-tree/compatible", O_RDONLY);
+if (dt_handle == -1) {
+log("Error opening device-tree property: %s", strerror(errno));
+log("Assuming non-ARM system, with no firmware on disk");
+return false;
+}
+
+length = read(dt_handle, buf, sizeof(buf)-1);
+if (length == -1)
+log("Error reading device-tree property: %s", strerror(errno));
+
+close_ret = close(dt_handle);
+if (close_ret == -1)
+log("Error closing device-tree property: %s", strerror(errno));
+
+if (length == -1 || close_ret == -1) {
+log("Assuming no firmware on disk");
+return false;
+}
+
+buf[length] = '\0';
+for (cur = buf; cur < buf+length; cur += strlen(cur)+1) {
+if (0 == strncmp(cur, "allwinner,", 10)
+|| 0 == strncmp(cur, "fsl,imx6", 8)
+|| 0 == strncmp(cur, "ti,am33xx", 9)) {
+log("Machine type '%s'; stores firmware on disk", cur);
+return true;
+}
+}
+
+log("Machine type checked; assuming no firmware on disk");
+return false;
 }

 void
@@ -1368,15 +1389,15 @@ command_commit()
 critical_error("The device %s is not opened.", device_name);
 log("command_commit()");

-/* The boot device on sunxi-based systems needs special handling.
+/* The boot device on some systems needs special handling.
  * By default partman calls ped_disk_clobber when writing the
- * partition table, but on sunxi-based systems this would overwrite
+ * partition table, but on some systems this would overwrite
  * the firmware area, resulting in an unbootable system (see
  * bug #751704).
  */
 if (is_system_with_firmware_on_disk() && !strncmp(disk->dev->path, 
"/dev/mmcblk", 11)) {
 disk->needs_clobber = 0;
-log("Sunxi/Freescale/AM33XX detected. Disabling 
ped_disk_clobber " \
+log("Disabling ped_disk_clobber " \
 "for the boot device %s to protect the firmware " \
 "area.", disk->dev->path);
 }

Bug#978955: last update disables socket activation

[Michael Biebl]

On Thu, 7 Jan 2021 13:23:30 +0100 Michael Biebl 
wrote:

> I can not reproduce the problem.
> If I run
> systemctl disable --now ssh.service
> systemctl enable --now ssh.socket
> apt install --reinstall systemd
> 
> ssh.socket keeps running. So at a first glance this doesn't look like
a 
> systemd problem.
> Please provide a (debug) journal log, which shows the problem.

Marc, any news here?


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

Bug#981345: buster-pu: package systemd/241-7~deb10u6

[Michael Biebl]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org, k...@debian.org, 
debian-b...@lists.debian.org

Hi,

I'd like to make a stable upload for systemd fixing #975561:

  journal: do not trigger assertion when journal_file_close() get NULL

The rest is autopkgtest updates, as the current state is a bit sad [1]
on stable.

The full (annotated) changelog is

systemd (241-7~deb10u6) buster; urgency=medium

  * journal: do not trigger assertion when journal_file_close() get NULL
(Closes: #975561)

https://salsa.debian.org/systemd-team/systemd/-/commit/42f62d560748cf79353d0a66d1ccf49517f951d3

* test-bpf: skip test when run inside containers.
The test reliably fails inside LXC and Docker when run on a new enough
kernel. It's unclear whether this is a kernel, LXC/Docker or systemd
issue and apparently there is no real interest to get this fixed, so
let's skip this test.

https://salsa.debian.org/systemd-team/systemd/-/commit/de5350a0090a51ba391baf57e5d3e549bf126a6b

  * autopkgtest: mark networkd-test.py as flaky.
See https://github.com/systemd/systemd/issues/18357
and https://github.com/systemd/systemd/issues/18196

https://salsa.debian.org/systemd-team/systemd/-/commit/996babe874059cc70f54f4edbd3e00a46a208bb7


CCed kibi/debian-boot, as usual.
The udev package should not be affected, as the above change only
affects the journal, which is not used in d-i.
The regression potential is rather low. The fix itself is a cherry-pick
from upstream and has been part of sid/testing since quite a while.


Regards,
Michael


[1] https://ci.debian.net/packages/s/systemd/


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

Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 8c3b276..61dcee2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+systemd (241-7~deb10u6) buster; urgency=medium
+
+  * journal: do not trigger assertion when journal_file_close() get NULL
+(Closes: #975561)
+  * test-bpf: skip test when run inside containers.
+The test reliably fails inside LXC and Docker when run on a new enough
+kernel. It's unclear whether this is a kernel, LXC/Docker or systemd
+issue and apparently there is no real interest to get this fixed, so
+let's skip this test.
+  * autopkgtest: mark networkd-test.py as flaky.
+See https://github.com/systemd/systemd/issues/18357
+and https://github.com/systemd/systemd/issues/18196
+
+ -- Michael Biebl   Fri, 29 Jan 2021 15:16:06 +0100
+
 systemd (241-7~deb10u5) buster; urgency=medium
 
   * basic/cap-list: parse/print numerical capabilities (Closes: #964926)
diff --git a/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch 
b/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch
index 231158c..78c2d01 100644
--- a/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch
+++ b/debian/patches/debian/Re-enable-journal-forwarding-to-syslog.patch
@@ -30,7 +30,7 @@ index 2791678..3a9e20a 100644
  systemd.journald.forward_to_syslog,
  systemd.journald.forward_to_kmsg,
 diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
-index 2a960eb..7fe0f82 100644
+index ba0b35d..cd45212 100644
 --- a/src/journal/journald-server.c
 +++ b/src/journal/journald-server.c
 @@ -1835,6 +1835,7 @@ int server_init(Server *s) {
diff --git 
a/debian/patches/journal-do-not-trigger-assertion-when-journal_file_close-.patch
 
b/debian/patches/journal-do-not-trigger-assertion-when-journal_file_close-.patch
new file mode 100644
index 000..9cb536b
--- /dev/null
+++ 
b/debian/patches/journal-do-not-trigger-assertion-when-journal_file_close-.patch
@@ -0,0 +1,46 @@
+From: Yu Watanabe 
+Date: Tue, 28 May 2019 12:40:17 +0900
+Subject: journal: do not trigger assertion when journal_file_close() get NULL
+
+We generally expect destructors to not complain if a NULL argument is passed.
+
+Closes #12400.
+
+(cherry picked from commit c377a6f3ad3d9bed4ce7e873e8e9ec6b1650c57d)
+---
+ src/journal/journal-file.c| 3 ++-
+ src/journal/journald-server.c | 7 ++-
+ 2 files changed, 4 insertions(+), 6 deletions(-)
+
+diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
+index 56827f9..04cf1ef 100644
+--- a/src/journal/journal-file.c
 b/src/journal/journal-file.c
+@@ -335,7 +335,8 @@ bool journal_file_is_offlining(JournalFile *f) {
+ }
+ 
+ JournalFile* journal_file_close(JournalFile *f) {
+-assert(f);
++if (!f)
++   

Bug#980263: taskwarrior: Filtering for project-names containing hyphen and number stopped working

[Nicola Chiapolini]

Reopened upstream, my use-case also includes 'c.vs.2021-11' which is not fixed

Bug#981344: dgit setup-gitattributes sometimes fails to populate .git/info/attributes on the first run (?!)

[Andrej Shadura]

Package: dgit
Version: 9.12
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

I found that sometimes dgit setup-gitattributes fails to set up the
attributes on the first run in a freshly cloned repo:

$ git clone https://gitlab.apertis.org/pkg/php7.3
Cloning into 'php7.3'...
remote: Enumerating objects: 316, done.
remote: Counting objects: 100% (316/316), done.
remote: Compressing objects: 100% (308/308), done.
remote: Total 21825 (delta 18), reused 93 (delta 7), pack-reused 21509
Receiving objects: 100% (21825/21825), 26.28 MiB | 11.47 MiB/s, done.
Resolving deltas: 100% (4136/4136), done.
Updating files: 100% (20246/20246), done.
$ cd php7.3
$ dgit -D setup-gitattributes
| git rev-parse --show-toplevel
=> `/tmp/php7.3'
| git config -z --get-regexp --local '.*'
| git config -z --get-regexp --local '.*'
| git config -z --get-regexp --global '.*'
| git config -z --get-regexp --system '.*'
$ cat .git/info/attributes
$ ls -l .git/info/attributes
-rw-rw-r-- 1 andrewsh andrewsh 0 Jan 29 17:38 .git/info/attributes
$ dgit -D setup-gitattributes
| git rev-parse --show-toplevel
=> `/tmp/php7.3'
| git config -z --get-regexp --local '.*'
| git config -z --get-regexp --local '.*'
| git config -z --get-regexp --global '.*'
| git config -z --get-regexp --system '.*'
is_gitattrs_setup: found nothing
$ cat .git/info/attributes
*   dgit-defuse-attrs
[attr]dgit-defuse-attrs -text -eol -crlf -ident -filter 
-working-tree-encoding
# ^ see GITATTRIBUTES in dgit(7) and dgit setup-new-tree in dgit(1)

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSD3NF/RLIsyDZW7aHoRGtKyMdyYQUCYBQ6QwAKCRDoRGtKyMdy
YZfQAQCkvpaUdij4d4eBN/hgktIJoE8L8Ld5vZdCzAaAbCdlxgD/dWy2iHr5kxKx
B2zBbI6pX5C2p7E/KDkHxX56zhylBwE=
=g+3O
-END PGP SIGNATURE-

Bug#970395: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs

[Henrique de Moraes Holschuh]

On Tue, 26 Jan 2021, Debian Bug Tracking System wrote:
> > reassign 970395 amd64-microcode
> Bug #970395 [src:firmware-nonfree] firmware-nonfree: Please add AMD-SEV 
> firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs
> Bug reassigned from package 'src:firmware-nonfree' to 'amd64-microcode'.
> Ignoring request to alter found versions of bug #970395 to the same values 
> previously set
> Ignoring request to alter fixed versions of bug #970395 to the same values 
> previously set
> > # please update to latest bc9cd0b7b0e96038ccc041ff409948d8f176142d
> > # 20/11/2020 in linux-firmware
> > done
> Unknown command or malformed arguments to command.
> > bc9cd0b7b0e96038ccc041ff409948d8f176142d has:
> Unknown command or malformed arguments to command.
> >Update AMD SEV firmware to version 0.17 build 44 for AMD family 17h
> Unknown command or malformed arguments to command.
> > processors with models in the range 00h to 0fh.
> Unknown command or malformed arguments to command.
> > Update AMD SEV firmware to version 0.24 build 7 for AMD family 17h
> Unknown command or malformed arguments to command.
> Too many unknown commands, stopping here.

I will look into this soon, probably this weekend.

I will direct any questions I have to the submitters and to this bug
report.

However, I have to find out if these firmware data files should go into
the early initramfs like the microcode (and *how*: naming, packaging
into a single file? the early initramfs works differently than normal
firmware loading).  Or should it go into the normal initramfs ?  Or
both?

If you have the answer to these questions and can follow up with them,
it will hasten the fix since I will not have to spend time looking for
the answers.

-- 
  Henrique Holschuh

Bug#980962: buster-pu: package intel-microcode/3.20201118.1~deb10u1

[Henrique de Moraes Holschuh]

On Sun, 24 Jan 2021, Henrique de Moraes Holschuh wrote:
 Regressions were indeed reported (as expected).  A few days ago, Intel
> published relevant information pinpointing the regression on Skylake D0
> and Skylake R0 processors to specific conditions (detailed below for
> completeness).
> 
> The 3.20201118.1~deb10u1 version of the package (the one I am proposing
> for the stable update) contains changes not (yet?) in unstable to
> address the Skylake D0/R0 issue: they had their updates frozen
> to the same revision currently in Debian stable.

I better explain that in a more direct, clear way:

The reason why I want to update the package in stable is: the updated
microcode in this package have security mitigations for a few newer
speculative execution sidechannel attacks, and fix some critical
defects/"errata" on many recent processor models, *other than Skylake
R0/D0*.

The s-p-u version of the intel-microcode package I am proposing has
*less* changes than the packages currently in unstable/testing.

The microcode updates have been tested in unstable since 2020-12-27, and
in testing since 2020-01-02.

Issues with it were reported in Ubuntu and Arch Linux, for specific
system vendors and computer models (not processor models -- i.e. it does
not look like a general issue with the microcode updates) when running
outdated firmware.

A *general* microcode update issue was reported only for Skylake D0/R0.
The offending microcode changes for Skylake D0/R0 are *reverted* in this
s-p-u package.

To do that, the package keeps the microcode for these two processor
models *exactly the same* as they already are in Debian stable.


The package changes when compared to the packages currently in Debian
stable are:

1. microcode binary data (except for Skylake D0 and R0)
2. upstream documentation
3. Debian metadata (changelog, version).


Thanks!

-- 
  Henrique Holschuh

Bug#700633: Why this eatmydata patch still not applied to debootstrap? My USB storage devices are slow

[Askar Safin]

severity -1 normal
thanks

Hi.

Why this bug ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700633 ) still 
is not fixed?

I did some experiments and here are results: if I run debootstrap stage of d-i 
under eatmydata, then its time decreases from 755 s to 370 - 405 s. (I 
installed Debian 
to USB storage device).

Please, fix this bug. Fix is simple, benefits for many users are big. (So I 
change severity.)

I think eatmydata mode should be enabled by default in debootstrap. Both inside 
of d-i and outside of it.

==
Askar Safin
https://github.com/safinaskar

Bug#908293: accountsservice: High CPU usage after system startup

[Francesco P. Lovergine]

On Tue, Oct 30, 2018 at 10:46:22PM -0400, Scott Bailey wrote:

Package: accountsservice
Version: 0.6.45-1
Followup-For: Bug #908293

Dear Maintainer,

I noticed in passing that the accounts-daemon process is consuming 99%+ of
one
of my processors, on a long-term ongoing basis, and neither restarts (via
systemctl) nor reboots seem to be curbing its enthusiasm.

I'm responding to the original bug report, although that was for an earlier
version, as the symptoms seem to largely mirror mine.

Thanks,

-Scott




Apparently, this also triggering autodir daemon that I use on our servers 
extensively since years. Recently, I had to install x2go/vnc and mate on 
several boxes to allow people to use a DE during covid‐19 lockdown here, and 
autodir randomly starts to log tons of messages such:


gen 29 09:21:31 Y autodir[42811]: [autohome] warning: no user found with 
name XX.tiff
gen 29 09:21:31 Y autodir[42811]: [autohome] alert: module autohome failed 
on XX.tiff
gen 29 09:21:31 Y autodir[42811]: [autohome] warning: no user found with 
name XX.wbmp
gen 29 09:21:31 Y autodir[42811]: [autohome] alert: module autohome failed 
on XX.wbmp
gen 29 09:21:31 Y autodir[42811]: [autohome] warning: no user found with 
name XX.webp
gen 29 09:21:31 Y autodir[42811]: [autohome] alert: module autohome failed 
on XX.webp
gen 29 09:21:31 Y autodir[42811]: [autohome] warning: no user found with 
name XX.xbm
gen 29 09:21:31 Y autodir[42811]: [autohome] alert: module autohome failed 
on XX.xbm
gen 29 09:21:31 Y autodir[42811]: [autohome] warning: no user found with 
name XX.xpm
gen 29 09:21:31 Y autodir[42811]: [autohome] alert: module autohome failed 
on XX.xpm

It seems directly due to the new services installed. X is generally an 
already logged user.
Of course that stops after restarting the autodir daemon, but high cpu times 
appear for accounts-daemon, systemd-logd (well, of course) and caja. I could 
probably mitigate the issue in autodir by stopping the continuous reporting, 
but there's something strange in the caja/accounts-daemon or both, not sure. 


The whole thing is quite annoying...


--
Francesco P. Lovergine

Bug#981343: debian-archive-keyring: remove 8/jessie keys

[Ansgar]

Package: debian-archive-keyring
Version: 2019.1
Severity: normal

The Debian 8 (Jessie) signing keys are no longer used, but still
shipped in debian-archive-keyring.gpg:

pub   rsa4096/0xCBF8D6FD518E17E1 2013-08-17 [SC] [expires: 2021-08-15]
  75DDC3C4A499F1A18CB5F3C8CBF8D6FD518E17E1
uid   Jessie Stable Release Key 


pub   rsa4096/0x7638D0442B90D010 2014-11-21 [SC] [expires: 2022-11-19]
  126C0D24BD8A2942CC7DF8AC7638D0442B90D010
uid   Debian Archive Automatic Signing Key (8/jessie) 


pub   rsa4096/0x9D6D8F6BC857C906 2014-11-21 [SC] [expires: 2022-11-19]
  D21169141CECD440F2EB8DDA9D6D8F6BC857C906
uid   Debian Security Archive Automatic Signing Key (8/jessie) 


They should be rotated out into debian-archive-removed-keys.gpg.

Ansgar