Bug#985862: linux: Please enable support for NXP/Freescale iMX8

[Wookey]

Source: linux
Severity: normal

The iMX8 SoC is used on various boards, widely available to debian
users and well supported by free software, but the platform is not
enabled in debian kernels, which is a rather major omission. I don't
know why not (I guess no-one filed this bug?).

These are all avilable today and should at least mostly work with
mainline:
Nitrogen 8M 
 https://boundarydevices.com/product/nitrogen8m/
Solidrun 
 Cubox M https://shop.solid-run.com/product/SRMP8QDWB1D04GE008X00CE/
 Hummingboard Pulse 
https://shop.solid-run.com/product-category/embedded-computers/nxp-family/hummingboard-m/
Purism
 Librem 5 Phone https://en.wikipedia.org/wiki/Librem_5
Compulab
 SBC-iMX8X 
https://www.compulab.com/products/sbcs/sbc-imx8x-nxp-i-mx-8x-single-board-computer/
 (supported since 5.4.24)
Toradex
 Apalis iMX8 CoM 
https://www.toradex.com/computer-on-modules/apalis-arm-family/nxp-imx-8

I believe that all that is needed is adding
CONFIG_ARCH_MXC=y in debian/config/arm64/config
Which is set by default upstream.

(There may be other drivers that should enabled too for some of these
platforms?)

I just built the kernel with the above config change and it builds
fine on arm64, and installs and boots on softiron. I don't have an
iMX8 here to test on, but we can find some, I'm sure.

It seems like the timing was rather unfortunate here with some of this
hardware only becoming widely available in Q4 2020 (shortly before the
Bullseye freeze). Is there any chance of one more hardware enablement
upload for bullseye, or does this feel like too big a change? If not,
getting this into a point release would make debian stable useful on a
lot more hardware. What testing would make the kernel team reasonably
happy about doing that?

-- 
Wookey

Bug#982661: mame: Crash on startup

[Celelibi]

Hello,

After some debugging, here are some informations:
- I use the r300 mesa driver.
- Hardware accelerated programs like glxgears tend to work, but crash
  when they exit.
- They crash with the same backtrace.
- The driver r300 doesn't implement the function set_shader_buffers.
- Setting LIBGL_DEBUG=verbose isn't very informative, see below [1].
- Actually, in the function cso_destroy_context [2], we can see it would
  be expected that the value of maxssbo to be 0. Instead I get 16.
- This bug has been fixed upstream [3].
- The fix has been backported to the release 21.0.0.

So I guess this bug report should be reassigned to the package
libgl1-mesa-dri, retitled accordingly and marked as fixed upstream. And
probably be closed as soon as the release 21.0.0 reach debian sid.


Best regards,
Celelibi



[1]
libGL: using driver radeon for 5
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/celelibi/.drirc: No such file or 
directory.
libGL: pci id for fd 5: 1002:791f, driver r300
libGL: MESA-LOADER: dlopen(/usr/lib/x86_64-linux-gnu/dri/r300_dri.so)
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/celelibi/.drirc: No such file or 
directory.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/celelibi/.drirc: No such file or 
directory.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/celelibi/.drirc: No such file or 
directory.
libGL: Using DRI2 for screen 0


[2]
int maxssbo = scr->get_shader_param(scr, sh,
PIPE_SHADER_CAP_MAX_SHADER_BUFFERS);
...
if (maxssbo > 0) {
   ctx->pipe->set_shader_buffers(ctx->pipe, sh, 0, maxssbo, ssbos, 0);
}

[3] 
https://gitlab.freedesktop.org/mesa/mesa/-/commit/58e43594fc457eaaf1b1e01e48948959a82080bc

Bug#979343: sddm: general protection fault in libQt5Qml.so.5.15.2

[Bernhard Übelacker]

Hello everyone,



I added it, and now I got one:
Tue 2021-03-23 20:20:40 CET2000   109   115  11 present 
/usr/bin/sddm-greeter

If I extract it, I get:
 Executable: /usr/bin/sddm-greeter

...

 #9  0x7fe7b41f5def __clone (libc.so.6 + 0xfddef)


With this "coredumpctl gdb 2000", and when you have gdb installed,
you should get a prompt "(gdb) ".
There a command "bt" should get a better backtrace than the automatic one.




You can get the core file, if you like, at
https://www.helgefjell.de/data/sddm.core


I tried to have a look at this one in the hope I have the same
package versions installed as you, and have received a backtrace
showing we are inside the __run_exit_handlers.
This might explain why you get no issue with it except the logging,
because this process has already done its main work
and is about to end itself.

What I further see is some object destruction going on
with mentioning QV4 - which I believe is tightly related to
Qts javascript engine.

And finally it is in a method QMetaType::destruct, which is
unfortunately about to call a function pointer m_destructor
that consists of some string data.

Getting a traps instead of a segfault might be because of
the function pointer using more than the lower 48 bits, to
which address space is currently limited?
At least a short test with the value 0x0070006d006f0063
leads to such a traps message, using 0x006d006f0063
shows a "segfault at" message in dmesg.

But having this string at this position might just be coincidence,
a few debugging details might be found in attached file.

Kind regards,
Bernhard


Core was generated by `/usr/bin/sddm-greeter --socket /tmp/sddm-:0-aSeIQL 
--theme /usr/share/sddm/them'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  QMetaType::destruct (data=0x563464af9d00, this=0x5634649ea3b8) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qmetatype.h:2375
2375m_destructor(data);
[Current thread is 1 (Thread 0x7fe7b49fb840 (LWP 2000))]
(gdb) bt
#0  QMetaType::destruct (data=0x563464af9d00, this=0x5634649ea3b8) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qmetatype.h:2375
#1  QV4::Heap::QQmlValueTypeWrapper::destroy (this=0x7fe79833d460) at 
qml/qqmlvaluetypewrapper.cpp:100
#2  0x7fe7b52fa55f in QV4::Chunk::sweep (this=0x7fe79833, 
engine=0x56346475ffe0) at memory/qv4mm.cpp:349
#3  0x7fe7b52fa7f3 in operator() (c=, __closure=) at memory/qv4mm.cpp:630
#4  std::__partition<__gnu_cxx::__normal_iterator 
>, QV4::BlockAllocator::sweep():: > (__pred=..., __last=0x2, 
__first=0x7fe79833) at /usr/include/c++/10/bits/stl_algo.h:1515
#5  std::partition<__gnu_cxx::__normal_iterator 
>, QV4::BlockAllocator::sweep():: > (__pred=..., __last=..., 
__first=...) at /usr/include/c++/10/bits/stl_algo.h:4673
#6  QV4::BlockAllocator::sweep (this=this@entry=0x56346442fa60) at 
memory/qv4mm.cpp:631
#7  0x7fe7b52fb415 in QV4::MemoryManager::sweep 
(this=this@entry=0x56346442fa50, lastSweep=lastSweep@entry=false, 
classCountPtr=classCountPtr@entry=0x0) at memory/qv4mm.cpp:994
#8  0x7fe7b52fbf2d in QV4::MemoryManager::runGC (this=0x56346442fa50) at 
memory/qv4mm.cpp:1054
#9  0x7fe7b52fddb5 in QV4::MemoryManager::allocate (size=32, 
allocator=0x56346442fa60, this=0x56346442fa50) at 
../../include/QtQml/5.15.2/QtQml/private/../../../../../src/qml/memory/qv4mm_p.h:307
#10 QV4::MemoryManager::allocString (this=this@entry=0x56346442fa50, 
unmanagedSize=) at memory/qv4mm.cpp:791
#11 0x7fe7b536418e in QV4::MemoryManager::allocWithStringData (arg1=..., unmanagedSize=, this=0x56346442fa50) at 
../../include/QtQml/5.15.2/QtQml/private/../../../../../src/qml/memory/qv4mm_p.h:217
#12 QV4::ExecutionEngine::newString (this=this@entry=0x56346475ffe0, s=...) at 
jsruntime/qv4engine.cpp:894
#13 0x7fe7b539f688 in QV4::ErrorPrototype::method_toString (b=, thisObject=0x7fe7986b9508) at jsruntime/qv4errorobject.cpp:352
#14 0x7fe7b541706f in QV4::FunctionObject::call (argc=0, argv=0x0, 
thisObject=0x7fe7986b9508, this=0x7fe7986b9530) at 
jsruntime/qv4functionobject_p.h:172
#15 QV4::RuntimeHelpers::ordinaryToPrimitive 
(engine=engine@entry=0x56346475ffe0, object=object@entry=0x7fe7986b9508, 
typeHint=typeHint@entry=0x7fe7986b9310) at jsruntime/qv4runtime.cpp:517
#16 0x7fe7b5417394 in QV4::RuntimeHelpers::objectDefaultValue 
(object=0x7fe7986b9508, object@entry=0x7fe7986b9518, typeHint=typeHint@entry=2) 
at jsruntime/qv4runtime.cpp:495
#17 0x7fe7b541bd75 in QV4::RuntimeHelpers::toPrimitive 
(typeHint=QV4::STRING_HINT, value=...) at jsruntime/qv4runtime_p.h:123
#18 QV4::Value::toQStringNoThrow (this=this@entry=0x7fe7986b9508) at 
jsruntime/qv4value.cpp:150
#19 0x7fe7b536d5de in QV4::ExecutionEngine::catchExceptionAsQmlError 
(this=this@entry=0x56346475ffe0) at 
../../include/QtQml/5.15.2/QtQml/private/../../../../../src/qml/jsruntime/qv4scopedvalue_p.h:234
#20 0x7fe7b5518412 in QQmlDelayedError::catchJavaScriptException 
(engine=0x56346475ffe0, this=0x5634647b3860) 

Bug#985854: dwm: open calibre gui prevents switching focus to other windows

[florine forine]

Package: dwm
Version: 6.1-5+b1
Severity: normal

Dear Maintainer,

 An open instance of the calibre GUI (ebook library management tool with a
 qt-interface) prevents the user to switch between windows (using keyboard
 commands mod1-k, mod1-j) with the same tag as the calibre GUI.

 The calibre GUI remains always in foreground.

 But keyboard command Mod1-Shift-[1..n] work (tagging the GUI)


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

Versions of packages dwm depends on:
ii  libc6   2.31-9
ii  libfontconfig1  2.13.1-4.2
ii  libx11-62:1.7.0-2
ii  libxft2 2.3.2-2
ii  libxinerama12:1.1.4-2

-- no debconf information


signature.asc
Description: PGP signature

Bug#985861: ustreamer: Please build-depend on libjpeg-dev instead of libjpeg62-turbo-dev

[Logan Rosen]

Package: ustreamer
Version: 3.16-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Hi,

ustreamer currently build-depends on libjpeg62-turbo-dev, which ties it
to a particular JPEG implementation. Build-depending on libjpeg-dev
allows it to use whatever JPEG implementation is the default in Debian
(and its derivatives) instead.

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

  * Build-depend on libjpeg-dev instead of libjpeg62-turbo-dev.

Thanks for considering the patch.

Logan
diff -Nru ustreamer-3.16/debian/control ustreamer-3.16/debian/control
--- ustreamer-3.16/debian/control   2021-01-21 21:36:18.0 -0500
+++ ustreamer-3.16/debian/control   2021-03-24 22:13:27.0 -0400
@@ -4,7 +4,7 @@
 Maintainer: Sam Reed 
 Build-Depends: debhelper-compat (= 12),
   libevent-dev,
-  libjpeg62-turbo-dev,
+  libjpeg-dev,
   uuid-dev,
   libbsd-dev
 Standards-Version: 4.5.1

Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc

[Daniel Shahaf]

Good morning Felix,

Felix Lechner wrote on Tue, Mar 23, 2021 at 14:16:26 -0700:
> Hi Daniel,
> 
> On Mon, Jul 13, 2020 at 8:27 AM Daniel Shahaf  wrote:
> >
> > a debian/upstream/signing-key.asc file
> > which contains an expired snapshot of upstream's signing key
> 
> Did uscan give you any trouble when trying to validate upstream's
> release signature?

In zsh-syntax-highlighting's packaging I don't use uscan(1).  I just
git-merge(1) the new upstream tag, and use git-archive(1) to fake
a .orig tarball.

According to comments in zsh-syntax-highlighting's debian/README.source
and debian/source/lintian-overrides, uscan(1) was avoided because
upstream produces signed tags but not signed tarballs, and no way was
identified to have uscan(1) verify them.  Thus, the automation that
calls git-archive(1) also handles verification manually.

In my specific case, I don't actually need the verification at all
because I happen to upstream's release manager and sign the tags myself
in that capacity, but the workflow doesn't depend on this.

Cheers,

Daniel

> Kind regards
> Felix Lechner
> 

Bug#985233: O: lmbench -- Utilities to benchmark UNIX systems

[Al Stone]

On 22 Mar 2021 22:37, Andreas Beckmann wrote:
> Hi Al,
> 
> On Sun, 14 Mar 2021 15:17:52 -0600 Al Stone  wrote:
> > I intend to orphan the lmbench package.  I no longer use it,
> 
> Can you push the changes and tag from the -5 upload, please?
> 
> And could you try to move the package on salsa from your personal namespace
> to the 'debian' or 'hpc-team' namespace? (I think that should be Settings ->
> General -> Advanced -> Transfer project, but I have never used it.) There is
> no need to do an upload to update the Vcs URLs.
> 
> Thanks,
> 
> Andreas, who might adopt it for the HPC team

Howdy, Andreas.

I tried to transfer the package but the only namespace I was able to
enter was my own.  I can't tell if that's the way the other namespaces
are set up or just operator error on my part -- either way, salsa
won't let me.  Sorry :(.

-- 
Ciao,
al
--
Al Stone 
E-mail: a...@ahs3.net
--

Bug#985362: mumble: Unhide after Minimize to tray flashes rapidly

[Chris Knadle]

retitle 985362 mumble: Unhide after Minimize to tray flashes rapidly under KDE
tags 985362 - moreinfo
thx

Hello Johnathan.

Thanks for your continued testing, it's appreciated.

I'm still working to get KDE installed in a Sid VM because the Sid VM I have has 
a disk that's too small to add KDE to, so I'm figuring out the procedure needed 
to extend the virtual disk to fit it. It involves extending the virtual disk 
file size withe VM off (qemu-img), then partition size, logical volume size, 
then filesystem size.


Jonathan Rubenstein:


Thank you for your reply, Chris.

This sounds like Mumble being brought out of being minimized and then 
minimizing again, as if there were either no or two mouse clicks; i.e. this 
sounds like a mouse button switch that's starting to go bad. I've had this 
happen to me, it leads to thinking of all kinds of things being broken that 
aren't.


I have right clicked on the mumble icon and hit "Show"—which should only ever 
allow one mouse click because it disappears—and still experience this issue even 
with that. This can also happen when running 'mumble' in a terminal with mumble 
already open and minimized to tray, or opening a desktop file.


I've also run xev and clicked the window 100 times, saving the log to a file[1]. 
This log contains no more and no less than exactly 100 mouse button down entries 
and 100 mouse button up entries.


Hmm. Yeah that sounds conclusive that it's not a mouse button issue. 
Interesting.  Thanks, this was a great idea.


So my first suggestion is to try changing mice to see if it's a mouse button 

problem,

I have briefly switched mice to my old one, and I have the same issue at the 
same reproduction rate.


This also fits a conclusion that it's not the mouse button.

and the second is to try adjust the mouse button timing in KDE settings 
(especially if you have done so recently). >
I cannot find these settings in KDE 5, but as I can reproduce without using the 
mouse at all via a terminal or desktop file, I do not believe this will help.


Yeah the other thing is that the test done with counting mouse clicks and them 
matching up in number would also invalidate the idea of this being an issue of 
mouse settings in KDE 5.


To answer the question of where the settings for this should be, it should be in 
KDE "System Settings" under "Input Devices"


https://userbase.kde.org/System_Settings/Input_Devices#Mouse

At first glance I suspect this isn't a Mumble bug, or at least that if it does 
relate to Mumble directly that it doesn't happen on all desktop environments. 
I regularly use the "Hide in tray when minimized" feature but not on KDE.


I agree, it does not seem to happen on all desktop environments.


Okay cool, so that part seems consistent.


I have a Sid VM where I think I'll try adding KDE Plasma to for testing.


I can try in a VM as well. I'll also give it a go in some other DEs and WMs.


I hope my testing is satisfactory, let me know if I can do anything else.


Yes this testing has been very helpful, thank you.
It means more than might be expected; this is the kind of collaboration that I 
enjoy.



[1]: https://paste.debian.net/1190823/


Since this was supplied I got curious so I had a look: yup, 100 mouse clicks and 
releases as expected.


user@host:~/Downloads$ fgrep ButtonPress paste_1190823 | wc -l
100
user@host:~/Downloads$ fgrep ButtonRelease paste_1190823 | wc -l
100

   -- Chris

--
Chris Knadle
chris.kna...@coredump.us

Bug#985860: regexp.c: change format from "%d" to "%ld" for the output of a difference of two pointers of type character

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From e8fd7ed864784608ffc0db2955271c8a24e9f8a8 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Thu, 25 Mar 2021 01:26:35 +
>Subject: [PATCH] regexp.c: change format from "%d" to "%ld" for the output of
> a difference of two pointers of type character

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

diff --git a/regexp.c b/regexp.c
index 316743e..9db173f 100644
--- a/regexp.c
+++ b/regexp.c
@@ -1086,12 +1086,12 @@ regdump(regexp * r)
 s = r->program + 1;
 while (op != END) {/* While that wasn't END last time... */
op = OP(s);
-   printf("%2d%s", s - r->program, regprop(s));/* Where, what. */
+   printf("%2ld%s", s - r->program, regprop(s));   /* Where, what. */
next = regnext(s);
if (next == NULL)   /* Next ptr. */
printf("(0)");
else
-   printf("(%d)", (s - r->program) + (next - s));
+   printf("(%ld)", (s - r->program) + (next - s));
s += 3;
if (op == ANYOF || op == ANYBUT || op == EXACTLY) {
/* Literal string, where present. */
-- 
2.30.2



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

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

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#985634: git (1:2.31.0-1): no longer runs addons from /usr/lib/git-core breaking lots of 3rdpty stuff

[Thorsten Glaser]

Dixi quod…

>I imagine *many* other third-party addons do the same. Please
>make git search the old location after the new one (preferred)

Uhm, ping?

Bug#985858: Fails to start with seccomp violation (eventfd2)

[peter green]

I've prepared a patch that allows additional syscalls on some
architectures and pushed it to a branch in the debcargo-conf repo.


Rust-sniffglue is not a key package, so as I see it you have two
possible ways forward here.

The first is to upload the package as-is and file an unblock
request justifying your changes to the release team.

The second is to fix the autopkgtest. It's currently "neutral"
due to a dependency on rust-boxxy which is not present in
Debian. From taking a quick look it looks to me like any
tests that rely on boxxy could probablly be patched out and
the dev-dependency dropped to allow the remainder of the
testsuite to run.

Bug#979592: RFS: openrct2/0.3.3+ds-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2

[Mathias Gibbens]

On Wed, 2021-03-24 at 07:58 +0200, Andrius Merkys wrote:
> owner 979592 !
> owner 985806 !
> owner 985807 !
> thanks
> 
> Hi Mathias,
> 
> On 2021-03-24 03:47, Mathias Gibbens wrote:
> > retitle 979592 RFS: openrct2/0.3.3+ds-1 [ITP] -- Open-source re-
> > implementation of RollerCoaster Tycoon 2
> > thanks
> > 
> >   I have uploaded a revised version of openrct2 to mentors.d.n:
> > 
> >dget -x 
> > https://mentors.debian.net/debian/pool/contrib/o/openrct2/openrct2_0.3.3+ds-1.dsc
> > 
> >   Packaging changes since my previous upload can be viewed on
> > salsa:
> > https://salsa.debian.org/gibmat/openrct2/-/commit/5856cfd2595580d4873b71c4dbfa7955729ecebd
> > 
> >   I have also started two related RFS bugs for openrct2-objects and
> > openrct2-title-sequences:
> > 
> >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985806
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985807
> 
> I will happily sponsor all three packages. I have cloned out your
> packaging repositories and gave the packaging a look. There are a
> couple
> minor issues:

  Thanks! Fixes for the issues you spotted are done for all three
packages, as needed.

> 
> 1. In debian/upstream/metadata, Bug-Database value has to be an URL.
> Most likely these will be GitHub issue trackers, in particular, links
> ending with '/issues' (spotted in openrct2-objects).

  Oops, that's an embarrassing copy-n-paste mistake -- fixed.

> 
> 2. In debian/upstream/metadata, Bug-Submit value has unneeded
> '/choose'
> (spotted in openrct2-objects).

  Fixed.

> 
> 3. Upstream copyright entry in debian/copyright lacks years. If the
> upstream do not limit their copyright in years, I usually take the
> year
> range spanning commits in the upstream Git repository (spotted in
> openrct2-objects).

  OK, I've done as you suggest and looked at the git history to put
some years in the d/copyright file.

> 
> 4. In debian/rules of openrct2-title-sequences, there is a hard-coded
> upstream version of the package. This may easily get forgotten when
> packaging new upstream versions. I suggest replacing the hard-coded
> version with $(DEB_VERSION_UPSTREAM) from /usr/share/dpkg/pkg-
> info.mk,
> see [1] for example.

  That is indeed a nicer way to get the version. The upstream
developers have released a few revisions of the current "version" that
have a sequential letter appended, but the actual path for some of the
files doesn't have that extra letter in it. I've updated the shell
script so there's no longer a hard-coded value.

> 
> You have indicated that you are going to be the sole maintainer for
> the
> packages, which is OK. But have you considered team-maintaining your
> packages in Debian Games Team? Team maintenance has its advantages,
> for
> example, team members would be able to commit and upload the packages
> fixing bugs and uploading new upstream versions. But of course the
> choice to team-maintain or not is yours.

  For now I'm planning to be the sole maintainer, but I'd be happy to
eventually transition to a team setup as well. Beyond just getting
openrct2 into Debian, I wanted to do all the work myself for the
learning experience, and after going through the process of releasing
updated versions as they become available once or twice, I'd be fine
with bringing things under a team umbrella.

> 
> [1] https://sources.debian.org/src/byteman/4.0.12-2/debian/rules/
> 
> Best,
> Andrius
> 

  I uploaded new versions of all three packages to mentors.d.n, and
pushed corresponding commits with the changes to the repositories:


https://salsa.debian.org/gibmat/openrct2/-/commit/8bb65232c57b63c9ca18912772e4e78742a7cff7

https://salsa.debian.org/gibmat/openrct2-objects/-/commit/4e67cc2bac4b263c4a74c889923d2ba0e2f8effb

https://salsa.debian.org/gibmat/openrct2-title-sequences/-/commit/8bbc6367390dd14e063fceb0a1346306eb30fdb5

  If things are good, I believe the packages are ready. I've built them
locally for my buster system, and everything that I've tested is
working correctly.

  Also, once the packages are uploaded to NEW, I'll push a tag to each
repository to properly record which commit corresponds to the uploaded
version of each package.

Mathias


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

Bug#969174: firefox: FF80 broke webext-* add-ons on existing profiles and new profiles after three restarts

[Christoph Anton Mitterer]

On Wed, 2021-03-10 at 06:00 +0900, Mike Hommey wrote:
> This is not the same issue at all, and this is not new in FF80
> either.
> It has been this way for, essentially, ever. If you want to file a
> separate bug for this, fine, but piling on this unrelated bug, with
> all
> its history being unrelated to this, is not helpful.

Well it seemed pretty convincing that it's the same bug, given that
that behaviour has never occurred in all years of webext add-ons
before, where these were always active right from the start.


Anyway, it seems with FF87, Mozilla blessed people with further
goodness and the old bug is also back again... at least I see add-ons
like ublock or no-script ineffective, even though their icon is
displayed this time... but they seem to actually get re-enabled, when
one disables/enables them (I guess again, only in the very same
session).

Bug#985859: cpqarrayd - ship with bullseye? - no driver support

[Chris Hofstaedtler]

Source: cpqarrayd
Version: 2.3.6
Severity: serious

Linux upstream has removed the "cciss" driver in 4.14-rc1. cpqarrayd
needs the cciss driver to function.

I imagine we shouldn't ship software that did not work with buster's
kernel in bullseye.

Chris

Bug#985858: Fails to start with seccomp violation (eventfd2)

[kpcyrd]

Package: sniffglue
Version: 0.11.1-5+b1
Severity: grave

I've noticed it's currently not possible to use sniffglue due to seccomp
violations:

# sniffglue -vv
Bad system call (core dumped)
#

sniffglue uses a seccomp sandbox to allow-list a reduced set of syscalls
to attempt to mitigate the risk of exploitable bugs in the network
processing code.

Since the binary dynamically links to system libraries this may
occasionally cause problems if new syscalls are used in new versions of
those libraries.

This has happened with sniffglue and the libraries currently in debian
testing, I've prepared a patch that allows additional syscalls on some
architectures and pushed it to a branch in the debcargo-conf repo.

Bug#985857: RFP: libjs-bootstrap5 -- HTML, CSS and JS framework

[Yohann D'ANELLO]

Package: wnpp
Severity: wishlist

* Package name: libjs-bootstrap5
  Version : 5.0.0-beta3
  Upstream Author : The Bootstrap Authors 
* URL : https://getbootstrap.com/
* License : MIT
  Programming Lang: Javascript
  Description : HTML, CSS and JS framework

Bootstrap is well-known HTML, CSS and JS framework. The stable version
is the fourth version, which is currently provided by the package
libjs-bootstrap4 by Debian.
However, Bootstrap 5 is about to get released in a few months, and
developers might start developing their applications with this new
version. Providing the latest version in the unstable or experimental
repository (and maybe later in bullseye-backports) might be useful
in that way.
This bug is destinated to the Debian Javascript Maintainers.

Bug#985856: term.c: add "feature_test_macros(7)" definitions for "cfmakeraw()"

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 4e0602f24ba305bea39b7d5eba49d83931d618ab Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Wed, 24 Mar 2021 23:44:55 +
>Subject: [PATCH] term.c: add "feature_test_macros(7)" definitions for
> "cfmakeraw()"

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

diff --git a/term.c b/term.c
index 2cee711..9e305dd 100644
--- a/term.c
+++ b/term.c
@@ -4,6 +4,17 @@
  *
  * Terminal interface.
  */
+/* Needed for cfmakeraw() */
+#ifndef _DEFAULT_SOURCE
+#define _DEFAULT_SOURCE 1 /* for glibc >= 2.19 */
+#endif
+/* For glibc <= 2.19
+ *
+#ifndef _BSD_SOURCE
+#define _BSD_SOURCE 1
+#endif
+ *
+ */
 #define raw __curses__raw__
 #include 
 #include 
-- 
2.30.2



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

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

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#985855: unblock: nemo/4.8.6-1

[Norbert Preining]

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

Please unblock package nemo

[ Reason ]
The new upstream fixes a potential crash, the only relevant upstream
commit is
nemo-view.c: Partially revert b4d0318

This causes a segfault when a python extension keeps a reference to
the NemoWindow given in provider.get_file_items() to use in a callback
and the window is closed.

ref: #2686

This is not a fix, just a workaround for now to prevent a crash.


[ Impact ]
Possible crashes of nemo.

[ Tests ]
Manual testing on functionality and whether crashes can be reproduced.

[ Risks ]
Trivial code that removes a free.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


unblock nemo/4.8.6-1
diff -Nru nemo-4.8.5/debian/changelog nemo-4.8.6/debian/changelog
--- nemo-4.8.5/debian/changelog 2021-03-02 13:52:49.0 +0900
+++ nemo-4.8.6/debian/changelog 2021-03-13 07:47:45.0 +0900
@@ -1,3 +1,9 @@
+nemo (4.8.6-1) unstable; urgency=medium
+
+  * New upstream version 4.8.6
+
+ -- Norbert Preining   Sat, 13 Mar 2021 07:47:45 +0900
+
 nemo (4.8.5-1) unstable; urgency=medium
 
   [ Fabio Fantoni ]
diff -Nru nemo-4.8.5/meson.build nemo-4.8.6/meson.build
--- nemo-4.8.5/meson.build  2021-02-26 20:38:31.0 +0900
+++ nemo-4.8.6/meson.build  2021-03-05 22:57:48.0 +0900
@@ -1,7 +1,7 @@
 # Meson build file
 
 # https://github.com/linuxmint/nemo
-project('nemo', 'c', version: '4.8.5',
+project('nemo', 'c', version: '4.8.6',
   meson_version: '>=0.41.0'
 )
 
diff -Nru nemo-4.8.5/src/nemo-view.c nemo-4.8.6/src/nemo-view.c
--- nemo-4.8.5/src/nemo-view.c  2021-02-26 20:38:31.0 +0900
+++ nemo-4.8.6/src/nemo-view.c  2021-03-05 22:57:48.0 +0900
@@ -5852,8 +5852,6 @@
g_free (subdir);
}
 }
-
-g_clear_object ();
}
 }
 

Bug#985853: debian-installer: Whitespace before a commented line in preseed file causes line to be parsed

[Andrew McDonnell]

Package: debian-installer
Version: 20190702+deb10u8
Severity: important
Tags: d-i

In a preseed file I accidentally had a space before a comment character, which
caused my preseed to fail in unexpected ways. I could not find anythying that
stood out in the documentation (e.g.
https://www.debian.org/releases/buster/amd64/apbs04.en.html or
https://www.debian.org/releases/stable/amd64/apbs03.en.html) stating that this
would occur.

The specific example in my case looked like this:

#_preseed_V1
d-i debian-installer/locale string en_AU
d-i keyboard-configuration/xkb-keymap select us
d-i keymap select us
... etc ...
# Example of fetching a script to run
 #d-i preseed/run string http://10.1.2.3/my-script.sh


My install was hanging and when I entered a console and looked in the syslog,
it was attempting to access that script for which the IP address does not exist
on my network. I finally started to understand the problem when I did this, the
latter finally triggered a parse error in the installer console:

 #d-iWHATpreseed/run string http://10.1.2.3/my-script.sh


 #d-iWHATpreseed/runISstringHAPPENINGhttp://10.1.2.3/my-script.sh

at this point I saw the white space, removed it and the problem went away.

(I am also unsure whether "d-iWHAT" is also a bug or just some default applying
if the item owner is not found)

So I guess that either
- whitespace is disallowed before a comment character and this should be added
to https://www.debian.org/releases/stable/amd64/apbs03.en.html - it mentioned
whitespace between fields but not at the start of a line
- this is a bug



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

Kernel: Linux 5.8.0-36-lowlatency (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#985851: term.c: comment out a redeclaration of "getenv()"

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 38b6313a8f4d991b728260b6c59eb6d97b37a9fb Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Wed, 24 Mar 2021 19:54:26 +
>Subject: [PATCH] term.c: comment out a redeclaration of "getenv()"

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

diff --git a/term.c b/term.c
index 4bbafec..2cee711 100644
--- a/term.c
+++ b/term.c
@@ -240,7 +240,7 @@ static int *nonsp;  /* number of non-space 
characters on line */
 
 #ifdef TERM_DEBUG
 static char*term_debug = NULL;
-extern char*getenv();
+/*extern char*getenv();*/ /* Is declared in  */
 #define curxy_nonsp(curxy_l < 0 ? -1 : nonsp[curxy_l])
 #endif
 
-- 
2.30.2



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

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

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#985852: nn.c: comment out the absent function "mal_debug()"

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From d5b355b2c193ef3fd5430e9d3f4057618a2a1c92 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Wed, 24 Mar 2021 20:37:58 +
>Subject: [PATCH] nn.c: comment out the absent function "mal_debug()"

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

diff --git a/nn.c b/nn.c
index 8576046..6f3ebb8 100644
--- a/nn.c
+++ b/nn.c
@@ -774,9 +774,13 @@ main(int argc, char *argv[])
 
 #endif
 
+/*
+ *  The function "mal_debug()" does not exist in this software, "nn".
 #ifdef MALDEBUG
 mal_debug(getenv("MALDEBUG") ? atoi(getenv("MALDEBUG")) : 0);
 #endif
+ *
+ */
 
 pname = program_name(argv);
 
-- 
2.30.2



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

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

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#985850: RFS: filezilla/3.53.1-1 [Team] -- Full-featured graphical FTP/FTPS/SFTP client

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: filezilla
   Version : 3.53.1-1
   Upstream Author : Tim Kosse 
 * URL : https://filezilla-project.org/
 * License : BSD-like, CC0-1.0, GPL-2+, permissive, MIT
 * Vcs : https://salsa.debian.org/debian/filezilla
   Section : net

It builds those binary packages:

  filezilla-common - Architecture independent files for filezilla
  filezilla - Full-featured graphical FTP/FTPS/SFTP client

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.53.1-1.dsc

Changes since the last upload:

 filezilla (3.53.1-1) experimental; urgency=medium
 .
   * Team upload
   * New upstream version 3.53.1

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#985849: kde-plasma-desktop: Task Manager (in panel) forgets settings after logout (reload)

[Otto Richter]

Package: kde-plasma-desktop
Version: 5:111
Severity: normal

Dear Maintainer,

Changing the settings of my task manager in the default kde panel is not 
preserved over logout / login.

I configured, for example, that middle-click closes an application /
group, but I always and up with the default of spawning a new instance
again.
Also, I added a second panel with a second task manager on my second
screen and it applied some default pinned entries there. I unpinned
them, but they reappear after every login.

I installed debian stable yesterday and upgraded to testing as described
in the wiki. I did not do major configurations to the system, most of
the stuff is pretty much "as-is" and configured via the GUI.

You can probably guess that such a behaviour is a little bit annoying
when you don't want to live with the default settings.
Thank you very much for checking out this report.


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

Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kde-plasma-desktop depends on:
ii kde-baseapps 4:20.12.0+5.111
ii plasma-desktop 4:5.20.5-4
ii plasma-workspace 4:5.20.5-5
ii udisks2 2.9.2-1
ii upower 0.99.11-2

Versions of packages kde-plasma-desktop recommends:
ii kwin-x11 4:5.20.5-1
ii sddm 0.19.0-2
ii xserver-xorg 1:7.7+22

Versions of packages kde-plasma-desktop suggests:
ii kdeconnect 20.12.3-1

-- no debconf information

Bug#985848: RFS: xpenguins/3.2.1-1 -- little penguins walk on your windows

[Micheal Waltz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: xpenguins
   Version : 3.2.1-1
   Upstream Author : Willem Vermin 
 * URL : 
https://www.ratrabbit.nl/ratrabbit/software/xpenguins/index.html
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/games-team/xpenguins
   Section : games

It builds those binary packages:

  xpenguins - little penguins walk on your windows

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/x/xpenguins/xpenguins_3.2.1-1.dsc

Changes since the last upload:

 xpenguins (3.2.1-1) unstable; urgency=medium
 .
   * New upstream version 3.2.1
   * Update standards to 4.5.1 and compat to 13

-- 
Micheal Waltz
https://keybase.io/ecliptik
GPG Fingerprint: 5F70 F2AC BD58 F580 DF15  3D1F 4FA2 70F5 CD36 71F9


signature.asc
Description: PGP signature

Bug#985339: nauty: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andrius Merkys]

Hello,

On 2021-03-24 15:58, Torrance, Douglas wrote:
> Has there been any progress on this bug?  I'm not sure how to reproduce
> it, but I'd be happy to help in any way that I can.  nauty and its
> reverse dependencies have been marked for auto-removal on Apr. 29
> because of it.

I managed to reproduce the bug by running piuparts locally:

$ sudo piuparts --scriptsdir /etc/piuparts/scripts-multi-distro-upgrade
-d jessie -d stretch -d buster -d bullseye --apt libnauty-dev=None
--no-eatmydata --mirror http://ftp.de.debian.org/debian --keyring
keyring-with-jessie-key.gpg

However, I am not sure how to proceed next. In principle I could tinker
with maintscripts, but I am not sure how to instruct piuparts to pick my
.deb instead of what is already present in bullseye.

I will come back to this later.

Andrius

Bug#985446: release-notes: cgroupv2 is the default cgroup hierarchy

[Thomas Goirand]

Hi,

A quick draft for the release notes:
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/72

Feel free to rewrite / reword if you feel I've done a poor job (I'm not
proud), or simply rewrite it all if you think you can do better. But if
nobody else does the job better, please do merge.

Cheers,

Thomas Goirand (zigo)

Bug#959022: cgroup-tools: does not work in cgroup2 / unified hierarchy

[Paul Gevers]

Hi all,

For documentation, I log our IRC conversation here.

[20:24:27]  elbrus et al: just in case you have already seen
santiago_ 's email: what's your thought on #959022
[20:24:38] [zwiebelbot] Debian#959022: cgroup-tools: does not work in
cgroup2 / unified hierarchy - https://bugs.debian.org/959022
[20:26:24]  do you lean towards getting libcgroup updated to
support cgroupv2 or documenting in the release notes that rdeps of
libcgroup will have to switch to the old cgroupv1 setup if they need
this functionality?
[20:29:13] -*- bunk looks at
https://tracker.debian.org/news/1236679/accepted-clsync-045-2-source-into-unstable/
and wonders whether the remaining 3 rdeps should/can also drop
dependencies in the latter case.
[20:31:24]  I think zigo said cinder needs it
[20:32:10]  no idea what that is, but I understand it's part of
the OpenStack stack?
[20:33:25] -*- bunk wonders whether there is a reviewable change for the
"fix by adding/packporting cgroupv2" option, since that would IMHO sound
better than documenting manual changes in the release notes
[20:34:50]  elbrus: good question. It sounds more like,
cinder can use cgroup in certain configurations. Not sure if it's really
a hard dependency
[20:35:55]  Then again, I don't really know OpenStack either.
zigo_ are you around?
[20:38:27]  mbiebl[m]: so any user of any of these rdeps would
need to run their full system in an "less supported" way?
[20:38:46]  sounds ... not ideal
[20:38:55]  elbrus: yeah, it's an all-or-nothing setting
[20:39:01]  boo
[20:39:40]  right, this makes me a bit nervous. I'm not sure
where cgroupv1 support will be 3 years down the lane
[20:40:03]  I can imagine that systemd upstream won't have
any interest in bugs that might result of it
[20:40:04]  security risks?
[20:40:14]  or just bugs?
[20:41:02]  by the way, I'll probably copy/paste this discussion
in the bug unless anybody objects
[20:41:11]  hm, not sure if it has security implications
[20:41:46]  and what's the amount of updates systemd normally
gets in the release?
[20:41:47]  I can tell you in 3 years :-)
[20:41:56]  obviously ;)
[20:42:26]  but I mean, do you consider this a risky surface, or
is it most likely OK?
[20:46:21]  cinder using libcgroup to configure I/O bandwidth
looks like optional functionality already present upstream in buster but
only enabled in bullseye.
[20:46:51]  elbrus: AFAIU the cgroup stuff is mostly resource
control, so not security critical.  But by bookworm people should
probably finish migration to cgroupv2...
[20:46:57]  booting with hybrid/cgroupv1 probably works ok
(still).
[20:46:57]  But a/ you first need to know, that you have to
fiddle with grub / kernel command line settings to make it work
[20:46:57]  I'mf not sure if the error messages in
cinder/OpenStack give any clue what the problem is
[20:47:30]  and b/ I'd prefer if all users just would use
cgroupv2, as this makes it easier for me as systemd maintainer
[20:48:10]  ansgar: I don't think there's a question about
bookworm :)
[20:48:13]  From #d-systemd yesterday: "cgcreate: libcgroup
initialization failed: Cgroup is not mounted" seems to be the error
message from cgcreate (which cinder calls)
[20:49:24]  Maybe it's easy to patch relevant places in
cgroup-tools to include some Debian-specific note pointing to the kernel
command-line arguments or some README file?
[20:49:29]  then we should ask zigo to disable that new option?
[20:49:54]  thanks ansgar
[20:50:16]  (I have no idea how discoverable these messages are
to users if it's some other tool calling cgcreate.)
[20:50:51]  I guess the only really relevant rdep of
libcgroup is cinder i.e. the OpenStack suite
[20:50:53]  elbrus: Cinder uses "cgcreate" from cgroupv1 to do
block device QoS, so yeah, we need to document the kernel command line
parameters and keep cgroups v1 around if possible.
[20:51:12]  elbrus: I did test the command line arguments that I
documented in the bug, and it does work perfectly.
[20:51:19]  zigo: I read the bug
[20:51:47]  FSVO perfectly
[20:52:06]  the maintainer of systemd disagrees about it being
perfectly supported
[20:52:19]  nova looks similar to cinder?
[20:52:29]  then there's mininet
[20:52:52]  mininet is a leaf package
[20:53:47]  cinder looks like that too (at least on popcon)
[20:54:21]  (sorry, not leaf, didn't check that)
[20:54:26]  as said, I'm not really familiar with the
OpenStack suite of software
[20:55:03]  so I don't know if cinder is actually entirely
optional (my understanding was, it isn't)
[20:56:05]  IMHO plan A would be if santiago would have a
reasonable package to update cgroup-tools (there is some preliminary
package mentioned in the bug)
[20:56:32]  The thing to write in the command line is:
[20:56:32]  systemd.unified_cgroup_hierarchy=false
systemd.legacy_systemd_cgroup_controller=false
[20:56:49]  With it, cgroups v1 is mounted somewhere in /sys.
[20:57:04]  "new upstream version" sounds better than "keep the
old version that requires manual kernel commandline 

Bug#651783: libpcap0.8: libpcap should be linked with libnl

[Steev Klimaszewski]

Hi Romain,

It has been a "few" years since this bug has seen much action, and I
would like to inquire about the possibility of enabling this now that
libnl-1 and libnl-2 seem to be gone.

There is a project called Nzyme (http://nzyme.org) and it depends on
libpcap being able to put a device into monitor mode.  This doesn't
happen if libpcap is not built against libnl, and there's no indication
of why, unfortunately.  You can test this without having to go through
setting up nzyme with the very simple "tcpdump -I -i wlan0" - it simply
spits out that the device does not support monitor mode.

I did a test here locally, and it seems like libnl is an automagic dep,
so simply having the libnl-genl-3-dev package installed at the time of
building causes it to link against it.  I have tested that it works and
does what is expected of it; both "tcpdump -I -i wlan0" work properly as
well as nzyme.

One thing I didn't look into, is whether libnl is available on the other
architectures - in Kali we only support amd64/i386/arm{el,hf}/arm64 so
I'm not sure how it affects hurd or kfreebsd.

-- steev

Bug#979343: sddm: general protection fault in libQt5Qml.so.5.15.2

[Helge Kreutzmann]

Hello all,
On Mon, Mar 22, 2021 at 10:29:18AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On Sun, 21 Mar 2021 at 02:12, Helge Kreutzmann  wrote:
> >
> > Hello Bernhard,
> > On Sun, Mar 21, 2021 at 01:59:34AM +0100, Bernhard Übelacker wrote:
> > > Am 20.03.21 um 21:44 schrieb Helge Kreutzmann:
> > > > If I should install a -dbg version or something else please
> > > > inform me.
> > >
> > > Thank you for the additional information.
> > > There might really be something more. If you have not, is it possible
> > > to install the package "systemd-coredump".
> > >
> > > If then a crash happens again and it gets recorded it should
> > > be mentioned in journalctl and this command should list them:
> > > coredumpctl list
> > > And a core should be stored. (But maybe just for the current boot)
> > >
> > > There should be already a slight backtrace in journalctl
> > > that might be helpful, but with 'coredumpctl gdb' and at the gdb
> > > prompt with 'bt' it might reveal some more information.
> > > Even better when sddm-dbgsym is installed, and if sufficiently RAM is
> > > available, libqt5qml5-dbgsym. (and some more not yet known in between ...)
> 
> Add libqt5core5a-dbgsym, as it's the basic package every Qt app relies on.

I added it, and now I got one:
Tue 2021-03-23 20:20:40 CET2000   109   115  11 present 
/usr/bin/sddm-greeter 

If I extract it, I get:
Executable: /usr/bin/sddm-greeter
 Control Group: /user.slice/user-109.slice/session-2.scope
  Unit: session-2.scope
 Slice: user-109.slice
   Session: 2
 Owner UID: 109 (sddm)
   Boot ID: 55dcd237fc794d05a6946fe117d23b60
Machine ID: b25779ab94cf4c318e85f954d3dd3acc
  Hostname: samd
   Storage: 
/var/lib/systemd/coredump/core.sddm-greeter.109.55dcd237fc794d05a6946fe117d23b60.2000.161652723800.zst
   Message: Process 2000 (sddm-greeter) of user 109 dumped core.

Stack trace of thread 2000:
#0  0x7fe7b5523ec7 _ZNK9QMetaType8destructEPv 
(libQt5Qml.so.5 + 0x2d3ec7)
#1  0x7fe7b52fa55f 
_ZN3QV45Chunk5sweepEPNS_15ExecutionEngineE (libQt5Qml.so.5 + 0xaa55f)
#2  0x7fe7b52fa7f3 operator() (libQt5Qml.so.5 + 0xaa7f3)
#3  0x7fe7b52fb415 _ZN3QV413MemoryManager5sweepEbPFvPKcE 
(libQt5Qml.so.5 + 0xab415)
#4  0x7fe7b52fbf2d _ZN3QV413MemoryManager5runGCEv 
(libQt5Qml.so.5 + 0xabf2d)
#5  0x7fe7b52fddb5 
_ZN3QV413MemoryManager8allocateEPNS_14BlockAllocatorEm (libQt5Qml.so.5 + 
0xaddb5)
#6  0x7fe7b536418e 
_ZN3QV413MemoryManager19allocWithStringDataINS_6StringE7QStringEEPNT_4DataEmT0_ 
(libQt5Qml.so.5 + 0x11418e)
#7  0x7fe7b539f688 
_ZN3QV414ErrorPrototype15method_toStringEPKNS_14FunctionObjectEPKNS_5ValueES6_i 
(libQt5Qml.so.5 + 0x14f688)
#8  0x7fe7b541706f 
_ZNK3QV414FunctionObject4callEPKNS_5ValueES3_i (libQt5Qml.so.5 + 0x1c706f)
#9  0x7fe7b5417394 
_ZN3QV414RuntimeHelpers18objectDefaultValueEPKNS_6ObjectEi (libQt5Qml.so.5 + 
0x1c7394)
#10 0x7fe7b541bd75 
_ZN3QV414RuntimeHelpers11toPrimitiveERKNS_5ValueENS_8TypeHintE (libQt5Qml.so.5 
+ 0x1cbd75)
#11 0x7fe7b536d5de 
_ZN3QV415ExecutionEngine24catchExceptionAsQmlErrorEv (libQt5Qml.so.5 + 0x11d5de)
#12 0x7fe7b5518412 
_ZN16QQmlDelayedError24catchJavaScriptExceptionEPN3QV415ExecutionEngineE 
(libQt5Qml.so.5 + 0x2c8412)
#13 0x7fe7b551d4c4 _ZN11QQmlBinding8evaluateEPb 
(libQt5Qml.so.5 + 0x2cd4c4)
#14 0x7fe7b5521367 
_ZN21QQmlNonbindingBinding8doUpdateERKN24QQmlJavaScriptExpression13DeleteWatcherE6QFlagsIN16QQmlPropertyData9WriteFlagEERN3QV45ScopeE
 (libQt5Qml.so.5 + 0x2d1367)
#15 0x7fe7b551f144 
_ZN11QQmlBinding6updateE6QFlagsIN16QQmlPropertyData9WriteFlagEE (libQt5Qml.so.5 
+ 0x2cf144)
#16 0x7fe7b54fc1ad 
_ZN12QQmlNotifier10emitNotifyEP20QQmlNotifierEndpointPPv (libQt5Qml.so.5 + 
0x2ac1ad)
#17 0x7fe7b47940d5 _Z10doActivateILb0EEvP7QObjectiPPv 
(libQt5Core.so.5 + 0x2e40d5)
#18 0x7fe7b4794546 
_ZN9QtPrivate15QSlotObjectBase4callEP7QObjectPPv (libQt5Core.so.5 + 0x2e4546)
#19 0x7fe7b478d94f _ZN7QObject9destroyedEPS_ 
(libQt5Core.so.5 + 0x2dd94f)
#20 0x7fe7b47928cd _ZN7QObjectD2Ev (libQt5Core.so.5 + 
0x2e28cd)
#21 0x7fe7b41364d7 n/a (libc.so.6 + 0x3e4d7)
#22 0x7fe7b413667a exit (libc.so.6 + 0x3e67a)
#23 0x7fe7b411ed11 __libc_start_main (libc.so.6 + 0x26d11)
#24 0x56346320e04a _start (sddm-greeter + 0x1b04a)

Stack trace of thread 2359:
#0  0x7fe7b41eb3ff __poll (libc.so.6 + 0xf33ff)
#1  0x7fe7b31ca0ae n/a (libglib-2.0.so.0 + 0x520ae)
#2  0x7fe7b31ca1cf g_main_context_iteration 

Bug#985847: #985847 is fixed-upstream

[Ryutaroh Matsumoto]

Control: tags -1 + fixed-upstream

#985847 is fixed in upstream by
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1798

Ryutaroh

Bug#985847: libmutter-7-0: gnome-shell with wayland shows deformed output with v3d.ko

[Ryutaroh Matsumoto]

Package: libmutter-7-0
Version: 3.38.4-1
Severity: important
Tags: upstream sid bullseye
Control: forwarded -1 https://gitlab.gnome.org/GNOME/mutter/-/issues/1520

Dear Maintainer,

Gnome shell with wayland shows deformed output as shown in
https://gitlab.gnome.org/GNOME/mutter/-/issues/1520
I confirmed that the symptom also appears with Firefox in Debian Bullseye.

This symptom does not happen with weston with Xwayland.
Related Ubuntu bug report at
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1896171

I wish some fix will be included in Bullseye Updates...

Best regards, Ryutaroh Matsumoto


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

Kernel: Linux 5.10.17-v8+ (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
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 libmutter-7-0 depends on:
ii  adwaita-icon-theme 3.38.0-1
ii  gsettings-desktop-schemas  3.38.0-2
ii  libatk1.0-02.36.0-2
ii  libc6  2.31-10
ii  libcairo-gobject2  1.16.0-5
ii  libcairo2  1.16.0-5
ii  libcanberra0   0.30-7
ii  libdrm22.4.104-1
ii  libegl11.3.2-1
ii  libfontconfig1 2.13.1-4.2
ii  libfribidi01.0.8-2
ii  libgbm120.3.4-1
ii  libgdk-pixbuf-2.0-02.42.2+dfsg-1
ii  libgl1 1.3.2-1
ii  libglib2.0-0   2.66.8-1
ii  libgnome-desktop-3-19  3.38.5-1
ii  libgraphene-1.0-0  1.10.4+dfsg1-1
ii  libgtk-3-0 3.24.24-3
ii  libgudev-1.0-0 234-1
ii  libice62:1.0.10-1
ii  libinput10 1.16.4-3
ii  libjson-glib-1.0-0 1.6.2-1
ii  libpango-1.0-0 1.46.2-3
ii  libpangocairo-1.0-01.46.2-3
ii  libpangoft2-1.0-0  1.46.2-3
ii  libpipewire-0.3-0  0.3.19-4
ii  libsm6 2:1.2.3-1
ii  libstartup-notification0   0.12-6+b1
ii  libsystemd0247.3-3
ii  libudev1   247.3-3
ii  libwacom2  1.8-2
ii  libwayland-server0 1.19.0-2
ii  libx11-6   2:1.7.0-2
ii  libx11-xcb12:1.7.0-2
ii  libxau61:1.0.9-1
ii  libxcb-randr0  1.14-3
ii  libxcb-res01.14-3
ii  libxcb11.14-3
ii  libxcomposite1 1:0.4.5-1
ii  libxcursor11:1.2.0-2
ii  libxdamage11:1.1.5-2
ii  libxext6   2:1.3.3-1.1
ii  libxfixes3 1:5.0.3-2
ii  libxi6 2:1.7.10-1
ii  libxinerama1   2:1.1.4-2
ii  libxkbcommon-x11-0 1.0.3-2
ii  libxkbcommon0  1.0.3-2
ii  libxkbfile11:1.1.0-1
ii  libxrandr2 2:1.5.1-1
ii  libxtst6   2:1.2.3-1
ii  mutter-common  3.38.4-1

libmutter-7-0 recommends no packages.

libmutter-7-0 suggests no packages.

Versions of packages libmutter-7-0 is related to:
ii  libegl-mesa0 [libegl-vendor]  20.3.4-1
ii  libgl1-mesa-dri   20.3.4-1
ii  libglx-mesa0 [libglx-vendor]  20.3.4-1

-- no debconf information

Bug#985846: RFP: elpa-org-present -- minimalist presentation tool for Emacs org-mode

[Martin]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-emac...@lists.debian.org

* Package name: elpa-org-present
  Version : git master
  Upstream Author : Ric Lister
* URL : https://github.com/rlister/org-present/
* License : GPL-2+
  Programming Lang: Emacs-Lisp
  Description : minimalist presentation tool for Emacs org-mode

This is meant to be an extremely minimalist presentation tool
for Emacs org-mode. Simply layout your presentation with each
slide under a top-level header, start the minor mode with
'org-present', and page through each slide with left/right keys.

Bug#985833: General: when searching repos I get an error message

[silverback]

Package: General
Severity: normal
X-Debbugs-Cc: 51lv3rb...@protonmail.com

Dear Maintainer,

After using the command apt search 'package_name' if the package can't be
found I get the following error message, when the error happened and every
other instance I have a good internet connection. I'm assuming that the
'unable to open database file' would mean there was no connection, am I right?

Sorry, command-not-found has crashed! Please file a bug report at:
http://www.debian.org/Bugs/Reporting
Please include the following information with the report:

command-not-found version: 0.3
Python version: 3.9.2 final 0
Distributor ID: Kali
Description:Kali GNU/Linux Rolling
Release:2021.1
Codename:   kali-rolling
Exception information:

unable to open database file
Traceback (most recent call last):
  File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in 
crash_guard
callback()
  File "/usr/lib/command-not-found", line 90, in main
cnf = CommandNotFound.CommandNotFound(options.data_dir)
  File "/usr/share/command-not-found/CommandNotFound/CommandNotFound.py", line 
79, in __init__
self.db = SqliteDatabase(dbpath)
  File "/usr/share/command-not-found/CommandNotFound/db/db.py", line 12, in 
__init__
self.con = sqlite3.connect(filename)
sqlite3.OperationalError: unable to open database file

-- System Information:
Distributor ID: Kali
Description:Kali GNU/Linux Rolling
Release:2021.1
Codename:   kali-rolling
Architecture: x86_64

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

Bug#985845: pgbouncer: Obsolete URL in README.Debian

[Ben Harris]

Package: pgbouncer
Version: 1.15.0-1
Severity: minor

Dear Maintainer,

/usr/share/doc/pgbouncer/README.Debian includes this:

General usage information can be found at
  http://wiki.postgresql.org/wiki/PgBouncer

However, that page now just says:

The information that used to be on this wiki page is contained on the
PgBouncer website (https://www.pgbouncer.org/).

The README.Debian file should be updated to link to that new URL.

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

Kernel: Linux 5.10.0-4-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pgbouncer depends on:
ii  libc-ares2 1.17.1-1
ii  libc6  2.31-9
ii  libevent-2.1-7 2.1.12-stable-1
ii  libpam0g   1.4.0-6
ii  libssl1.1  1.1.1j-1
ii  lsb-base   11.1.0
ii  postgresql-common  225

pgbouncer recommends no packages.

Versions of packages pgbouncer suggests:
ii  python3   3.9.2-2
ii  python3-psycopg2  2.8.6-2

-- Configuration Files:
/etc/pgbouncer/pgbouncer.ini [Errno 13] Permission denied: 
'/etc/pgbouncer/pgbouncer.ini'
/etc/pgbouncer/userlist.txt [Errno 13] Permission denied: 
'/etc/pgbouncer/userlist.txt'

-- no debconf information

--
Ben Harris, University of Cambridge Information Services.

Bug#945337: why is the version from elpa needed

[積丹尼 Dan Jacobson]

All I know is many bugs are fixed in the newer versions.
Fine.

Bug#969264: firmware-iwlwifi:

[maximilian attems]

tags 969264 moreinfo
stop

> Version: 20200721-1

> Wi-Fi connection has been behaving erratically, lots of lags - for
> instance - in LAN-SSH connections.

> $ lspci | grep "Network controller"
> 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205
> [Taylor Peak] (rev 34)

Is this reproducible with current Debian testing?

thank you for your report.

Bug#985844: nanopb: CVE-2021-21401

[Salvatore Bonaccorso]

Source: nanopb
Version: 0.4.4-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for nanopb.

CVE-2021-21401[0]:
| Nanopb is a small code-size Protocol Buffers implementation in ansi C.
| In Nanopb before versions 0.3.9.8 and 0.4.5, decoding a specifically
| formed message can cause invalid `free()` or `realloc()` calls if the
| message type contains an `oneof` field, and the `oneof` directly
| contains both a pointer field and a non-pointer field. If the message
| data first contains the non-pointer field and then the pointer field,
| the data of the non-pointer field is incorrectly treated as if it was
| a pointer value. Such message data rarely occurs in normal messages,
| but it is a concern when untrusted data is parsed. This has been fixed
| in versions 0.3.9.8 and 0.4.5. See referenced GitHub Security Advisory
| for more information including workarounds.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-21401
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21401
[1] https://github.com/nanopb/nanopb/security/advisories/GHSA-7mv5-5mxh-qg88

Regards,
Salvatore

Bug#985832: installation report: netboot debian-installer kernel too old

[Anhu]

Package: installation-reports

Boot method: network
Image version:
http://ftp.debian.org/debian/dists/bullseye/main/installer-amd64/current/images/netboot/debian-installer/amd64/linux
Date: 2021-03-11 ++

Machine: KVM
Processor: x86_64
Memory: 2 GB
Partitions: does not matter

Output of lspci -knn (or lspci -nn): does not matter

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [E]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

Installing bullseye via network fails since the (directory named)
_current_ debian-installer at

http://ftp.debian.org/debian/dists/bullseye/main/installer-amd64/current/images/netboot/debian-installer/amd64/linux

is a kernel 5.9.0-4-amd64:

# file linux
linux: Linux kernel x86 boot executable bzImage, version 5.9.0-4-amd64
(debian-ker...@lists.debian.org) #1 SMP Debian 5.9.11-1 (2020-11-27),
RO-rootFS, swap_dev 0x5, Normal VGA

... which does not match the more recent kernel (modules) in

http://ftp.debian.org:80/debian/dists/bullseye/main/debian-installer/binary-amd64/Packages.xz
.

which rather fit kernel-image-5.10.0-3-amd64.

The installation fails after 'download-installer' succeeded:

"WARNNG **: no packages matching running kernel 5.9.0-4-amd64 in archive"

Since we use Foreman for automatic installation, this bug blocks testing
of debian bullseye in our environment. Is it possible to automatically
create the netboot installer whenever a new kernel is available? Thanks!

Bug#985843: libxstream-java: CVE-2021-21341 CVE-2021-21342 CVE-2021-21343 CVE-2021-21344 CVE-2021-21345 CVE-2021-21346 CVE-2021-21347 CVE-2021-21348 CVE-2021-21349 CVE-2021-21350 CVE-2021-21351

[Salvatore Bonaccorso]

Source: libxstream-java
Version: 1.4.15-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for libxstream-java.

CVE-2021-21341[0]:
| XStream is a Java library to serialize objects to XML and back again.
| In XStream before version 1.4.16, there is vulnerability which may
| allow a remote attacker to allocate 100% CPU time on the target system
| depending on CPU type or parallel execution of such a payload
| resulting in a denial of service only by manipulating the processed
| input stream. No user is affected who followed the recommendation to
| setup XStream's security framework with a whitelist limited to the
| minimal required types. If you rely on XStream's default blacklist of
| the Security Framework, you will have to use at least version 1.4.16.


CVE-2021-21342[1]:
| XStream is a Java library to serialize objects to XML and back again.
| In XStream before version 1.4.16, there is a vulnerability where the
| processed stream at unmarshalling time contains type information to
| recreate the formerly written objects. XStream creates therefore new
| instances based on these type information. An attacker can manipulate
| the processed input stream and replace or inject objects, that result
| in a server-side forgery request. No user is affected, who followed
| the recommendation to setup XStream's security framework with a
| whitelist limited to the minimal required types. If you rely on
| XStream's default blacklist of the Security Framework, you will have
| to use at least version 1.4.16.


CVE-2021-21343[2]:
| XStream is a Java library to serialize objects to XML and back again.
| In XStream before version 1.4.16, there is a vulnerability where the
| processed stream at unmarshalling time contains type information to
| recreate the formerly written objects. XStream creates therefore new
| instances based on these type information. An attacker can manipulate
| the processed input stream and replace or inject objects, that result
| in the deletion of a file on the local host. No user is affected, who
| followed the recommendation to setup XStream's security framework with
| a whitelist limited to the minimal required types. If you rely on
| XStream's default blacklist of the Security Framework, you will have
| to use at least version 1.4.16.


CVE-2021-21344[3]:
| XStream is a Java library to serialize objects to XML and back again.
| In XStream before version 1.4.16, there is a vulnerability which may
| allow a remote attacker to load and execute arbitrary code from a
| remote host only by manipulating the processed input stream. No user
| is affected, who followed the recommendation to setup XStream's
| security framework with a whitelist limited to the minimal required
| types. If you rely on XStream's default blacklist of the Security
| Framework, you will have to use at least version 1.4.16.


CVE-2021-21345[4]:
| XStream is a Java library to serialize objects to XML and back again.
| In XStream before version 1.4.16, there is a vulnerability which may
| allow a remote attacker who has sufficient rights to execute commands
| of the host only by manipulating the processed input stream. No user
| is affected, who followed the recommendation to setup XStream's
| security framework with a whitelist limited to the minimal required
| types. If you rely on XStream's default blacklist of the Security
| Framework, you will have to use at least version 1.4.16.


CVE-2021-21346[5]:
| XStream is a Java library to serialize objects to XML and back again.
| In XStream before version 1.4.16, there is a vulnerability which may
| allow a remote attacker to load and execute arbitrary code from a
| remote host only by manipulating the processed input stream. No user
| is affected, who followed the recommendation to setup XStream's
| security framework with a whitelist limited to the minimal required
| types. If you rely on XStream's default blacklist of the Security
| Framework, you will have to use at least version 1.4.16.


CVE-2021-21347[6]:
| XStream is a Java library to serialize objects to XML and back again.
| In XStream before version 1.4.16, there is a vulnerability which may
| allow a remote attacker to load and execute arbitrary code from a
| remote host only by manipulating the processed input stream. No user
| is affected, who followed the recommendation to setup XStream's
| security framework with a whitelist limited to the minimal required
| types. If you rely on XStream's default blacklist of the Security
| Framework, you will have to use at least version 1.4.16.


CVE-2021-21348[7]:
| XStream is a Java library to serialize objects to XML and back again.
| In XStream before version 1.4.16, there is a vulnerability which may
| allow a remote attacker to occupy a thread that consumes maximum CPU
| time and will never return. No user is affected, who followed the
| recommendation to setup XStream's 

Bug#985842: solo-python: please clarify package description

[Daniele Forsi]

Package: solo-python
Severity: minor

Dear Maintainer,

package description says "rest the key" , is that a typo for "reset the key"?

thanks,
Daniele

Bug#985841: node-ssri: CVE-2021-27290

[Salvatore Bonaccorso]

Source: node-ssri
Version: 8.0.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for node-ssri.

CVE-2021-27290[0]:
| ssri 5.2.2-8.0.0, fixed in 8.0.1, processes SRIs using a regular
| expression which is vulnerable to a denial of service. Malicious SRIs
| could take an extremely long time to process, leading to denial of
| service. This issue only affects consumers using the strict option.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-27290
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27290
[1] https://github.com/npm/ssri/commit/76e223317d971

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#973529: firmware-atheros: Link wifi rate limited at 1MB/s

[MLHPUB]

Hi,

Unfortunately, family school use forced me re-install Windows on the 
computer :-/
But before that, I could notice a normal Wifi transfert rate back 
(according my AP capabilities) with only a wrong display information in 
KDE netwworking tool.


Regards,

Matthieu



Le 24/03/2021 à 11:14, maximilian attems a écrit :

tags 973529 moreinfo
stop


Version: 20200918-1


How about latest Debian testing version, is that still the case?


thank you.

Bug#984888: pam-mysql: Newly added test with 323 hashed passwords fail on s390x

[wferi]

Balint Reczey  writes:

> On Sun, Mar 14, 2021 at 3:49 PM  wrote:
>
>> Debugging suggests that the internal SHA-1 implementation does not work
>> on big-endian architectures.  The easy way out is switching to the
>> libcrypto implementation (the package already depends on libssl1.1 and
>> the PAM module links against libcrypto.so.1).  The hard way is finding
>> the bug and fixing it for arbitrary endianness.  I wonder which one the
>> Release Team prefers...
>
> I'm sure the Release Team would prefer using a well known SHA
> implementation rather than an internal one especially when the
> internal one proved to be broken.

Actually the fix is already uploaded, though debci hasn't tested it yet.
The internal implementation had the necessary conditional compilation
directives, but the corresponding Autoconf test was missing.  So a
one-line patch (already merged upstream) sufficed.  In the past I tried
to persuade upstream into dropping the internal crypto routines, but
the idea didn't get traction.
-- 
Cheers,
Feri

Bug#985840: gitlab-shell: should not ship /usr/bin/check

[Julien Cristau]

Package: gitlab-shell
Version: 13.13.0+debian-1+b1
Severity: serious

/usr/bin/check seems like an awfully generic program name to be shipped
in something like gitlab-shell.  Please don't.

Thanks,
Julien

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

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

Versions of packages gitlab-shell depends on:
ii  libc6  2.31-9

gitlab-shell recommends no packages.

gitlab-shell suggests no packages.

-- no debconf information

Bug#985839: term.c: reverse the addition of "#if def __osf__" around "cfmakeraw(_tty)" and add comments about it

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From f6a0c43e231b1347447fed67f3737d54162c0444 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Wed, 24 Mar 2021 17:46:57 +
>Subject: [PATCH] term.c: reverse the addition of "#if def __osf__" around
> "cfmakeraw(_tty)" and add comments about it

Signed-off-by: Bjarni Ingi Gislason 
---
 term.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/term.c b/term.c
index 670f542..4bbafec 100644
--- a/term.c
+++ b/term.c
@@ -672,10 +672,17 @@ init_term(int full)
 #else
 
 #ifdef HAVE_TERMIOS_H
-#  ifdef __osf__
 cfmakeraw(_tty);
-#  endif
+/*
+ *  cfmakeraw makes the following according to the man page "cfmakeraw(3)":
 
+termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | 
ICRNL | IXON);
+termios_p->c_oflag &= ~OPOST;
+termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN);
+termios_p->c_cflag &= ~(CSIZE | PARENB);
+termios_p->c_cflag |= CS8;
+ *
+*/
 /* read a maximum of 10 characters in one burst; timeout in 1-200 ms */
 raw_tty.c_cc[VMIN] = KEY_BURST;
 
-- 
2.30.2



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

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

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#985838: ITP: python-leidenalg -- Python3 implementation of the Leiden algorithm in C++

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: python-leidenalg -- Python3 implementation of the Leiden 
algorithm in C++
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: python-leidenalg
  Version : 0.8.3
  Upstream Author : Vincent Traag
* URL : https://github.com/vtraag/leidenalg
* License : GPL-3+
  Programming Lang: C
  Description : Python3 implementation of the Leiden algorithm in C++
 This package implements the Leiden algorithm in C++ and exposes it to
 Python. It relies on igraph for it to function. Besides the relative
 flexibility of the implementation, it also scales well, and can be run
 on graphs of millions of nodes (as long as they can fit in memory). The
 core function is find_partition which finds the optimal partition using
 the Leiden algorithm, which is an extension of the Louvain algorithm for
 a number of different methods. The methods currently implemented are
 .
  1. modularity,
  2. Reichardt and Bornholdt's model using the configuration null model
 and the Erdös-Rényi null model,
  3. the Constant Potts model (CPM),
  4. Significance and finally
  5. Surprise.
 .
 In addition, it supports multiplex partition optimisation allowing
 community detection on for example negative links or multiple time
 slices. There is the possibility of only partially optimising a
 partition, so that some community assignments remain fixed. It also
 provides some support for community detection on bipartite graphs.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/python-leidenalg

Bug#984888: pam-mysql: Newly added test with 323 hashed passwords fail on s390x

[Balint Reczey]

Hi,

On Sun, Mar 14, 2021 at 3:49 PM  wrote:
>
> Balint Reczey  writes:
>
> > Autopkgtests are failing in CI on s390x due to the following newly added 
> > tests:
> >
> > ...
> > OK: Y_MD5: correct password accepted
> > OK: Y_MD5: incorrect password refused
> > FAIL: mysql: correct password refused
> > OK: mysql: incorrect password refused
> > ...
>
> (It isn't the 323 variant that fails, but anyway...)
>
> Debugging suggests that the internal SHA-1 implementation does not work
> on big-endian architectures.  The easy way out is switching to the
> libcrypto implementation (the package already depends on libssl1.1 and
> the PAM module links against libcrypto.so.1).  The hard way is finding
> the bug and fixing it for arbitrary endianness.  I wonder which one the
> Release Team prefers...

I'm sure the Release Team would prefer using a well known SHA
implementation rather than an internal one especially when the
internal one proved to be broken.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#985837: document in README.source how README.Debian is generated from README.Debian.m4

[John Scott]

Source: gcc-defaults
Version: 4:11-20210116-1
Severity: wishlist

I wanted to send a merge request to clarify some language in
README.Debian, but there doesn't seem to be any information on how
README.Debian is generated from README.Debian.m4. The most intuitive
way would be with a call like
   debian/rules debian/README.Debian

but there is no such Make target.

It's hard for a newcomer to find their way around a complex package
like gcc-defaults without an up-to-date README.source, and it seems
like this is something that should be documented there.

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

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



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

Bug#985709: ibus-mozc: mozc-tool ignores KDE Qt theme

[Gunnar Hjalmarsson]

On 2021-03-24 14:37, Daniel T wrote:
Doing just `dpkg -i 
mozc-utils-gui_2.23.2815.102+dfsg-10build1_amd64.deb` does indeed solve 
the problem.


Thanks!

@Nobuhiro: Should this be reported upstream? I don't see anything about 
it in the upstream issue tracker.


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980905: fstrim: FITRIM ioctl failed: Device or resource busy on NTFS device

[Jochen Kellner]

Package: ntfs-3g
Version: 1:2017.3.23AR.3-3
Followup-For: Bug #980905

Dear Maintainer,

I'm running a buster system which also fails fstrim on ntfs-3g with a bpo 
kernel.
I've found this report for Arch Linux: https://bugs.archlinux.org/task/69600
This report references a backport of this kernel fix:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7e0815797656f029fab2edc309406cddf931b9d8

I've not compiled a kernel with this fix yet.

Should we reassign the report to the kernel package?

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

Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/16 CPU cores)
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 ntfs-3g depends on:
ii  fuse   2.9.9-1+deb10u1
ii  libc6  2.28-10
ii  libgcrypt201.8.4-5
ii  libgnutls303.6.7-4+deb10u6
ii  libgpg-error0  1.35-1
ii  libntfs-3g883  1:2017.3.23AR.3-3

ntfs-3g recommends no packages.

ntfs-3g suggests no packages.

-- no debconf information

Bug#985836: unblock: bluefish/2.2.12-1.1

[Boyuan Yang]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: by...@debian.org j...@debian.org
Severity: normal

Please unblock package bluefish

Current bluefish/2.2.12-1 is affected by RC bug
https://bugs.debian.org/983859 . A targeted fix was uploaded
as bluefish/2.2.12-1.1 to fix this problem.

[ Reason ]
Fix RC bug 983859 (bluefish: missing Breaks+Replaces on bluefish-data).

[ Impact ]
If the fix does not enter Bullseye, any user upgrading from Debian 10
to Debian 11 with bluefish and bluefish-data installed would encounter
issue when upgrading:

| Preparing to unpack .../032-bluefish_2.2.12-1+b1_amd64.deb ...
| Unpacking bluefish (2.2.12-1+b1) over (2.2.10-1) ...
| dpkg: error processing archive /tmp/apt-dpkg-install-m8WUj5/032-
bluefish_2.2.12-1+b1_amd64.deb (--unpack):
|  trying to overwrite '/usr/share/bluefish/jsbeautifier/__init__.py',
which is also in package bluefish-data 2.2.10-1
| Preparing to unpack .../033-bluefish-data_2.2.12-1_all.deb ...
| Unpacking bluefish-data (2.2.12-1) over (2.2.10-1) ...

[ Tests ]
Manual test was performed:

  * Install a fresh Debian 10 system
  * Install all binary packages provided by src:bluefish
  * Update sources.list to use current Sid repos
  * Do "apt install bluefish bluefish-data bluefish-plugins"

With old bluefish/2.2.12-1, the procedure above would fail.
With new bluefish/2.2.12-1.1, the procedure above finished
successfully.

[ Risks ]
No risk expected since the fix is pretty trivial.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
The fix was a NMU and the original maintainer has been
acknowledged (in CC list).

Full debdiff in attachment.


unblock bluefish/2.2.12-1.1

-- 
Regards,
Boyuan Yang
diff -Nru bluefish-2.2.12/debian/changelog bluefish-2.2.12/debian/changelog
--- bluefish-2.2.12/debian/changelog	2020-11-09 07:55:00.0 -0500
+++ bluefish-2.2.12/debian/changelog	2021-03-23 21:16:28.0 -0400
@@ -1,3 +1,11 @@
+bluefish (2.2.12-1.1) unstable; urgency=high
+
+  * Non-maintainer upload acknowledged by current maintainer.
+  * debian/control: Let package bluefish Breaks+Replaces bluefish-data
+(<< 2.2.12-1.1~). (Closes: #983859)
+
+ -- Boyuan Yang   Tue, 23 Mar 2021 21:16:28 -0400
+
 bluefish (2.2.12-1) unstable; urgency=medium
 
   [ Pino Toscano ]
diff -Nru bluefish-2.2.12/debian/control bluefish-2.2.12/debian/control
--- bluefish-2.2.12/debian/control	2020-11-09 07:53:54.0 -0500
+++ bluefish-2.2.12/debian/control	2021-03-23 21:16:28.0 -0400
@@ -39,6 +39,8 @@
   tidy,
   weblint-perl | weblint,
   www-browser
+Breaks: bluefish-data (<< 2.2.12-1.1~)
+Replaces: bluefish-data (<< 2.2.12-1.1~)
 Description: advanced Gtk+ text editor for web and software development
  Bluefish is a powerful editor targeted towards programmers and web
  developers, with many options to write websites, scripts and programming


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

Bug#984579: libgstreamer1.0-dev: leaves diversions after upgrade from buster

[Andreas Beckmann]

Followup-For: Bug #984579
Control: tag -1 patch
>From a0d35a50c03b23c9e24cccbc3b894cc8faf1b2c4 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Wed, 24 Mar 2021 13:27:03 +0100
Subject: [PATCH] remove obsolete diversions on upgrades from buster

---
 debian/changelog|  4 
 debian/libgstreamer1.0-dev.postinst | 10 ++
 2 files changed, 14 insertions(+)
 create mode 100644 debian/libgstreamer1.0-dev.postinst

diff --git a/debian/changelog b/debian/changelog
index 06fcaf93..4ba5e8e6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,7 +1,11 @@
 gstreamer1.0 (1.18.3-2) UNRELEASED; urgency=medium
 
+  [ Helmut Grohne ]
   * Annotate Build-Depends libgmp-dev and libgsl-dev  (Closes: 
#981203).
 
+  [ Andreas Beckmann ]
+  * Remove obsolete diversions on upgrades from buster (Closes: #984579).
+
  -- Helmut Grohne   Wed, 27 Jan 2021 17:11:51 +0100
 
 gstreamer1.0 (1.18.3-1) unstable; urgency=medium
diff --git a/debian/libgstreamer1.0-dev.postinst 
b/debian/libgstreamer1.0-dev.postinst
new file mode 100644
index ..1f4f2c9f
--- /dev/null
+++ b/debian/libgstreamer1.0-dev.postinst
@@ -0,0 +1,10 @@
+#!/bin/sh
+set -e
+
+if [ "$1" = "configure" ] && dpkg --compare-versions "$2" lt-nl "1.18.3-2~"
+then
+   dpkg-divert --package libgstreamer1.0-dev --rename --remove 
/usr/bin/dh_gstscancodecs
+   dpkg-divert --package libgstreamer1.0-dev --rename --remove 
/usr/share/man/man1/dh_gstscancodecs.1.gz
+fi
+
+#DEBHELPER#
-- 
2.20.1

Bug#984894: python-azure: flaky autopkgtest: You need to call 'result' or 'wait' on all LROPoller you have created

[Luca Boccassi]

Control: severity -1 important
Control: tags -1 unreproducible help

On Tue, 9 Mar 2021 20:51:00 +0100 Paul Gevers 
wrote:
> Source: python-azure
> Version: 20201208+git-3
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org

> Usertags: flaky
> 
> Dear maintainer(s),
> 
> Your package has an autopkgtest, great. However, I looked into
> the history of your autopkgtest [1] (because it is blocking
> sphinx) and I noticed it fails regularly, while a rerun passes. I
> copied some of the output at the bottom of this report.
> 
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are causing people unrelated to your package to spend time on these
> tests.
> 
> Paul
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-azure/10719743/log.gz

Hi,

Thanks for the report.

I have ran the sdk/resources/azure-mgmt-resource tests locally for ~30
times and unfortunately I am not able to reproduce the issue. Hence I'm
downgrading + adding tags for help - if anyone is able to reproduce or
spot the issue, a MR is more than welcome.
This particular module was also updated in -4 to solve an unrelated
issue, so it might very well be that this is solved too.

-- 
Kind regards,
Luca Boccassi


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

Bug#985362: mumble: Unhide after Minimize to tray flashes rapidly

[Jonathan Rubenstein]

Thank you for your reply, Chris.

This sounds like Mumble being brought out of being minimized and then minimizing 
again, as if there were either no or two mouse clicks; i.e. this sounds like a 
mouse button switch that's starting to go bad. I've had this happen to me, it 
leads to thinking of all kinds of things being broken that aren't.


I have right clicked on the mumble icon and hit "Show"—which should only 
ever allow one mouse click because it disappears—and still experience 
this issue even with that. This can also happen when running 'mumble' in 
a terminal with mumble already open and minimized to tray, or opening a 
desktop file.


I've also run xev and clicked the window 100 times, saving the log to a 
file[1]. This log contains no more and no less than exactly 100 mouse 
button down entries and 100 mouse button up entries.


My mouse is also very new, I got it under 2 months ago, a SteelSeries 
Rival 3.


So my first suggestion is to try changing mice to see if it's a mouse button 

problem,

I have briefly switched mice to my old one, and I have the same issue at 
the same reproduction rate.


and the second is to try adjust the mouse button timing in KDE settings 

(especially if you have done so recently).
I cannot find these settings in KDE 5, but as I can reproduce without 
using the mouse at all via a terminal or desktop file, I do not believe 
this will help.


At first glance I suspect this isn't a Mumble bug, or at least that if it does 
relate to Mumble directly that it doesn't happen on all desktop environments. I 
regularly use the "Hide in tray when minimized" feature but not on KDE.


I agree, it does not seem to happen on all desktop environments.


I have a Sid VM where I think I'll try adding KDE Plasma to for testing.


I can try in a VM as well. I'll also give it a go in some other DEs and WMs.


I hope my testing is satisfactory, let me know if I can do anything else.


[1]: https://paste.debian.net/1190823/

Bug#985835: alien incorrectly replicates filepaths

[Rich Ercolani]

Package: alien
Version: 8.95.3
Severity: important
Tags: patch
X-Debbugs-Cc: rincebr...@gmail.com

Dear Maintainer,

alien incorrectly copies files when it's generating packages on my system, 
resulting in packages
where instead of, say, /usr/include/... and /usr/sbin/..., it puts things in 
/include/... and 
/sbin/...

I've created a patch, which I'm not entirely happy with, that fixes it for the 
test case I was
reproducing it on (generating deb packages from the upstream zfsonlinux source 
packages, which
use alien to turn their generated rpms into debs).

Thanks,
- Rich Ercolani

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

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

Versions of packages alien depends on:
ii  cpio   2.13+dfsg-4
ii  debhelper  13.3.4
ii  dpkg-dev   1.20.7.1
ii  make   4.3-4
ii  perl   5.32.1-3
ii  rpm4.16.1.2+dfsg1-0.4
ii  rpm2cpio   4.16.1.2+dfsg1-0.4

alien recommends no packages.

Versions of packages alien suggests:
ii  bzip21.0.8-4
pn  lintian  
ii  patch2.7.6-7
ii  xz-utils [lzma]  5.2.5-1.0

-- no debconf information
--- Alien/Package/Deb.pm.aside  2021-03-24 12:46:48.445705086 -0400
+++ Alien/Package/Deb.pm2021-03-24 12:46:54.829597635 -0400
@@ -482,9 +482,11 @@
 override_dh_auto_build:
 
 override_dh_auto_install:
+   mkdir -p debian/\$(PACKAGE)
# Copy the packages's files.
find . -maxdepth 1 -mindepth 1 -not -name debian -print0 | \\
-   xargs -0 -r -i cp -a {} debian/\$(PACKAGE)
+   sed -e s#'./'##g | \\
+   xargs -0 -r -i cp -a ./{} debian/\$(PACKAGE)/{}
 #
 # If you need to move files around in debian/\$(PACKAGE) or do some
 # binary patching, do it here

Bug#985834: ancient-maintscript-entry should mention when last relevant version was

[Jelmer Vernooij]

X-Debbugs-Cc: raph...@offensive-security.com
Package: lintian-brush
Version: 0.101
Severity: minor

Raphael writes:

> I noticed a case where lintian-brush drops a
> .maintscript file:
> https://janitor.kali.org/cupboard/pkg/hashcat-utils/059988c9-7de0-454a-9ed5-99381ae399a6/
>*
> The commit message just says that it's "obsolete". How does it decide
> that it's obsolete? Does it link the version with a date through the
> changelog? In any case, it would be great if the commit message explained
> how the tool came to this conclusion...

Ideally, ancient-maintscript-entry should list when the last version was for
which the maintscript entry was relevant and when it was uploaded.


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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.21.1
ii  python3  3.9.2-2
ii  python3-breezy   3.1.0-8
ii  python3-debian   0.1.39
ii  python3-debmutate0.27
ii  python3-distro-info  1.0
ii  python3-dulwich  0.20.15-1
ii  python3-iniparse 0.4-3
ii  python3-ruamel.yaml  0.16.12-2
ii  python3-upstream-ontologist  0.1.14-1

Versions of packages lintian-brush recommends:
ii  decopy   0.2.4.4-0.1
ii  dos2unix 7.4.1-1
ii  gpg  2.2.27-1
ii  libdebhelper-perl13.3.4
ii  lintian  2.104.0
ii  ognibuild0.0.2-1
ii  python3-asyncpg  0.21.0-1+b2
ii  python3-bs4  4.9.3-1
ii  python3-docutils 0.16+dfsg-3
ii  python3-levenshtein  0.12.2-1
ii  python3-lxml 4.6.3-1
ii  python3-markdown 3.3.4-1
ii  python3-pyinotify0.9.6-1.3

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

-- no debconf information

Bug#985799: ruby-licensee 9.14.1-1: no library files in the DEB package

[Pirate Praveen]

On Wed, 24 Mar 2021 12:44:28 +0530 Pirate Praveen 
 wrote:
> On Tue, 23 Mar 2021 21:31:28 + Mike Gabriel 
 wrote:

> > Package: ruby-licensee
> > Version: 9.14.1-1
> > Severity: grave
> > X-Debbugs-Cc: prav...@debian.org
> >
> > The ruby-licensee package as currently found in Debian experimental
> > lacks the entire library folder of the licensee Gem. These files, 
at

> > least, are missing from the package:
> >
> > .
> > ├── licensee
> > │   ├── commands
> > │   │   ├── detect.rb
> > │   │   ├── diff.rb
> > │   │   ├── license_path.rb
> > │   │   └── version.rb
> > │   ├── content_helper.rb
> > │   ├── hash_helper.rb
> > │   ├── license_field.rb
> > │   ├── license_meta.rb
> > │   ├── license.rb
> > │   ├── license_rules.rb
> > │   ├── matchers
> > │   │   ├── cabal.rb
> > │   │   ├── cargo.rb
> > │   │   ├── copyright.rb
> > │   │   ├── cran.rb
> > │   │   ├── dice.rb
> > │   │   ├── dist_zilla.rb
> > │   │   ├── exact.rb
> > │   │   ├── gemspec.rb
> > │   │   ├── matcher.rb
> > │   │   ├── npm_bower.rb
> > │   │   ├── nuget.rb
> > │   │   ├── package.rb
> > │   │   ├── reference.rb
> > │   │   └── spdx.rb
> > │   ├── matchers.rb
> > │   ├── project_files
> > │   │   ├── license_file.rb
> > │   │   ├── package_manager_file.rb
> > │   │   ├── project_file.rb
> > │   │   └── readme_file.rb
> > │   ├── project_files.rb
> > │   ├── projects
> > │   │   ├── fs_project.rb
> > │   │   ├── github_project.rb
> > │   │   ├── git_project.rb
> > │   │   └── project.rb
> > │   ├── projects.rb
> > │   ├── rule.rb
> > │   └── version.rb
> > └── licensee.rb
> >
> > I stumbled over this when checking the package content (dpkg -L
> > ruby-licensee) and compared it to the list of files being pulled in
> > using "gem install -v 9.14.1 licensee".
> >
> > Then DEB package only contains the cmdline executable, but lacks 
the


They use git command to find list of files to install which fails in 
the debian build env with a tarball. Usually this results in build 
failure but they have done the git command in a different way so it did 
not result in build failure so we did not notice it. This was resulted 
in autopkgtest failure, but sometimes autopkgtest fails for different 
reasons, we did not dig that deeper.


So the fix would be to patch the gemspec file to not use git command to 
find the list of files to install

Bug#985833: General: when searching repos I get an error message

[Timo Röhling]

Control: reassign -1 command-not-found
Control: tags -1 + wontfix

Hi Silverback!


unable to open database file
Traceback (most recent call last):
 File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in 
crash_guard
   callback()
 File "/usr/lib/command-not-found", line 90, in main
   cnf = CommandNotFound.CommandNotFound(options.data_dir)
 File "/usr/share/command-not-found/CommandNotFound/CommandNotFound.py", line 
79, in __init__
   self.db = SqliteDatabase(dbpath)
 File "/usr/share/command-not-found/CommandNotFound/db/db.py", line 12, in 
__init__
   self.con = sqlite3.connect(filename)
sqlite3.OperationalError: unable to open database file

There's no internet access involved; the tool cannot open the local
database file, which is located at /var/lib/command-not-found/commands.db
This can have a bunch of reasons: maybe the file was not created
properly, your filesystem might be corrupted, or your disk is full.

Speaking of potential fixes:


Sorry, command-not-found has crashed! Please file a bug report at:
http://www.debian.org/Bugs/Reporting

I see why you ended up filing a bug with Debian, but...


command-not-found version: 0.3
Python version: 3.9.2 final 0
Distributor ID: Kali
Description:Kali GNU/Linux Rolling
Release:2021.1
Codename:   kali-rolling

...even if this is an actual bug and not an issue with your machine,
it is probably Kali Linux related (which derives from Debian, but it is
*not* a Debian release), so you are better off asking for
support and/or file a bug there:

https://www.kali.org/docs/community/submitting-issues-kali-bug-tracker/

Cheers
Timo



signature.asc
Description: PGP signature

Bug#979132: auto-apt-proxy takes a long time to run under schroot

[Antonio Terceiro]

On Sat, Feb 06, 2021 at 08:55:41PM +0100, Francesco P. Lovergine wrote:
> 00:00:00 + [ 204 -gt 60 ]
> 00:00:00 + rm -f /tmp/.auto-apt-proxy-1000/cache
> 00:00:00 + [ -f /tmp/.auto-apt-proxy-1000/cache ]
> 00:00:00 + __detect__
> 00:00:00 + detect_DNS_SRV_record
> 00:00:00 + + shuf
> 00:00:00 hostname --domain
> 00:00:00 + awk /^[^#]/{print "http://; $1 ":" $4;found=1;exit}END{exit !found}
> 00:00:00 + /usr/lib/apt/apt-helper srv-lookup _apt_proxy._tcp.lovergine.com
> 00:00:00 + command -v ip
> 00:00:00 + ip route
> 00:00:00 + awk /default/ { print($3) }
> 00:00:00 + gateway=192.168.1.1
> 00:00:00 + getent hosts apt-proxy
> 00:00:00 + awk /[:blank:]/ { print($1) }
> 00:00:29 + explicit_proxy=
> <- HERE!?

`getent hosts apt-proxy` seems to be taking a lot of time. Is DNS
working correctly on this machine?


signature.asc
Description: PGP signature

Bug#985787: init-system-helpers: deb-systemd-helper - incoherent enable after WantedBy change

[Michael Biebl]

Am 24.03.21 um 13:52 schrieb Marcin Szewczyk:

I attach a patch (against debian/1.60). It differs from the one in
#797108. Maybe it goes in an acceptable direction. Please take a look if
you have some time.


Thanks, very much appreciated!





OpenPGP_signature
Description: OpenPGP digital signature

Bug#984803: patchage: segfaults in ALSA mode

[Bernhard Übelacker]

Dear Maintainer,

On Mon, 08 Mar 2021 15:49:55 +0100 
=?utf-8?q?IOhannes_m_zm=C3=B6lnig_=28Debian/GNU=29?=  
wrote:

#4  0x554359e8 in PatchageCanvas::index_port(PortID const&, 
PatchagePort*) (this=0x0, id=..., port=0x557233c0) at 
../src/PatchageCanvas.hpp:59
#5  0x55450837 in AlsaDriver::create_port(PatchageModule&, 
std::__cxx11::basic_string, std::allocator > 
const&, bool, snd_seq_addr) (this=0x55888e60, input=false, addr=...) at ../src/AlsaDriver.cpp:318


318 dynamic_cast(parent.canvas())->index_port(


This crash seems to be caused by the line above where
parent.canvas() returns a null pointer leading to
this=0x0 in PatchageCanvas::index_port().

Unfortunately I found no upstream change related to this,
and upstream seems to have evolved much lately.
Therefore in [1] got removed altogether, therefore packaging
a new release might fix this.

Kind regards,
Bernhard

[1] 
https://gitlab.com/drobilla/patchage/-/commit/5128bfab7ddb9504abf17375e910e5bc94af291e

Bug#985831: ITP: fpyutils -- collection of useful non-standard Python functions

[Sakirnth Nagarasa]

Package: wnpp
Severity: wishlist
Owner: Sakirnth Nagarasa 

* Package name: fpyutils
  Upstream Author : Franco Masotti
* URL : https://github.com/frnmst/fpyutils/
* License : GPL-3+
  Description : collection of useful non-standard Python functions

 A collection of useful non-standard Python functions which aim to be
simple to use, highly readable but not efficient.

Greetings,
Sakirnth (Saki)

Bug#985339: nauty: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Torrance, Douglas]

Andrius Merkys writes:
> On 2021-03-17 00:51, Andreas Beckmann wrote:
>> On 16/03/2021 16.05, Andrius Merkys wrote:
>>> symlink_to_dir /usr/share/doc/nauty libnauty2 2.7r1+ds-1~
>> 
>> That looks correct.
>
> Thanks for confirming.
>
>>>  From this I gather that upgrades of nauty <= 2.7r1+ds-1 to this new
>>> version should trigger the replacement of a symlink with real directory
>>> before placing the files inside. Or am I wrong?
>> 
>> In buster we have
>>   /usr/share/doc/nauty -> libnauty2
>> but in jessie we had
>>   /usr/share/doc/nauty -> /usr/share/doc/libnauty2
>> 
>> and that is not caught by the maintscript entry.
>
> OK, I see, so the problem is due to jessie -> buster upgrade.
>
>> The following should catch both cases:
>> 
>> symlink_to_dir /usr/share/doc/nauty /usr/share/doc/libnauty2 2.7r1+ds-2~
>
> dpkg-maintscript-helper(1) says:
>
> dpkg-maintscript-helper symlink_to_dir \
> pathname old-target prior-version package -- "$@"
>
> pathname is the absolute name of the old symlink (the path will be a
> directory at the end of the installation) and old-target is the target
> name of the former symlink at pathname. It can either be absolute or
> relative to the directory containing pathname.
>
> From this I gather that absolute and relative paths are equivalent, but
> I may read it wrong. Maybe both have to be added?:
>
> symlink_to_dir /usr/share/doc/nauty libnauty2 2.7r1+ds-2~symlink_to_dir
> /usr/share/doc/nauty /usr/share/doc/libnauty2 2.7r1+ds-2~
>
>> I'll try to test that ...

Has there been any progress on this bug?  I'm not sure how to reproduce
it, but I'd be happy to help in any way that I can.  nauty and its
reverse dependencies have been marked for auto-removal on Apr. 29
because of it.

Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc

[Felix Lechner]

Hi Christoph,

On Wed, Mar 24, 2021 at 2:00 AM Christoph Biedl
 wrote:
>
> But that's your design decision.

No, it's an indicator that another QA tool might be a better place for
the warning.

> Other people's workflow might be different, though.

Everyone with a key uses 'uscan', and that is the right place to warn
about expired keys. It is not necessary to upload new Debian revisions
because a key is expired.

> Also, in lintian the change was rather small and therefore easy to
> implement.

The resulting tag is not useful for a package at rest. Think about it
this way: Many old packages may trigger the tag in the archive, but
there is no need to fix anything. Dead upstream sources also
illustrate that point.

> How do the other signing key checks do that? Where's the difference?

Keys that are not minimal, for example, take up space. We have keys
with over a thousand third-party signatures in the archive. [1] Keys
with weak hashes are a security risk. So are known compromised keys.
Expired keys, on the other hand, are not a package quality issue. They
will get updated in the course of time.

[1] https://lintian.debian.org/sources/xandikos/0.2.2-1.html

> it would still avoid breaking uscan in the future.

Uscan uses the network, but Lintian does not. In a similar vein,
Lintian can also not fix broken download URLs—which are arguably a
much bigger problem. (For an extended discussion, please see
Bug#985633 about recent changes at Github.) Errors that arise when
trying to access and validate new sources will be flagged right then
and there.

Without a new release, there is no need to update the key. From my
experience, that is also the attitude of upstream personnel, who may
only extend or distribute new keys at release time.

> It would alert if the key already has expired

As I reasoned here, that is not valuable information for a package at
rest. Lintian is a static analysis tool.

> the maintainer can update accordingly before breaking the
> validation chain.

The maintainer cannot download new versions without a validation
chain. The issue is always solved before Lintian runs. Lintian is the
wrong place to point it out. It is too late in the workflow, and
cannot arise naturally unless the maintainer intentionally works with
unvalidated sources.

Kind regards
Felix Lechner

Bug#985830: mmdebstrap: optimize /dev/null output

[Helmut Grohne]

Package: mmdebstrap
Version: 0.7.5-2
Severity: wishlist
File: /usr/bin/mmdebstrap
Tags: patch upstream

Hi josch,

I noticed that asking mmdebstrap to output to /dev/null can be a
reasonably common thing to do when the desired artifact resides inside
the chroot and is transferred via special hooks. Indeed, I think it is
so common that mmdebstrap should optimize this use case by skipping the
tar creation. To that end, I propose adding a new --format called
"null", which is automatically selected when the target is literally
"/dev/null". I'm attaching a patch with my implementation.

Helmut
--- a/mmdebstrap
+++ b/mmdebstrap
@@ -4384,7 +4384,8 @@
 if ($format eq 'dir') {
 $format = 'directory';
 }
-my @valid_formats = ('auto', 'directory', 'tar', 'squashfs', 'ext2');
+my @valid_formats = ('auto', 'directory', 'tar', 'squashfs', 'ext2',
+'null');
 if (none { $_ eq $format } @valid_formats) {
 error "invalid format. Choose from " . (join ', ', @valid_formats);
 }
@@ -5086,7 +5087,9 @@
 
 # figure out the right format
 if ($format eq 'auto') {
-if ($options->{target} ne '-' and -d $options->{target}) {
+if ($options->{target} eq '/dev/null') {
+$format = 'null';
+} elsif ($options->{target} ne '-' and -d $options->{target}) {
 $format = 'directory';
 } elsif (
 defined $tar_compressor
@@ -5157,30 +5160,32 @@
 info "automatically chosen format: $format";
 }
 
-if ($options->{target} eq '-' and $format ne 'tar') {
+if ($options->{target} eq '-' and $format ne 'tar' and $format ne 'null') {
 error "the $format format is unable to write to standard output";
 }
 
-if (any { $_ eq $format } ('tar', 'squashfs', 'ext2')) {
-if (  any { $_ eq $options->{variant} } ('extract', 'custom')
-  and any { $_ eq $options->{mode} } ('fakechroot', 'proot')) {
-info "creating a tarball or squashfs image or ext2 image in"
-  . " fakechroot mode or proot mode might fail in extract and"
-  . " custom variants because there might be no tar inside the"
-  . " chroot";
-}
-# try to fail early if target tarball or squashfs image cannot be
-# opened for writing
-if ($options->{target} ne '-') {
-if ($options->{dryrun}) {
-if (-e $options->{target}) {
-info "not overwriting $options->{target} because in"
-  . " dry-run mode";
+if (any { $_ eq $format } ('tar', 'squashfs', 'ext2', 'null')) {
+if ($format ne 'null') {
+if (  any { $_ eq $options->{variant} } ('extract', 'custom')
+  and any { $_ eq $options->{mode} } ('fakechroot', 'proot')) {
+info "creating a tarball or squashfs image or ext2 image in"
+  . " fakechroot mode or proot mode might fail in extract and"
+  . " custom variants because there might be no tar inside the"
+  . " chroot";
+}
+# try to fail early if target tarball or squashfs image cannot be
+# opened for writing
+if ($options->{target} ne '-') {
+if ($options->{dryrun}) {
+if (-e $options->{target}) {
+info "not overwriting $options->{target} because in"
+  . " dry-run mode";
+}
+} else {
+open my $fh, '>', $options->{target}
+  or error "cannot open $options->{target} for writing: $!";
+close $fh;
 }
-} else {
-open my $fh, '>', $options->{target}
-  or error "cannot open $options->{target} for writing: $!";
-close $fh;
 }
 }
 # since the output is a tarball, we create the rootfs in a temporary
@@ -5332,7 +5337,7 @@
   = sprintf("%06o\0", unpack("%16C*", $entry));
 $devtar .= $entry;
 }
-} elsif ($format eq 'directory') {
+} elsif (any { $_ eq $format } ('directory', 'null')) {
 # nothing to do
 } else {
 error "unknown format: $format";
@@ -5435,7 +5440,7 @@
   or error "tar failed: $?";
 
 info "done";
-} elsif ($format eq 'directory') {
+} elsif (any { $_ eq $format } ('directory', 'null')) {
 # nothing to do
 } else {
 error "unknown format: $format";
@@ -5537,7 +5542,7 @@
 }
 
 info "done";
-} elsif ($format eq 'directory') {
+} elsif (any { $_ eq $format } ('directory', 'null')) {
 # nothing to do
 } else {
 error "unknown format: $format";
@@ -5608,7 +5613,7 @@
 
 

Bug#985709: ibus-mozc: mozc-tool ignores KDE Qt theme

[Daniel T]

Dear Mr. Hjalmarsson,

Doing just `dpkg -i mozc-utils-gui_2.23.2815.102+dfsg-10build1_amd64.deb`
does indeed solve the problem.

Sincerely,
Daniel Tang

On Wed., Mar. 24, 2021, 07:19 Gunnar Hjalmarsson, 
wrote:

> One idea, Daniel:
>
> In your 21.04 installation, can you please manually install version
> 2.23.2815.102+dfsg-10build1 of the mozc packages from 20.10. You may
> need to download:
>
> - ibus-mozc
> - mozc-data
> - mozc-server
> - mozc-utils-gui
>
> If that makes the theme issue go away, we have isolated the cause of the
> issue to mozc. Otherwise the cause reasonably lies somewhere else.
>
> --
> Cheers,
>
> Gunnar Hjalmarsson
> https://launchpad.net/~gunnarhj
>
>

Bug#985829: smartmontools: smartctl segmentation fault on ia64

[anatoly pugachev]

Package: smartmontools
Version: 7.2-1+b1
Severity: important

Dear Maintainer,

could you please include patch for smartmontools on ia64 arch, since
without proper compiler flags (-fno-cse-follow-jumps), it would sigserv.

Upstream discussion is at
https://github.com/smartmontools/smartmontools/issues/61

# smartctl -A /dev/sda -d cciss,0
smartctl 7.2 2020-12-30 r5155
[ia64-linux-5.12.0-rc4-7-gf83fac525997] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke,
www.smartmontools.org

Segmentation fault


Thanks.

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

Kernel: Linux 5.12.0-rc4-7-gf83fac525997 (SMP w/16 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages smartmontools depends on:
ii  debianutils  4.11.2
ii  libc6.1  2.31-4
ii  libcap-ng0   0.7.9-2.2+b1
ii  libgcc-s110.2.1-6+b1
ii  libselinux1  3.1-2
ii  libstdc++6   10.2.1-6+b1
ii  libsystemd0  246.6-5
ii  libunwind8   1.3.2-2
ii  lsb-base 11.1.0

smartmontools recommends no packages.

Versions of packages smartmontools suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-2
ii  curl   7.74.0-1
ii  gpg2.2.27-1
pn  gsmartcontrol  
pn  smart-notifier 
ii  wget   1.21-1

-- no debconf information

Bug#985787: init-system-helpers: deb-systemd-helper - incoherent enable after WantedBy change

[Marcin Szewczyk]

On Tue, Mar 23, 2021 at 04:20:18PM +0100, Michael Biebl wrote:
> Am 23.03.21 um 15:32 schrieb Marcin Szewczyk:
> > Package: init-system-helpers
> > Version: 1.56+nmu1
> > Severity: normal
> > 
> > I use debhelper to install and enable systemd user units. I noticed that
> > after changing the `WantedBy` value from default.target to
> > graphical.target the new symlink was not created.
> 
> This happens rarely enough, that adding explicit support for that in i-s-h
> is probably not worth the complications.
> That said, if someone can come up with a clean patch to do that, I'm happy
> to take a look.

I attach a patch (against debian/1.60). It differs from the one in
#797108. Maybe it goes in an acceptable direction. Please take a look if
you have some time.

Pardon my Perl. I have not used it for 15 years.

>From the commit message:
> take changes in references to units into account
> 
> - react to changes eg. in WantedBy
> - enable: add symlinks to added units
> - update-state: remove state files of no longer managed links (garbage
>   collection)

-- 
Marcin Szewczyk
http://wodny.org
>From bfb0aecc46009cca72f5a3c1b0ca3fb2a2280048 Mon Sep 17 00:00:00 2001
From: Marcin Szewczyk 
Date: Wed, 24 Mar 2021 13:35:22 +0100
Subject: [PATCH] take changes in references to units into account

- react to changes eg. in WantedBy
- enable: add symlinks to added units
- update-state: remove state files of no longer managed links (garbage
  collection)
---
 script/deb-systemd-helper | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/script/deb-systemd-helper b/script/deb-systemd-helper
index 7e929ed..e626380 100755
--- a/script/deb-systemd-helper
+++ b/script/deb-systemd-helper
@@ -250,6 +250,11 @@ sub no_link_installed {
 my ($scriptname, $service_path) = @_;
 
 my @links = get_link_closure($scriptname, $service_path);
+# Previous package version might have managed additional links.
+# Take them into account to determine if the service was previously 
enabled.
+my $dsh_state = dsh_state_path($scriptname);
+my @dsh_links = map { { src => $_ } } state_file_entries($dsh_state);
+push(@links, @dsh_links);
 my @existing_links = grep { -l $_->{src} } @links;
 
 return (@existing_links == 0);
@@ -329,6 +334,7 @@ sub update_state {
 
 my $dsh_state = dsh_state_path($scriptname);
 my @links = get_link_closure($scriptname, $service_path);
+my @dsh_links = state_file_entries($dsh_state);
 
 debug "Old state file contents: " .
 Data::Dumper::Dumper([ state_file_entries($dsh_state) ]);
@@ -344,6 +350,14 @@ sub update_state {
 }
 close($outfh);
 
+# Remove state files of previously managed links if they are no longer 
managed.
+my %links = map { $_->{src} => 1 } @links;
+for my $dsh_link (@dsh_links) {
+my $statefile = $dsh_link;
+$statefile =~ s,^/etc/systemd/$instance/,$enabled_state_dir/,;
+unlink($statefile) unless exists($links{$dsh_link});
+}
+
 debug "Renaming temp file $tmpname to state file $dsh_state";
 rename($tmpname, $dsh_state) or
 error("Unable to move $tmpname to $dsh_state");
-- 
2.25.0

Bug#985828: yubiserver FTCBFS: does not pass --host to ./configure

[Helmut Grohne]

Source: yubiserver
Version: 0.6-3.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

yubiserver fails to cross build from source, because it does not pass
--host to ./configure. The easiest way of doing so - using
dh_auto_configure - makes yubiserver cross buildable. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru yubiserver-0.6/debian/changelog 
yubiserver-0.6/debian/changelog
--- yubiserver-0.6/debian/changelog 2018-10-27 11:43:28.0 +0200
+++ yubiserver-0.6/debian/changelog 2021-03-24 12:40:39.0 +0100
@@ -1,3 +1,10 @@
+yubiserver (0.6-3.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 24 Mar 2021 12:40:39 +0100
+
 yubiserver (0.6-3.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff --minimal -Nru yubiserver-0.6/debian/rules yubiserver-0.6/debian/rules
--- yubiserver-0.6/debian/rules 2015-06-29 10:39:45.0 +0200
+++ yubiserver-0.6/debian/rules 2021-03-24 12:40:38.0 +0100
@@ -16,9 +16,7 @@
 configure: configure-stamp
 configure-stamp:
dh_testdir
-   # Add here commands to configure the package.
-   
-   ./configure --prefix=/ --bindir=/usr/bin --sbindir=/usr/sbin 
--mandir=/usr/share/man 
--with-default-sqlite3-db-file=/var/lib/yubiserver/yubiserver.sqlite 
--with-default-yubiserver-log-file=/var/log/yubiserver/yubiserver.log
+   dh_auto_configure -- --prefix=/ --bindir=/usr/bin --sbindir=/usr/sbin 
--mandir=/usr/share/man 
--with-default-sqlite3-db-file=/var/lib/yubiserver/yubiserver.sqlite 
--with-default-yubiserver-log-file=/var/log/yubiserver/yubiserver.log
touch configure-stamp
 
 build: configure-stamp build-arch build-indep

Bug#985589: unblock: jsonnet/0.17.0+ds-2

[M. Zhou]

Control: tags -1 -moreinfo

src:jsonnet (=0.17.0+ds-2) has been uploaded onto unstable,
and built on all release architectures.

On Sun, 2021-03-21 at 14:31 +0100, Sebastian Ramacher wrote:
> Control: tags -1 + confirmed moreinfo
> 
> On 2021-03-20 13:49:44 +, M. Zhou wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > 
> > 
> > Please unblock package jsonnet
> > 
> > [ Reason ]
> > 
> > I missed the lib package in the Depends: field of its -dev package,
> > resulting in dangling symlinks during anbe's tests. Not yet
> > uploaded.
> 
> Looks good. Please remove the moreinfo tag once it's available in
> unstable.
> 
> Cheers

Bug#985827: ssed should support DEB_BUILD_OPTIONS=nocheck

[Helmut Grohne]

Source: ssed
Version: 3.62-7
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Please support skipping the test suite when passing
DEB_BUILD_OPTIONS=nocheck. Among other things not doing so breaks cross
compilation. I'm attaching a patch for your convenience.

Helmut
diff -u ssed-3.62/debian/rules ssed-3.62/debian/rules
--- ssed-3.62/debian/rules
+++ ssed-3.62/debian/rules
@@ -19,7 +19,9 @@
 
$(MAKE)
 
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
$(MAKE) check
+endif
 
touch build-stamp
 
diff -u ssed-3.62/debian/changelog ssed-3.62/debian/changelog
--- ssed-3.62/debian/changelog
+++ ssed-3.62/debian/changelog
@@ -1,3 +1,10 @@
+ssed (3.62-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Honour DEB_BUILD_OPTIONS=nocheck. (closes: #-1)
+
+ -- Helmut Grohne   Wed, 24 Mar 2021 12:37:19 +0100
+
 ssed (3.62-7) unstable; urgency=low
 
   * Updated maintainer field (closes: #565360)

Bug#985826: RFS: bm/1.14.0 [ITP]

[Thomas Dreibholz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: bm
Version: 1.14.0+g202103241242~119c4a
Upstream Author: Antonin Bas mailto:anto...@barefootnetworks.com>>
  * URL: https://github.com/p4lang/behavioral-model

  * License: Apache-2.0 GPL-3+
  * Section: net

This is the second version of the P4 software switch (also known as
behavioral model), nicknamed bmv2.

"bm " builds these binary
packages:

  * p4lang-bmv2-bin - p4lang behavioral-model (binaries)
  * p4lang-bmv2-dev - p4lang behavioral-model
  * p4lang-bmv2-libs - p4lang behavioral-model (libraries)
  * p4lang-bmv2 - p4lang behavioral-model (metapackage)
  * python3-bmv2 - p4lang behavioral-model (Python libraries)

To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/bm
.

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

dget -x 
https://mentors.debian.net/debian/pool/main/b/bm/bm_1.14.0+g202103241242~119c4a.dsc
 


More information about "bm "
can be obtained from https://github.com/p4lang/behavioral-model
.

Most recent changelog entry:

bm (1.14.0+g202103241242~119c4a) unstable; urgency=medium

  * Self-made package

-- Thomas Dreibholz > Wed, 24 Mar 2021
13:42:22 +0100

-- 
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

===
 Thomas Dreibholz

 SimulaMet -- Simula Metropolitan Centre for Digital Engineering
 Centre for Resilient Networks and Applications
 Pilestredet 52
 0167 Oslo, Norway
---
 E-Mail: dre...@simula.no
 Homepage:   http://simula.no/people/dreibh
===



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985815: RFS: usermanager/1.0.74+git20210323-1 [ITP] -- Graphical user manager

[Gürkan Myczko]

Hi Adam,


The .desktop file has a stray line at its start.


fixed


The menu icon for .desktop doesn't show up for me (in XFCE).


probably because it's .gif and fd.o doesn't support it


It should be grouped in "System" rather than "Other".


maybe or rather probably


The package's short desc shouldn't be capitalized.


fixed

The long desc shouldn't mention that this program started as an 
university

assignment, it's a bit of history not relevant to using the program.


dropped


Some method of su{,do}-to-root should be providen -- as is, the program
fails to start claiming it needs root, and starting it as root manually
involves some bits generally unknown by users who need a clicky-clicky
tool (ie, the intended audience).


for upstream


When deleting an user ("gnats" in my case) it threw a message that
/home/gnats doesn't exist -- despite $HOME for that user being
/var/lib/gnats (obtainable by getpwent()->pw_dir).


for upstream


Meow!


Woff!

Bug#983843: xrdp FTBFS on several architectures

[Matt Burt]

The kfreebsd variant fails are down to FUSE_USE_VERSION not being 
defined for a header file that uses types from fuse_lowlevel.h


I've put together a patch to fix this which moves the definition of 
FUSE_USE_VERSION from a C file to Makefile.am:-


diff --git a/sesman/chansrv/Makefile.am b/sesman/chansrv/Makefile.am
index 767ac27b..1a57a563 100644
--- a/sesman/chansrv/Makefile.am
+++ b/sesman/chansrv/Makefile.am
@@ -18,7 +18,7 @@ endif
 CHANSRV_EXTRA_LIBS =

 if XRDP_FUSE
-AM_CPPFLAGS += -DXRDP_FUSE $(FUSE_CFLAGS)
+AM_CPPFLAGS += -DXRDP_FUSE $(FUSE_CFLAGS) -DFUSE_USE_VERSION=26
 CHANSRV_EXTRA_LIBS += $(FUSE_LIBS)
 endif

diff --git a/sesman/chansrv/chansrv_fuse.c b/sesman/chansrv/chansrv_fuse.c
index f29ea0ed..74ac06d1 100644
--- a/sesman/chansrv/chansrv_fuse.c
+++ b/sesman/chansrv/chansrv_fuse.c
@@ -130,7 +130,12 @@ void xfuse_devredir_cb_file_close(struct 
state_close *fip)

 ** **
 **/

-#define FUSE_USE_VERSION 26
+/* FUSE_USE_VERSION must be defined globally for other parts of
+ * xrdp-chansrv which include  for definitions. Check
+ * it's actually defined here */
+#ifndef FUSE_USE_VERSION
+#error Define FUSE_USE_VERSION in the make system and recompile
+#endif

 #include 
 #include 

I can propose this for upstream if you like (I'm a project maintainer), 
but we haven't tested the FUSE stuff against a FreeBSD kernel.

Bug#985824: RFP: elpa-om-to-xml -- convert Emacs org-mode files to XML

[Martin]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-emac...@lists.debian.org

* Package name: elpa-om-to-xml
  Version : 0.0.7
  Upstream Author : Norman Walsh 
* URL : https://github.com/ndw/org-to-xml/
* License : GPL-3+
  Programming Lang: Emacs-Lisp
  Description : convert Emacs org-mode files to XML

This project contains a library to convert Emacs org-mode files
to XML: om-to-xml.

The goal is a complete and accurate translation of the internal
org-mode data structures to XML. This produces XML that isn’t
especially pretty, but the assumption is that downstream XML
processing tools can be used to transform it.

Bug#962696: #962696 - please consider renaming package

[Holger Levsen]

tags 962696 help
clone 962696 -1
retitle -1 vrms should not be part of bullseye
severity -1 serious
tags -1 help

Hi Ivo,

thanks for filing this overdue idea in the BTS almost a year ago and sorry 
for not responding earlier. FWIW, I fully agree and I agreed before yesterday
too (when RMS announced the FSF would let him join their board again), even
though I didn't reply to this bug until now, sigh & sorry for that.

So, what to rename this package too? vdfsg? virtual-dfsg? drm? (dfsg reminder
motivationer? or some such?)

Technically renaming is straight forward (just a bunch of find and sed commands)
once the future name has been choosen, though choosing the name is difficult.
Help and suggestions welcome.

And then, getting the transition and upgrades right is also a bit difficult,
though I'll plan an easy way. (=I probably don't plan to maintain a 
/usr/bin/vrms
compability symlink or such.)

Last but not least, I'm unsure what to do with vrms in bullseye. I certainly
at least don't want vrms binary package in it, I could probably life with a
src:vrms package, but then again, if the release team were to allow a package
rename at this time of the bullseye release cycle, I suppose changing the
source package name as well (and only shipping a transitional vrms package)
would be ok too.

And then I'm thinking that just removing the whole package would be the least
work. sigh. (Though I know there are quite some fond users.)

Feedback/comments/suggestions much appreciated. (Though I will ignore those
argueing for keeping the vrms name.)


-- 
cheers,
Holger

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

Because things are the way they are, things will not stay the way they are.
(Bertolt Brecht)


signature.asc
Description: PGP signature

Bug#985823: RFP: elpa-org-ml -- functional API for org-mode

[Martin]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-emac...@lists.debian.org

* Package name: elpa-org-ml
  Version : 5.6.1
  Upstream Author : Nathan Dwarshuis 
* URL : https://github.com/ndwarshuis/org-ml/
* License : GPL-3+
  Programming Lang: Emacs-Lisp
  Description : functional API for org-mode

This is a functional API for org-mode primarily using the `org-element'
library. `org-element.el' provides the means for converting an org buffer to
a parse-tree data structure. This library contains functions to modify this
parse-tree in a more-or-less 'purely' functional manner (with the exception
of parsing from the buffer and writing back to the buffer). For the purpose
of this package, the resulting parse tree is composed of 'nodes'.

Bug#985822: unblock: slirp4netns/1.0.1-2

[Reinhard Tartler]

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

Please unblock package slirp4netns

Upstream author Akihiro Suda has reached out to me privately
about the slirp4netns package in Debian. Among others, he
(rightfully) pointed out that ipv6 is not working in the current
package due to an oversight. The remeidy is an easy to review pathc

[ Reason ]
Fix an oversight that restores ipv6

[ Impact ]
Users of podman, buildah, etc. that want to run rootless will get
unpleasently suprises when they try rootless networking that involves
ipv6

[ Tests ]
There are no automated tests

[ Risks ]
The patch seems trivial and safe. A non-functional slirp4netns has the
risk of breaking rootless podman.


unblock slirp4netns/1.0.1-2


diff --git a/debian/changelog b/debian/changelog
index 6f89392..20a2903 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+slirp4netns (1.0.1-2) unstable; urgency=medium
+
+  * Apply patch from upstrema to make ipv6 usable (Closes: #985780)
+
+ -- Reinhard Tartler   Wed, 24 Mar 2021 07:43:48 -0400
+
 slirp4netns (1.0.1-1) unstable; urgency=medium

   * New upstream version 1.0.1
diff --git a/debian/patches/ipv6.patch b/debian/patches/ipv6.patch
new file mode 100644
index 000..f585f21
--- /dev/null
+++ b/debian/patches/ipv6.patch
@@ -0,0 +1,21 @@
+From 8d2aefecce7cca696f44d0792e196ecdd22072e4 Mon Sep 17 00:00:00 2001
+From: Ralf Haferkamp 
+Date: Fri, 3 Jul 2020 11:35:52 +0200
+Subject: [PATCH] Fix config_from_options() to correctly enable ipv6
+
+Signed-off-by: Ralf Haferkamp 
+---
+ main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/main.c
 b/main.c
+@@ -680,7 +680,7 @@
+ if (rc < 0) {
+ goto finish;
+ }
+-cfg->enable_ipv6 = cfg->enable_ipv6;
++cfg->enable_ipv6 = opt->enable_ipv6;
+ cfg->disable_host_loopback = opt->disable_host_loopback;
+ cfg->enable_sandbox = opt->enable_sandbox;
+ cfg->enable_seccomp = opt->enable_seccomp;
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..b5b92c7
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+ipv6.patch

Bug#985703: debian-edu-doc-legacy-en: broken symlink: /usr/share/doc/debian-edu-doc-legacy-en/debian-edu-itil-manual-images/alert.png -> /debian-edu-doc-en/usr/share/doc/debian-edu-doc-en/debian-edu-b

[Wolfgang Schweer]

Hi Andreas,

[ Andreas Beckmann, 2021-03-22 ]
> On 22/03/2021 13.14, Wolfgang Schweer wrote:
> > Actually
> > /debian-edu-doc-en/usr/share/doc/debian-edu-doc-en/debian-edu-bullseye-manual-images/alert.png
> > should be shipped, but is missing. I'll take a look.
> 
> There is an extra '/debian-edu-doc-en/' prefix to the target path, that
> likely the problem. I didn't check the source how that gets generated ...
 
Thanks for the pointer. After digging into it, the failure seems to be 
caused by a workaround introduced five years ago but not working anymore 
after legacy manuals have been split out into debian-edu-doc-legacy-xx 
some time ago. Please note that the alert.png file is actually unneeded 
for the debian-edu-itil-manual.
 
Replacing alert.png (which points to a file also belonging to 
debian-edu-doc-en) with an image exclusively belonging to a manual 
shipped with debian-edu-doc-legacy-en fixes the issue. This image is 
only there to make sure at least one image is available in the image 
directory (that's the mentioned workaround as far as I was able to find 
out).

Wolfgang


signature.asc
Description: PGP signature

Bug#985786: systemd: should be restartable even with mounted network filesystems

[Michael Biebl]

Am 23.03.2021 um 16:23 schrieb Michael Biebl:

Please consider raising this upstream at
https://github.com/systemd/systemd

It's very likely that upstream has some follow up questions.

I would suggest to include your strace in that upstream bug report and 
also attach your /etc/fstab.


This sounds a bit like https://github.com/systemd/systemd/issues/16156
Unfortunately your strace log was clipped off.

Can you try https://github.com/systemd/systemd/pull/19101 ?

Michael

Bug#985815: RFS: usermanager/1.0.74+git20210323-1 [ITP] -- Graphical user manager

[Adam Borowski]

On Wed, Mar 24, 2021 at 09:22:47AM +0100, Gürkan Myczko wrote:
>  * Package name: usermanager
>Version : 1.0.74+git20210323-1
>  * URL : https://github.com/xen0vas/UserManager

>  usermanager (1.0.74+git20210323-1) experimental; urgency=medium
>  .
>* Initial release. (Closes: #985784)

The .desktop file has a stray line at its start.

The menu icon for .desktop doesn't show up for me (in XFCE).

It should be grouped in "System" rather than "Other".

The package's short desc shouldn't be capitalized.

The long desc shouldn't mention that this program started as an university
assignment, it's a bit of history not relevant to using the program.

Some method of su{,do}-to-root should be providen -- as is, the program
fails to start claiming it needs root, and starting it as root manually
involves some bits generally unknown by users who need a clicky-clicky
tool (ie, the intended audience).

When deleting an user ("gnats" in my case) it threw a message that
/home/gnats doesn't exist -- despite $HOME for that user being
/var/lib/gnats (obtainable by getpwent()->pw_dir).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄ `

Bug#985818: unblock: swift/2.26.0-9

[Thomas Goirand]

Hi,

As we've noticed some errors with "greenlet.error: cannot switch to a
different thread" in production, I'd like to also fix the uwsgi
configuration for account+container to a single thread by default, as
per the attached debdiff. After the fix, the error is gone from our
production, so it seems to do the trick. Note that thanks to uwsgi, the
performances is still ok.

Debdiff attached. Sorry that it had to be a follow-up to this bug.

Cheers,

Thomas Goirand (zigo)

diff -Nru swift-2.26.0/debian/changelog swift-2.26.0/debian/changelog
--- swift-2.26.0/debian/changelog   2021-03-24 10:12:53.0 +0100
+++ swift-2.26.0/debian/changelog   2021-03-24 11:53:15.0 +0100
@@ -1,3 +1,10 @@
+swift (2.26.0-10) unstable; urgency=medium
+
+  * Switch account+container-server on a single uwsgi tread, to avoid locks
+with "greenlet.error: cannot switch to a different thread" in the logs.
+
+ -- Thomas Goirand   Wed, 24 Mar 2021 11:53:15 +0100
+
 swift (2.26.0-9) unstable; urgency=medium
 
   * Add python3-dnspython as Recommends for the proxy, as this is needed for
diff -Nru swift-2.26.0/debian/swift-account-server-uwsgi.ini 
swift-2.26.0/debian/swift-account-server-uwsgi.ini
--- swift-2.26.0/debian/swift-account-server-uwsgi.ini  2021-03-24 
10:12:53.0 +0100
+++ swift-2.26.0/debian/swift-account-server-uwsgi.ini  2021-03-24 
11:53:15.0 +0100
@@ -38,7 +38,7 @@
 ##
 
 # We ran benches to validate these values, and they seem ok:
-threads = 12
+threads = 1
 listen = 100
 
 # These are used in the gate.
diff -Nru swift-2.26.0/debian/swift-container-server-uwsgi.ini 
swift-2.26.0/debian/swift-container-server-uwsgi.ini
--- swift-2.26.0/debian/swift-container-server-uwsgi.ini2021-03-24 
10:12:53.0 +0100
+++ swift-2.26.0/debian/swift-container-server-uwsgi.ini2021-03-24 
11:53:15.0 +0100
@@ -38,7 +38,7 @@
 ##
 
 # We ran benches to validate these values, and they seem ok:
-threads = 12
+threads = 1
 listen = 100
 
 # These are used in the gate.

Bug#985709: ibus-mozc: mozc-tool ignores KDE Qt theme

[Gunnar Hjalmarsson]

One idea, Daniel:

In your 21.04 installation, can you please manually install version 
2.23.2815.102+dfsg-10build1 of the mozc packages from 20.10. You may 
need to download:


- ibus-mozc
- mozc-data
- mozc-server
- mozc-utils-gui

If that makes the theme issue go away, we have isolated the cause of the 
issue to mozc. Otherwise the cause reasonably lies somewhere else.


--
Cheers,

Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature

Bug#984800: cgroup-tools: does not work in cgroup2 / unified hierarchy

[Santiago Ruano Rincón]

Control: severity -1 important
Control: forwarded -1 https://github.com/mininet/mininet/issues/1051

Lowering the severity, #959022 has been "downgraded" to important.


signature.asc
Description: PGP signature

Bug#968614:

[Fabio Pedretti]

Waqar, are you still able to reproduce this issue with current version
in bullseye, 1.8.7-1?

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 

Bug#985719: praat: Menu bar invisible

[Joonas Kylmälä]

Hi,

I was able to launch GNOME/Xorg finally[1] and Praat works there just
fine. The problem only happens with GNOME/Wayland. Are you able to
reproduce with GNOME/Wayland?

Other GTK3 programs on GNOME/Wayland seem to work OK, e.g. I tried Totem
/ Video player. Maybe Praat has some X11 specific code that is now
causing trouble?

Joonas

[1] (unrelated to this bug) One theory I have is that mesa3d might have
race condition on /dev/card0 lock and that caused mesa3d not to be able
to fully load (because x11 log had permission related error on card0).

Rafael Laboissière:
> Control: tags -1 + moreinfo unreproducible
> 
> I cannot reproduce the bug on my system with Gnome/Xorg. Does the
> problem occur only in Praat for you or also in other GTK3 programs?
> 
> Best regards,
> 
> Rafael Laboissière

Bug#945337: why is the version from elpa needed

[David Bremner]

積丹尼 Dan Jacobson  writes:

> I.e., already about 11 versions deep on
> https://elpa.gnu.org/packages/tramp.html

Yes, I can see the version difference, but not what actual difference it
makes to users.

> What's worse is:
> A debian users visits
> https://elpa.gnu.org/packages/tramp.html
> and sees
> To install this package, run in Emacs:
> M-x package-install RET tramp RET
> but as debian already has an old tramp,
> so underneath his fingertips this expands to
> tramp-theme 
> and unless he notices what happened,
> he still can't advance beyond the old tramp version!
> All he has done is install tramp-theme, not tramp.

I think package-install is behaving as documented here. If I go to tramp in
package-list-packages, and select install, it installs fine.

>
> So there are more elpa- packages in Debian than even on the official
> elpa website!

We use elpa to mean the packaging standard, not the archive site. In
hindsight we might have chosen better terminology, but we're stuck with
it now.

> Therefore I propose that all packages on the elpa website be
> automatically included in Debian.

There is nothing automatic about it. It requires real humans to do real
work packaging and maintaining those packages. 

In general RFP bugs have a low closure rate because you are asking
someone else to do work on a problem they are not necessarily interested
in. I was offering you a chance to explain why doing this work is
important.

Bug#839662: [firmware-atheros] ath10k_pci firmware crashes when ap changes bandwith

[Michael Meier]

sorry. I've solved the problem by getting an other network adapter => 
can't help anymore



On 24.03.21 11:18, maximilian attems wrote:

tags 839662 moreinfo
stop


The same problem here with firmware-atheros version 20170823-1~bpo9+1
and kernel 4.14.0-2-amd64.
It's a dell xps 13 8th gen, with a:

Is this reproducible with an up to date Debian Testing?


Sorry for the late reply and thank you for the reports.

Bug#985821: Mariadb crashes on long semaphore list related to "InnoDB persistent stats analyze forces full scan forcing lock crash"

[vasilis g]

Package: mariadb-server

Version: 1:10.3.27-0+deb10u1


Mariadb aborts an long semaphore list relating to analyze table commands
for large databases. After I ran analyze on a big table on a server with
slow storage, I aborted the command and restarted the server. Since then
it seems that mariadb crashes every day at some time with a long
semaphore list. The last crash was monitored, and I stopped the workload
on the db. The only queries still running where 12 insert and updates
that just did never commit. These queries are usual application queries
that hit the db hundred times per minute.

After searching it seems that this is fixed upstream with
https://jira.mariadb.org/browse/MDEV-24275 and has to do with "InnoDB
persistent stats analyze forces full scan forcing lock crash".

We are running Debian buster 10.8 and I think this should be fixed as
this is the only mariadb version available for stable.

Mariadb logs

 [ERROR] [FATAL] InnoDB: Semaphore wait has lasted > 600 seconds. We
intentionally crash the server because it appears to be hung.

Kind regards

Bug#839662: [firmware-atheros] ath10k_pci firmware crashes when ap changes bandwith

[maximilian attems]

tags 839662 moreinfo
stop

> The same problem here with firmware-atheros version 20170823-1~bpo9+1 
> and kernel 4.14.0-2-amd64.
> It's a dell xps 13 8th gen, with a:

Is this reproducible with an up to date Debian Testing?


Sorry for the late reply and thank you for the reports.

Bug#920937: firmware-atheros: Firmware QCA6174 crashes on wakeup from suspend

[maximilian attems]

> I seem to have the same problem with version 20190717 (debian testing 
> 5.4.13-1 amd64).

How about firmware 20210208-4, which should have an upgrade and
latest linux in Debian Bullseye?

thanks for your reports.

Bug#973529: firmware-atheros: Link wifi rate limited at 1MB/s

[maximilian attems]

tags 973529 moreinfo
stop

> Version: 20200918-1


How about latest Debian testing version, is that still the case?


thank you.

Bug#985820: python3-cryptography: Core dump in buster openssl binding

[Markus Demleitner]

Package: python3-cryptography
Version: 2.6.1-3+deb10u2
Severity: normal
Tags: security

A long-running, twisted-based server occasionally (days to weeks) gets aborted
when processing HTTPS requests.  Here's a basic core dump from an abort:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f604e0d2535 in __GI_abort () at abort.c:79
#2  0x7f604e129508 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7f604e23428d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x7f604e12fc1a in malloc_printerr (
str=str@entry=0x7f604e23243b "free(): invalid pointer") at malloc.c:5341
#4  0x7f604e13142c in _int_free (av=, p=,
have_lock=) at malloc.c:4165
#5  0x7f604d77a9be in SSL_SESSION_free ()
   from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#6  0x7f604d5ddc8c in OPENSSL_LH_doall_arg ()
   from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
#7  0x7f604d77bf57 in SSL_CTX_flush_sessions ()
   from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#8  0x7f604d7924d3 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#9  0x7f604d787e3e in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#10 0x7f604d773f34 in SSL_do_handshake ()
   from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
#11 0x7f604d12971c in ?? ()
   from 
/usr/lib/python3/dist-packages/cryptography/hazmat/bindings/_openssl.abi3.so
#12 0x005ccba1 in _PyMethodDef_RawFastCallKeywords ()

This is about all I know at this point.  I've not yet managed to trigger this
on a development system.  On the operational system, I can live with
having a watchdog restart the service when it gets aborted, so I could
limp on until bullseye here.

On the other hand, an invalid free in openssl sounds a bit unnerving, and 
so I thought I'd report this and offer to at least install debug
packages and look more closely at the problem (disclaimer: as I may have 
to wait weeks until I'll get another abort, responses may be slow).

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=UTF-8) (ignored: LC_ALL set to 
de_DE.UTF-8), LANGUAGE=en_US (charmap=UTF-8) (ignored: LC_ALL set to 
de_DE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages python3-cryptography depends on:
ii  libc62.28-10
ii  libssl1.11.1.1d-0+deb10u5
ii  python3  3.7.3-1
ii  python3-asn1crypto   0.24.0-1
ii  python3-cffi-backend [python3-cffi-backend-api-min]  1.12.2-1
pn  python3-cffi-backend-api-max 
ii  python3-six  1.12.0-1

python3-cryptography recommends no packages.

Versions of packages python3-cryptography suggests:
pn  python-cryptography-doc   
pn  python3-cryptography-vectors  

-- no debconf information

Bug#985774: [Python-modules-team] Bug#985774: python3-django-tables2 is seriously outdated

[Pierre-Elliott Bécue]

Le mardi 23 mars 2021 à 18:54:03-0300, Emmanuel Arias a écrit :
> On Tue, Mar 23, 2021 at 10:44:41PM +0100, Pierre-Elliott Bécue wrote:
> > Le mardi 23 mars 2021 à 15:18:25-0300, Emmanuel Arias a écrit :
> > > Hello
> > > 
> > > > 
> > > > django-tables2 latest version is 2.3.4, while Debian provides the
> > > > version 2.1.1 in testing and unstable. This old version does not provide
> > > > any compatibility for Django 3, which exist in the experimental
> > > > repository. Is it possible to update the binaries for
> > > > python3-django-tables2, at least in unstable/experimental?
> > > 
> > > I've just push to salsa [0] a debian/experimental branch. I'll need
> > > sponsoship to upload.
> > > 
> > > [0] 
> > > https://salsa.debian.org/python-team/packages/django-tables/-/tree/debian/experimental
> > > 
> > > Chers,
> > 
> > Hi Emmanuel,
> > 
> > Your package is good to go, after fixing some minor issues:
> > 
> >  * You did not upload the upstream branch
> >  * You did not upload the pristine-tar branch
> >  * You did not upload the upstream release tag
> >  * You did not set a proper experimental version and label the release
> >to experimental
> 
> oh no, so sorry for thats, I've just forgot upload.

Hi Emmanuel,

As far as I am concerned, there is no need to feel sorry, I was merely
giving you intel on what changes I did to have the package uploaded.

I'm grateful that you did work on the package and made it upload-ready.

Bests,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#947689:

[Fabio Pedretti]

tags 947689 fixed-upstream

This issue should be fixed in this upstream commit:
https://git.netfilter.org/iptables/commit/?id=5f1fcacebf9b4529950b6e3f88327049a0ea7cd2

-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 

Bug#985819: unblock: webkit2gtk/2.30.6-1

[Alberto Garcia]

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

Please unblock package webkit2gtk

Starting from buster webkit2gtk has been receiving security updates,
with a dozen DSAs published so far, at a pace of once every month or
two. These updates follow the upstream stable releases.

webkit2gtk 2.30.6 is a point release that was published on the 18th of
March. It contains fixes for seven new security bugs: CVE-2020-27918,
CVE-2020-29623, CVE-2021-1765, CVE-2021-1789, CVE-2021-1799,
CVE-2021-1801, CVE-2021-1870. You can see the details on the latest
upstream security advisory:

   https://webkitgtk.org/security/WSA-2021-0002.html

I would like to have this version of webkit2gtk unblocked and after
that I'll prepare a new security update for buster.

Thanks,

Berto

unblock webkit2gtk/2.30.6-1

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

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

Bug#985818: unblock: swift/2.26.0-9

[Thomas Goirand]

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

Please unblock package swift

There's 2 changes. First, python3-dnspython is added as recommends, otherise
without it, the cname_lookup module of swift wouldn't work. But that's the
least important change.

The 2nd change is a patch from upstream, which avoids the swift processes to
fall into deadlocks. We experienced it in production, and that's not fun,
and it's also very hard to understand what's happening. I would really like
to have the patch included in Bullseye.

Debdiff attached.

Please unblock swift/2.26.0-9

Cheers,

Thomas Goirand (zigo)
diff -Nru swift-2.26.0/debian/changelog swift-2.26.0/debian/changelog
--- swift-2.26.0/debian/changelog   2021-02-23 14:11:16.0 +0100
+++ swift-2.26.0/debian/changelog   2021-03-24 10:12:53.0 +0100
@@ -1,3 +1,11 @@
+swift (2.26.0-9) unstable; urgency=medium
+
+  * Add python3-dnspython as Recommends for the proxy, as this is needed for
+the cname_lookup middleware.
+  * Add Turn_off_logging.logThreads_when_monkey-patched.patch.
+
+ -- Thomas Goirand   Wed, 24 Mar 2021 10:12:53 +0100
+
 swift (2.26.0-8) unstable; urgency=medium
 
   * Kill the autopkgtests. The team has other means of testing swift anyways.
diff -Nru swift-2.26.0/debian/control swift-2.26.0/debian/control
--- swift-2.26.0/debian/control 2021-02-23 14:11:16.0 +0100
+++ swift-2.26.0/debian/control 2021-03-24 10:12:53.0 +0100
@@ -356,6 +356,7 @@
  python3-barbicanclient,
  python3-castellan,
  python3-keystonemiddleware,
+ python3-dnspython,
 Description: distributed virtual object store - proxy server
  OpenStack Object Storage (code-named Swift) creates redundant, scalable object
  storage using clusters of standardized servers to store petabytes of
diff -Nru swift-2.26.0/debian/patches/series swift-2.26.0/debian/patches/series
--- swift-2.26.0/debian/patches/series  2021-02-23 14:11:16.0 +0100
+++ swift-2.26.0/debian/patches/series  2021-03-24 10:12:53.0 +0100
@@ -4,3 +4,4 @@
 set-default-workers-value.patch
 fix-eventlet-monkey-patching-with-py3.7.patch
 Fix__exit__calls.patch
+Turn_off_logging.logThreads_when_monkey-patched.patch
diff -Nru 
swift-2.26.0/debian/patches/Turn_off_logging.logThreads_when_monkey-patched.patch
 
swift-2.26.0/debian/patches/Turn_off_logging.logThreads_when_monkey-patched.patch
--- 
swift-2.26.0/debian/patches/Turn_off_logging.logThreads_when_monkey-patched.patch
   1970-01-01 01:00:00.0 +0100
+++ 
swift-2.26.0/debian/patches/Turn_off_logging.logThreads_when_monkey-patched.patch
   2021-03-24 10:12:53.0 +0100
@@ -0,0 +1,31 @@
+Description: Turn off logging.logThreads when monkey-patched
+ We've seen proxy-servers lock up while trying to log client disconnects.
+ The trouble is that we happen to do this while we're *already*
+ trying to log *something else*. If the timing works out particularly
+ badly, we end up with a double-call to (an eventlet-patched)
+ threading.current_thread(), which needs to enumerate all pthreads, which
+ uses a non-re-entrant lock in CPython.
+ .
+ The most expedient solution seems to be disabling logThreads so we never
+ call threading.current_thread().
+Author: Tim Burke 
+Date: Thu, 17 Sep 2020 17:41:03 -0700
+Change-Id: Ida9418a1bd30ed300a8a850cda567d60c9889ec7
+Origin: https://review.opendev.org/c/openstack/swift/+/752593
+Last-Update: 2021-03-24
+
+diff --git a/swift/common/utils.py b/swift/common/utils.py
+index 83417ff..b31e9af 100644
+--- a/swift/common/utils.py
 b/swift/common/utils.py
+@@ -554,6 +554,10 @@
+ # if thread is monkey-patched.
+ eventlet.patcher.monkey_patch(all=False, socket=True, select=True,
+   thread=True)
++# Trying to log threads while monkey-patched can lead to deadlocks; see
++# https://bugs.launchpad.net/swift/+bug/1895739
++logging.logThreads = 0
++
+ import __original_module_threading as orig_threading
+ import threading
+ orig_threading.current_thread.__globals__['_active'] = threading._active

Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc

[Christoph Biedl]

Felix Lechner wrote...

> By the way, the suggestion behind this bug may not be implemented
> anytime soon. It would cause Lintian's output to change over time
> (same Lintian version on same package). Such tags are hard to test in
> Lintian's test suite.

That argument seems fairly weird to me: Abandon or deny features because
they are difficult to test. By the way, to test behaviour over time,
faketime(1) serves me good enough. But that's your design decision.

> It would be more appropriate to flag expired keys on tracker.d.o.

Another place might be DDPO - problem with both is visibility. If such a
check was implemented in Lintian, package maintainers get any issues
right in their face when building the package (which usually includes
running lintian). Tracker or DDPO, I these those only occasionally.
Other people's workflow might be different, though.

Also, in lintian the change was rather small and therefore easy to
implement.

> Expired keys also do not affect package quality in the archive.

How do the other signing key checks do that? Where's the difference?

> They
> still validate old release signatures. I believe a maintainer would
> have to sidestep uscan intentionally in order to upload a source
> package with an upstream public key that turns out to be useless.

Assuming upstream already updated the signing key, it would still avoid
breaking uscan in the future.

It would alert if the key already has expired, something I reckon about
libgpg-error (key expiry December 2019, new upstream release uploads in
March and June 2020).

It could (after an extension of the check) warn about an upcoming
expiration so the maintainer can update accordingly before breaking the
validation chain. And yes, that's time-based behaviour.

Christoph


signature.asc
Description: PGP signature

Bug#985817: O: git-remote-hg -- bidirectional bridge between Git and Mercurial

[Paul Wise]

Package: wnpp
Severity: normal
Control: affects -1 src:git-remote-hg
X-Debbugs-CC: Jonas Smedegaard 
 
Jonas Smedegaard has stated in #971061 and #debian-devel a desire to
stop maintaining git-remote-hg, so I am orphaning it now and will
attempt to do a QA upload fixing the RC bugs this week.

 jonas: re git-remote-hg, do you prefer to orphan it and I do a
  QA upload or keep you in maintainer and do an NMU?
 pabs: I prefer to let go of maintaining git-remote-hg - is
  it an option that you do the orphhaning + QA in one go?
 sure, will do this week some time

The package description is:
 This package provides the hg remote helper,
 which allows Git to read from and write to Mercurial repositories
 as though they were remote Git repositories.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#985816: override: libhtp2:libs/optional

[Sascha Steinbiss]

Package: ftp.debian.org
Severity: normal

This is in response to bug #931477 [1] dealing with libhtp being
priority extra despite having set the Priority field in d/control years
ago. Please change/remove the override to make libhtp compliant with the
current policy and establish libhtp2 as priority optional.

Thanks!
Sascha

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931477