Bug#993597: xdvik-ja: fails to show Japanese characters

[Atsuhito Kohda]

Hi,

On Mon, 06 Sep 2021 16:38:17 +0900, Youhei SASAKI wrote:

> This is the desired behavior that the fonts embedded
> in the final generated PDF file will be the same as the fonts used for
> display in pxdvi.

Generally it is desired but there are some users who don't
want to embed japanese fonts because they want small PDF.
So I think it is not bad to use dvipdfmx/kanjix.map
but it is much better if there are different settings
for dvipdfmx and pxdvi.

> (1) Set pxdviUse=true in updmap-sys:
> 
>  updmap-sys --setoption pxdviUse=true
> 
> (2) Set the appropriate font in kanji-config-updmap-sys
> 
> (3) Modify /etc/texmf/dvips/xdvi/config.xdvi to load xdvi-ptex.map
> generated by the above command instead of kanjix.map

config.xdvi is contained in xdvik-ja then it looks to me
the above procedure can be done in postinst (or something).
But I might be wrong.

> Of course, if I specify a specific font with kanji-config-updmap{,-sys},
> there is no problem with the display (as you reported).

If the above is difficult, it will be sufficient to explain
kanji-config-updmap in README.Debian but a notification
(with debconf?) will be helpful.

> Did you have no problems with previous versions?

I use LuaTeX for several (or more) years so the last time
I used xdvik-ja might be VFlib version, I guess.

Thanks for your maintenance.
2021-9-8(Wed)

-- 
 ***
 Atsuhito Kohda
 atsuhito_k AT tokushima-u.ac.jp

Bug#273323: scripting solution

[Daniel Lange]

This works reasonably well:

curl "https://www.debian.org/social_contract.en.html; |\
sed '/^/,/^<\/div> /{//!b};d' |\
pandoc -f html -t latex -V geometry:a4paper,margin=2cm -o social_contract.pdf

Bug#993864: ITP: taskserver -- taskwarrior synchronisation server

[Gordon Ball]

Hi Sergio

Note that there is already `taskd` in the archive (former name of
taskserver). It's not been uploaded for a number of years and I believed
that it was dead upstream (and I had lost interest in using it). If
you're interested you could either take over that package (and introduce
a new binary name), or I can rm it in favour of taskserver.

On Tue, Sep 07, 2021 at 09:24:51AM -0300, Sergio de Almeida Cipriano Junior 
wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Sergio de Almeida Cipriano Junior 
> X-Debbugs-Cc: debian-de...@lists.debian.org, sergios...@protonmail.com
> 
> * Package name: taskserver
>   Version : 1.1.0
>   Upstream Author : Göteborg Bit Factory 
> * URL : https://github.com/GothenburgBitFactory/taskserver
> * License : MIT
>   Programming Lang: C++
>   Description : taskwarrior synchronisation server
> 
> Taskserver is a daemon or service that will allow you to share tasks among
> different client applications, primarily Taskwarrior.

Bug#992748: systemd-cron: postinst error - CVE-2017-9525?

[Martin-Éric Racine]

su 5. syysk. 2021 klo 18.41 Salvatore Bonaccorso (car...@debian.org) kirjoitti:
>
> Control: clone 992748 -1
> Control: retitle -1 systemd-cron: CVE-2017-9525: group crontab to root 
> escalation via postinst
> Control: severity -1 important
> Control: found -1 1.5.16-1
> Control: found -1 1.5.14-2
> Control: tags 992748 - security
>
> Hi Chris,
>
> On Sun, Sep 05, 2021 at 02:49:40PM +0200, Chris Hofstaedtler wrote:
> > Control: tags -1 + security
> >
> > * Alexandre Detiste  [210905 12:47]:
> > > Le lun. 23 août 2021 à 04:57, Martin-Éric Racine
> > >  a écrit :
> > > > Setting up systemd-cron (1.5.17-1) ...
> > > > xargs: warning: options --max-args and --replace/-I/-i are mutually 
> > > > exclusive, ignoring previous --max-args value
> > > > Thanks.
> > >
> > > This was copy-pasted from src:cron, which must have the same bug now.
> >
> > src:cron removed the offending code as part of a security fix in
> > 2018:
> >
> > https://salsa.debian.org/debian/cron/-/commit/a10ab4e346e941aaa92f4b671a96895392b917af
> >
> > This would suggest CVE-2017-9525 also affects src:systemd-cron.
>
> Looks right and confirmed in a quick test. If the attacher has gained
> crontab group then further escalation is possible.
>
> Though technically those two bugs will be resolved at the same step I
> though to be good to separate the escalation issue and the error in
> postinst (but as said, they will be fixed basically together).
>
> Once fixed in unstable, can you please fix the issue as well via
> upcoming point releases for bullseye and buster? Similarly as for the
> src:cron case a DSA is not warranted.

Alexandre,

Do you have time to fix this now? If not, would it be okay for the
security team to make an NMU for all affected releases?

Martin-Éric

Bug#992563: transition: gdal

[Sebastiaan Couwenberg]

On 9/7/21 3:07 PM, Sebastiaan Couwenberg wrote:
> On 9/5/21 6:48 PM, Sebastian Ramacher wrote:
>> On 2021-08-20 11:32:16 +0200, Bas Couwenberg wrote:
>>> Package: release.debian.org
>>> Severity: normal
>>> User: release.debian@packages.debian.org
>>> Usertags: transition
>>> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
>>> Control: forwarded -1 
>>> https://release.debian.org/transitions/html/auto-gdal.html
>>> Control: block -1 by 992527 992528
>>>
>>> For the Debian GIS team I'd like to transition to GDAL 3.3.1.
>>>
>>> Most reverse dependencies rebuilt successfully with GDAL 3.3.1 from
>>> experimental as summarized below.
>>>
>>> libgdal-grass doesn't need a binNMU as the 3.3.1 version will be
>>> uploaded to unstable instead.
>>
>> Assuming that the version of pdal in experimental also builds fine
>> against the new version of gdal, please go ahead and also start the pdal
>> transition.
> 
> PDAL 2.3.0 also builds successfully with GDAL 3.3 so I'll upload that to
> unstable once gdal is built on all release architectures. The gdal
> upload to unstable had to wait a bit for 3.2.2+dfsg-3 to migrated to
> testing to fix #993334 there too.

gdal has built on all release architectures, and pdal has been uploaded
to unstable as well.

Kind regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#993904: libclc-12: tahiti-amdgcn-mesa-mesa3d.bc is missing

[Kiong-Gē Liāu]

Package: libclc-12
Version: 1:12.0.1-8
Severity: important
X-Debbugs-Cc: gliao...@pm.me

Dear Maintainer,



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

   Run clblast_test_xgemm will lead to the error message: 
/usr/lib/clc/tahiti-amdgcn-mesa-mesa3d.bc: no such file or directory
   In previously available "libclc-amdgcn" (the one built with llvm11), this 
tahiti-amdgcn-mesa-mesa3d.bc file is available under /usr/lib/clc

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


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.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 libclc-12 depends on:
ii  libclang-common-12-dev  1:12.0.1-8
ii  libclc-12-dev   1:12.0.1-8

libclc-12 recommends no packages.

libclc-12 suggests no packages.

-- no debconf information

Bug#993895: libosmpbf-dev: Compilation error with g++ when including /usr/include/osmpbf/osmformat.pb.h

[Sebastiaan Couwenberg]

Control: tags -1 moreinfo

On 9/7/21 10:58 PM, Jocelyn Jaubert wrote:
> Should these two .h files be regenerated?

Possibly.

osmpbf (1.5.0-1) was uploaded to unstable on 2021-01-07,
protobuf (3.12.4-1) on 2021-01-16 (unstable had 3.12.3-2).

osmpbf was not rebuilt for the new minor version,
as it didn't trigger a transition.

Can you share a complete test case which can be used to reproduce the issue?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#993910: aqemu: Custom icons for the virtual machines don't work

[Pablo Mercader Alcántara]

Package: aqemu
Version: 0.9.2-3
Severity: minor
Tags: patch
X-Debbugs-Cc: programingf...@gmail.com

Dear Maintainer,

Aqemu lets you set a custom icon for your virtual machines. You can do this
through the menu that shows when you click on the virtual machine and select
the "Change Icon" option. The dialog that gets shown offers 5 different radio
button options, the last of which is "Custom Icon". If you select some valid
image through the browse button or write the correct image path directly to the
text box and press the ok button, the virtual machine's icon changes
accordingly. Then you can use your virtual machine and everything is fine. You
close aqemu. If you open it again, you will see that the icon you just set is
not shown, just the name of the virtual machine you put your custom icon to.
The machine is fine, it still works, but the icon is not persisting from one
session to the next.

If you go again to "Change Icon" and then to the "Custom Icon" setting again,
you will see that the program has added "/usr/share/aqemu/" to the beginning of
the path of your custom image. If you delete this prefix part and press ok the
image shows again. The expected behaviour would be that the path to my custom
image is not modified and it is shown every time that I open aqemu without
the need for editing it every time.

I know a thing or two about programming and because I thought that only a small
change would be needed to repair this, I downloaded the source package and did
some tests. I was hoping that I only had to find where the program was adding
the "/usr/share/aqemu/" part and erase that, and everything would be fine. It
was a bit more complicated than that, but I did solve it in the end. So here is
a little patch that solves this problem for me:

diff --git a/src/VM.cpp b/src/VM.cpp
index a75951c..ac5fde1 100644
--- a/src/VM.cpp
+++ b/src/VM.cpp
@@ -3637,7 +3637,7 @@ bool Virtual_Machine::Load_VM( const QString _name )
 }
 }

-if ( ! abs_found )
+if ( ! abs_found && ! Icon_Path.startsWith("/") )
 {
 Icon_Path = settings.value(
"AQEMU_Data_Folder","").toString() + Icon_Path;
 }


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

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

Versions of packages aqemu depends on:
ii  libc6   2.31-13
ii  libgcc-s1   10.2.1-6
ii  libqt5core5a5.15.2+dfsg-9
ii  libqt5dbus5 5.15.2+dfsg-9
ii  libqt5gui5  5.15.2+dfsg-9
ii  libqt5network5  5.15.2+dfsg-9
ii  libqt5widgets5  5.15.2+dfsg-9
ii  libstdc++6  10.2.1-6
ii  libvncclient1   0.9.13+dfsg-2
ii  qemu-system-x86 [qemu-kvm]  1:5.2+dfsg-11

aqemu recommends no packages.

aqemu suggests no packages.

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

[Kevin J. McCarthy]

Antonio,

I was going through recent Mutt commits, and I realized my fix for this 
is not quite correct.


The IMAP UID field is a 32-bit unsigned integer.  I unfortunately 
modeled the new compare_uid() function after all the other ones use by 
Mutt for sorting, which just uses subtraction.  However, that won't work 
properly if the values differ more than a signed int can hold.


I think the probability of users encountering that in practice is low. 
But if you're going through the effort of back-porting the fix, please 
wait and I'll commit a corrected fix tomorrow.


-Kevin

Bug#993843: [Pkg-zsh-devel] Bug#993843: zsh-static segfaults immediately

[David]

On Tue, Sep 07, 2021 at 12:23:38PM +0200, Axel Beckert wrote:

...
David wrote:

...


Sorry for the trouble. I (and the tests) admittedly only test the
non-static zsh. And except for some special lookups known to be not
possible with static compiled binaries, I also don't expect any
difference in functionality with zsh-static.


Thank you both so much for looking into it!  And Vincent noticing that 
/lib/x86_64-linux-gnu/libc.so.6 is being opened and mapped into memory 
is very eye opening, for a static binary!


Please forgive my ignorange in the automated test suites, but perhaps 
for a future test, would verifying the expected exit status of these 
commands help intercept this (and any other) weird problem?  :-)


  zsh-static -f -c "exit 0"
  zsh-static -f -c "exit 1"


Now for a more thorough test:  Is it possible (or even desireable?) to 
test the binary to verify it really is statically linked?  Perhaps grep 
strace output looking for potential evidence of .so files getting opened 
in some lib directory?



strace zsh-static -f -c "exit 0" 2>&1 | grep 
'^open[a-zA-Z0-9_]*(.*"[^"]*lib.*\.so\>[^"]*"'

openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_compat.so.2", 
O_RDONLY|O_CLOEXEC) = 11
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 11
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2", 
O_RDONLY|O_CLOEXEC) = 11

echo $?

0

For comparison, busybox is statically linked:

strace /bin/busybox -f -c "exit 0" 2>&1 | grep '^open[a-zA-Z0-9_]*(.*"[^"]*lib.*\.so\>[^"]*"' 
echo $?

1

(And I also just tested a couple small C programs invoking printf and 
compiled with and without "-static".)


There's gotta be a better test to detect run-time opening of shared 
libraries.  (My regex of looking for open...("... .so ...") feels 
hackish.)


- David

Bug#993909: RM: tepl -- RoM; unmaintained library

[Jeremy Bicha]

Package: ftp.debian.org
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-Cc: t...@packages.debian.org

tepl has been archived upstream and GNOME have switched all their
projects away from using the tepl library.

Please remove tepl from Debian.

References:
https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/564
https://gitlab.gnome.org/Archive/tepl

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#993908: lintian: piping the output thru a pager generates single-word description

[Sandro Tosi]

Package: lintian
Version: 2.105.0
Severity: normal
X-Debbugs-Cc: mo...@debian.org

Hello,
i just upgraded from 2.104.0 and when piping the ouput thru a pager, i get:

W: pytest source: no-nmu-in-changelog
N:
N:   When
N:   you
N:   NMU
N:   a
N:   package,
N:   that
N:   fact
N:   should
N:   be
N:   mentioned
N:   on
N:   the
N:   first
N:   line
N:   in
N:   the
N:   changelog
N:   entry.
N:   Use
N:   the
N:   words
N:   "NMU"
N:   or
N:   "Non-maintainer
N:   upload"
N:   (case
N:   insensitive).

which is pretty ugly; there are some perl complains:

Use of uninitialized value $columns in subtraction (-) at 
/usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm line 343.
Use of uninitialized value $columns in subtraction (-) at 
/usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm line 358.
Increasing $Text::Wrap::columns from  to 19 to accommodate length of subsequent 
tab at /usr/lib/x86_64-linux-gnu/perl-base/Text/Wrap.pm line 49.
Text::Wrap::wrap("N:   Visibility: ", "N:   ", 
"warning\x{a}") called at /usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm 
line 368

Lintian::Output::EWI::describe_tag(Lintian::Output::EWI=HASH(0x5607cf4a7e60), 
Lintian::Tag=HASH(0x5607cb375fd8), undef) called at 
/usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm line 238

Lintian::Output::EWI::print_hint(Lintian::Output::EWI=HASH(0x5607cf4a7e60), 
Lintian::Hint::Standard=HASH(0x5607cef92518), HASH(0x5607cb0574c0)) called at 
/usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm line 148

Lintian::Output::EWI::issue_hints(Lintian::Output::EWI=HASH(0x5607cf4a7e60), 
ARRAY(0x5607cf41e258), HASH(0x5607cb0574c0)) called at 
/usr/share/lintian/bin/../lib/Lintian/Pool.pm line 311
Lintian::Pool::process(Lintian::Pool=HASH(0x5607c9a1a1b0), 
Lintian::Profile=HASH(0x5607cadb1a08), SCALAR(0x5607cb064078), 
HASH(0x5607cb0574c0)) called at /usr/bin/lintian line 720
Use of uninitialized value $columns in subtraction (-) at 
/usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm line 343.
Use of uninitialized value $columns in subtraction (-) at 
/usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm line 358.
Increasing $Text::Wrap::columns from  to 19 to accommodate length of subsequent 
tab at /usr/lib/x86_64-linux-gnu/perl-base/Text/Wrap.pm line 49.
Text::Wrap::wrap("N:   Visibility: ", "N:   ", 
"warning\x{a}") called at /usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm 
line 368

Lintian::Output::EWI::describe_tag(Lintian::Output::EWI=HASH(0x5607cf4a7e60), 
Lintian::Tag=HASH(0x5607cb451500), undef) called at 
/usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm line 238

Lintian::Output::EWI::print_hint(Lintian::Output::EWI=HASH(0x5607cf4a7e60), 
Lintian::Hint::Standard=HASH(0x5607cef92608), HASH(0x5607cb0574c0)) called at 
/usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm line 148

Lintian::Output::EWI::issue_hints(Lintian::Output::EWI=HASH(0x5607cf4a7e60), 
ARRAY(0x5607cf41e258), HASH(0x5607cb0574c0)) called at 
/usr/share/lintian/bin/../lib/Lintian/Pool.pm line 311
Lintian::Pool::process(Lintian::Pool=HASH(0x5607c9a1a1b0), 
Lintian::Profile=HASH(0x5607cadb1a08), SCALAR(0x5607cb064078), 
HASH(0x5607cb0574c0)) called at /usr/bin/lintian line 720
Use of uninitialized value $columns in subtraction (-) at 
/usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm line 343.
Use of uninitialized value $columns in subtraction (-) at 
/usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm line 358.
Increasing $Text::Wrap::columns from  to 19 to accommodate length of subsequent 
tab at /usr/lib/x86_64-linux-gnu/perl-base/Text/Wrap.pm line 49.
Text::Wrap::wrap("N:   Visibility: ", "N:   ", "info\x{a}") 
called at /usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm line 368

Lintian::Output::EWI::describe_tag(Lintian::Output::EWI=HASH(0x5607cf4a7e60), 
Lintian::Tag=HASH(0x5607cb3aa750), undef) called at 
/usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm line 238

Lintian::Output::EWI::print_hint(Lintian::Output::EWI=HASH(0x5607cf4a7e60), 
Lintian::Hint::Standard=HASH(0x5607cec0d028), HASH(0x5607cb0574c0)) called at 
/usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm line 148

Lintian::Output::EWI::issue_hints(Lintian::Output::EWI=HASH(0x5607cf4a7e60), 
ARRAY(0x5607cf41e258), HASH(0x5607cb0574c0)) called at 
/usr/share/lintian/bin/../lib/Lintian/Pool.pm line 311
Lintian::Pool::process(Lintian::Pool=HASH(0x5607c9a1a1b0), 
Lintian::Profile=HASH(0x5607cadb1a08), SCALAR(0x5607cb064078), 
HASH(0x5607cb0574c0)) called at /usr/bin/lintian line 720
Use of uninitialized value $columns in subtraction (-) at 
/usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm line 343.
Use of uninitialized value $columns in subtraction (-) at 
/usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm line 358.
Increasing $Text::Wrap::columns from  to 19 to accommodate length of subsequent 
tab at 

Bug#993843: [Pkg-zsh-devel] Bug#993843: zsh-static segfaults immediately

[Vincent Lefevre]

Control: tags -1 upstream

I've found the cause of the use of the shared C library and the crash.
I can notice the following warnings:

gcc -static   -o zsh main.o  `cat stamp-modobjs`   -lgdbm -lpcre -lcap 
-lncursesw -ltinfo -ltinfo -lrt -lm  -lc
/usr/bin/ld: options.o: in function `dosetopt':
./obj-static/Src/../../Src/options.c:830: warning: Using 'initgroups' in 
statically linked applications requires at runtime the shared libraries from 
the glibc version used for linking
/usr/bin/ld: Modules/parameter.o: in function `get_all_groups':
./obj-static/Src/Modules/../../../Src/Modules/parameter.c:2058: warning: Using 
'getgrgid' in statically linked applications requires at runtime the shared 
libraries from the glibc version used for linking
/usr/bin/ld: Modules/files.o: in function `bin_chown':
./obj-static/Src/Modules/../../../Src/Modules/files.c:763: warning: Using 
'getgrnam' in statically linked applications requires at runtime the shared 
libraries from the glibc version used for linking
/usr/bin/ld: params.o: in function `usernamesetfn':
./obj-static/Src/../../Src/params.c:4420: warning: Using 'getpwnam' in 
statically linked applications requires at runtime the shared libraries from 
the glibc version used for linking
/usr/bin/ld: options.o: in function `dosetopt':
./obj-static/Src/../../Src/options.c:822: warning: Using 'getpwuid' in 
statically linked applications requires at runtime the shared libraries from 
the glibc version used for linking

This is exactly the issue we are seeing. Details about why the shared
C library is used with these functions:

  
https://stackoverflow.com/questions/15165306/compile-a-static-binary-which-code-there-a-function-gethostbyname
  https://bugzilla.redhat.com/show_bug.cgi?id=111298

Additional details about the upstream bug in my mail to zsh-workers,
Cc'ed to this bug, i.e.

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993843#46

For the Debian build, I suggest to turn the above warning into
an error (if possible) in order to make sure that the issue is
not left unnoticed (i.e. that the bug does not reappear after
it is fixed, with future changes in zsh).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#993843: [BUG] With --disable-dynamic-nss, not all functions calls are protected

[Vincent Lefevre]

[Posted to zsh-workers, with a Cc to the Debian bug.]

While looking at Debian bug 993843

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993843
  (zsh-static segfaults immediately)

I can notice the following warnings:

gcc -static   -o zsh main.o  `cat stamp-modobjs`   -lgdbm -lpcre -lcap 
-lncursesw -ltinfo -ltinfo -lrt -lm  -lc
/usr/bin/ld: options.o: in function `dosetopt':
./obj-static/Src/../../Src/options.c:830: warning: Using 'initgroups' in 
statically linked applications requires at runtime the shared libraries from 
the glibc version used for linking
/usr/bin/ld: Modules/parameter.o: in function `get_all_groups':
./obj-static/Src/Modules/../../../Src/Modules/parameter.c:2058: warning: Using 
'getgrgid' in statically linked applications requires at runtime the shared 
libraries from the glibc version used for linking
/usr/bin/ld: Modules/files.o: in function `bin_chown':
./obj-static/Src/Modules/../../../Src/Modules/files.c:763: warning: Using 
'getgrnam' in statically linked applications requires at runtime the shared 
libraries from the glibc version used for linking
/usr/bin/ld: params.o: in function `usernamesetfn':
./obj-static/Src/../../Src/params.c:4420: warning: Using 'getpwnam' in 
statically linked applications requires at runtime the shared libraries from 
the glibc version used for linking
/usr/bin/ld: options.o: in function `dosetopt':
./obj-static/Src/../../Src/options.c:822: warning: Using 'getpwuid' in 
statically linked applications requires at runtime the shared libraries from 
the glibc version used for linking

This is exactly the issue we are seeing in Debian: zsh-static
segfaults after upgrading glibc, and this issue disappears
after rebuilding zsh-static with the new glibc. And I could
see in the strace output that the shared C library libc.so.6
is read, while zsh-static should entirely be static.

However, --disable-dynamic-nss is used to build zsh-static,
so that the above functions should not be called.

I can see that Src/zsh_system.h has

#if defined(HAVE_INITGROUPS) && !defined(DISABLE_DYNAMIC_NSS)
# define USE_INITGROUPS
#endif

#if defined(HAVE_GETGRGID) && !defined(DISABLE_DYNAMIC_NSS)
# define USE_GETGRGID
#endif

#if defined(HAVE_GETGRNAM) && !defined(DISABLE_DYNAMIC_NSS)
# define USE_GETGRNAM
#endif

#if defined(HAVE_GETPWENT) && !defined(DISABLE_DYNAMIC_NSS)
# define USE_GETPWENT
#endif

#if defined(HAVE_GETPWNAM) && !defined(DISABLE_DYNAMIC_NSS)
# define USE_GETPWNAM
#endif

#if defined(HAVE_GETPWUID) && !defined(DISABLE_DYNAMIC_NSS)
# define USE_GETPWUID
#endif

But concerning the first warning, Src/options.c contains

# ifdef HAVE_INITGROUPS

I suppose that the test should have been

# ifdef USE_INITGROUPS

like in Src/params.c, which has

# ifdef USE_INITGROUPS
initgroups(x, pswd->pw_gid);
# endif

I suspect that there is the same issue with the other warnings.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#993907: transmission-qt segfaults when adding a torrent

[Antoine Beaupre]

Package: transmission-qt
Version: 3.00-1
Severity: normal

I have a reproducible, complete crash when adding a torrent with
transmission-qt on a remote transmission-daemon server:

sep 07 20:43:54 angela kernel: transmission-qt[63169] segfault at 25 ip 
7fe0b62fa7a9 sp 7ffd62fd4738 error 4 in 
libQt5Core.so.5.15.2[7fe0b623a000+2fe000] 
sep 07 20:43:54 angela kernel: Code: 90 48 8b 02 48 8b 36 41 89 c9 48 8b 48 10 
8b 56 04 44 8b 40 04 48 03 76 10 48 01 c1 e9 b0 fc ff ff 49 89 f0 48 8b 07 49 
8b 10 <48> 63 70 04 48 63 4a 04 39 ce 75 4b 48 83 ec 08 48 8d 3d a0 51 24 

gdb has this backtrace:

(gdb) bt
#0  0x767697a9 in operator==(QString const&, QString const&) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#1  0x776cf3e5 in QLabel::setText(QString const&) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#2  0x555c302f in FreeSpaceLabeloperator() (__closure=0x7fffce00, r=...) at 
FreeSpaceLabel.cc:87
#3  RpcQueueoperator() (r=..., 
this=0x7fffce00) at RpcQueue.h:98
#4  std::_Function_handler(const QFuture&), 
RpcQueue::normalizeFunc(const Func&) [with Func = 
FreeSpaceLabel::onTimer()::; typename 
std::enable_if::type, void>::value>::type*  = 0; 
RpcQueue::QueuedFunction = std::function(const 
QFuture&)>]:: >::_M_invoke(const 
std::_Any_data &, const QFuture &) (__functor=..., __args#0=...)
at /usr/include/c++/9/bits/std_function.h:286
#5  0x555f3eb1 in std::function 
(QFuture const&)>::operator()(QFuture const&) const 
(__args#0=..., this=0x7fffce00)
at /usr/include/c++/9/bits/std_function.h:688
#6  RpcQueue::runNext (this=0x55dcf590, response=...) at RpcQueue.cc:76
#7  0x555f47c8 in RpcQueue::stepFinished (this=0x55dcf590) at 
RpcQueue.cc:48
#8  0x768fe5e0 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x766f0df5 in QFutureWatcherBase::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x7759b15f in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#11 0x768c7fca in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x768caa01 in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#13 0x7691fe93 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x75645e6b in g_main_context_dispatch () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x75646118 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x756461cf in g_main_context_iteration () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x7691f51f in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x768c698b in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#19 0x768cec00 in QCoreApplication::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x55590a61 in main (argc=, argv=0x7fffd628) at 
Application.cc:649

Strangely, the torrent does get added and I can restart
transmission-qt to see it correctly, so I am not marking this as RC,
but it does feel pretty bad.

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), 
(1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 transmission-qt depends on:
ii  libc62.31-13
ii  libcurl4 7.74.0-1.3+b1
ii  libevent-2.1-7   2.1.12-stable-1
ii  libgcc-s110.2.1-6
ii  libminiupnpc17   2.2.1-1
ii  libnatpmp1   20150609-7.1
ii  libqt5core5a 5.15.2+dfsg-9
ii  libqt5dbus5  5.15.2+dfsg-9
ii  libqt5gui5   5.15.2+dfsg-9
ii  libqt5network5   5.15.2+dfsg-9
ii  libqt5widgets5   5.15.2+dfsg-9
ii  libssl1.11.1.1k-1+deb11u1
ii  libstdc++6   10.2.1-6
ii  transmission-common  3.00-1
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages transmission-qt recommends:
ii  xdg-utils  1.1.3-4.1

transmission-qt suggests no packages.

-- no debconf information

Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way

[Felix Lechner]

Hi,

On Fri, Dec 4, 2020 at 7:24 PM gregor herrmann  wrote:
>
> Could we maybe wait for a fix for #968154 in debian-policy?

I'm not sure what the policy team's intentions are, but Lintian's Data
module no longer provides the policy information. [1] We now keep the
data in a JSON file that is more reliably exchanged and updated. [2]
As a courtesy to this package (and to the policy team) Lintian now
ships an executable "/usr/share/lintian/private/latest-policy-version"
that provides the latest policy information. [3] Please use that
executable to obtain the information you require.

As a side note, Lintian no longer ships its private modules in the
public Perl path. [4] Please do not use our modules directly anymore.
We would be happy to give you access to additional data via
executables, if needed.

Marking this bug "important" because Debian CI is failing (but
separately, since I copied the policy bug). Thanks!

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/commit/d2f692f564ac725a0eb58a7d62abe57f66cdc753
[2] 
https://salsa.debian.org/lintian/lintian/-/commit/21fd3c7d1ae24bf3bb00ffbab6a0dd99acd3503c
[3] 
https://salsa.debian.org/lintian/lintian/-/commit/d43799ae30f55e8a211281295d4508b11d022147
[4] https://bugs.debian.org/968011

Bug#993906: ITP: sqlmodel -- SQL databases in Python, designed for simplicity, compatibility, and robustness

[Sandro Tosi]

Package: wnpp
Severity: wishlist
Owner: Sandro Tosi 
X-Debbugs-Cc: debian-de...@lists.debian.org, mo...@debian.org

* Package name: sqlmodel
  Version : 0.0.4
  Upstream Author : Sebastián Ramírez
* URL : https://github.com/tiangolo/sqlmodel
* License : MIT
  Programming Lang: Python
  Description : SQL databases in Python, designed for simplicity, 
compatibility, and robustness

 SQLModel is a library for interacting with SQL databases from Python code, with
 Python objects. It is designed to be intuitive, easy to use, highly compatible,
 and robust.
 .
 SQLModel is based on Python type annotations, and powered by Pydantic and
 SQLAlchemy.
 .
 The key features are:
 .
  * Intuitive to write: Great editor support. Completion everywhere. Less time
debugging. Designed to be easy to use and learn. Less time reading docs.
  * Easy to use: It has sensible defaults and does a lot of work underneath to
simplify the code you write.
  * Compatible: It is designed to be compatible with FastAPI, Pydantic, and
SQLAlchemy.
  * Extensible: You have all the power of SQLAlchemy and Pydantic underneath.
  * Short: Minimize code duplication. A single type annotation does a lot of
work. No need to duplicate models in SQLAlchemy and Pydantic.

 SQLModel is designed to simplify interacting with SQL databases in FastAPI
 applications, it was created by the same author.
 .
 It combines SQLAlchemy and Pydantic and tries to simplify the code you write as
 much as possible, allowing you to reduce the code duplication to a minimum, but
 while getting the best developer experience possible.
 .
 SQLModel is, in fact, a thin layer on top of Pydantic and SQLAlchemy, carefully
 designed to be compatible with both.

Bug#993843: [Pkg-zsh-devel] Bug#993843: zsh-static segfaults immediately

[Vincent Lefevre]

On 2021-09-07 22:22:34 +, David wrote:
> On Tue, Sep 07, 2021 at 12:23:38PM +0200, Axel Beckert wrote:
> > ...
> > David wrote:
> > > ...
> > 
> > Sorry for the trouble. I (and the tests) admittedly only test the
> > non-static zsh. And except for some special lookups known to be not
> > possible with static compiled binaries, I also don't expect any
> > difference in functionality with zsh-static.
> 
> Thank you both so much for looking into it!  And Vincent noticing that
> /lib/x86_64-linux-gnu/libc.so.6 is being opened and mapped into memory is
> very eye opening, for a static binary!
> 
> Please forgive my ignorange in the automated test suites, but perhaps for a
> future test, would verifying the expected exit status of these commands help
> intercept this (and any other) weird problem?  :-)
> 
>   zsh-static -f -c "exit 0"
>   zsh-static -f -c "exit 1"

No, this wouldn't help, because the libc6 version zsh-static has
been compiled against would be the same as the one for the test.

Here, the issue is that zsh-static is built against some libc6
version (at this time, zsh-static would work as expected), then
libc6 is upgraded to some newer version, and zsh-static no longer
works.

I'd say that it would be difficult to design a test framework for
up-to-date Debian/unstable that would be useful in practice (since
as soon as a new version of some package gets in unstable, all the
other packages would need to be tested), except for non-regression
tests about particular bugs like this one.

> Now for a more thorough test:  Is it possible (or even desireable?) to test
> the binary to verify it really is statically linked?  Perhaps grep strace
> output looking for potential evidence of .so files getting opened in some
> lib directory?
> 
> > strace zsh-static -f -c "exit 0" 2>&1 | grep 
> > '^open[a-zA-Z0-9_]*(.*"[^"]*lib.*\.so\>[^"]*"'
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_compat.so.2", 
> O_RDONLY|O_CLOEXEC) = 11
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 11
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2", 
> O_RDONLY|O_CLOEXEC) = 11
> > echo $?
> 0

Perhaps.

> For comparison, busybox is statically linked:
> 
> > strace /bin/busybox -f -c "exit 0" 2>&1 | grep
> > '^open[a-zA-Z0-9_]*(.*"[^"]*lib.*\.so\>[^"]*"' echo $?
> 1

busybox is dynamically linked:

$ file /bin/busybox
/bin/busybox: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=280a5ddfb6379abacc1a6c7a6024876f653cd6bf, for GNU/Linux 3.2.0, 
stripped

> (And I also just tested a couple small C programs invoking printf and
> compiled with and without "-static".)

I confirm that no shared libraries are read with -static on simple
programs.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#993905: lxc-create fails GPG checkserver due to keyserver depreciation

[Kyle]

Package: lxc
Version: 1:4.0.6-2
Severity: important
X-Debbugs-Cc: kyleantis...@gmail.com

Dear Maintainer,


lxc-create fails with the following error message caused by
sks-keyservers.net going offline, The lxc package currently in testing
includes a patch that fixes the issue by changing the keyserver from
pool.sks-keyservers.net to keyserver.ubuntu.com. This impacts both
oldstable and stable as of writing this.

Upstream patch that fixed the issue
https://github.com/lxc/lxc/commit/f2a5d95d00a55bed27ef9920d67617cc75fecad8

Error message
Setting up the GPG keyring
ERROR: Unable to fetch GPG key from keyserver
lxc-create: demo-container: lxccontainer.c: create_run_template: 1616 Failed to 
create container from template
lxc-create: demo-container: tools/lxc_create.c: main: 319 Failed to create 
container demo-container

Temporary work around
Setting environment variable DOWNLOAD_KEYSERVER to a working keyserver
allows it to work as expected.


-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

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

Versions of packages lxc depends on:
ii  bridge-utils 1.7-1
ii  debconf [debconf-2.0]1.5.77
ii  dnsmasq-base [dnsmasq-base]  2.85-1
ii  iproute2 5.10.0-4
ii  iptables 1.8.7-1
ii  libc62.31-13
ii  libcap2  1:2.44-1
ii  libgcc-s110.2.1-6
ii  liblxc1  1:4.0.6-2
ii  libseccomp2  2.5.1-1
ii  libselinux1  3.1-3
ii  lsb-base 11.1.0

Versions of packages lxc recommends:
ii  apparmor   2.13.6-10
ii  debootstrap1.0.123
ii  dirmngr2.2.27-2
ii  gnupg  2.2.27-2
ii  libpam-cgfs1:4.0.6-2
ii  lxc-templates  3.0.4-5
ii  lxcfs  4.0.7-1
ii  openssl1.1.1k-1+deb11u1
ii  rsync  3.2.3-4
ii  uidmap 1:4.8.1-1
ii  wget   1.21-1

Versions of packages lxc suggests:
pn  btrfs-progs  
ii  lvm2 2.03.11-2.1
pn  python3-lxc  

-- debconf information excluded

Bug#993893: libxcrypt-source: Update symbols for ARC to match its real glibc minver 2.32

[Alexey Brodkin]

Package: libxcrypt-source
Version: 4.4.25-2
Severity: normal
Tags: patch
Usertags: rebootstrap

Dear Maintainer,

In 4.4.25-2 version ARC symbols were added,
but since before very recenly we used back-ported glibc 2.31 for ARC
those aforementioned symbols were generated while building with glibc 2.31.

But now glibc 2.32 is available in Unstable and moreover it's
set as a "minver" for ARC, see [1] we need to update ARC symbols.
Otherwise on libxcrypt building 2.32-based symbols get reported as missing.

[1] https://salsa.debian.org/md/libxcrypt/-/blob/master/lib/libcrypt.minver#L63

Please pardon me that extra noise, but I'm still ramping-up on Debian stuff
and keep making stupid mistakes here and there.

Below is a diff against 4.4.25-2:
-->8
diff --git a/debian/libcrypt1.symbols.arc b/debian/libcrypt1.symbols.arc
index 4a22dd3..ebbbc05 100644
--- a/debian/libcrypt1.symbols.arc
+++ b/debian/libcrypt1.symbols.arc
@@ -1,10 +1,10 @@
 libcrypt.so.1 libcrypt1 #MINVER#
 #include "libcrypt1.symbols.common"
- GLIBC_2.31@GLIBC_2.31 1:4.1.0
- crypt@GLIBC_2.31 1:4.1.0
- crypt_r@GLIBC_2.31 1:4.1.0
- encrypt@GLIBC_2.31 1:4.1.0
- encrypt_r@GLIBC_2.31 1:4.1.0
- fcrypt@GLIBC_2.31 1:4.1.0
- setkey@GLIBC_2.31 1:4.1.0
- setkey_r@GLIBC_2.31 1:4.1.0
+ GLIBC_2.32@GLIBC_2.32 1:4.4.25
+ crypt@GLIBC_2.32 1:4.4.25
+ crypt_r@GLIBC_2.32 1:4.4.25
+ encrypt@GLIBC_2.32 1:4.4.25
+ encrypt_r@GLIBC_2.32 1:4.4.25
+ fcrypt@GLIBC_2.32 1:4.4.25
+ setkey@GLIBC_2.32 1:4.4.25
+ setkey_r@GLIBC_2.32 1:4.4.25
-->8


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

Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/12 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#993821: After upgrading libc, some services are unable to restart (including systemd-resolved)

[Michael Hudson-Doyle]

On Wed, 8 Sept 2021 at 07:04, Michael Biebl  wrote:

> Hi Aurelien
>
> Am 07.09.21 um 12:41 schrieb Aurelien Jarno:
> > Hi,
> >
> > On 2021-09-07 10:39, Michael Hudson-Doyle wrote:
>
> >> What's happening is that systemd is running with the old glibc, forks
> and
> >> then does NSS things that cause the new glibc's NSS modules to load and
> >> they don't necessarily work, leading to failures in any unit that
> specifies
> >> User=. At least for Ubuntu's builds the NSS modules seem to be ABI
> >> compatible between 2.32 and 2.33 (I didn't try 2.31 vs 2.32) but they
> are
> >> definitely not between 2.33 and 2.34.
> >
> > Thanks for this feedback and the pointer to the patch used in Ubuntu. It
> > seems to be a good solution, and matches what is done for other init
> > systems.
> >
> > On the other hand, the problem is supposed to only happen for major
> > glibc version upgrade where the NSS modules might have a different ABI.
> > In that regard, I would be tempted to restart it only for major versions
> > upgrade like it's done for other daemons. Now if the systemd maintainers
> > consider it's fine restarting it for each glibc upgrade, we should
> > probably go that way.
>
> I guess you are in a better position to make a judgement call here. If I
> read the glibc bug report correctly, there aren't strictly any
> guarantees regarding NSS modules. What that means for glibc minor
> updates, I'm not really in a position to tell.
>

I think in practice minor version updates are probably going to be fine
here, but also I think careful reexecing on every update is also likely to
be fine in practice.

If you wanted to be suuurrr paranoid, I guess you could embed in
the glibc postinst knowledge of which prior versions have binary-compatible
NSS modules but that seems like a lot of work for not much benefit (would
you only have to care about nss_files compatibility, or the full set?).


> Fwiw, I don't have a better proposal then Michael's patch he added to
> Ubuntu. We could run with that and if it causes problems, reiterate on it.
>

Yeah, the point where we start to offer updates to 21.10 will at the least
provide some data on how safe Ubuntu's approach is...

Cheers,
mwh

Bug#973881: Result of 'git debrebase make-patches' with 'diff.noprefix' git config confuses dgit

[Ian Jackson]

Didier 'OdyX' Raboud writes ("Bug#973881: Result of 'git debrebase 
make-patches' with 'diff.noprefix' git config confuses dgit"):
> after toggling a git diff option globally with:
>   git config --global diff.noprefix true
> 
> I noticed that dgit (at least build-source, but others too) started to fail
> comparing patches-applied with patches-unapplied trees.

How unfortunate.

> I'm reporting this against git debrebase, because it seems to me that git
> debrebase ought to always format patches in a known-to-work format, no matter
> what the user has configured for his personal git usage.

Quite so.

Unfortunately it is not so easy to do this right.  We have a private
tree but must choose which git config settings to inherit and which to
override.

This mostly works, but for settings where
  git config --local --add $key
breaks, it doesn't.  We have to manually add those with
  git config diff.noprefix 0
(in this case).

Thanks for the report!

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#977426: git-debrebase: complains about undocumented snag: -fanchor-treated

[Ian Jackson]

Wookey writes ("Bug#977426: git-debrebase: complains about undocumented snag: 
-fanchor-treated"):
> $ git debrebase new-upstream 20.05
> git-debrebase: snag detected (-fanchor-treated): old anchor is recognised due 
> to --anchor, cannot check upstream
> 
> I don't understand what it is complaining about and whilst -fanchor is
> described in man 1 git-debrebase -fanchor-treated is not. So
> documenting this would be good. If you explain it to me I could try
> and document it myself and supply a patch.

Hi.  Sorry we didn't reply at the time...

The manpage has this to say about --anchor:

   --anchor=

   Treats  as an anchor.  This overrides the usual
   logic which automatically classifies commits as anchors,
   pseudomerges, delta queue commits, etc.

   It also disables some coherency checks which depend on
   metadata extracted from its commit message, so it is a snag
   if  is the anchor for the previous upstream
   version in git-debrebase new- upstream operations.

The snag mentioned in that 2nd paragraph is precisely
-fanchor-treated.

You say "-fanchor is described in man 1 git-debrebase".  I think that
was a slip and you meant to say that "--anchor is described...".
Since none of the snags are otherwise documented.

I agree that that wording is not helpful.  It ought to say what you
need to check for yourself.  Otherwise how are you to know whether
it's right to -f it ?

> Adding -fanchor-treated makes the rebase proceed as expected, but I'd
> like to understand why that is needed rather than blindly adding it.

Quite so.

I will do this:

 diff --git a/git-debrebase.1.pod b/git-debrebase.1.pod
 index 639b07d2e..17e750a98 100644
 --- a/git-debrebase.1.pod
 +++ b/git-debrebase.1.pod
 @@ -532,9 +532,12 @@ commits as anchors, pseudomerges, delta queue commits, 
etc.
  It also disables some coherency checks
  which depend on metadata extracted from its commit message,
  so
 -it is a snag if  is the anchor
 +it is a snag (C<-fanchor-treated>) if  is the anchor
  for the previous upstream version in
  git-debrebase new-upstream operations.
 +You have to check yourself that the new upstream
 +is fast forward from the old one,
 +and has the right components (as if applicable).

  =item --dgit=

I'm hoping to upload RSN, so will close this bug then.  Feel free to
suggest better wording (in a new bug, if applicable).

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#709639: backup: root entry needed in /etc/aliases

[Charles Curley]

On Fri, 29 Aug 2014 04:47:09 +0100 Jose M Calhariz
 wrote:
> 
> Hi,
> 
> what is your local mail server?  exim4, postfix?
> 
>  Jose Calhariz

Postfix. But the default on Debian is exim.

Sorry to take so long to answer this.


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Bug#993903: xfce4-session: After resuming from suspend, the synaptic touchpad was no longer working

[Wirawan Purwanto]

Package: xfce4-session
Version: 4.12.1-6
Severity: important

Dear Maintainer,

My laptop is running stock Debian 10 with up-to-date software,
and no custom kernel or such modifications.
I am using the stock XFCE packages provided by Debian.
I notice that at random times (not quite sure the context of the
happenings, i.e. the precise cause of the issue), the synaptic
touchpad was no longer working after the laptop was suspended to RAM
then resumed.

Note: I file this bug against "xfce4-session" initially because I do
not know which package may cause the issue.

Desktop: XFCE, under Debian 10
Hardware: Lenovo Thinkpad T450s
Screen-saver: xscreensaver
(It has light-locker installed but not running)

After resume from suspend, the mouse was locked.
Clicking works, but the mouse would not move.

The last time this happened, the sequence of events was as follows:

1) the computer was completely connected to external USB mouse and keyboard

2) the computer was suspended using "xfce4-session-logout --suspend"

3) the peripheral devices were removed

4) the computer was resumed

Upon resumption, the mouse no longer moves according to the synaptic
touchpad's input.
But pressing the mechanical buttons (left/right buttons) worked.

I am not 100% confident if the external device being removed when
sleeping was the cause of the touchpad not working.

At first I thought this was a hardware error.
But today I diagnosed the situation with "libinput debug-events",
the movements of finger on the touchpad were registered, like:

event12  POINTER_MOTION+4.68s0.00/ -0.48 ( +0.00/ -1.00)
event12  POINTER_MOTION+4.70s0.48/  0.00 ( +1.00/ +0.00)
event12  POINTER_MOTION+4.70s0.00/ -1.04 ( +0.00/ -2.00)
event12  POINTER_MOTION+4.71s0.00/ -0.52 ( +0.00/ -1.00)
event12  POINTER_MOTION+4.74s   -0.38/  0.00 ( -1.00/ +0.00)
event12  POINTER_MOTION+4.75s0.00/ -0.38 ( +0.00/ -1.00)
event12  POINTER_MOTION+4.76s   -0.48/  0.00 ( -1.00/ +0.00)
event12  POINTER_MOTION+4.77s   -1.03/  0.00 ( -2.00/ +0.00)

Which means, the hardware was fine, and the hardware driver was fine too.
But for some reason the events was ignored by the desktop or the GUI.
Or was the touchpad input grabbed by a program--a screen saver??

This laptop has been running on Debian 10 since April 2021.
The issue only happened a few times.
Usually, when this issue happened, I could put the laptop through one
more suspend/resume cycle, then the touchpad became responsive again.
Which is annoying but not too bad.

But with the latest system reboot, the issue happened again only within 2-3
suspend/resume cycles from the boot-up.
This was "the last time this issue happened" again as described in
detail above.
But this time, the touchpad never became responsive again, despite the
"libinput" program showed activites from the hardware while my finger
was moving on the touchpad.
This is now counterproductive, since I am treating the OS as a
"server OS", i.e. I expect to rarely reboot the system so that I don't
have to restart all the open windows and documents.

PS: I will wait for responses from the community for a while before
rebooting the current OS.  I am doing so to keep this system running
in this erroneous state so that you can get whatever diagnostics
needed from this buggy state, if at all possible.

Thanks,
Wirawan

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

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

Versions of packages xfce4-session depends on:
ii  libatk1.0-02.30.0-2
ii  libc6  2.28-10
ii  libcairo2  1.16.0-4+deb10u1
ii  libdbus-1-31.12.20-0+deb10u1
ii  libdbus-glib-1-2   0.110-4
ii  libfontconfig1 2.13.1-2
ii  libfreetype6   2.9.1-3+deb10u2
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libglib2.0-0   2.58.3-2+deb10u3
ii  libgtk2.0-02.24.32-3
ii  libice62:1.0.9-2
ii  libpango-1.0-0 1.42.4-8~deb10u1
ii  libpangocairo-1.0-01.42.4-8~deb10u1
ii  libpangoft2-1.0-0  1.42.4-8~deb10u1
ii  libpolkit-gobject-1-0  0.105-25
ii  libsm6 2:1.2.3-1
ii  libwnck22  2.30.7-6
ii  libx11-6   2:1.6.7-1+deb10u2
ii  libxfce4ui-1-0 4.12.1-3
ii  libxfce4util7  4.12.1-3
ii  libxfconf-0-2  4.12.1-1
ii  xfce4-settings 4.12.4-1
ii  xfconf 4.12.1-1

Versions of packages xfce4-session recommends:
ii  dbus-x11   1.12.20-0+deb10u1
ii  libpam-systemd 241-7~deb10u8
ii  light-locker   1.8.0-3
ii  systemd-sysv   241-7~deb10u8

Bug#993902: arm64: enable RK3399 "VPU" drivers: Hantro, Rockchip Video Decoder

[Nathan Schulte]

Source: linux
Severity: wishlist
X-Debbugs-Cc: nmschu...@gmail.com

For example, the Pine64 ROCKPro64 single board computer with the
Rockchip RK3399 SoC is unable to leverage hardware video codec
acceleration without these kernel modules.

Importantly, please enable CONFIG_VIDEO_ROCKCHIP_VDEC.  Also consider
CONFIG_VIDEO_HANTRO_ROCKCHIP.

Thank you.

--
Nate

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

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

Bug#993867: glewlwyd: possible buffer overflow on webauthn registration

[Nicolas Mora]

Le 2021-09-07 à 15 h 03, Salvatore Bonaccorso a écrit :


Embarassing, I can assure you I did check the git repo.



That's ok, the commit message wasn't about the buffer overflow and it 
was a few weeks ago, so no worries :)


/Nicolas

Bug#993901: gitlab upgrade from 13.12.9 to 14.0.10 fails with error ArgumentError: wrong number of arguments (given 0, expected 1)

[Pirate Praveen]

Package: gitlab
Version: 14.0.10-1
Severity: important

When trying to upgrade gitlab from 13.12.9 to 14.0.10, installation 
fails during the db migration step with error (log below)


== 20210513163904 CleanupMoveContainerRegistryEnabledToProjectFeature: 
migrating

rake aborted!
StandardError: An error has occurred, all later migrations canceled:

wrong number of arguments (given 0, expected 1)
/usr/share/gitlab/config/initializers/postgresql_cte.rb:99:in 
`build_arel'

/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/relation.rb:583:in
`delete_all'
/usr/share/gitlab/db/post_migrate/20210513163904_cleanup_move_container_registry_enabled_to_proj
ect_feature.rb:16:in `up'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:870:i
n `public_send'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:870:i
n `exec_migration'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:851:i
n `block (2 levels) in migrate'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:850:i
n `block in migrate'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/connection_adapter
s/abstract/connection_pool.rb:462:in `with_connection'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:849:i
n `migrate'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:1037:
in `migrate'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:1329:
in `block in execute_migration_in_transaction'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:1382:
in `ddl_transaction'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:1328:
in `execute_migration_in_transaction'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:1302:
in `each'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:1302:
in `migrate_without_lock'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:1251:
in `block in migrate'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:1401:
in `block in with_advisory_lock'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:1416:
in `block in with_advisory_lock_connection'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/connection_adapter
s/abstract/connection_pool.rb:462:in `with_connection'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:1416:
in `with_advisory_lock_connection'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:1397:
in `with_advisory_lock'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:1251:
in `migrate'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:1086:
in `up'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:1061:
in `migrate'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/tasks/database_tas
ks.rb:237:in `migrate'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/railties/databases
.rake:92:in `block (3 levels) in '
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/railties/databases
.rake:90:in `each'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/railties/databases
.rake:90:in `block (2 levels) in '
/usr/share/rubygems-integration/all/gems/rake-13.0.3/exe/rake:27:in 
`'


Caused by:
ArgumentError: wrong number of arguments (given 0, expected 1)
/usr/share/gitlab/config/initializers/postgresql_cte.rb:99:in 
`build_arel'

/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/relation.rb:583:in
`delete_all'
/usr/share/gitlab/db/post_migrate/20210513163904_cleanup_move_container_registry_enabled_to_proj
ect_feature.rb:16:in `up'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:870:i
n `public_send'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:870:i
n `exec_migration'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:851:i
n `block (2 levels) in migrate'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:850:i
n `block in migrate'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/connection_adapter
s/abstract/connection_pool.rb:462:in `with_connection'
/usr/share/rubygems-integration/all/gems/activerecord-6.1.4/lib/active_record/migration.rb:849:i
n 

Bug#931947: printer-driver-brlaser: Brother HL-1110 printer is unsupported in Debian, but it works upstream

[Thorsten Alteholz]

Hi Jose,

thanks a lot for reporting bug #931947 for package printer-driver-brlaser.

Meanwhile two new versions of the software have been uploaded. As you 
reported that this bug has been fixed by upstream, we can probably close 
this bug..


Can you please confirm that the current version of printer-driver-brlaser 
is no longer affected by this bug?


Best regards
Thorsten

Bug#993900: kde-spectacle: AVIF not working

[NemaChybu team APT archive]

Package: kde-spectacle
Version: 20.12.3-1
Severity: normal

Dear Maintainer,

   * What led up to the situation? 

Using Spectacle as usual, with AVIF format selected in configuration.

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

Set AVIF in configuration, take screenshot, try to save picture or drag'n'drop 
from Spectacle.

   * What was the outcome of this action?

See above.

   * What outcome did you expect instead?

Saving avif image or dragged temporary image to other apps.



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

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

Versions of packages kde-spectacle depends on:
ii  kio5.78.0-5
ii  libc6  2.31-13
ii  libkf5configcore5  5.78.0-4
ii  libkf5configgui5   5.78.0-4
ii  libkf5configwidgets5   5.78.0-2
ii  libkf5coreaddons5  5.78.0-4
ii  libkf5dbusaddons5  5.78.0-2
ii  libkf5globalaccel-bin  5.78.0-3
ii  libkf5globalaccel5 5.78.0-3
ii  libkf5i18n55.78.0-2
ii  libkf5kiocore5 5.78.0-5
ii  libkf5kiogui5  5.78.0-5
ii  libkf5kiowidgets5  5.78.0-5
ii  libkf5kipi32.0.0   4:20.12.1-1
ii  libkf5newstuff55.78.0-4
ii  libkf5notifications5   5.78.0-2
ii  libkf5purpose-bin  5.78.0-2
ii  libkf5purpose5 5.78.0-2
ii  libkf5service-bin  5.78.0-2
ii  libkf5service5 5.78.0-2
ii  libkf5waylandclient5   4:5.78.0-2
ii  libkf5widgetsaddons5   5.78.0-2
ii  libkf5windowsystem55.78.0-2
ii  libkf5xmlgui5  5.78.0-2
ii  libkimageannotator00.4.0-2
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5dbus55.15.2+dfsg-9
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5printsupport55.15.2+dfsg-9
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libqt5x11extras5   5.15.2-2
ii  libstdc++6 10.2.1-6
ii  libxcb-cursor0 0.1.1-4
ii  libxcb-image0  0.4.0-1+b3
ii  libxcb-util1   0.4.0-1+b1
ii  libxcb-xfixes0 1.14-3
ii  libxcb11.14-3
ii  qdbus-qt5  5.15.2-5

kde-spectacle recommends no packages.

kde-spectacle suggests no packages.

-- debconf-show failed

Bug#993898: buster-pu: package btrbk/0.27.1-1+deb10u1

[Thorsten Alteholz]

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


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

This CVE is marked as no-dsa by the security team.

The same patch was already uploaded to unstable with version 0.27.1-2.

  Thorsten

diff -Nru btrbk-0.27.1/debian/changelog btrbk-0.27.1/debian/changelog
--- btrbk-0.27.1/debian/changelog   2018-12-05 22:27:30.0 +0100
+++ btrbk-0.27.1/debian/changelog   2021-08-29 19:03:02.0 +0200
@@ -1,3 +1,12 @@
+btrbk (0.27.1-1+deb10u1) buster; urgency=high
+
+  * Non-maintainer upload by the LTS Team.
+  * CVE-2021-38173
+fixes a security vulnerability which would have allowed for an
+arbitrary code execution
+
+ -- Thorsten Alteholz   Sun, 29 Aug 2021 19:03:02 +0200
+
 btrbk (0.27.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru btrbk-0.27.1/debian/patches/CVE-2021-38173.patch 
btrbk-0.27.1/debian/patches/CVE-2021-38173.patch
--- btrbk-0.27.1/debian/patches/CVE-2021-38173.patch1970-01-01 
01:00:00.0 +0100
+++ btrbk-0.27.1/debian/patches/CVE-2021-38173.patch2021-08-29 
19:03:02.0 +0200
@@ -0,0 +1,32 @@
+From 58212de771c381cd4fa05625927080bf264e9584 Mon Sep 17 00:00:00 2001
+From: Axel Burri 
+Date: Sun, 21 Mar 2021 12:53:22 +0100
+Subject: [PATCH] ssh_filter_btrbk.sh: fix alternation regex
+
+Security vulnerability fixed in alternation regex. Specialy crafted
+commands may be executed without being propely checked.
+
+Affects all versions >= btrbk-v0.23.0
+
+Regression from:
+
+   ccb5ed5e71 ssh_filter_btrbk: allow "realpath" and "cat /proc/self/mounts" 
on targets
+
+Reported by: @protree (responsible disclosure)
+---
+ ssh_filter_btrbk.sh | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+Index: btrbk-0.27.1/ssh_filter_btrbk.sh
+===
+--- btrbk-0.27.1.orig/ssh_filter_btrbk.sh  2021-08-30 15:04:39.595339393 
+0200
 btrbk-0.27.1/ssh_filter_btrbk.sh   2021-08-30 15:04:39.591339393 +0200
+@@ -87,7 +87,7 @@
+ return 0
+ fi
+ 
+-exact_cmd_match="^${allow_exact_list}$";
++exact_cmd_match="^(${allow_exact_list})$";
+ if [[ $SSH_ORIGINAL_COMMAND =~ $exact_cmd_match ]] ; then
+ return 0
+ fi
diff -Nru btrbk-0.27.1/debian/patches/series btrbk-0.27.1/debian/patches/series
--- btrbk-0.27.1/debian/patches/series  1970-01-01 01:00:00.0 +0100
+++ btrbk-0.27.1/debian/patches/series  2021-08-29 19:03:02.0 +0200
@@ -0,0 +1 @@
+CVE-2021-38173.patch

Bug#993899: bullseye-pu: package btrbk/0.27.1-1.1+deb11u1

[Thorsten Alteholz]

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


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

This CVE is marked as no-dsa by the security team.

The same patch was already uploaded to unstable with version 0.27.1-2.

  Thorsten
diff -Nru btrbk-0.27.1/debian/changelog btrbk-0.27.1/debian/changelog
--- btrbk-0.27.1/debian/changelog   2021-01-03 13:57:08.0 +0100
+++ btrbk-0.27.1/debian/changelog   2021-08-29 19:03:02.0 +0200
@@ -1,3 +1,12 @@
+btrbk (0.27.1-1.1+deb11u1) bullseye; urgency=high
+
+  * Non-maintainer upload by the LTS Team.
+  * CVE-2021-38173
+fixes a security vulnerability which would have allowed for an
+arbitrary code execution
+
+ -- Thorsten Alteholz   Sun, 29 Aug 2021 19:03:02 +0200
+
 btrbk (0.27.1-1.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru btrbk-0.27.1/debian/patches/CVE-2021-38173.patch 
btrbk-0.27.1/debian/patches/CVE-2021-38173.patch
--- btrbk-0.27.1/debian/patches/CVE-2021-38173.patch1970-01-01 
01:00:00.0 +0100
+++ btrbk-0.27.1/debian/patches/CVE-2021-38173.patch2021-08-29 
19:03:02.0 +0200
@@ -0,0 +1,32 @@
+From 58212de771c381cd4fa05625927080bf264e9584 Mon Sep 17 00:00:00 2001
+From: Axel Burri 
+Date: Sun, 21 Mar 2021 12:53:22 +0100
+Subject: [PATCH] ssh_filter_btrbk.sh: fix alternation regex
+
+Security vulnerability fixed in alternation regex. Specialy crafted
+commands may be executed without being propely checked.
+
+Affects all versions >= btrbk-v0.23.0
+
+Regression from:
+
+   ccb5ed5e71 ssh_filter_btrbk: allow "realpath" and "cat /proc/self/mounts" 
on targets
+
+Reported by: @protree (responsible disclosure)
+---
+ ssh_filter_btrbk.sh | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+Index: btrbk-0.27.1/ssh_filter_btrbk.sh
+===
+--- btrbk-0.27.1.orig/ssh_filter_btrbk.sh  2021-08-30 15:04:39.595339393 
+0200
 btrbk-0.27.1/ssh_filter_btrbk.sh   2021-08-30 15:04:39.591339393 +0200
+@@ -87,7 +87,7 @@
+ return 0
+ fi
+ 
+-exact_cmd_match="^${allow_exact_list}$";
++exact_cmd_match="^(${allow_exact_list})$";
+ if [[ $SSH_ORIGINAL_COMMAND =~ $exact_cmd_match ]] ; then
+ return 0
+ fi
diff -Nru btrbk-0.27.1/debian/patches/series btrbk-0.27.1/debian/patches/series
--- btrbk-0.27.1/debian/patches/series  1970-01-01 01:00:00.0 +0100
+++ btrbk-0.27.1/debian/patches/series  2021-08-29 19:03:02.0 +0200
@@ -0,0 +1 @@
+CVE-2021-38173.patch

Bug#993897: ITP: obs-ptz -- Plugin for OBS Studio to add a PTZ Camera control dock.

[Daniel Lenharo de Souza]

Package: wnpp
Severity: wishlist
Owner: Daniel Lenharo de Souza 
X-Debbugs-Cc: debian-de...@lists.debian.org, lenh...@debian.org

* Package name: obs-ptz
  Version : 0.7.0
  Upstream Author : Grant Likely 
* URL : https://github.com/glikely/obs-ptz
* License : GPL2
  Programming Lang: C++
  Description : Plugin for OBS Studio to add a PTZ Camera control dock.

This plugin adds a PTZ camera control panel to OBS that can control multiple
cameras, and can automatically change selected camera based on the currently
active preview or program scene.
.
The plugin supports the VISCA serial, VISCA-over-IP, and PELCO-P protocols,
with plans to add support for other camera control protocols in the future.

Features:

Pan, Tilt, and Zoom controls
Save and recall camera presets
Control any number of cameras
Auto select active camera based on active scene
Supported protocols
VISCA
VISCA-over-IP
Pelco-P

Bug#993896: [INTL:sv] Swedish strings for intel-mkl debconf

[Martin Bagge / brother]

package: intel-mkl
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother
# Translation of intel-mkl debconf template to Swedish
# Copyright (C) 2021 Martin Bagge 
# This file is distributed under the same license as the intel-mkl package.
#
# Martin Bagge , 2021
msgid ""
msgstr ""
"Project-Id-Version: intel-mkl\n"
"Report-Msgid-Bugs-To: intel-...@packages.debian.org\n"
"POT-Creation-Date: 2018-06-16 10:31+\n"
"PO-Revision-Date: 2021-09-07 23:12+0200\n"
"Last-Translator: Martin Bagge \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: title
#. Description
#: ../libmkl-rt.templates:1001
msgid "Intel Math Kernel Library (Intel MKL)"
msgstr "Intel Math Kernel Library (Intel MKL)"

#. Type: boolean
#. Description
#: ../libmkl-rt.templates:2001
msgid "Use libmkl_rt.so as the default alternative to BLAS/LAPACK?"
msgstr "Ska libmkl_rt.so användas som standardval för BLAS/LAPACK?"

#. Type: boolean
#. Description
#: ../libmkl-rt.templates:2001
msgid ""
"Intel MKL's Single Dynamic Library (SDL) is installed on your machine. This "
"shared object can be used as an alternative to both libblas.so.3 and "
"liblapack.so.3, so that packages built against BLAS/LAPACK can directly use "
"MKL without rebuild."
msgstr ""
"Intel MKLs Single Dynamic Library (SDL) är installerat på din maskin. Detta "
"delade objekt kan användas som ett alternativ till både libblas.so.3 och "
"liblapack.so.3 så att paket som är byggda mot BLAS/LAPACK kan använda MKL "
"direkt utan att byggas om."

#. Type: boolean
#. Description
#: ../libmkl-rt.templates:2001
msgid ""
"However, MKL is non-free software, and in particular its source code is not "
"publicly available. By using MKL as the default BLAS/LAPACK implementation, "
"you might be violating the licensing terms of copyleft software that would "
"become dynamically linked against it. Please verify that the licensing terms "
"of the program(s) that you intend to use with MKL are compatible with the "
"MKL licensing terms. For the case of software under the GNU General Public "
"License, you may want to read this FAQ:"
msgstr ""
"Notera dock att MKL är icke-fri mjukvara och framförallt är det som så att "
"källkoden inte är publikt tillgänglig. Genom att använda MKL som "
"standardimplementation för BLAS/LAPACK kommer du att bryta mot licensen för "
"copyleft-mjukvara som dynamiskt råkar länka mot MKL. Säkerställ att "
"licensvillkoren för program som du planerar att använda med MKL är "
"kompatibla med MKLs licensvillkor. För mjukvara som använder GNU General "
"Public License (GPL) bör du läsa denna FAQ:"

#. Type: boolean
#. Description
#: ../libmkl-rt.templates:2001
msgid "https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs;
msgstr "https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs;

#. Type: boolean
#. Description
#: ../libmkl-rt.templates:2001
msgid ""
"If you don't know what MKL is, or unwilling to set it as default, just "
"choose the preset value or simply type Enter."
msgstr ""
"Om du inte vet vad MKL är eller om du inte känner för att ange det som "
"standardval kan du med fördel välja det förmarkerade värdet här."

#. Type: multiselect
#. Description
#: ../libmkl-rt.templates:3001
msgid "Which of the these alternatives should point to MKL?"
msgstr "Vilket av dessa alternativ ska peka till MKL?"

#. Type: multiselect
#. Description
#: ../libmkl-rt.templates:3001
msgid ""
"Please select the alternatives that should point to MKL. The selection "
"applies to all available architectures, and the related development packages "
"will follow the same selection."
msgstr ""
"Ange det alternativ som ska peka på MKL. Valet är applicerbart på alla "
"tillgängliga arkitekturer och deras respektive utvecklingspaket kommer att "
"följa samma vak"

#. Type: multiselect
#. Description
#: ../libmkl-rt.templates:3001
msgid ""
"Typically the user may want to point both BLAS/LAPACK to MKL (libmkl_rt.so). "
"Type Enter if you are not sure what to select."
msgstr ""
"Generellt sett vill du peka båda BLAS pch LAPACK till MKL (libmkl_rt.so). "
"Detta är förvalt."

Bug#993874: flurm FTBFS with glibc 2.32: fatal error: sys/sysctl.h: No such file or directory

[Aurelien Jarno]

control: tag -1 + upstream
control: tag -1 + patch

Hi

On 2021-09-07 16:45, Helmut Grohne wrote:
> Source: slurm
> Version: 0.4.3-2
> Severity: serious
> Tags: ftbfs
> X-Debbugs-Cc: debian-gl...@lists.debian.org
> 
> slurm fails to build from source with glibc 2.32, because sys/sysctl.h
> was removed. A build ends with:
> 
> | [ 50%] Building C object CMakeFiles/slurm.dir/slurm.c.o
> | /usr/bin/cc -D_HAVE_NCURSES  -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -o CMakeFiles/slurm.dir/slurm.c.o -c 
> /<>/slurm.c
> | In file included from /<>/slurm.c:37:
> | /<>/os.h:180:10: fatal error: sys/sysctl.h: No such file or 
> directory
> |   180 | #include 
> |   |  ^~
> | compilation terminated.
> | make[3]: *** [CMakeFiles/slurm.dir/build.make:85: 
> CMakeFiles/slurm.dir/slurm.c.o] Error 1
> | make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> | make[2]: *** [CMakeFiles/Makefile2:98: CMakeFiles/slurm.dir/all] Error 2
> | make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> | make[1]: *** [Makefile:152: all] Error 2
> | make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> | dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j1 VERBOSE=1 
> returned exit code 2
> | make: *** [debian/rules:3: build] Error 25
> | dpkg-buildpackage: error: debian/rules build subprocess returned exit 
> status 2
> 

Please find attached a patch to fix that. This upstream PR might also be
relevant here: https://github.com/mattthias/slurm/pull/39

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--- slurm-0.4.3/debian/patches/0002-Drop-sysctl-h-include
+++ slurm-0.4.3/debian/patches/0002-Drop-sysctl-h-include
@@ -0,0 +1,19 @@
+Description: Drop sysctl.h include
+ The  include is used to get access to the sysctl function. In
+ practice this function is only used on FreeBSD, NetBSD, OpenBSD and MacOS, but
+ not on Linux. Drop the include as it is not provided anymore by recent glibc
+ versions.
+Author: Aurelien Jarno  
+Forwarded: no
+Last-Update: 2021-09-07
+
+--- slurm-0.4.3.orig/os.h
 slurm-0.4.3/os.h
+@@ -177,7 +177,6 @@
+ #elif defined (__linux__) /* L I N U X */
+ #include 
+ #include 
+-#include 
+ #include 
+ #include 
+ #include 
--- slurm-0.4.3/debian/patches/series
+++ slurm-0.4.3/debian/patches/series
@@ -1 +1,2 @@
 0001-Fix-empty-lines-in-manpage.patch
+0002-Drop-sysctl-h-include

Bug#993895: libosmpbf-dev: Compilation error with g++ when including /usr/include/osmpbf/osmformat.pb.h

[Jocelyn Jaubert]

Package: libosmpbf-dev
Version: 1.5.0-1
Severity: normal

Dear Maintainer,

When compiling a c++ program including one of these files:
/usr/include/osmpbf/fileformat.pb.h
/usr/include/osmpbf/osmformat.pb.h

I'm getting a compilation error linked to protobuf structures.


Example:

$ cat osmpbf-fail.cc #include 
#include 

int main ()
{
}

$ g++ osmpbf-fail.cc In file included from osmpbf-fail.cc:1:
/usr/include/osmpbf/fileformat.pb.h:48:51: error: ‘AuxiliaryParseTableField’
in namespace ‘google::protobuf::internal’ does not name a type; did you mean
‘AuxillaryParseTableField’?
   48 |   static const
::PROTOBUF_NAMESPACE_ID::internal::AuxiliaryParseTableField aux[]
  |
^~~~
  |
AuxillaryParseTableField
In file included from osmpbf-fail.cc:2:
/usr/include/osmpbf/osmformat.pb.h:49:51: error: ‘AuxiliaryParseTableField’
in namespace ‘google::protobuf::internal’ does not name a type; did you mean
‘AuxillaryParseTableField’?
   49 |   static const
::PROTOBUF_NAMESPACE_ID::internal::AuxiliaryParseTableField aux[]
  |
^~~~
  |
AuxillaryParseTableField
...

Should these two .h files be regenerated?


The same file compiles correctly on Debian Buster.


Thanks,
Jocelyn



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

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

Versions of packages libosmpbf-dev depends on:
ii  libosmpbf1   1.5.0-1
ii  libprotobuf-dev  3.12.4-1

libosmpbf-dev recommends no packages.

libosmpbf-dev suggests no packages.

-- no debconf information

Bug#993882: Info received (Bug#993882: Acknowledgement (power64le: virt-manager refuses to start fresh install of FreeBSD 13.0 due to qemu issue on power8 host (safe cache missing)))

[Karel Gardas]

Hello,

tested the same on Ubuntu 20.04 LTS up-to-date and it shows the same
issue although its qemu is probably somewhat older version.

Conclusion: not broken by debian, not broken recently. Probably general
issue on power8 (or general issue on my machine.)

Karel

Bug#924761: hang on startup, no "loading" indicator

[David Gene]

I also experience slow startup times. For example, if I open the Atom 
 .deb, gdebi-gtk takes about 10 seconds to show the 
package into and become responsive. In contrast, command line gdebi only 
takes about a second. So there is probably potential to speed up startup 
in general.


I agree there should be some sort of indication that gdebi-gtk is still 
reading the input file- and to do it on a different thread than the gtk 
thread, so you can still interact with the window.

Bug#993894: leptonlib: New Version 1.81.1

[Matthias Erich Popp]

Source: leptonlib
Severity: wishlist
X-Debbugs-Cc: oquo8...@gmx.de




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

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


https://github.com/DanBloomberg/leptonica/releases/download/1.81.1/leptonica-1.81.1.tar.gz

http://www.leptonica.org/source/leptonica-1.81.1.tar.gz

Bug#993792: bullseye-pu: package iotop-c/1.17-1

[Boian Bonev]

On Tue, 2021-09-07 at 20:14 +0100, Jonathan Wiltshire wrote:
> On Tue, Sep 07, 2021 at 08:38:58PM +0300, Boian Bonev wrote:

> 
> This is behaviour change or enhancement, it is generally not OK in a
> stable
> update unless you can convince us it has a really good case e.g. the
> only
> way to fix a security issue.

I see no point in doing that - those two fixes were improving user
experience, i.e. enhancements. Thanks for your advise.

> While you are doing that please also ensure the changelog refers to
> appropriate bugs in the BTS so that the changes are easily traced
> back.

Can not do that - there was no bug filed for the problem initially; I
have discovered it by browsing test cases that cause problems for a
similar package and using them as test cases for this one. Somehow I do
not see a point in filing a bug myself, assign it to myself and close
it immediately afterwards. If required, I will do.

PFA the updated debdiff.

Thanks,
diff -Nru iotop-c-1.17/debian/changelog iotop-c-1.17/debian/changelog
--- iotop-c-1.17/debian/changelog	2021-02-06 03:02:03.0 +0200
+++ iotop-c-1.17/debian/changelog	2021-09-06 04:54:40.0 +0300
@@ -1,3 +1,10 @@
+iotop-c (1.17-1+deb11u1) bullseye; urgency=medium
+
+  * Backport bugfix from 1.18
+- fix OOB access caused by UTF8 process names
+
+ -- Boian Bonev   Mon, 06 Sep 2021 01:54:40 +
+
 iotop-c (1.17-1) unstable; urgency=medium
 
   * Update to new upstream release of 1.17
diff -Nru iotop-c-1.17/debian/patches/fix-OOB-on-utf.patch iotop-c-1.17/debian/patches/fix-OOB-on-utf.patch
--- iotop-c-1.17/debian/patches/fix-OOB-on-utf.patch	1970-01-01 02:00:00.0 +0200
+++ iotop-c-1.17/debian/patches/fix-OOB-on-utf.patch	2021-09-06 04:54:40.0 +0300
@@ -0,0 +1,20 @@
+Description: Fix OOB access on some UTF input
+ On architectures with signed char type and input that is >=128 there is
+ an out-of-bounds access causing SIGSEGV. It is most probably not exploitable
+ but degrades user experience.
+---
+Origin: upstream, https://github.com/Tomas-M/iotop/commit/8aaa4fce743cf14a5a727c6cb24c63450d317a28
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/iotop/+bug/1932523
+Last-Update: 2021-09-06
+
+--- iotop-c-1.17.orig/src/utils.c
 iotop-c-1.17/src/utils.c
+@@ -171,7 +171,7 @@ inline const char *esc_low_ascii1(char c
+ 	static char ehex[0x20][6];
+ 	static int initialized=0;
+ 
+-	if (c>=0x20) // no escaping needed
++	if (c<0||c>=0x20) // no escaping needed
+ 		return NULL;
+ 	if (!initialized) {
+ 		int i;
diff -Nru iotop-c-1.17/debian/patches/series iotop-c-1.17/debian/patches/series
--- iotop-c-1.17/debian/patches/series	1970-01-01 02:00:00.0 +0200
+++ iotop-c-1.17/debian/patches/series	2021-09-06 04:54:40.0 +0300
@@ -0,0 +1 @@
+fix-OOB-on-utf.patch

Bug#993224: ublock-origin 1.37.0+dfsg-1~deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: ublock-origin
Version: 1.37.0+dfsg-1~deb10u1

Explanation: new upstream stable release; fix denial of service issue 
[CVE-2021-36773]

Bug#991221: mariadb-10.3 10.3.31-0+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: mariadb-10.3
Version: 10.3.31-0+deb10u1

Explanation: new upstream stable release; security fixes [CVE-2021-2389 
CVE-2021-2372]; fix Perl executable path in scripts

Bug#971590: rt-tests: bump to a new upstream release

[Uwe Kleine-König]

Hello,

On 9/7/21 4:35 AM, Punit Agrawal wrote:

I was looking to update the rt-tests package in Debian as it is lagging
behind upstream.

Before digging into the task, I wanted to check if you're planning to
make any changes or had any patches that haven't been pushed. Pointers
to any particular issues to watch out for would also be appreciated.


There is nothing pending on my side and if you want to adopt rt-tests 
that is fine for me. ISTR that Anders Roxell showed some interest in 
maintaining rt-tests, too, in the past, but I cannot find the 
corresponding conversation.


Upstream used to be quite responsive to patches and I don't assume this 
has changed. Being in the #linux-rt irc channel (on OFTC) might be 
beneficial to contact them.


Best regards
Uwe



OpenPGP_signature
Description: OpenPGP digital signature

Bug#993892: [INTL:sv] Swedish strings for zfs-linux debconf

[Martin Bagge / brother]

package: zfs-linux
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.

--
brother
# Translation of zfs-linux debconf template to Swedish
# Copyright (C) 2021 Martin Bagge 
# This file is distributed under the same license as the zfs-linux package.
#
# Martin Bagge , 2013, 2019, 2021
msgid ""
msgstr ""
"Project-Id-Version: zfs-linux\n"
"Report-Msgid-Bugs-To: zfs-li...@packages.debian.org\n"
"POT-Creation-Date: 2021-03-30 14:43+0800\n"
"PO-Revision-Date: 2021-09-07 21:28+0200\n"
"Last-Translator: Martin Bagge / brother \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 2.2\n"

#. Type: boolean
#. Description
#: ../zfs-dkms.templates:1001
msgid "Abort building OpenZFS on a 32-bit kernel?"
msgstr "Ska bygget av OpenZFS på en 32-bitars kärna avbrytas?"

#. Type: boolean
#. Description
#: ../zfs-dkms.templates:1001
msgid "You are attempting to build OpenZFS against a 32-bit running kernel."
msgstr "Du försöker bygga OpenZFS mot en 32-bitars kärna."

#. Type: boolean
#. Description
#. Type: boolean
#. Description
#: ../zfs-dkms.templates:1001 ../zfs-dkms.templates:2001
msgid ""
"Although possible, building in a 32-bit environment is unsupported and "
"likely to cause instability leading to possible data corruption. You are "
"strongly advised to use a 64-bit kernel; if you do decide to proceed with "
"using OpenZFS on this kernel then keep in mind that it is at your own risk."
msgstr ""
"Det är inte omöjligt men att bygga i en 32-bitars-miljö är inte något som "
"stöds och kommer troligen att leda till ostabilt system och det i sin tur "
"kan leda till dataförlust. Att använda en 64-bitars kärna är starkt "
"rekommenderat. Om du väljer att fortsätta med att använda OpenZFS på den här "
"kärnan är det helt och hållet på din egen risk."

#. Type: boolean
#. Description
#: ../zfs-dkms.templates:2001
msgid "Abort building OpenZFS on an unknown kernel?"
msgstr "Ska bygget av OpenZFS på en okänd kärntyp avbrytas?"

#. Type: boolean
#. Description
#: ../zfs-dkms.templates:2001
msgid ""
"You are attempting to build OpenZFS against a running kernel that could not "
"be identified as 32-bit or 64-bit. If you are not completely sure that the "
"running kernel is a 64-bit one, you should probably stop the build."
msgstr ""
"Du försöker bygga OpenZFS mot en kärna som varken kan identifieras som 32-"
"bitars eller 64-bitars. Om du inte är helt säker på att du kör en 64-bitars "
"kärna ska du avbryta bygget nu."

#. Type: note
#. Description
#: ../zfs-dkms.templates:3001
msgid "Licenses of OpenZFS and Linux are incompatible"
msgstr "Licenserna för OpenZFS och Linux är inte kompatibla"

#. Type: note
#. Description
#: ../zfs-dkms.templates:3001
msgid ""
"OpenZFS is licensed under the Common Development and Distribution License "
"(CDDL), and the Linux kernel is licensed under the GNU General Public "
"License Version 2 (GPL-2). While both are free open source licenses they are "
"restrictive licenses. The combination of them causes problems because it "
"prevents using pieces of code exclusively available under one license with "
"pieces of code exclusively available under the other in the same binary."
msgstr ""
"OpenZFS använder licensen Common Development and Distribution License (CDDL) "
"och Linuxkärnan använder GNU General Public License Version 2 (GPL-2). Båda "
"dessa är fria och öppna licenser men de är också begränsande. Detta leder "
"till besvär när kodbitar ska kombineras i samma binärfil. I båda fallen "
"råder ett exklusivt förbud mot detta."

#. Type: note
#. Description
#: ../zfs-dkms.templates:3001
msgid ""
"You are going to build OpenZFS using DKMS in such a way that they are not "
"going to be built into one monolithic binary. Please be aware that "
"distributing both of the binaries in the same media (disk images, virtual "
"appliances, etc) may lead to infringing."
msgstr ""
"Du kommer att bygga OpenZFS med DKMS på ett sådant sätt att de inte byggs "
"ihop till en monolit-binär. Vänligen notera att distribution av dessa "
"binärer på samma media(diskavbildningar, virtuella maskin-bilder eller "
"dylikt) kan innebära intrång i upphovsrätt och avtal."

Bug#993890: [INTL:sv] Swedish strings for rocksndiamonds debconf

[Martin Bagge / brother]

package: rocksndiamonds
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother
http://sis.bthstudent.se

--
brother
# Translation of rocksndiamonds debconf template to Swedish
# Copyright (C) 2021 Martin Bagge 
# This file is distributed under the same license as the rocksdiaminds package.
#
# Daniel Nylander , 2007
# Martin Bagge , 2009, 2021
msgid ""
msgstr ""
"Project-Id-Version: rocksndiamonds\n"
"Report-Msgid-Bugs-To: rocksndiamo...@packages.debian.org\n"
"POT-Creation-Date: 2020-12-25 21:14+0100\n"
"PO-Revision-Date: 2021-09-07 21:31+0200\n"
"Last-Translator: Martin Bagge \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Poedit-Language: Swedish\n"
"X-Poedit-Country: Sweden\n"
"X-Poedit-SourceCharset: utf-8\n"

#. Type: boolean
#. Description
#: ../templates:2001
msgid "Download non-free game data?"
msgstr "Hämta icke-fritt speldata?"

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"The data files required by rocksndiamonds do not have licenses that would "
"allow them to be distributed as a package. However, they can be "
"automatically downloaded from the Internet and installed locally."
msgstr ""
"Datafilerna som behövs för rocksndiamonds saknar licens eller är "
"licensierade på ett sätt som gör det omöjligt att inkludera dem i ett paket. "
"De kan dock hämtas automatiskt över Internet för att sedan bli installerade "
"lokalt."

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"Some of these require downloading large files: BD2K3 (4.5 MiB), BD Dream "
"(11 MiB), Contributions 1995 - 2006 (6 MiB), Emerald Mine Club (44 MiB), "
"Legend of Zelda (2.1 MiB), Legend of Zelda II (12 MiB), rnd_jue (18 MiB), "
"Snake Bite (6.3 MiB), Supaplex (7.2 MiB)."
msgstr ""
"Detta innebär att några lite större filer kommer att hämtas: BD2K3 (4.5 "
"MiB), BD Dream (11 MiB), Contributions 1995 - 2006 (6 MiB), Emerald Mine "
"Club (44 MiB), Legend of Zelda (2.1 MiB), Legend of Zelda II (12 MiB), "
"rnd_jue (18 MiB), Snake Bite (6.3 MiB), Supaplex (7.2 MiB)."

#. Type: multiselect
#. Description
#: ../templates:3001
msgid "Games to download data for:"
msgstr "Spel att hämta ner data för:"

#. Type: error
#. Description
#: ../templates:4001
msgid "Missing utilities for download or unpacking"
msgstr "Saknar verktyg för att hämta eller packa upp"

#. Type: error
#. Description
#: ../templates:4001
msgid ""
"Downloading and unpacking the game data requires the packages wget, p7zip, "
"and unzip, but not all of these are available."
msgstr ""
"För att kunna hämta speldata krävs paketen wget, p7zip och unzip men något "
"av dem saknas."

#. Type: error
#. Description
#: ../templates:4001
msgid ""
"You should install them and then reconfigure this package by using \"dpkg-"
"reconfigure rocksndiamonds\"."
msgstr ""
"Installera den eller de du saknar och kör sedan inställningsdelen av detta "
"paketet igen med kommandot \"dpkg-reconfigure rocksndiamonds\"."

#. Type: error
#. Description
#: ../templates:5001
msgid "Cannot download required resources"
msgstr "Kan inte hämta resurser som krävs"

#. Type: error
#. Description
#: ../templates:5001
msgid ""
"An error occurred while downloading game data. You should check the network "
"connection and settings and retry later on."
msgstr ""
"Ett fel inträffade när speldata skulle hämtas. Kontrollera "
"nätverksanslutningen och -inställningar och försök sedan igen."

Bug#993891: [INTL:sv] Swedish strings for xringd debconf

[Martin Bagge / brother]

package: xringd
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother
http://sis.bthstudent.se

--
brother
# Translation of xringd debconf template to Swedish
# Copyright (C) 2021 Martin Bagge 
# This file is distributed under the same license as the xringd package.
#
# Daniel Nylander , 2005
# Martin Bagge , 2021
msgid ""
msgstr ""
"Project-Id-Version: xringd 1.20-24\n"
"Report-Msgid-Bugs-To: xri...@packages.debian.org\n"
"POT-Creation-Date: 2015-09-26 08:36+0200\n"
"PO-Revision-Date: 2021-09-07 20:59+0200\n"
"Last-Translator: Martin Bagge \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: string
#. Description
#: ../templates:2001
msgid "Modem device:"
msgstr "Modemets enhetsnamn"

#. Type: string
#. Description
#: ../templates:2001
msgid "Please enter the name of the device the modem is connected to."
msgstr "Ange namnet på enheten som modemet är ansluten till."

#. Type: string
#. Description
#: ../templates:2001
msgid ""
"Xringd needs to poll a modem attached via a serial port. Please specify "
"which serial port the modem uses (usually /dev/ttyS[0-4])."
msgstr ""
"Xringd kommer att läsa av ett modem som är anslutet på en seriell port. Ange "
"vilken port (vanligtvis /dev/ttyS[0-4]) ditt modem är inkopplat på."

Bug#993889: [INTL:sv] Swedish strings for diaspora-installer debconf

[Martin Bagge / brother]

package: diaspora-installer
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.

--
brother
# Translation of diaspora-installer debconf template to Swedish
# Copyright (C) 2021 Martin Bagge 
# This file is distributed under the same license as the diaspora-installer package.
#
# Martin Bagge , 2015, 2021
# Jonatan Nyberg , 2017
msgid ""
msgstr ""
"Project-Id-Version: diaspora-installer\n"
"Report-Msgid-Bugs-To: diaspora-instal...@packages.debian.org\n"
"POT-Creation-Date: 2017-04-27 12:48+0530\n"
"PO-Revision-Date: 2021-09-07 21:23+0200\n"
"Last-Translator: Jonatan Nyberg \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 1.8.11\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid "Host name for this instance of Diaspora:"
msgstr "Värdnamn för denna instansen av Diaspora:"

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid ""
"Please choose the host name which should be used to access this instance of "
"Diaspora."
msgstr ""
"Vänligen ange värdnamnet som ska anges för att få tillgång till den här "
"instansen av Diaspora."

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid ""
"This should be the fully qualified name as seen from the Internet, with the "
"domain name that will be used to access the pod."
msgstr ""
"Detta ska vara det fullt kvalificerade namnet som syns på internet, med "
"domännamnet som behövs för att få tillgång till denna pod."

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid ""
"If a reverse proxy is used, give the hostname that the proxy server responds "
"to."
msgstr ""
"Om en reverse proxy används, ange värdnamnet som proxyservern svarar på."

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid ""
"This host name should not be modified after the initial setup because it is "
"hard-coded in the database."
msgstr ""
"Detta värdnamn ska inte justeras efter första installationen eftersom det är "
"hårdkodat i databasen."

#. Type: note
#. Description
#: ../diaspora-common.templates:2001
msgid "PostgreSQL application password"
msgstr "PostgreSQL-applikationslösenord"

#. Type: note
#. Description
#: ../diaspora-common.templates:2001
msgid ""
"You can leave the PostgreSQL application password blank, as the \"ident\" "
"authentication method is used, allowing the diaspora user on the system to "
"connect to the Diaspora database without a password."
msgstr ""
"Du kan lämna PostgreSQL-applikationslösenordet tomt, eftersom \"ident\" "
"autentiseringsmetoden används tillåts diaspora användaren på systemet "
"ansluta till Diaspora databasen utan lösenord."

#. Type: boolean
#. Description
#: ../diaspora-common.templates:3001
msgid "Enable https?"
msgstr "Aktivera https?"

#. Type: boolean
#. Description
#: ../diaspora-common.templates:3001
msgid ""
"Enabling https means that an SSL/TLS certificate is required to access this "
"Diaspora instance (as Nginx will be configured to respond only to https "
"requests). A self-signed certificate is enough for local testing (and can be "
"generated using, for instance, the package easy-rsa), but will not be "
"accepted for federation with other Diaspora pods."
msgstr ""
"Aktivera https innebär att ett SSL-certifikat krävs för att få tillgång till "
"denna Diaspora instans (eftersom Nginx konfigureras till att endast svara på "
"https förfrågningar). Ett självsignerat certifikat är tillräckligt för lokal "
"prövning (och kan genereras med, till exempel, paketet easy-rsa), men kommer "
"inte att accepteras för federation med andra diaspora pods."

#. Type: boolean
#. Description
#: ../diaspora-common.templates:3001
msgid ""
"Some certificate authorities like Let's Encrypt (letsencrypt.org), StartSSL "
"(startssl.com) offer free SSL/TLS certificates that work with Diaspora; "
"however, certificates provided by CAcert will not work with Diaspora."
msgstr ""
"Vissa certifikatutfärdare som Let's Encrypt (letsencrypt.org), StartSSL "
"(startssl.com) erbjuder gratis SSL-certifikat som fungerar med Diaspora; "
"dock kommer inte certifikat från CAcert att fungera med Diaspora."

#. Type: boolean
#. Description
#: ../diaspora-common.templates:3001
msgid ""
"Nginx must be reloaded after the certificate and key files are made "
"available at /etc/diaspora/ssl. letsencrypt package may be used to automate "
"interaction with Let's Encrypt to obtain a certificate."
msgstr ""
"Nginx måste laddas om efter certifikatet och nyckelfilerna görs tillgängliga "
"i /etc/diaspora/ssl. letsencrypt-paket kan användas för att automatisera "
"interaktion med Let's Encrypt för att erhålla ett certifikat."

#. Type: boolean
#. Description
#: ../diaspora-common.templates:3001
msgid ""
"You can disable https if you want to access Diaspora only locally or you 

Bug#993882: Acknowledgement (power64le: virt-manager refuses to start fresh install of FreeBSD 13.0 due to qemu issue on power8 host (safe cache missing))

[Karel Gardas]

Hi,

one addition. I've noticed that architecture options are probably wrong
for the pseries machine. By default it selects ppc64le where I believe
ppc64 is the right one.

I've tested both options here so the bug is not related to wrong default
value of architecture options. Just to let you know.

Thanks!

Bug#993887: gnome-shell-extension-dash-to-panel: Please add version constraint: Breaks: gnome-shell (<< 40)

[Boyuan Yang]

Package: gnome-shell-extension-dash-to-panel
Severity: grave
Version: 43-1

Hi Jonathan,

As discussed in https://bugs.debian.org/993058 , gnome-shell-extension-dash-
to-panel/43-1 does not work with GNOME Shell 3.38 or earlier versions.
However, the current condition is that it was uploaded onto Unstable even if
gnome-shell/40.x is still in experimental. This will make current gnome-shell
3.38.6 crash when gnome-shell-extension-dash-to-panel/43-1 is also installed
(that is exactly what I experienced :-(

Ideally we should only upload gnome-shell-extension-dash-to-panel/43-1 when
gnome shell 40.x already appears in Sid. Since that is already not possible,
please add Breaks: gnome-shell (<< 40) to the binary package to make sure that
no users would end up with a broken GUI environment.

Thanks,
Boyuan Yang


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

Bug#993886: f3: Update homepage

[Nelson A. de Oliveira]

Package: f3
Version: 8.0-1
Severity: minor

Hi!

debian/{control,README.Debian} are using an outdated upstream homepage
(http://oss.digirati.com.br/f3 instead
https://fight-flash-fraud.readthedocs.io/en/stable/)

They should be updated, when possible.

(see at https://github.com/AltraMayor/f3/issues/171 that upstream
considers https://fight-flash-fraud.readthedocs.io/en/stable/ as the
homepage)

And while at it, I don't know if debian/README.Debian adds any useful
information (and could probably just be removed)

Thank you!

Best regards,
Nelson

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

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

Versions of packages f3 depends on:
ii  libc6   2.32-1
ii  libparted2  3.4-1
ii  libudev1247.9-1

f3 recommends no packages.

f3 suggests no packages.

Bug#993792: bullseye-pu: package iotop-c/1.17-1

[Jonathan Wiltshire]

On Tue, Sep 07, 2021 at 08:38:58PM +0300, Boian Bonev wrote:
> Or maybe I misunderstand now - in case you mean that some of the fixes
> are not acceptable, please clarify which patches to drop and which to
> keep. In my opinion all the 3 fixes are trivial, have been tested, have
> low risk, will improve user experience and are safe to keep, but I may
> be missing something.
> 
> Here is the changelog, hope that helps to make things unambiguous: 
> 

I mean you have requested an update fixing the crash on unicode process
names, but you also included other fixes and enhancements:

>   * Backport bugfixes from 1.18
> - fix OOB access caused by UTF8 process names

This is fine.

> - fix screen flicker during refresh with visible help

This is fine if it is serious enough to be causing real problems (not just
cosmetic).

> - allow ESC to close the help window

This is behaviour change or enhancement, it is generally not OK in a stable
update unless you can convince us it has a really good case e.g. the only
way to fix a security issue.

While you are doing that please also ensure the changelog refers to
appropriate bugs in the BTS so that the changes are easily traced back.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



signature.asc
Description: PGP signature

Bug#993821: After upgrading libc, some services are unable to restart (including systemd-resolved)

[Michael Biebl]

Hi Aurelien

Am 07.09.21 um 12:41 schrieb Aurelien Jarno:

Hi,

On 2021-09-07 10:39, Michael Hudson-Doyle wrote:



What's happening is that systemd is running with the old glibc, forks and
then does NSS things that cause the new glibc's NSS modules to load and
they don't necessarily work, leading to failures in any unit that specifies
User=. At least for Ubuntu's builds the NSS modules seem to be ABI
compatible between 2.32 and 2.33 (I didn't try 2.31 vs 2.32) but they are
definitely not between 2.33 and 2.34.


Thanks for this feedback and the pointer to the patch used in Ubuntu. It
seems to be a good solution, and matches what is done for other init
systems.

On the other hand, the problem is supposed to only happen for major
glibc version upgrade where the NSS modules might have a different ABI.
In that regard, I would be tempted to restart it only for major versions
upgrade like it's done for other daemons. Now if the systemd maintainers
consider it's fine restarting it for each glibc upgrade, we should
probably go that way.


I guess you are in a better position to make a judgement call here. If I 
read the glibc bug report correctly, there aren't strictly any 
guarantees regarding NSS modules. What that means for glibc minor 
updates, I'm not really in a position to tell.


Fwiw, I don't have a better proposal then Michael's patch he added to 
Ubuntu. We could run with that and if it causes problems, reiterate on it.


Regards,
Michael

Bug#993793: bullseye-pu: package reportbug/7.10.3

[Jonathan Wiltshire]

On Tue, Sep 07, 2021 at 02:52:35PM +0100, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed moreinfo
> 
> On Mon, Sep 06, 2021 at 05:47:40PM +0200, Thomas Goirand wrote:
> > This fixes the suite names against stable.
> > Note that Sandro Tosi (maintainer of reportbug) agrees
> > that I do this update in Stable.
> 
> Please go ahead and remove this bug's wontfix tag when uploaded.

Err, I meant moreinfo. Nothing to read into that, honest :)


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



signature.asc
Description: PGP signature

Bug#991036: [Debian-on-mobile-maintainers] Bug#991036: libhandy: Should this package be removed in bookworm?

[Henry-Nicolas Tourneur]

Le mardi 07 septembre 2021 à 10:07 +0100, Simon McVittie a écrit :
> On Tue, 13 Jul 2021 at 13:36:17 +0300, Adrian Bunk wrote:
> > A more recent version is already available in src:libhandy-1.
> > 
> > Both versions will be in bullseye, but still shipping both in
> > bookworm would feel wrong.
> 
> I think you're right, but I think it might also be too soon for this
> to
> be considered RC, because progress cannot be made on its removal
> until
> some transitions have gone through.
> 
> I've opened bugs for the four remaining reverse-dependencies:
> 
> - #993849: gnome-authenticator
> - #993850: gnome-calendar
> - #993852: gnome-metronome
> - #993853: kgx
> 
> gnome-authenticator has a new upstream version 4.x that uses GTK4 and
> libadwaita, but libadwaita is not yet stable and is in NEW (it might
> be
> possible to bundle a snapshot in gnome-authenticator). gnome-
> authenticator 4
> itself is a rewrite from Python into Rust, so this is unlikely to be
> quick
> to update. (The Debian package is also mis-named, this is not an
> official
> GNOME application.)
> 
Hello Simon,

I am the maintainer of gnome-authenticator in the Python team, and
indeed, its rewrite in Rust means it'll take time to update as there
are many crate dependencies that needs to be available in the archive
first (I am also working with the Rust team to progress this).

Ideally, I'd preferr of course that the package remains available in
booksworm and I'll be working toward that.

Regards, 

Henry-Nicolas Tourneur


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

Bug#993885: upgrade failures

[Daniel Baumann]

Package: nfs-utils
Version: 1:2.5.4-1~exp2
Severity: serious

Hi Anibal

thanks for the previous upload, however, the upgrade of nfs-common from 
sid to experimental still fails:


---snip---
[...]
Get:2 http://debian.ethz.ch/debian experimental/main amd64 libnfsidmap1 
amd64 1:2.5.4-1~exp2 [78.4 kB]
Get:3 http://debian.ethz.ch/debian sid/main amd64 libevent-core-2.1-7 
amd64 2.1.12-stable-1 [139 kB]

Fetched 523 kB in 0s (3464 kB/s)
(Reading database ... 21068 files and directories currently installed.)
Preparing to unpack .../nfs-common_1%3a2.5.4-1~exp2_amd64.deb ...
Unpacking nfs-common (1:2.5.4-1~exp2) over (1:1.3.4-6) ...
dpkg: error processing archive 
/var/cache/apt/archives/nfs-common_1%3a2.5.4-1~exp2_amd64.deb (--unpack):
 trying to overwrite '/usr/share/man/man5/idmapd.conf.5.gz', which is 
also in package libnfsidmap2:amd64 0.25-6

Running in chroot, ignoring request.
All runlevel operations denied by policy
invoke-rc.d: policy-rc.d denied execution of restart.
Errors were encountered while processing:
 /var/cache/apt/archives/nfs-common_1%3a2.5.4-1~exp2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
---snap---

Regards,
Daniel

Bug#993884: tracker-miner-fs: Leftover config file /etc/xdg/autostart/tracker-miner-fs.desktop not cleaned on upgrade

[Boyuan Yang]

Package: tracker-miner-fs
Version: 3.1.1-4
Severity: normal
X-Debbugs-CC: jbi...@debian.org

Dear Debian GNOME Maintainers,

After upgraded from tracker 2.x to tracker 3.x, the leftover config file for
package tracker-miner-fs /etc/xdg/autostart/tracker-miner-fs.desktop still
stays in the filesystem. This will cause errors in system log after login:

systemd-xdg-autostart-generator[2772]: Exec binary '/usr/libexec/tracker-
extract' does not exist: No such file or directory

systemd-xdg-autostart-generator[2772]: Not generating service for XDG
autostart app-tracker\x2dextract-autostart.service, error parsing Exec= line:
No such file or directory

This is not a severe issue, yet I believe we should clean up this old config
file on upgrade. Otherwise, this warning will always appear unless tracker-
miner-fs package gets purged.

Thanks,
Boyuan yang


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

Bug#993883: tracker-extract: Calls nonexistant /usr/libexec/tracker-extract in /etc/xdg/autostart/tracker-extract.desktop

[Boyuan Yang]

Package: tracker-extract
Version: 3.1.1-4
Severity: important
X-Debbugs-CC: jbi...@debian.org

Dear Debian GNOME maintainers,

Current tracker-extract package is providing a broken
/etc/xdg/autostart/tracker-extract.desktop . After logging in, the following
error pops up in system log:

systemd-xdg-autostart-generator[2772]: Exec binary '/usr/libexec/tracker-
extract' does not exist: No such file or directory
systemd-xdg-autostart-generator[2772]: Not generating service for XDG
autostart app-tracker\x2dextract-autostart.service, error parsing Exec= line:
No such file or directory

Obviously we should call /usr/libexec/tracker-extract-3.

Thanks,
Boyuan Yang


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

Bug#993867: glewlwyd: possible buffer overflow on webauthn registration

[Salvatore Bonaccorso]

Hi Nicolas,

On Tue, Sep 07, 2021 at 05:16:21PM +, Nicolas Mora wrote:
> Hello,
> 
> 7 septembre 2021 12:19 "Salvatore Bonaccorso"  a écrit:
> 
> > 
> > Can you report the issue upstream?
> > 
> The issue is already fixed upstream (I'm the upstream author):
> https://github.com/babelouest/glewlwyd/commit/0efd112bb62f566877750ad62ee828bff579b4e2

Embarassing, I can assure you I did check the git repo.

Regards,
Salvatore

Bug#993882: power64le: virt-manager refuses to start fresh install of FreeBSD 13.0 due to qemu issue on power8 host (safe cache missing)

[Karel Gardas]

Package: virt-manager
Version: 1:3.2.0-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation?

An attempt to configure and run newly created FreeBSD 13.0 VM

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

Select "Local install media"
Leave architecture options as they are (ppc64le/pseries)
Specify boot iso (FBSD 13.0 release powerpc-powerpc64-disc1.iso)
Specify OS as 'FreeBSD 13.0'
Set memory to 8129MB
Set CPUs to 4
Enable storage for this virtual machine
Leave 20GB as space for disk
Finish with provided option.
This starts install process which results in "Unable to complete install: 
'internal error: qemu unexpectedly closed the monitor: 
 qemu-system-ppc64le: Requested saef cache capability level not supported by 
KVM Try appending -machine cap-cfpc=broken'

   * What was the outcome of this action?

On Close button click, the machine is destroyed hence there is no outcome.

   * What outcome did you expect instead?
i
Newly created and run FBSD 13.0 machine.

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


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: ppc64el (ppc64le)

Kernel: Linux 5.10.0-8-powerpc64le (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
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 virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gir1.2-gtk-3.0   3.24.30-3
ii  gir1.2-gtk-vnc-2.0   1.0.0-1+b1
ii  gir1.2-gtksource-4   4.8.1-4
ii  gir1.2-libosinfo-1.0 1.8.0-1
ii  gir1.2-libvirt-glib-1.0  4.0.0-2
ii  gir1.2-vte-2.91  0.64.2-2
ii  python3  3.9.2-3
ii  python3-dbus 1.2.18-2
ii  python3-gi   3.40.1-2
ii  python3-gi-cairo 3.40.1-2
ii  python3-libvirt  7.0.0-2
ii  virtinst 1:3.2.0-3

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

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

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

-- no debconf information

Bug#961162: django-fsm: FTBFS with Django 3.x

[Carsten Schoenert]

Hello Michael,

so far I've seen your latest upload of django-fsm should have fixed this
report.

At least I can rebuild django-fsm 2.7.1-2 within experimental (together
with python3-django 2:3.2.6-1) and also can succesfull run the
autopkgtest there.

Was closing this report just forgotten?

Regards
Carsten

Am Wed, May 20, 2020 at 04:35:31PM -0400 schrieb Chris Lamb:
> Source: django-fsm
> Version: 2.6.1-2
> Severity: normal
> User: python-modules-t...@lists.alioth.debian.org
> Usertags: django-3.x
> 
> Dear maintainer,
> 
> The version of Django experimental is currently 3.0.6-1. I have built
> the 153 reverse-dependencies in unstable against this version and 114
> of these build & pass their testsuite successfully. Unfortunately,
> django-fsm fails to build. Please see:
> 
> http://bugs.debian.org/960890
> 
> ... for more information. Please use this bug report for queries
> or questions regarding Django 3.x that are not specific to this
> particular package in order to reduce duplicated work across all of
> the bugs.
> 
>   […]
> 
>   Traceback (most recent call last):
> File "tests/manage.py", line 14, in 
>   execute_from_command_line(sys.argv)
> File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
> line 401, in execute_from_command_line
>   utility.execute()
> File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
> line 377, in execute
>   django.setup()
> File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in 
> setup
>   apps.populate(settings.INSTALLED_APPS)
> File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 91, 
> in populate
>   app_config = AppConfig.create(entry)
> File "/usr/lib/python3/dist-packages/django/apps/config.py", line 90, in 
> create
>   module = import_module(entry)
> File "/usr/lib/python3.8/importlib/__init__.py", line 127, in 
> import_module
>   return _bootstrap._gcd_import(name[level:], package, level)
> File "", line 1014, in _gcd_import
> File "", line 991, in _find_and_load
> File "", line 975, in _find_and_load_unlocked
> File "", line 671, in _load_unlocked
> File "", line 783, in exec_module
> File "", line 219, in 
> _call_with_frames_removed
> File 
> "/home/lamby/temp/cdt.20200517001623.iiYoFCQhhs.ags.lamby-debian-experimental.python3-django-fsm/django-fsm-2.6.1/django_fsm/__init__.py",
>  line 11, in 
>   from django.utils.functional import curry
>   ImportError: cannot import name 'curry' from 'django.utils.functional' 
> (/usr/lib/python3/dist-packages/django/utils/functional.py)
>   E: pybuild pybuild:352: test: plugin custom failed with: exit code=1: 
> python3.8 tests/manage.py
>   dh_auto_test: error: pybuild --test -i python{version} -p 3.8 returned exit 
> code 13
>   make[1]: *** [debian/rules:13: override_dh_auto_test] Error 25
>   make[1]: Leaving directory 
> '/home/lamby/temp/cdt.20200517001623.iiYoFCQhhs.ags.lamby-debian-experimental.python3-django-fsm/django-fsm-2.6.1'
>   make: *** [debian/rules:10: build] Error 2
>   dpkg-buildpackage: error: debian/rules build subprocess returned exit 
> status 2
> 
>   […]
> 
> The full build log is attached.
> 
> 
> Regards,
> 
> -- 
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

Bug#993881: ITP: obs-move-transition -- plugin for OBS Studio to improve switching scenes

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: obs-move-transition
  Version : 2.5.0
  Upstream Author : Exeldro 
* URL : https://obsproject.com/forum/resources/move-transition.913/
* License : GPL-2
  Programming Lang: C
  Description : plugin for OBS Studio to improve switching scenes

 This plugin moves sources to a new position during a scene transition,
 adding nice effects. If the 2 scenes contain a source with similar name
 (configured with settings) it will do the move the position and size
 between the 2 positions.
 .
 This filter can be added to a scene or a source to override the move
 transition for a source of the scene or the source global.
 .
 To use Move Transition, find for "Move" in "Scene Transitions" dock.
 This plugin is supported by OBS Studio 25 or above.

Bug#993880: exim4-config: additional dkim macro for dkim_identity

[Richard Lewis]

Package: exim4-config
Version: 4.94.2-7
Severity: normal
Tags: patch

Dear Maintainer,

In the file 
  /etc/exim4/conf.d/transport/30_exim4-config_remote-smtp
there are various macros around various dkim
settings.

But there is nothing for dkim_identity (which
sets the 'i=', see eg 
https://exim.org/exim-html-4.91/doc/html/spec_html/ch-dkim_and_spf.html
this has been available since at least buster)

The attached patch adds such a macro.

(Apologies if this is not the way to submit such a patch)



Thanks for considering applying this




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

Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread)
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 exim4-config depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77

Versions of packages exim4-config recommends:
ii  ca-certificates  20210119

exim4-config suggests no packages.

-- Configuration Files:
/etc/exim4/conf.d/acl/30_exim4-config_check_rcpt changed [not included]
/etc/exim4/conf.d/acl/40_exim4-config_check_data changed [not included]
/etc/exim4/conf.d/main/01_exim4-config_listmacrosdefs changed [not included]
/etc/exim4/conf.d/transport/30_exim4-config_remote_smtp changed [not included]
/etc/exim4/exim4.conf.template changed [not included]
/etc/exim4/passwd.client [Errno 13] Permission denied: 
'/etc/exim4/passwd.client'

-- debconf information excluded
--- etc__exim4__conf.d__transport__30_exim4-config_remote-smtp.orig 
2021-09-05 23:13:30.119197133 +0100
+++ etc__exim4__conf.d__transport__30_exim4-config_remote-smtp.new  
2021-09-05 23:17:30.522924605 +0100
@@ -24,3 +24,3 @@
 .ifdef REMOTE_SMTP_HELO_DATA
   helo_data=REMOTE_SMTP_HELO_DATA
 .endif
.ifdef REMOTE_SMTP_INTERFACE
  interface = REMOTE_SMTP_INTERFACE
.endif
 .ifdef DKIM_DOMAIN
 dkim_domain = DKIM_DOMAIN
 .endif
+.ifdef DKIM_IDENTITY
+dkim_identity = DKIM_IDENTITY
+.endif
 .ifdef DKIM_SELECTOR
 dkim_selector = DKIM_SELECTOR
 .endif

Bug#993739: blends-common: tempfile has to be replaced by mktemp

[Andreas Tille]

Hi,

thanks to you both for the bug report.  I confirm the description
what to do sounds pretty easy - but a patch that works would simplify
my work.

Thanks a lot

  Andreas. 

-- 
http://fam-tille.de

Bug#985406: apt-cacher-ng: Here is one solution for this bug

[Richard Lewis]

Package: apt-cacher-ng
Tags: patch
Followup-For: Bug #985406

Dear Maintainer,

I also see this bug. Attached is one way to 
solve it - depends only on find(1).

i put this as a separate file in
/etc/cron.daily/ but you might want to append
it to the existing cron script.

Would be great to get this fixed

Thanks for considering.



-- Package-specific info:

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread)
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 apt-cacher-ng depends on:
ii  adduser  3.118
ii  debconf [debconf-2.0]1.5.77
ii  dpkg 1.20.9
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13
ii  libevent-2.1-7   2.1.12-stable-1
ii  libevent-pthreads-2.1-7  2.1.12-stable-1
ii  libgcc-s110.2.1-6
ii  liblzma5 5.2.5-2
ii  libssl1.11.1.1k-1+deb11u1
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.3-6
ii  libwrap0 7.6.q-31
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages apt-cacher-ng recommends:
ii  ca-certificates  20210119

Versions of packages apt-cacher-ng suggests:
pn  avahi-daemon  
pn  doc-base  
ii  libfuse2  2.9.9-5

-- Configuration Files:
/etc/apt-cacher-ng/acng.conf changed [not included]
/etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: 
'/etc/apt-cacher-ng/security.conf'

-- debconf information excluded
#!/bin/sh
if [ -d /var/log/apt-cacher-ng ]; then
# rm older than 7 days
find /var/log/apt-cacher-ng -maxdepth 1 -name 
'maint_*.log.html.gz' -type f -user apt-cacher-ng -mtime +7 -delete

# gzip older than 1 day
find /var/log/apt-cacher-ng -maxdepth 1 -name 
'maint_*.log.html' -type f -user apt-cacher-ng -mtime +1 -exec gzip '{}' ';'
fi

Bug#993876: Crash after recent glibc update

[Marc Haber]

Hi,

On Tue, Sep 07, 2021 at 06:10:00PM +0200, wavexx wrote:
> I'm getting this crash when running a current unstable distribution:

I confirm this behavior. Have not investigated any further, maybe a
simple rebuild against new glibc helps. There is also #993821 which is
also NSS related.

Greetings
Marc

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

Bug#993346: pytest-mock: please upgrade to latest upstream release

[Sandro Tosi]

> Thanks - just pushed an update to debian/changelog.

uploaded! thanks for your contribution to Debian

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

Bug#993792: bullseye-pu: package iotop-c/1.17-1

[Boian Bonev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2021-09-07 at 15:04 +0100, Jonathan Wiltshire wrote:
> Control: tag -1 moreinfo
> 
> On Mon, Sep 06, 2021 at 06:06:47PM +0300, Boian Bonev wrote:
> > [ Changes ]
> > This update includes backported fixed from version 1.18 (already
> > in unstable). There are 4 patches, two of which are related, and
> > the other two are independent.

I was seeing unstable in the check-list and typed that instead of
testing.


> Please drop the unrelated changes and attach a revised debdiff.

Maybe I didn't express myself properly - by related, I mean related
between each other - one of the fixes is split in two separate patch
files and they should stay together or be dropped together. There are 3
fixes in 4 files total.


Or maybe I misunderstand now - in case you mean that some of the fixes
are not acceptable, please clarify which patches to drop and which to
keep. In my opinion all the 3 fixes are trivial, have been tested, have
low risk, will improve user experience and are safe to keep, but I may
be missing something.

Here is the changelog, hope that helps to make things unambiguous: 

  * Backport bugfixes from 1.18
- fix OOB access caused by UTF8 process names
- fix screen flicker during refresh with visible help
- allow ESC to close the help window


Thanks!
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEumC8IPN+WURNbSUAE2VyCRPS8i0FAmE3o7IACgkQE2VyCRPS
8i0NKA/+MJngPDxj/k3k9K6YXeBbOFTLLagUPyTNKOb3CgDClHR/3qzm7+lC34nV
hto/oNPUgaXVVPnsd9ooGAL+ABSXRVih/uw3yWowyLWqIeY98KzfjT6YO+40NTYe
55pGX/KyxLA6i+SAG+H9aRBIz9BYUbmerOOMfkKtpPoLj0Y/msG+6Q96HoXTn0gW
nYA5oDLhVwpI2ItOhVBtYA18gOL/VXUHmfZ4SJD6gOudB2EsFufxIteAymu/475+
OCZPYsMUD2uBOPanEP+gnfb2fWnZPDqQp8DR16u5XqTHGRes0U43JoxxTeV1Hv1h
kRTOC2IoJicsXn7PR+jEizfES6qFkuUbFoSwS3X1KQakrMiWURQUpGGEwMV+NwB7
at4SaQRe0nHM9V3EKBtsclZuAfOvhU/Px+z5WNo+DOu6xxiBI4vAJugSUDTBQbKD
V36myN+8hGLQfWIw47hEUu/haAnr8afJgqrE3wcGABUbUVu6MW0SbYFCe79jG84I
3y2BR55GSKuDcTgy0H3qRhCFBvS6iY/UP5miLoMG7MQk5IwVk85Vqps/IQ3kbey1
NUt5RLIeUFa52m6VQsPxqvQ7cZnpumxdlzmLtFYXtZgorRYHDppPy9eXvTHKp2aW
yfotlqh50StyX0Hb7+XwaXJBnLMHl2M7Vy08dPoi26kp7UnFgII=
=gZnW
-END PGP SIGNATURE-

Bug#592834: Just saw this when using autoremove

[Farokh - Best Tech Service, LLC]

I just updated my 20.04 install, it installed 5.4.0-84 (among other 
things). I rebooted and then used apt autoremove to remove anything old. 
Here's what I got:


   root@rct2:/home/farokh# apt autoremove
   Reading package lists... Done
   Building dependency tree
   Reading state information... Done
   The following packages will be REMOVED:
  linux-headers-5.4.0-77 linux-headers-5.4.0-77-generic
   linux-headers-5.4.0-80 linux-headers-5.4.0-80-generic
  linux-image-5.4.0-77-generic linux-image-5.4.0-80-generic
   linux-modules-5.4.0-77-generic linux-modules-5.4.0-80-generic
  linux-modules-extra-5.4.0-77-generic
   linux-modules-extra-5.4.0-80-generic
   0 upgraded, 0 newly installed, 10 to remove and 0 not upgraded.
   After this operation, 755 MB disk space will be freed.
   Do you want to continue? [Y/n]
   (Reading database ... 187508 files and directories currently installed.)
   Removing linux-headers-5.4.0-77-generic (5.4.0-77.86) ...
   Removing linux-headers-5.4.0-77 (5.4.0-77.86) ...
   Removing linux-headers-5.4.0-80-generic (5.4.0-80.90) ...
   Removing linux-headers-5.4.0-80 (5.4.0-80.90) ...
   Removing linux-modules-extra-5.4.0-77-generic (5.4.0-77.86) ...
   Removing linux-image-5.4.0-77-generic (5.4.0-77.86) ...
   /etc/kernel/postrm.d/initramfs-tools:
   update-initramfs: Deleting /boot/initrd.img-5.4.0-77-generic
   /etc/kernel/postrm.d/zz-update-grub:
   Sourcing file `/etc/default/grub'
   Sourcing file `/etc/default/grub.d/init-select.cfg'
   Generating grub configuration file ...
   Found linux image: /boot/vmlinuz-5.4.0-84-generic
   Found initrd image: /boot/initrd.img-5.4.0-84-generic
   Found linux image: /boot/vmlinuz-5.4.0-81-generic
   Found initrd image: /boot/initrd.img-5.4.0-81-generic
   Found linux image: /boot/vmlinuz-5.4.0-80-generic
   Found initrd image: /boot/initrd.img-5.4.0-80-generic
   done
   Removing linux-modules-extra-5.4.0-80-generic (5.4.0-80.90) ...
   Removing linux-image-5.4.0-80-generic (5.4.0-80.90) ...
   /etc/kernel/postrm.d/initramfs-tools:
   update-initramfs: Deleting /boot/initrd.img-5.4.0-80-generic
   /etc/kernel/postrm.d/zz-update-grub:
   Sourcing file `/etc/default/grub'
   Sourcing file `/etc/default/grub.d/init-select.cfg'
   Generating grub configuration file ...
   File descriptor 10
   (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted))
   leaked on vgs invocation. Parent PID 3468: /usr/sbin/grub-probe
   File descriptor 10
   (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted))
   leaked on vgs invocation. Parent PID 3468: /usr/sbin/grub-probe
   File descriptor 10
   (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted))
   leaked on vgs invocation. Parent PID 3481: /usr/sbin/grub-probe
   File descriptor 10
   (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted))
   leaked on vgs invocation. Parent PID 3481: /usr/sbin/grub-probe
   File descriptor 10
   (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted))
   leaked on vgs invocation. Parent PID 3494: /usr/sbin/grub-probe
   File descriptor 10
   (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted))
   leaked on vgs invocation. Parent PID 3494: /usr/sbin/grub-probe
   File descriptor 10
   (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted))
   leaked on vgs invocation. Parent PID 3507: /usr/sbin/grub-probe
   File descriptor 10
   (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted))
   leaked on vgs invocation. Parent PID 3507: /usr/sbin/grub-probe
   File descriptor 10
   (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted))
   leaked on vgs invocation. Parent PID 3579: /usr/sbin/grub-probe
   File descriptor 10
   (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted))
   leaked on vgs invocation. Parent PID 3579: /usr/sbin/grub-probe
   Found linux image: /boot/vmlinuz-5.4.0-84-generic
   Found initrd image: /boot/initrd.img-5.4.0-84-generic
   Found linux image: /boot/vmlinuz-5.4.0-81-generic
   Found initrd image: /boot/initrd.img-5.4.0-81-generic
   File descriptor 10
   (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted))
   leaked on vgs invocation. Parent PID 3979: /usr/sbin/grub-probe
   File descriptor 10
   (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted))
   leaked on vgs invocation. Parent PID 3979: /usr/sbin/grub-probe
   File descriptor 10
   (/var/lib/dpkg/triggers/linux-update-5.4.0-77-generic (deleted))
   leaked on lvs invocation. Parent PID 4086: /bin/sh
   done
   Removing linux-modules-5.4.0-77-generic (5.4.0-77.86) ...
   Removing linux-modules-5.4.0-80-generic (5.4.0-80.90) ...


Here is all the text from the ssh sessions:


   farokhs-Mac-Pro:~ farokh$ ssh rctmail
   far...@mail.rocklandtimes.com's password:
   Welcome to Ubuntu 20.04.3 LTS (GNU/Linux 5.4.0-81-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management: https://landscape.canonical.com
 * Support:    

Bug#993805: UDD: duplicate entries for the same release

[Sandro Tosi]

> A RM bug for manual cruft removal of this arch:all package should fix it ...

i've filed #993879 -- thanks

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

Bug#993879: RM: python-setuptools-scm -- RoQA; cruft

[Sandro Tosi]

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

Hello,
python-setuptools-scm (specifically version 4.1.2-3 is still in unstable due to
a weird chain of dependencies:

  mini-buildd -> python-keyring -> python-setuptools-scm

but mini-buildd is severely broken in sid, and already FTBFS in unstable,
so there's no need to keep this package around (which is also skewing other
work in the Python team).

Thanks,
Sandro

Bug#993647: libccid >= 1.4.35 breaks SafeNet tokens

[Vladimir K]

Hello.
I've tested the patch, it fixes the issue, but only for tokens with firmware 
0.12
It appears that one of my tokens has firmware 0.13 and it is still affected by 
the bug.
Adding 0x0013 to the condition also fixes 0.13 tokens.

> tags 993647 upstream fixed-upstream pending
> thank
> 
> Le 06/09/2021 à 12:16, Vladimir K a écrit :
> 
>> Hello.
> 
> Hello,
> 
>> safenetauthenticationclient maintains some sort of binary cache in 
>> /var/tmp/eToken.cache/.
>> It masks the problem after libccid upgrae for a while.
>> I was able to fully reproduce it on a fresh test eToken 5110, the problem 
>> appears after the cache is cleared.
>>
>> 3 logs of pcscd attached:
>> 1. with libccid 1.4.35, success
>> 2. with libccid 1.4.36, just after upgrade, success
>> 3. with libccid 1.4.36, after cleaning SAC cache, fail.
>>
>> Each log is gathered while the following actions were performed:
>> 1. connected token.
>> 2. run p11tool --login --list-all 'pkcs11:token=Test%20Token', entered PIN
>> 3. disconnected token
> 
> Thanks for the logs.
> 
> I fixed the issue upstream in 
> https://salsa.debian.org/rousseau/CCID/-/commit/b48e1e697010431b7f03d4ecfe917ceee95e2c64
> 
> I have no idea when I will make a new upstream release of the CCID driver.
> In the mean time I propose you to apply the fix and rebuild the driver 
> yourself.
> 
> Bye
> 
> --
> Dr. Ludovic Rousseau

Bug#993867: glewlwyd: possible buffer overflow on webauthn registration

[Nicolas Mora]

Hello,

7 septembre 2021 12:19 "Salvatore Bonaccorso"  a écrit:

> 
> Can you report the issue upstream?
> 
The issue is already fixed upstream (I'm the upstream author):
https://github.com/babelouest/glewlwyd/commit/0efd112bb62f566877750ad62ee828bff579b4e2

Bug#983718: RM: yash [mips64el mipsel] -- RoQA; no longer builds on mips*

[Chris Hofstaedtler]

* Sean Whitton  [210907 17:06]:
> On Sun 28 Feb 2021 at 09:58PM +02, Adrian Bunk wrote:
> 
> So it's expected that it won't be possible to resolve the build issue on
> those archs any time soon?  Have you any analysis of the failures?

No activity on investigating or rectifying the build issues was
reported for 7 months before your reply. If anything was going to
happen "soon", this bug would not have existed anymore.

Chris

Bug#993878: aqbanking-tools: request now requires nonsensical parameter

[Gregor Best]

Package: aqbanking-tools
Version: 6.3.0-1
Severity: normal

Dear Maintainer,

The aqbanking-cli tool now requires a --number parameter, which does not make 
sense in all circumstances. This is a bug that has since been fixed upstream 
(in commit 8c26a24e4d313da04fc1dd3fc8f128ff125a89e0).

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

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

Versions of packages aqbanking-tools depends on:
ii  libaqbanking44   6.3.0-1
ii  libc62.31-13
ii  libgwenhywfar79  5.6.0-2

aqbanking-tools recommends no packages.

Versions of packages aqbanking-tools suggests:
ii  gwenhywfar-tools  5.6.0-2

-- no debconf information

Bug#993877: ifupdown-extra: check-duplicate-ip wrongly detects a duplicate when using `arping` package

[Alex Volkov]

Package: ifupdown-extra
Version: 0.32
Severity: important
Tags: patch

Dear Maintainer,

/usr/sbin/arping from `arping` package uses '-d' option to detect duplicates, 
not '-D'. I fixed it in the provided patch (also took the liberty to fix the 
case for the interface flag).

Also, the default ARP_TIMEOUT set in /etc/default/network-test renders 
ineffective the specific setting of 1500 ms for it in the script, which should 
be at least noted in the comments or README.

-- System Information:
Debian Release: 11.0
  APT prefers stable
  APT policy: (991, 'stable'), (500, 'stable-security'), (500, 'oldstable'), 
(99, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.46-bootes0-p-1000 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages ifupdown-extra depends on:
ii  arping   2.21-2
ii  bind9-host [host]1:9.16.15-1
ii  curl 7.74.0-1.3+b1
ii  dpkg 1.20.9
ii  iproute2 5.10.0-4
ii  iputils-ping [ping]  3:20210202-1
ii  lsb-base 11.1.0
ii  net-tools1.60+git20181103.0eebece-1
ii  netcat-openbsd   1.217-3

Versions of packages ifupdown-extra recommends:
ii  ethtool  1:5.9-1
ii  ndisc6   1.0.4-2

ifupdown-extra suggests no packages.

-- Configuration Files:
/etc/default/network-test changed [not included]
/etc/network/if-up.d/10check-duplicate-ip changed [not included]

-- no debconf information
--- 10check-duplicate-ip.org	2021-09-07 09:22:25.0 +0500
+++ 10check-duplicate-ip	2021-09-07 10:22:16.0 +0500
@@ -83,7 +83,7 @@
 # Skip interface is address is IPv6, arping only works for IPv4
 if ! echo ${ADDR} | grep -q ":" ; then
 		[ "$VERBOSITY" -eq 1 ] && $OUTPUT "DEBUG: Sending arp pings through $real_iface (for $IFACE) to detect other systems using $ADDR"
-$ARPING -c $ARP_COUNT -w $ARP_TIMEOUT -D -I $real_iface $ADDR $ARPING_EXTRAOPTS >$ARPING_REDIR
+$ARPING -c $ARP_COUNT -w $ARP_TIMEOUT $ARPING_DAD $ARPING_IFACE $real_iface $ADDR $ARPING_EXTRAOPTS >$ARPING_REDIR
 		if [ $? -ne 0 ] ; then
 $OUTPUT "ERROR: Duplicate address $ADDR assigned in the network where $real_iface is connected to."
 		fi
@@ -119,6 +119,8 @@
 ARPING=/usr/bin/arping
 ARP_TIMEOUT=${ARP_TIMEOUT:-3} # Time here is measured in seconds
 ARPING_EXTRAOPTS="-q" # Use -q(uiet) in iputil's arping
+ARPING_DAD="-D"   # Detect duplicates
+ARPING_IFACE="-I" # Interface
 ARPING_REDIR="/dev/stdout"# Do not redirect output
 else
 if [ -x /usr/sbin/arping ] ; then
@@ -126,6 +128,8 @@
 ARP_TIMEOUT=${ARP_TIMEOUT:-1500} # Time here is measures in milliseconds
  # experiments show anything less than 1500 is unreliable.
 ARPING_EXTRAOPTS=""  # No '-q' option in arping
+ARPING_DAD="-d"  # Detect duplicates
+ARPING_IFACE="-i"# Interface
 ARPING_REDIR="/dev/null"# Send output to /dev/null if using this program
 else
 # Do not continue if ARPING is not available

Bug#993365: Button pusts computer to sleep, but still cannot wake up

[Jiri 'Ghormoon' Novak]

Hello,

I've just tried the grub option  init_on_alloc=0, it seems that the
power button now makes the computer go to sleep, but still it's
impossible to wake up.

Regards, JN

Bug#993864: ITP: taskserver -- taskwarrior synchronisation server

[Sergio de Almeida Cipriano Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio de Almeida Cipriano Junior 
X-Debbugs-Cc: debian-de...@lists.debian.org, sergios...@protonmail.com

* Package name: taskserver
  Version : 1.1.0
  Upstream Author : Göteborg Bit Factory 
* URL : https://github.com/GothenburgBitFactory/taskserver
* License : MIT
  Programming Lang: C++
  Description : taskwarrior synchronisation server

Taskserver is a daemon or service that will allow you to share tasks among
different client applications, primarily Taskwarrior.

Bug#993647: libccid >= 1.4.35 breaks SafeNet tokens

[Ludovic Rousseau]

tags 993647 upstream fixed-upstream pending
thank

Le 06/09/2021 à 12:16, Vladimir K a écrit :

Hello.


Hello,


safenetauthenticationclient maintains some sort of binary cache in 
/var/tmp/eToken.cache/.
It masks the problem after libccid upgrae for a while.
I was able to fully reproduce it on a fresh test eToken 5110, the problem 
appears after the cache is cleared.

3 logs of pcscd attached:
1. with libccid 1.4.35, success
2. with libccid 1.4.36, just after upgrade, success
3. with libccid 1.4.36, after cleaning SAC cache, fail.

Each log is gathered while the following actions were performed:
1. connected token.
2. run p11tool --login --list-all 'pkcs11:token=Test%20Token', entered PIN
3. disconnected token


Thanks for the logs.

I fixed the issue upstream in 
https://salsa.debian.org/rousseau/CCID/-/commit/b48e1e697010431b7f03d4ecfe917ceee95e2c64

I have no idea when I will make a new upstream release of the CCID driver.
In the mean time I propose you to apply the fix and rebuild the driver yourself.

Bye

--
Dr. Ludovic Rousseau

Bug#844148: reproducible on big but not small machines

[Camm Maguire]

Greetings!  You can limit the memory accessible to any GCL based process
by a factor of 0.5 via

export GCL_MEM_MULTIPLE=0.5

The algorithm *is* supposed to avoid OOM, however, so if there are
reproducible details on that I could try to look into it.

GCL probes the brk'able memory at startup, takes the lesser of that and
physical ram, and runs with that as a heap limit to maximize speed for
the power user.  There are several other environment variables which can
tune the gc/allocation algorithms at runtime if you are interested.

Take care,

Adam Borowski  writes:

>> > VM with 64 cores
>
>> Neither ACL2 nor underlying gcl makes any use of threads or locks
>
> I assume the 64-core box has adequate memory as well.
>
> For me, also on a 64-core box with "only" 128GB RAM, acl2 takes a
> three-digit number of gigs for itself, ignoring any other processes
> that are also running on the machine.  It keeps doing something nasty,
> with garbage collection prominently showing in stack traces.
>
> On a small box, it also hogs most of the memory for itself, being strongly
> anti-social, but finishes successfully.
>
> On a tiny box that's still fine for building any other package, it OOMs.
>
>
> Meow!

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#993867: glewlwyd: possible buffer overflow on webauthn registration

[Salvatore Bonaccorso]

Hi Nicolas,

On Tue, Sep 07, 2021 at 10:05:08AM -0400, Nicolas Mora wrote:
> Package: glewlwyd
> Version: 2.5.2-2
> Severity: important
> Tags: patch security
> X-Debbugs-Cc: Debian Security Team 
> 
> 
> 
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500,
> 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
> Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 glewlwyd depends on:
> ii  dbconfig-pgsql 2.0.19
> ii  debconf [debconf-2.0]  1.5.77
> pn  glewlwyd-common
> ii  init-system-helpers1.60
> ii  libc6  2.31-13
> ii  libcbor0   0.5.0+dfsg-2
> ii  libconfig9 1.5-0.4
> ii  libcrypt1  1:4.4.18-4
> ii  libgnutls303.7.1-5
> pn  libhoel1.4 
> pn  libiddawc0.9   
> ii  libjansson42.13.1-1.1
> ii  libldap-2.4-2  2.4.57+dfsg-3
> ii  libnettle8 3.7.3-1
> ii  liboath0   2.6.6-3
> pn  liborcania2.1  
> pn  librhonabwy0.9 
> pn  libulfius2.7   
> pn  libyder2.0 
> ii  lsb-base   11.1.0
> ii  sqlite33.34.1-3
> ii  ucf3.0043
> ii  zlib1g 1:1.2.11.dfsg-2
> 
> glewlwyd recommends no packages.
> 
> Versions of packages glewlwyd suggests:

> --- a/src/scheme/webauthn.c
> +++ b/src/scheme/webauthn.c
> @@ -1530,7 +1530,7 @@
>gnutls_pubkey_t pubkey = NULL;
>gnutls_x509_crt_t cert = NULL;
>gnutls_datum_t cert_dat, data, signature, cert_issued_by;
> -  unsigned char data_signed[200], client_data_hash[32], cert_export[32], 
> cert_export_b64[64];
> +  unsigned char * data_signed = NULL, client_data_hash[32], cert_export[32], 
> cert_export_b64[64];
>size_t data_signed_offset = 0, client_data_hash_len = 32, cert_export_len 
> = 32, cert_export_b64_len = 0;
>
>if (j_error != NULL) {
> @@ -1619,6 +1619,12 @@
>  break;
>}
>
> +  if ((data_signed = 
> o_malloc(rpid_hash_len+client_data_hash_len+credential_id_len+cert_x_len+cert_y_len+2))
>  == NULL) {
> +y_log_message(Y_LOG_LEVEL_DEBUG, "check_attestation_fido_u2f - Error 
> allocating data_signed");
> +json_array_append_new(j_error, json_string("Internal error"));
> +break;
> +  }
> +
>// Build bytestring to verify signature
>data_signed[0] = 0x0;
>data_signed_offset = 1;
> @@ -1653,6 +1659,7 @@
>}
>
>  } while (0);
> +o_free(data_signed);
>  
>  if (json_array_size(j_error)) {
>j_return = json_pack("{sisO}", "result", G_ERROR_PARAM, "error", 
> j_error);

Can you report the issue upstream?

Regards,
Salvatore

Bug#993838: sane-utils: fails to detect scanner w/o root privileges; the user is in scanner group

[Jörg Frings-Fürst]

Hello,

at first please answer always into the bug,too.


First please send the output of

systemctl status udev



Then check that

ENV{DEVNAME}!="", ENV{libsane_matched}=="yes", RUN+="/bin/setfacl -m 
g:scanner:rw $env{DEVNAME}"

is in one line without linebreak before the end.


Next please test:

Add the file as root:

/etc/udev/rules.d/scanner.rules


Insert this line 

SUBSYSTEMS=="usb", ATTRS{idVendor}=="07b3", ATTRS{idProduct}=="1300", 
GROUP="scanner"



Then reboot und test it again.

If fails then give me the output of

systemctl status udev

again.


Thanks 


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.




Am Dienstag, dem 07.09.2021 um 20:25 +0700 schrieb A L:
> 
> 07.09.2021 16:28, Jörg Frings-Fürst пишет:
> > Hello Andrei,
> > 
> > please add as root the file
> > 
> > /usr/lib/udev/rules.d/99-libsane1.rules
> > 
> > with the context
> > 
> > ENV{DEVNAME}!="", ENV{libsane_matched}=="yes", RUN+="/bin/setfacl -
> > m g:scanner:rw $env{DEVNAME}"
> > 
> > then reboot. And tell me if the error is fixed with it.
> > 
> > CU
> > Jörg
> > 
> 
> Sorry, no results ..
> 
> 
> # cat /usr/lib/udev/rules.d/99-libsane1.rules
> 
> ENV{DEVNAME}!="", ENV{libsane_matched}=="yes", RUN+="/bin/setfacl -m 
> g:scanner:rw $env{DEVNAME}"
> #
> 
> # sane-find-scanner
> 
>    # sane-find-scanner will now attempt to detect your scanner. If
> the
>    # result is different from what you expected, first make sure your
>    # scanner is powered up and properly connected to your computer.
> 
>    # No SCSI scanners found. If you expected something different,
> make 
> sure that
>    # you have loaded a kernel SCSI driver for your SCSI adapter.
> 
> found USB scanner (vendor=0x07b3 [PLUSTEK INC], product=0x1300
> [USB2.0 
> SCANNER], chip=GL845) at libusb:002:002
> 
> 
> $ sane-find-scanner
> 
>    # sane-find-scanner will now attempt to detect your scanner. If
> the
>    # result is different from what you expected, first make sure your
>    # scanner is powered up and properly connected to your computer.
> 
>    # No SCSI scanners found. If you expected something different,
> make 
> sure that
>    # you have loaded a kernel SCSI driver for your SCSI adapter.
> 
> could not open USB device 0x8087/0x0024 at 003:002: Access denied 
> (insufficient permissions)
> could not open USB device 0x1d6b/0x0002 at 003:001: Access denied 
> (insufficient permissions)
> could not open USB device 0x046d/0xc33a at 001:004: Access denied 
> (insufficient permissions)
> could not open USB device 0x062a/0x4101 at 001:003: Access denied 
> (insufficient permissions)
> could not open USB device 0x8087/0x0024 at 001:002: Access denied 
> (insufficient permissions)
> could not open USB device 0x1d6b/0x0002 at 001:001: Access denied 
> (insufficient permissions)
> could not open USB device 0x1d6b/0x0003 at 004:001: Access denied 
> (insufficient permissions)
> could not open USB device 0x07b3/0x1300 at 002:002: Access denied 
> (insufficient permissions)
> could not open USB device 0x1d6b/0x0002 at 002:001: Access denied 
> (insufficient permissions)
>    # No USB scanners found. If you expected something different, make
> sure that ...
> 
> WBR,
> 
> Andrei
> 
> 
> 
> 



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

Bug#993745: O: psad -- Designed to work with iptables to detect port scans

[Boyuan Yang]

X-Debbugs-CC: t...@debian.org
Control: tags 993802 -moreinfo

Hi,

在 2021-09-07星期二的 03:31 -0300，Leandro Cunha写道：
> X-Debbugs-CC: by...@debian.org
> 
> > I believe what you are doing is exactly called "packaging hijacking",
> > which is
> > unfavorable. Since the original maintainer did not volunteerly orphan the
> > package and that the Debian MIA Team did not kick in, we must not assume
> > that
> > the original package maintainer has given up the maintenance
> > responsibility.
> > 
> > Debian has a readily-available process to handle current situation (ITS)
> > and I
> > believe you also know it. We should follow this procedure to take over
> > package
> > maintenance in order to ensure smooth takeover where no argument would
> > take
> > place.
> > 
> > My suggestion is to convert this orphaning report to ITS report and start
> > ITS
> > process immediately according to
> > https://www.debian.org/doc/manuals/developers-reference/pkgs.html#package-salvaging
> > .
> > 
> > This mail copy is also sent to the original package maintainer (Franck
> > Joncourt). Franck: please let us know whether you are still going to
> > maintain
> > this package in Debian. If there's no response, we will continue with the
> > ITS
> > process and take over the maintenance of package psad in Debian.
> > 
> > Thanks,
> > Boyuan Yang
> 
> He was a maintainer of fwsnort according to the bug report [1]. That's
> where I made this decision. I was in doubt if the package is orphaned
> directly or needs to go through ITS. But I've never seen this before and
> seeing bug reports like this that the package has simply been orphaned.
> 
> I had emailed him, let's not fill his inbox.
> 
> I have a little over a year and I'm still learning to deal with situations.
> And yes, I've read the documentation, link below:
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#orphaning-a-package
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831274


I just reviewed the information, and the logic seems to be like this:

* Package psad listed Franck Joncourt  as the
maintainer,

* Franck Joncourt has multiple email addresses known to Debian as shown in
https://qa.debian.org/developer.php?login=franck.joncourt%40gmail.com ,
including the one called fra...@debian.org ,

* Looking at fra...@debian.org , Franck's role as Debian Developer has ended (
https://nm.debian.org/person/franck/ shows emeritus status since 2015),

* The Debian QA/MIA Team should have filed bugs to all packages Franck
previously maintained to remove the name from package maintenance, and it
indeed happened in https://bugs.debian.org/831274 . However, since Franck was
not using the debian.org email for package psad, package psad was not covered.


In this case, I think orphaning the package looks reasonable. CC-ing tobi
(from MIA Team) about this issue: I believe we also need more bug reports on
packages on
https://qa.debian.org/developer.php?login=franck.joncourt%40gmail.com to have
the name removed from package uploaders list.

Thanks,
Boyuan Yang


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

Bug#993876: Crash after recent glibc update

[wavexx]

Package: aide
Version: 0.17.3-4+b2
Severity: important

I'm getting this crash when running a current unstable distribution:

Stack trace of thread 5750:
#0  0x7ff4fa275fae __nss_database_lookup2 
(/lib/x86_64-linux-gnu/libc-2.32.so + 0x11ffae)
#1  0x7ff4fa31e520 n/a (n/a + 0x0)
#2  0x004f28a3 __new_getpwuid_r (/usr/bin/aide + 0xf28a3)
#3  0x004f2253 getpwuid (/usr/bin/aide + 0xf2253)
#4  0x00479aed __acl_to_any_text (/usr/bin/aide + 0x79aed)
#5  0x00415361 acl2line (/usr/bin/aide + 0x15361)
#6  0x00416ff6 get_file_attrs (/usr/bin/aide + 0x16ff6)
#7  0x004113ed db_readline_disk (/usr/bin/aide + 0x113ed)
#8  0x004172b5 populate_tree (/usr/bin/aide + 0x172b5)
#9  0x0040282f main (/usr/bin/aide + 0x282f)
#10 0x00498989 __libc_start_main (/usr/bin/aide + 0x98989)
#11 0x0040339a _start (/usr/bin/aide + 0x339a)

The crash doesn't occur in aide-dynamic.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (800, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread)
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)

aide depends on no packages.

Versions of packages aide recommends:
ii  aide-common  0.17.3-4

Versions of packages aide suggests:
pn  figlet  

Bug#993848: postgresql-13: A SELECT query with cursor can cause segmentation fault

[Tomas Barton]

Here's an attempt to make the bug reproducible. Unfortunately I'm not able
to reproduce the issue with generated data.

dropdb testdb || true
createdb -E UTF8 testdb
cat < stress.sql
CREATE TABLE "public".downloaded_images (
   itemid text NOT NULL,
   property text NOT NULL,
   image_number integer DEFAULT 0 NOT NULL,
   filename text,
   download_time timestamp without time zone DEFAULT CURRENT_TIMESTAMP,
   failures_count integer DEFAULT 0
);


INSERT INTO "public".downloaded_images(itemid, property, filename,
download_time)
SELECT md5(RANDOM()::TEXT), 'categoryPagePhotoUrl', md5(RANDOM()::TEXT),
NOW()
FROM generate_series(1, 10);
EOF

cat < evil.sql
BEGIN;

CREATE TABLE IF NOT EXISTS "vgg16_fc1"
 (itemId TEXT,
  embedding_number INT DEFAULT 0,
  embedding JSONB,
  weight NUMERIC DEFAULT 1,
  last_update TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  additional_data JSON,
  PRIMARY KEY(itemId, embedding_number)
  );

  CREATE INDEX IF NOT EXISTS "last_update_vgg16_fc1" ON "vgg16_fc1"
  USING btree ("last_update");


DECLARE "test-cursor-vgg16_fc1" CURSOR WITH HOLD FOR
   SELECT di.itemId, image_number, filename FROM (SELECT *
   FROM "public".downloaded_images
   WHERE property='categoryPagePhotoUrl' AND filename IS NOT NULL)
di
   LEFT JOIN (SELECT itemId, MIN(last_update) as last_update FROM
"vgg16_fc1" GROUP BY itemId) computed ON di.itemId=computed.itemId
   WHERE COALESCE(last_update, '1970-01-01') < download_time;


FETCH 1 IN "test-cursor-vgg16_fc1";


COMMIT;
EOF
psql -d testdb -f stress.sql
psql -d testdb -f evil.sql

Anytime I run the evil.sql, it crashes the server.

BEGIN
CREATE TABLE
CREATE INDEX
DECLARE CURSOR
psql:evil.sql:28: server closed the connection unexpectedly
   This probably means the server terminated abnormally
   before or while processing the request.
psql:evil.sql:28: fatal: connection to server was lost


On Tue, 7 Sept 2021 at 14:09, Christoph Berg  wrote:

> Re: Tomas Barton
> > a slightly sophisticated SELECT query with a CURSOR can lead to
> > postgresql server segmentation fault.
> >
> > LOG:  server process (PID 10722) was terminated by signal 11:
> Segmentation
> > fault
> > DETAIL:  Failed process was running: COMMIT
>
> > I'll try to make an reproducable code, let me known if you need more
> > information.
> >
> > The query might be a bit nasty, but it shouldn't crash whole server.
>
> Can you share the query and the schema?
>
> Christoph
>

Bug#991631: nfs-utils: please update to newer upstream version

[Salvatore Bonaccorso]

Hey Anibal,

On Mon, Sep 06, 2021 at 02:17:52AM +1000, Anibal Monsalve Salazar wrote:
> On Mon, Sep 6, 2021 at 1:46 AM Salvatore Bonaccorso  wrote:
> > On Mon, Sep 06, 2021 at 01:31:35AM +1000, Anibal Monsalve Salazar wrote:
> > > On Sat, Sep 4, 2021 at 10:47 PM Hector Oron  wrote:
> > > > El ds., 4 de set. 2021, 9:33, Anibal Monsalve Salazar 
> > > >  va escriure:
> > > >>
> > > >> Hello Salvatore, Héctor,
> > > >>
> > > >> Just to let you know that I have been working with version 2.5.4 and 
> > > >> the 2.5.5 RCs for the last few days, almost full time. Currently, I'm 
> > > >> reviewing once again all the patches.
> > > >
> > > > Excellent! I worked on it sometime, but my work is not ready, I should 
> > > > post it once it is ready for review and testing.
> > > >
> > > > Anibal, do you have some WIP you can publish (on salsa) for review 
> > > > and/or testing?
> > > >
> > > > I feel we are pretty close for a real update. :-)
> > > >
> > > > Thanks all for the work
> > >
> > > I uploaded nfs-utils 1:2.5.4-1~exp1 to experimental. Please try it.
> > > I'm using it right now.
> > >
> > > I plan to keep working on it.
> >
> > Great thank you, and from now on I guess it will be much easier to
> > keep on track.
> >
> > Can you please push the changes to the packaging repository?
> >
> > https://salsa.debian.org/kernel-team/nfs-utils/
> 
> Sure.

And thanks as well for 1:2.5.4-1~exp2. Can you please still push the
changes? For tagging the releases we usually use the scripts/d-k-tag
from https://salsa.debian.org/kernel-team/kernel-team .

Regards,
Salvatore

Bug#903880: ° //

[Daniel Mark Roland]

Përshëndetje, unë jam avokati Daniel M. Roland, ju kam shkruar më herët në
lidhje me trashëgiminë e familjes tuaj, por ende nuk kam marrë përgjigje,
pse?

Bug#993875: urlview FTBFS: configure: error: cannot find required auxiliary files: compile missing

[Helmut Grohne]

Source: urlview
Version: 0.9-21
Severity: serious
Tags: ftbfs

urlview fails to build from source in unstable. A build performed with
sbuild on amd64 ends with:

| cd . && CFLAGS="-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security" CXXFLAGS="-g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security" CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" 
LDFLAGS="-Wl,-z,relro" /<>/./configure --build=x86_64-linux-gnu 
--prefix=/usr --includedir="\${prefix}/include" --mandir="\${prefix}/share/man" 
--infodir="\${prefix}/share/info" --sysconfdir=/etc --localstatedir=/var 
--libexecdir="\${prefix}/lib/urlview" --srcdir=. --disable-maintainer-mode 
--disable-dependency-tracking --disable-silent-rules 
mandir=/<>/debian/urlview/usr/share/man
| configure: WARNING: unrecognized options: --disable-maintainer-mode
| configure: error: cannot find required auxiliary files: compile missing
| make: *** [/usr/share/cdbs/1/class/autotools.mk:46: debian/stamp-autotools] 
Error 1
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Helmut

Bug#993872: gnucobol3 FTCBFS: abuses AC_CHECK_FILE

[Helmut Grohne]

Source: gnucobol3
Version: 3.1.2-4
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gnucobol3 fails to cross build from source, because it abuses
AC_CHECK_FILE. The macro is meant to check for files on the host system,
but it is used to check for files inside the build tree. Please use test
-e for that purpose instead. The attached patch fixes the relevant uses,
but it does not make gnucobol3 cross buildable, because it still fails
due to help2man. Please consider applying the patch and close this bug
when doing so anyway.

Helmut
--- gnucobol3-3.1.2.orig/configure.ac
+++ gnucobol3-3.1.2/configure.ac
@@ -830,7 +830,7 @@
 	AC_MSG_NOTICE([Checks for local cJSON ...])
 	curr_libs="$LIBS"; curr_cppflags="$CPPFLAGS"
 	with_cjson_local=no
-	AC_CHECK_FILE([./libcob/cJSON.c],
+	AS_IF([test -e ./libcob/cJSON.c],
 	  [AC_MSG_CHECKING([if linking of ./libcob/cJSON.c works])
 	   CPPFLAGS="$curr_cppflags -I./libcob"
 	   LIBS="$LIBS $COMMON_LIBS"
@@ -848,7 +848,7 @@
 	   LIBS="$curr_libs"]
 	)
 	if test "$with_cjson_local" = "no"; then
-	  AC_CHECK_FILE([$srcdir/libcob/cJSON.c],
+	  AS_IF([test -e "$srcdir/libcob/cJSON.c"],
 	[AC_MSG_CHECKING([if linking of $srcdir/libcob/cJSON.c works])
 	 CPPFLAGS="$curr_cppflags -I$srcdir/libcob"
 	 LIBS="$LIBS $COMMON_LIBS"

Bug#993874: flurm FTBFS with glibc 2.32: fatal error: sys/sysctl.h: No such file or directory

[Helmut Grohne]

Source: slurm
Version: 0.4.3-2
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: debian-gl...@lists.debian.org

slurm fails to build from source with glibc 2.32, because sys/sysctl.h
was removed. A build ends with:

| [ 50%] Building C object CMakeFiles/slurm.dir/slurm.c.o
| /usr/bin/cc -D_HAVE_NCURSES  -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -o CMakeFiles/slurm.dir/slurm.c.o -c 
/<>/slurm.c
| In file included from /<>/slurm.c:37:
| /<>/os.h:180:10: fatal error: sys/sysctl.h: No such file or 
directory
|   180 | #include 
|   |  ^~
| compilation terminated.
| make[3]: *** [CMakeFiles/slurm.dir/build.make:85: 
CMakeFiles/slurm.dir/slurm.c.o] Error 1
| make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[2]: *** [CMakeFiles/Makefile2:98: CMakeFiles/slurm.dir/all] Error 2
| make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[1]: *** [Makefile:152: all] Error 2
| make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j1 VERBOSE=1 returned 
exit code 2
| make: *** [debian/rules:3: build] Error 25
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Helmut

Bug#993873: spline FTBFS: strips with the build architecture strip

[Helmut Grohne]

Source: spline
Version: 1.2-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

spline fails to cross build from source, because it strips with the
build architecture strip during make install. Doing so also breaks
generation of -dbgsym packages, but DEB_BUILD_OPTIONS=nostrip is
surprisingly honoured by the upstream Makefile. Please consider applying
the attached patch to disable such stripping and leaving it up to
dh_strip, which uses the correct strip.

Helmut
diff --minimal -Nru spline-1.2/debian/changelog spline-1.2/debian/changelog
--- spline-1.2/debian/changelog 2019-01-27 13:44:20.0 +0100
+++ spline-1.2/debian/changelog 2021-09-07 12:43:48.0 +0200
@@ -1,3 +1,10 @@
+spline (1.2-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Defer stripping to dh_strip. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 07 Sep 2021 12:43:48 +0200
+
 spline (1.2-4) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff --minimal -Nru spline-1.2/debian/rules spline-1.2/debian/rules
--- spline-1.2/debian/rules 2019-01-27 13:44:20.0 +0100
+++ spline-1.2/debian/rules 2021-09-07 12:43:47.0 +0200
@@ -6,6 +6,9 @@
 %:
dh $@
 
+override_dh_auto_install:
+   DEB_BUILD_OPTIONS="nostrip ${DEB_BUILD_OPTIONS}" dh_auto_install
+
 override_dh_auto_test:
# don't run the tests if suppressed with DEB_BUILD_OPTIONS=nocheck
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))

Bug#993871: rustc build ignores DEB_BUILD_OPTIONS=parallel=N

[Helmut Grohne]

Source: rustc
Version: 1.49.0+dfsg1-1
Severity: wishlist

When building the rustc package from source, the parallel=N option in
DEB_BUILD_OPTIONS is not honoured. Instead, the number of CPUs available
is used. In particular, a non-parallel build via parallel=1 is not
possible.

According to Ximin Luo, the cargo wrapper automatically passes the
correct -j option for everything but rustc, which matches my
observation. I do hope that you immediately know where this is.

A standard technique for computing the relevant flag is as follows:

ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
NJOBS := -j $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
endif

Helmut

Bug#993870: guesoglc FTBFS: make[2]: *** No rule to make target '../src/glew.c', needed by 'libGLC_la-glew.lo'. Stop.

[Helmut Grohne]

Source: quesoglc
Version: 0.7.2-6
Severity: serious
Tags: ftbfs

quesoglc fails to build from source in unstable. A non-parallel build
ends as follows:

| make[2]: *** No rule to make target '../src/glew.c', needed by 
'libGLC_la-glew.lo'.  Stop.
| make[2]: Leaving directory '/<>/build'
| make[1]: *** [Makefile:555: all-recursive] Error 1
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j1 returned exit code 2
| make: *** [debian/rules:4: build-arch] Error 25
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

Helmut

Bug#993869: libdvd-pkg: which(1) is deprecatd

[Christoph Anton Mitterer]

Package: libdvd-pkg
Version: 1.4.3-1-1
Severity: normal



Hi.

usr/lib/libdvd-pkg/b-i_libdvdcss.sh uses which, which has been deprecated:

Unpacking libdvd-pkg (1.4.3-1-1) over (1.4.2-1-1) ...
Setting up libdvd-pkg (1.4.3-1-1) ...
...
libdvd-pkg: Unpacking and configuring...
libdvd-pkg: Building the package... (it may take a while)
libdvd-pkg: Build log will be saved to 
/usr/src/libdvd-pkg/libdvdcss2_1.4.3-1~local_amd64.build
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.
...


Please use command -v instead :-)

Cheers,
Chris.

Bug#993045: Please bring back the -unsafe-string switch

[Julien Puydt]

Le mardi 07 septembre 2021 à 13:30 +0200, Stéphane Glondu a écrit :
> Le 06/09/2021 à 11:01, Julien Puydt a écrit :
> > The configure script checks for the availability of the switch, and
> > adds it to OCAMLCFLAGS... I checked String.set doesn't seem to be
> > used
> > and String.blit only once, so perhaps there's something simple to
> > do.
> > 
> > My current packaging is available here:
> > https://salsa.debian.org/science-team/scilab
> 
> I've removed the check (patch attached), and the package builds with
> no errors. I don't know how to check that everything works properly,
> though.

Hmmm... here it doesn't link, but indeed it doesn't look like it fails
because of OCaml.

Thanks!

J.Puydt

Bug#992122: golang-github-prometheus-client-golang-dev: new "collectors" package needed for packaging

[Peymaneh Nejad]

(Messed up my initial mail, sorry for the noise case this reaches you twice...)
Hi.

Am 12.08.21 um 07:41 schrieb Peymaneh Nejad:

Dear maintainers,

I am working on packaging the Caddy web server[1] which requires the
package github.com/prometheus/client_golang/prometheus/collectors that
was added recently in these commits[2] and is included in v1.11.0

Are you planning to update the package anytime soon?

If not: would you consider backporting this module and uploading a new revision?
I could also prepare a patch for that.


I looked into upgrading to v1.11.0 client_golang which requires 
github.com/prometheus/common v0.26.0, which in turn depends on a package 
(github.com/go-kit/log) that is not even yet in the archives[1].


 From a quick check with ratt it also seems an upgrade would break lot of 
reverse deps. Therefore I would go on with a backport of said module and do a 
team upload end of the week. Let me know if there is issues with that procedure


Kind regards,
Peymaneh



OpenPGP_signature
Description: OpenPGP digital signature

Bug#993793: bullseye-pu: package reportbug/7.10.3

[Jonathan Wiltshire]

Control: tag -1 confirmed moreinfo

On Mon, Sep 06, 2021 at 05:47:40PM +0200, Thomas Goirand wrote:
> This fixes the suite names against stable.
> Note that Sandro Tosi (maintainer of reportbug) agrees
> that I do this update in Stable.

Please go ahead and remove this bug's wontfix tag when uploaded.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



signature.asc
Description: PGP signature

Bug#993792: bullseye-pu: package iotop-c/1.17-1

[Jonathan Wiltshire]

Control: tag -1 moreinfo

On Mon, Sep 06, 2021 at 06:06:47PM +0300, Boian Bonev wrote:
> [ Changes ]
> This update includes backported fixed from version 1.18 (already
> in unstable). There are 4 patches, two of which are related, and
> the other two are independent.

Please drop the unrelated changes and attach a revised debdiff.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



signature.asc
Description: PGP signature

Bug#993868: gnome-control-center: No input devices listed in sound after update to Debian 11.

[Joseph Dighton]

Package: gnome-control-center
Version: 1:3.38.4-1
Severity: normal
X-Debbugs-Cc: jd.qz...@gmail.com

Dear Maintainer,

   * What led up to the situation?
Upgraded distro from Debian 10 to Debian 11.
After the upgrade I noticed that I there are no longer any
options populating in the input device menu in
gnome-control-center. 

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Installed non-free firmware and retested, issue persists. 
Checked that modules were loaded. 
Checked that hardware was present in system. 

   * What was the outcome of this action?
No change. There are still no input devices listed. 

   * What outcome did you expect instead?
Expected issue to be resolved, or at least to discover the root
cause. 

   The below link contain the outputs of
   gnome-control-center -v, lsmod, modprobe -c, lspci, and journalctl -a

   freeshell.de/tx3yz/

   I am available if additional logs or input is needed:
   
   Joseph Dighton
   jd.qz...@gmail.com




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

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

Versions of packages gnome-control-center depends on:
ii  accountsservice0.6.55-3
ii  apg2.2.3.dfsg.1-5+b2
ii  colord 1.4.5-3
ii  desktop-base   11.0.3
ii  desktop-file-utils 0.26-1
ii  gnome-control-center-data  1:3.38.4-1
ii  gnome-desktop3-data3.38.5-3
ii  gnome-settings-daemon  3.38.2-1
ii  gsettings-desktop-schemas  3.38.0-2
ii  libaccountsservice00.6.55-3
ii  libatk1.0-02.36.0-2
ii  libc6  2.31-13
ii  libcairo2  1.16.0-5
ii  libcheese-gtk253.38.0-3
ii  libcheese8 3.38.0-3
ii  libcolord-gtk1 0.1.26-2
ii  libcolord2 1.4.5-3
ii  libcups2   2.3.3op2-3+deb11u1
ii  libepoxy0  1.5.5-1
ii  libfontconfig1 2.13.1-4.2
ii  libgdk-pixbuf-2.0-02.42.2+dfsg-1
ii  libglib2.0-0   2.66.8-1
ii  libgnome-bluetooth13   3.34.3-2
ii  libgnome-desktop-3-19  3.38.5-3
ii  libgoa-1.0-0b  3.38.0-3
ii  libgoa-backend-1.0-1   3.38.0-3
ii  libgsound0 1.0.2-5
ii  libgtk-3-0 3.24.24-4
ii  libgtop-2.0-11 2.40.0-2
ii  libgudev-1.0-0 234-1
ii  libhandy-1-0   1.0.3-2
ii  libibus-1.0-5  1.5.23-2
ii  libkrb5-3  1.18.3-6
ii  libmalcontent-0-0  0.10.0-2
ii  libmm-glib01.14.12-0.2
ii  libnm0 1.30.0-2
ii  libnma01.8.30-1
ii  libpango-1.0-0 1.46.2-3
ii  libpangocairo-1.0-01.46.2-3
ii  libpolkit-gobject-1-0  0.105-31
ii  libpulse-mainloop-glib014.2-2
ii  libpulse0  14.2-2
ii  libpwquality1  1.4.4-1
ii  libsecret-1-0  0.20.4-2
ii  libsmbclient   2:4.13.5+dfsg-2
ii  libsoup2.4-1   2.72.0-2
ii  libudisks2-0   2.9.2-2
ii  libupower-glib30.99.11-2
ii  libwacom2  1.8-2
ii  libwayland-server0 1.18.0-2~exp1.1
ii  libx11-6   2:1.7.2-1
ii  libxi6 2:1.7.10-1
ii  libxml22.9.10+dfsg-6.7

Versions of packages gnome-control-center recommends:
ii  cracklib-runtime  2.9.6-3.4
ii  cups-pk-helper0.2.6-1+b1
ii  gkbd-capplet  3.26.1-1
ii  gnome-online-accounts 3.38.0-3
ii  gnome-user-docs   3.38.2-1
ii  gnome-user-share  3.34.0-2
ii  iso-codes 4.6.0-1
ii  libcanberra-pulse 0.30-7
ii  libnss-myhostname 247.3-6
pn  malcontent-gui
ii  network-manager-gnome 1.20.0-3
ii  policykit-1   0.105-31
ii  pulseaudio-module-bluetooth   14.2-2
ii  realmd0.16.3-3
ii  rygel 0.40.0-1
ii  rygel-tracker 0.40.0-1
ii  system-config-printer-common  1.5.14-1

Versions of packages gnome-control-center suggests:
ii  gnome-software   3.38.1-1
ii  gstreamer1.0-pulseaudio  1.18.4-2
pn  libcanberra-gtk-module   
ii  libcanberra-gtk3-module  0.30-7
ii  x11-xserver-utils7.7+8

-- no debconf information

Bug#993858: ocaml-dune: dune-install doesn't correctly place "doc" section in Debian systems

[Emilio Jesús Gallego Arias]

Hello Stéphane,

Stéphane Glondu  writes:

> I guess we are talking about people doing "sudo dune install", right? As
> opposed to "dune install" being called during Debian package builds.

I am talking about both, in particular it would be nice if

   DESTDIR=debian/tmp dune install

would install OCaml package docs in `share/doc` as opposed to `doc`,
which is the Opam layout.

> Installing arbitrary software this way (with root privileges) should not
> be done IMHO, but if done, it must happen in /usr/local (or outside
> /usr). I remember having trouble configuring dune correctly to do that
> (I couldn't tell it to "dune install" into /usr/local, but still look
> for libraries in /usr/lib/ocaml in "dune build".

This should have been solved, tho not sure in which version.

> It would be nice if dune had a notion of "profile": a default "local"
> one that would use /usr/local directories, and a "debian" one, used only
> for Debian package builds, that would use $destdir/usr and $destdir/etc.
> While searching for libraries in all profiles ("local" first, then
> "debian").

That's an interesting idea; for now, using dune 2.9, you should be able
to emulate profiles using the right options to `dune install`.

I think the idea upstream is more towards let packagers configure the
right defaults at dune build time, then have all the package builds work ok.

> The "correct" path for the "doc" section in the "local" profile would be
> /usr/local/share/doc.

Indeed, so with this patch, `dune install --prefix=/usr/local` will work 
correctly.

>> This creates problems for both users and developers.
>
> What kind of problems?

Developers using

  DESTDIR=debian/tmp dune install

have to manually move doc to share/doc

Users have the problem with --prefix=/usr/local not installing the docs
in the right location.

> Patching things this way could (would, I think) break Debian package
> builds. One has to check that all packages using dune (and there are a
> lot of them now) still build with this patch. Maybe this could be done
> during as part of an OCaml transition... To be continued.

Indeed, it could, tho actually I couldn't find a package installing the
docs as installed by dune.

>> Note that a similar problem may exist for files in the "etc" section.
>
> I am not really sure on how to handle the "etc" section. I would use
> /etc directly, even for third-party software but /usr/local/etc exists
> on the Internet, so maybe it would be better to use it in the "local"
> profile.

I guess the etc section is fine for both uses outlined above? Maybe not
for the packaging one, as actually you'd want

 DESTDIR=debian/tmp dune install --prefix=/usr/ --etcdir=/etc

the current Dune default is the Opam layout which would install config
in /usr/etc IIANM.

Kind regards,
Emilio

Bug#993156: nvidia-driver: recommend libnvidia-encode1

[Andreas Beckmann]

Control: notfound -1 470.57.02-2
Control: close -1 470.42.01-1

On 28/08/2021 06.35, mooff wrote:

I think it would be appropriate to add libnvidia-encode1 to recommends
for nvidia-driver.


That is already implemented (see #989885), the Recommends is in 
nvidia-driver-libs (and the fix was backported to stable and oldstable, 
too).



Andreas