Bug#732148: Genshi documentation might move to Sphinx eventually

[Simon Cross]

Addressing this should become easier once the Genshi documentation has
been migrated to Sphinx. See
https://github.com/edgewall/genshi/issues/10 for the upstream issue on
the migration.

Bug#527236: Upstream issue created

[Simon Cross]

I created https://github.com/edgewall/genshi/issues/32 upstream to
make this request more visible.

Bug#973734: doxygen: markdown anchors do not work with special symbols in path

[Michael R. Crusoe]

Package: doxygen
Version: 1.8.20-4
Severity: important
Tags: patch upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

Since doxygen 1.8.19, markdown anchors do not work with special symbols in 
path, like "+".

This means that any Debian package with a "+ds" "+dfsg" in their version
will have a problem.

Upstream issue: https://github.com/doxygen/doxygen/issues/8156
Upstream patch: https://github.com/doxygen/doxygen/pull/8157

This affected the seqan3 Debian package, though we have worked around it
by skipping some tests for now.

Thanks in advance for considering the upstream patch in the Debian
package of doxygen.

Cheers,

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEck1gkzcRPHEFUNdHPCZ2P2xn5uIFAl+iXRESHGNydXNvZUBk
ZWJpYW4ub3JnAAoJEDwmdj9sZ+biV58QAL4tYRIUA/xNzM2Ugg6DYmXcKmFn2+Dq
nn7mTV2waXJ3jNQL+QaFMs6/kP8b9gwYMHdiSU8kRiNGL0srcMO1U/hgYhl+Z+5B
Hgpkx41Ozi9vXK45ZVW0oaQ2vt6Ru+7DdUwmaWXvpAnEBWtphDI2IOil/PwdQPP3
tkHvB3RWfFnVxXLf6UhoJmswyjLKw0W1gMyes864BbbO9G+KXFn5/Xe9hxcj3Zav
NBZSrTD7I/I9VrySo/u+EW8gylX9y5MmoaL6+1ZhB885uhdv7aTujR3mUaGRz5hE
au4shfFwMvRZUOtGPhocUs1RRJODPs4CIpdrzFUpf+c7yhV8DbXIyzY2RADHiEVg
FTTYCl29LAMPXL5Fy8XR/fSe2K80P8LAEfNRscDsf6YnVw2p17HyaN0DNm8l9gZg
agHrOQgItBXHeww95y+xqnaKhJdm1UVBiIZ0jxBOBOpIPJJTAc5lsld+o/X20auX
q9CC/ev7UruDttItccwSSBNV57156gQ7FYX//+mLyhPzxmaGdU1cW9MqSLThGS4D
DFwL3Gw0nWOJw2/fO4aSSxu+K39rHjy8hn6RxP5uo4CPy5XKRPKLm4RJwpH6pQYX
Ipy2MNuOt+RHjfY0I2zAZw3jKuKsJ45gh0a0wOps8lJkqpBANOcpAFzGfE30BkIA
xq/XG8WHsmZ0
=GR/1
-END PGP SIGNATURE-

Bug#971788: marked as done (libnvidia-rtcore: Broken dependnecies: dependant libgcc-s1 version is unavailable)

[Atamert Ölçgen]

Now I managed to update and test. Thanks again!

On Wed, Nov 4, 2020 at 1:08 AM Andreas Beckmann  wrote:

> On 11/3/20 9:24 PM, Atamert Ölçgen wrote:
> > As of now I still can't upgrade to 450.80.*.
> > https://packages.debian.org/buster-backports/libnvidia-rtcore also
> > lists 450.66-1~bpo10+1 with the missing dependency. Am I missing
> something?
>
> Please wait some hours until the package has been built and distributed
> to the mirrors ;-)
>
> Andreas
>


-- 
Kind Regards,
Atamert Ölçgen

◻◼◻
◻◻◼
◼◼◼

www.muhuk.com

Bug#973571: ovmf: does not work with qemu-system-i386 5.1

[Ryutaroh Matsumoto]

I also verified that 32-bit version of OVMF_CODE_4M.ms.fd works.

I did
cp /home/ryutaroh/OVMF_VARS_4M.ms.fd /tmp
qemu-system-i386 -m 1024 -smp 1 -nographic -net nic,model=virtio -net 
user,hostfwd=tcp:127.0.0.1:10022-:22 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-pci,rng=rng0,id=rng-device0 \
-drive 
file=/var/lib/debci/qemu/sid-i386-uefi-nopae.img,cache=unsafe,if=virtio,index=0,format=qcow2
 \
-machine q35,smm=on -global driver=cfi.pflash01,property=secure,value=on \
-drive if=pflash,format=raw,read-only,file=/home/ryutaroh/OVMF_CODE_4M.ms.fd \
-drive if=pflash,format=raw,file=/tmp/OVMF_VARS_4M.ms.fd -enable-kvm

The important options for secure booting may be

-machine q35,smm=on
-global driver=cfi.pflash01,property=secure,value=on
-drive if=pflash,format=raw,read-only,file=/home/ryutaroh/OVMF_CODE_4M.ms.fd
-drive if=pflash,format=raw,file=/tmp/OVMF_VARS_4M.ms.fd
-enable-kvm

Ryutaroh

Bug#973721: libssreflect-coq: Depends: coq-8.12.0+4.08.1 but it is not installable

[Stéphane Glondu]

Le 03/11/2020 à 22:53, Sebastian Ramacher a écrit :
> The following packages have unmet dependencies:
>  libssreflect-coq : Depends: coq-8.12.0+4.08.1 but it is not installable
> E: Unable to correct problems, you have held broken packages.

Oh. I built the package locally (on Sep 11), but forgot to upload it. Sorry!


Cheers,

-- 
Stéphane

Bug#973250: libpam-tacplus: CVE-2020-27743

[Salvatore Bonaccorso]

Control: notfound -1 1.3.8-2

On Tue, Oct 27, 2020 at 09:14:33PM +0100, Salvatore Bonaccorso wrote:
> Source: libpam-tacplus
> Version: 1.3.8-2

That was actually not correct. The issue is only present after 1.5.0.

Regards,
Salvatore

Bug#973733: RTW88_8821ce module fails to find firmware during install and must be reloaded

[Brandon Werner]

On Tue, Nov 3, 2020, at 10:52 PM, Brandon Werner wrote:
> package: src:linux
> 
> Hi,
> I downloaded one of the firmware netinstall builds of Debian from today 
> (11/03/2020) to try installing on my netbook with the 8821ce wifi card 
> since Debian now has the 5.9 kernel. During the text install with 
> speech, I received an error that the network card could not be found. I 
> opened a console and looking at dmesg showed the driver not finding the 
> firmware with a -2 error, however, I noticed that the requested files 
> had been unpacked to /lib/firmware. I unloaded rtw88_8821ce and 
> reloaded it using modprobe and the firmware was found, after which the 
> network interface was successfully brought up.
I took a look at the installer logs and found something that looks like it 
could be the likely problem.

Nov  3 22:09:17 check-missing-firmware: removing and loading kernel module 
rtw_8821ce

I think some substitution is going wrong in the installer because it seems like 
the module should be called rtw88_8821ce.
> I was able to continue through the rest of the install without issue. I am 
> not sure what logs 
> would help but would be happy to provide anything requested to diagnose 
> this issue.

Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-friendly

[Boyuan Yang]

Hi,

在 2020-11-03星期二的 22:21 +，Limonciello, Mario写道：
> > -Original Message-
> > From: Boyuan Yang 
> > Sent: Tuesday, November 3, 2020 13:09
> > To: sub...@bugs.debian.org
> > Subject: Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-
> > friendly
> > 
> > Package: fwupd-amd64-signed
> > Severity: grave
> > Version: 1.4.6+2
> > X-Debbugs-CC: 93...@debian.org mario.limoncie...@dell.com
> > 
> > Dear EFI Team,
> > 
> > Package fwupd-amd64-signed currently cannot be installed on Debian
> > Unstable/Sid. It depends on fwupd (= 1.4.6-2) while Sid only has
> > fwupd
> > (= 1.4.6-2+b1).
> 
> I'm sorry can you show me where this +b1 build is?
> 
> I don't see it mentioned in https://tracker.debian.org/pkg/fwupd

It is shown at https://buildd.debian.org/status/package.php?p=fwupd .
If you actually install a Debian Sid system, you can also find the
package with this version string.


> > It seems obvious that such dependency relationship made
> > fwupd/fwupd-
> > amd64-signed not binNMU-friendly. Please consider setting a version
> > range to allow binNMU-ed package to satisfy the dependency
> > relationship.

Please consider reading https://wiki.debian.org/binNMU and see how can
things be improved.

Thanks,
Boyuan Yang

Bug#973527: swi-prolog: regression on 32-bits architectures

[Lev Lamberov]

Hi Sebastian,

Вт 03 ноя 2020 @ 21:59 Sebastian Andrzej Siewior :

> On 2020-11-01 15:59:19 [+0500], Lev Lamberov wrote:

>> there is a regression on 32-bits architectures [regression]. It should
>> be fixed upstream (in b218a30b5e4bb92ddd399238666448a102117bad), but the
>> fix is not tested yet. And currently I'm running low on time, so it
>> would be nice if someone could at least test the fix, prepare fixed
>> package for upload, or even upload NMU (in this case, please, also push
>> your changes to the Salsa repository).
>
> I applied the patch, built i386 and can confirm that the patch you
> mentioned did solve the problem by running debian/tests/runtests.
> I'm attaching the NMU.
> Feel free to either grab the needed pieces or telling to NMU it.

thanks for you work on it. Please, go ahead and upload NMU and push your
changes to Salsa repository.

Thanks!

Regards,
Lev

Bug#973733: RTW88_8821ce module fails to find firmware during install and must be reloaded

[Brandon Werner]

package: src:linux

Hi,
I downloaded one of the firmware netinstall builds of Debian from today 
(11/03/2020) to try installing on my netbook with the 8821ce wifi card since 
Debian now has the 5.9 kernel. During the text install with speech, I received 
an error that the network card could not be found. I opened a console and 
looking at dmesg showed the driver not finding the firmware with a -2 error, 
however, I noticed that the requested files had been unpacked to /lib/firmware. 
I unloaded rtw88_8821ce and reloaded it using modprobe and the firmware was 
found, after which the network interface was successfully brought up. I was 
able to continue through the rest of the install without issue. I am not sure 
what logs would help but would be happy to provide anything requested to 
diagnose this issue.

Bug#973732: texlive-bibtex-extra: bbl2bib fails to load BibTeX/Parser.pm

[Joachim Zobel]

Package: texlive-bibtex-extra
Version: 2020.20200925-1
Severity: normal

Dear Maintainer,

This is easy to reproduce:

$ bbl2bib -h
Can't locate BibTeX/Parser.pm in @INC (you may need to install the
BibTeX::Parser module) (@INC contains: //texmf-dist/scripts/bibtexperllibs
/etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.3
/usr/local/share/perl/5.30.3 /usr/lib/x86_64-linux-gnu/perl5/5.30
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-
gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl) at
/usr/bin/bbl2bib line 110.
BEGIN failed--compilation aborted at /usr/bin/bbl2bib line 110.

$ ls -l /usr/share/texlive/texmf-dist/scripts/bibtexperllibs/BibTeX/Parser.pm
-rw-r--r-- 1 root root 8521  1. Mai 2018  /usr/share/texlive/texmf-
dist/scripts/bibtexperllibs/BibTeX/Parser.pm



-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 1715 Nov  4 03:45 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Jun  8 10:31 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Sep 26 22:41 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Sep 26 22:41 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Sep  9 07:50 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Sep 26 22:41 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Sep 26 22:41 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3106 Oct 17 10:38 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jan 17  2017 mktex.cnf
-rw-r--r-- 1 root root 475 Sep  9 07:50 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-bibtex-extra depends on:
ii  tex-common  6.15
ii  texlive-base2020.20200925-1
ii  texlive-binaries2020.20200327.54578-5
ii  texlive-latex-base  2020.20200925-1

texlive-bibtex-extra recommends no packages.

texlive-bibtex-extra suggests no packages.

Versions of packages tex-common depends on:
ii  dpkg  1.20.5
ii  ucf   3.0043

Versions of packages tex-common suggests:
ii  debhelper  13.2.1

Versions of packages texlive-bibtex-extra is related to:
ii  tex-common6.15
ii  texlive-binaries  2020.20200327.54578-5

-- no debconf information

Bug#973731: ITP: ruby-launchy -- helper class for launching cross-platform applications

[Daniel Leidert]

Sent back to the list and CC to Antonio

Am Mittwoch, den 04.11.2020, 07:54 +0530 schrieb Pirate Praveen:
> On 2020, നവംബർ 4 7:05:29 AM IST, Daniel Leidert  wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Daniel Leidert 
> > X-Debbugs-Cc: debian-de...@lists.debian.org, debian-r...@lists.debian.org
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > * Package name: ruby-launchy
> >  Version : 2.5.0
> >  Upstream Author : Jeremy Hinegardner
> > * URL : https://github.com/copiousfreetime/launchy
> > * License : ISC
> >  Programming Lang: Ruby
> >  Description : helper class for launching cross-platform applications
> > 
> > Launchy is a helper class for launching cross-platform applications in a 
> > fire
> > and forget manner. There are application concepts (browser, email client, 
> > etc)
> > that are common across all platforms, and they may be launched differently 
> > on
> > each platform. Launchy is here to make a common approach to launching 
> > external
> > applications from within ruby programs.
> > 
> > This is a dependency of the travis.rb gem (a command line client for 
> > travis-ci.
> 
> There is already a similar package
> https://tracker.debian.org/pkg/ruby-launchy-shim

I missed that. It might be necessary to either update this package to match
launchy 2.5.0 or maybe even remove it? I definitely need it for travis. But I
will ask FTP masters to hold the package back until we reached a consensus.

Antonio, what do you think? You maintained ruby-launchy-shim.


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

If you like my work consider sponsoring me via
https://www.patreon.com/join/dleidert


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

Bug#973731: ITP: ruby-launchy -- helper class for launching cross-platform applications

[Pirate Praveen]

On 2020, നവംബർ 4 7:05:29 AM IST, Daniel Leidert  wrote:
>Package: wnpp
>Severity: wishlist
>Owner: Daniel Leidert 
>X-Debbugs-Cc: debian-de...@lists.debian.org, debian-r...@lists.debian.org
>
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>* Package name: ruby-launchy
>  Version : 2.5.0
>  Upstream Author : Jeremy Hinegardner
>* URL : https://github.com/copiousfreetime/launchy
>* License : ISC
>  Programming Lang: Ruby
>  Description : helper class for launching cross-platform applications
>
>Launchy is a helper class for launching cross-platform applications in a fire
>and forget manner. There are application concepts (browser, email client, etc)
>that are common across all platforms, and they may be launched differently on
>each platform. Launchy is here to make a common approach to launching external
>applications from within ruby programs.
>
>This is a dependency of the travis.rb gem (a command line client for travis-ci.

There is already a similar package
https://tracker.debian.org/pkg/ruby-launchy-shim


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#626230: Many years latter

[Karl Schmidt]

uhh -- This won't run on many of the x86 processors... fails on Atom(TM) x5-Z8350 and the N2807 -- Even on a 
i7-7700K it still crashes if the file is large (some size limit could be added?)


This was originally a assembly language program - there is a version in the sources that is C ( The make file is 
building the assembly one with nasm )..



There was a time when the size mattered - and it is fast - simple and -- used 
to work..

There is a C translation in the sources - could be that should be what gets 
built?

But I have a hunch it is only me and a handful of other users.

https://qa.debian.org/popcon.php?package=e3

I would hate to see this program go - but my assembly skills are not with x86 - could be the installed version 
should be the C version?


The fact is it is not runable on many amd64 systems - and really shouldn't be 
released as is.

I hope someone comes up and fixes it so it can run on atoms and  N2807  etc.. -- I've confirmed it crashes and 
likely causes corruption ( top shows left over processes.. ).


The only other shell editor that I have found with the e3ne key bindings is 
diakonos - no longer in Debian.

I hope this doesn't disappear - but it really shouldn't be in stable in it's 
current condition.



--

Karl Schmidt  EMail k...@lrak.net
3209 West 9th Street Ph (785) 979-8397
Lawrence, KS 66049

Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-friendly

[Limonciello, Mario]

> -Original Message-
> From: Boyuan Yang 
> Sent: Tuesday, November 3, 2020 13:09
> To: sub...@bugs.debian.org
> Subject: Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-friendly
> 
> Package: fwupd-amd64-signed
> Severity: grave
> Version: 1.4.6+2
> X-Debbugs-CC: 93...@debian.org mario.limoncie...@dell.com
> 
> Dear EFI Team,
> 
> Package fwupd-amd64-signed currently cannot be installed on Debian
> Unstable/Sid. It depends on fwupd (= 1.4.6-2) while Sid only has fwupd
> (= 1.4.6-2+b1).

I'm sorry can you show me where this +b1 build is?

I don't see it mentioned in https://tracker.debian.org/pkg/fwupd

> 
> It seems obvious that such dependency relationship made fwupd/fwupd-
> amd64-signed not binNMU-friendly. Please consider setting a version
> range to allow binNMU-ed package to satisfy the dependency
> relationship.
> 
> Thanks,
> Boyuan Yang

Bug#973731: ITP: ruby-launchy -- helper class for launching cross-platform applications

[Daniel Leidert]

Package: wnpp
Severity: wishlist
Owner: Daniel Leidert 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-r...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: ruby-launchy
  Version : 2.5.0
  Upstream Author : Jeremy Hinegardner
* URL : https://github.com/copiousfreetime/launchy
* License : ISC
  Programming Lang: Ruby
  Description : helper class for launching cross-platform applications

Launchy is a helper class for launching cross-platform applications in a fire
and forget manner. There are application concepts (browser, email client, etc)
that are common across all platforms, and they may be launched differently on
each platform. Launchy is here to make a common approach to launching external
applications from within ruby programs.

This is a dependency of the travis.rb gem (a command line client for travis-ci.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl+iBWAACgkQS80FZ8KW
0F1rORAAq644/sX/udilHEqZylSjzZEaQHlGhAkS8+n11L573L5xaXlrE76mSVxs
axyXs7cvrj1r3Mo3h/6kjZ1ItcVGUPrRRPQZu9ihxAJgaKYQ/hJb24V+8uu9ripY
b92sFO20F8YJPS6RgOBpdVgT5tlEPv47qzx6TQBAAluUJxvaQc/iiwXTe5/sOJyY
70omIQ1s5uv+L5JaQ8Js0ZgSRW1ll5rjWH2mxlW3onei8Wp3OXwICyAlLpeUv2Ef
XkpYgEnnefwT4Kiw/EAT/bOlLRCvloUJ/jbQVsi/7Fi8QEnBezhlvoAspw2YZoHt
2eAmoLzPFEKQV9OmDq7SVvqK4fJ5v2Nxz4DJw/10Qgr7T6O4IhE3cRfrR/srY/0o
J9BC0Inb4rest0UgBPijdV1/EzKtATBiVv6C0m85WvuB9jq41uI2S6FQ1yn4H43Z
bkA+w5IfHqEl1Uxx7EyXMHyC5fm2OMc5TROEwwC8t+F0iST6Ht+mri/HVojNFHMm
ZTDDtf3ICW6i+X6jVj8Yu4EHEalw9ER8sm8uCC+vU1wLr+7n/b5tGDXrUh/L9lOB
czEX+m8koU26TD4m+1EZjH/u0SDASqDEujVX+H5xiDTDRx0ek6/cQ3mYPB/dE95w
PYTUJvPPxypvSsHRJSjy6Xjz75onwid+yi4/ES8fTCg2OodWalg=
=8sHF
-END PGP SIGNATURE-

Bug#973729: nvidia-kernel-dkms: cannot load nvidia-uvm

[Joel Ray Holveck]

Package: nvidia-kernel-dkms
Version: 455.38-1
Severity: normal

Thanks for the recent 450.80.02 update!  I now can run the Nvidia driver with 
the 5.9 kernel.

However, I cannot load the nvidia-uvm kernel module.  When I try, the error 
messages logged in dmesg are:

nvidia_uvm: Unknown symbol radix_tree_preloads (err -2)
nvidia_uvm: Unknown symbol set_cpus_allowed_ptr (err -2)
nvidia_uvm: Unknown symbol mmu_notifier_unregister (err -2)
nvidia_uvm: Unknown symbol __mmu_notifier_register (err -2)

If I try to repeat with the 455.38 driver from experimental (as described in 
the data dump below), I only get the radix_tree_preloads error message.

nvidia-uvm is required for CUDA programs to run.  It's normally loaded when a 
CUDA program starts up, through nvidia-modprobe -u.

I can run CUDA programs successfully with the earlier 5.8 kernel and either the 
bullseye 450.80.02-1 or experimental 455.38-1 driver.  I just cannot run them 
with the 5.9 kernel.

Attached is quick CUDA test program.  Compile with "nvcc -o foo foo.cu", and 
run.  On my current system, I get "foo: foo.cu:18: cudaGetDevice(): 
cudaErrorUnknown (999)" and the nvidia_uvm load errors appear in dmesg.

-- Package-specific info:
uname -a:
Linux thor 5.9.0-1-amd64 #1 SMP Debian 5.9.1-1 (2020-10-17) x86_64 GNU/Linux

/proc/version:
Linux version 5.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.0-15) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 
5.9.1-1 (2020-10-17)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  455.38  Thu Oct 22 06:06:59 UTC 
2020
GCC version:  gcc version 10.2.0 (Debian 10.2.0-15) 

lspci 'display controller [030?]':
09:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU106 [GeForce RTX 
2070 Rev. A] [10de:1f07] (rev a1) (prog-if 00 [VGA controller])
Subsystem: NVIDIA Corporation TU106 [GeForce RTX 2070 Rev. A] 
[10de:12ad]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video  226,   0 Nov  3 14:42 /dev/dri/card0
crw-rw+ 1 root render 226, 128 Nov  3 14:42 /dev/dri/renderD128
crw-rw-rw-  1 root root   195, 254 Nov  3 14:42 /dev/nvidia-modeset
crw-rw-rw-  1 root root   195,   0 Nov  3 14:42 /dev/nvidia0
crw-rw-rw-  1 root root   195, 255 Nov  3 14:42 /dev/nvidiactl

/dev/dri/by-path:
total 0K
lrwxrwxrwx 1 root root  8 Nov  3 14:42 pci-:09:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Nov  3 14:42 pci-:09:00.0-render -> ../renderD128
video:x:44:joelh,boinc

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Nov  3 14:39 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   49 Feb 27  2020 
/etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root   49 Nov  3 14:39 
/etc/alternatives/glx--libEGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   51 Nov  3 14:39 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   48 Feb 27  2020 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Feb 27  2020 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Nov  3 14:39 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   48 Nov  3 14:39 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 Nov  3 14:39 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 Nov  3 14:39 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   55 Feb 27  2020 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root   55 Feb 27  2020 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root   55 Nov  3 14:39 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   55 Nov  3 14:39 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   57 Nov  3 14:39 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 

Bug#972802: [Pkg-rust-maintainers] Bug#972802: rust-webpki-roots: duplicates ca-certificates, remove from Debian?

[Paul Wise]

On Tue, 2020-11-03 at 20:45 +, kpcyrd wrote:

> It's more complicated than that, there's rustls-native-certs to use the
> local certificate store, but the patch would be so invasive that debian
> would effectively maintain a fork. At the time of writing webpki-roots
> has 85 reverse dependencies on crates.io, while rustls-native-certs has
> 13.

I wonder if a wrapper crate that would present a common API and allow a
build-time choice between the two options would be the way to go? Then
everything that uses either of them could get changed upstream to use
the wrapper, upstream builds could use webpki-roots and Debian could
configure our builds to use rustls-native-certs. Is that plausible?

> > - The quality of the ca-certificates package on debian-based Linux
> > distributions is poor. At the time of writing, this ships many
> > certificates not included in the Mozilla set, either because they
> > failed an audit and were withdrawn[1] or were removed for
> > mississuance[2].
> 
> [1]: https://bugs.mozilla.org/show_bug.cgi?id=1448506
> [2]: https://bugs.mozilla.org/show_bug.cgi?id=1552374

FTR, those URLs are broken, they need "bugs" replaced with "bugzilla".

TÜRKTRUST was removed from the Debian package in 20190110 and Certnomis
was removed from the Debian package in 20200601, those were definitely
quite a bit later than what Mozilla did :(

I'm not sure what the solution there is. It probably doesn't help that
the current maintainer is not yet a Debian member, but is a Debian
Maintainer (DM), but can't upload ca-certificates without a sponsor.
Maybe the package should be co-maintained by the Debian security team? 

https://ftp-master.debian.org/dm.txt

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#973667: Directory List /.../.../.../... titles puts "meat" too far to the right

[Katsumi Yamaoka]

On Tue, 03 Nov 2020 06:56:31 +0800, 積丹尼さん wrote:
> Let's say in emacs-w3m we are browsing the directory
> file:///home/jidanni/jidanni.org/geo/antipodes/programs/

> Well, perhaps the buffer name/title should be

>programs Directory list,
> or
>programs Directory list 
> (/home/jidanni/jidanni.org/geo/antipodes/programs/),
> instead of
>Directory list of /home/jidanni/jidanni.org/geo/antipodes/programs/

That's a good idea, but the title is what w3m says AFAIU;
emacs-w3m only copies it.  Though it would probably be possible to
make emacs-w3m modify it, I think doing it by w3m is much better.

Bug#973666: Cursor left at top when browsing directories

[Katsumi Yamaoka]

On Tue, 03 Nov 2020 06:39:29 +0800, 積丹尼さん wrote:
> $ w3m file:///home/jidanni/jidanni.org/geo/antipodes/programs/
> puts the cursor in the right spot.

> But in emacs-w3m, the cursor is left way at the top!

Fixed in the emacs-w3m git master.  Thanks.

Bug#957439: libforms: ftbfs with GCC-10

[Paul Wise]

On Tue, 2020-11-03 at 11:18 -0500, Peter S Galbraith wrote:

> Thanks for your upload. Real life took over again. :-(

No worries. Debian should definitely be lower priority than real life :)

> Want to take over the package? :-)

I don't have time to take over another package, sorry. :(

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#168814: Andreas Klunder

[Ekaterina Dear]

Es scheint mir, dass wir gemeinsame Hobbys haben werden!! Ich habe dich bemerkt 
sofort und beschloss, Ihnen zu schreiben!! Bitte, sagen Sie mir deinen Namen 
und welchem Ort leben Sie?


Wann bist du geboren? Ich möchte denken, dass Ihnen meine Photo mögen!! Ich 
denke, dass es ein gegenseitiges Sympathie zwischen Ihnen und mir geben wird!!


Alle Menschen unabhängig vom Alter, suchen einen Begleiter, mit der Sie sich 
unterhalten und interessante Themen besprechen können!! Die Leben fehlt es an 
Freude und Verständnis!! Jede Frau träumt davon, jemanden haben, die zuhörten 
und verstehen!!


Was denkst Sie darüber? Ich werde dir von meinem Hauptwunsch schreiben!! Ich 
warte auf einen guten Freund oder nur einen angenehmen Gesprächspartner!! Wenn 
Sie an einer angenehmen Dialog wünschen, schreiben Sie mir und erzählen Sie mir 
mehr über sich!!


Ich bin sicher, dass ich mich nicht in dir enttäuscht sein werde und Sie ein 
anständiger Mensch sind!! Ich bin Kateryna!! Und ich werde auf deineAntwort 
warten!!


Lassen Sie sich nicht entmutigen, wenn kann ich Ihnen nicht sofort beantworten, 
weil ich gerade ein wenig freie Zeit haben!! Aber ich werde Ihnen später 
beantworten!! Bitte schreibe mir!!







Sorry, you have Javascript Disabled To see this page as it is meant to appear, 
please enable your Javascript See instructions here

  *

[decoarchi.com][decoarchi.com][decoarchi.com]

  *
0

  *   Disclaimer
  *   Privacy Policy
  *   Contact Us
  *   Sitemap

18Mar2020

  *
[decoarchi.com][decoarchi.com][decoarchi.com]

  *   Apartment
  *   Decoration
  *   DIY
  *   Garden
  *   Interior
  *   RV
  *
  *
 *
 *

Bug#973718: blueman: CVE-2020-15238

[Nobuhiro Iwamatsu]

Hi,

I added some comment on https://mentors.debian.net/. Could  you check it?

Best regards,
  Nobuhiro

2020年11月4日(水) 8:09 Nobuhiro Iwamatsu :
>
> Hi,
>
> Sorry,.I will check this,If there is no problem, upload it.
>
> Best regards,
>   Nobuhiro
>
> 2020年11月4日(水) 6:17 Christopher Schramm :
>
> >
> > Hi Salvatore,
> >
> > 2.1.4-1 is waiting at https://mentors.debian.net/package/blueman/. I can
> > add the CVE number and / or this bug to the changelog if you like.
> >
> > Unfortunately my sponsor Nobuhiro seems to be unavailable.
> >
> > Regards
>
>
>
> --
> Nobuhiro Iwamatsu
>iwamatsu at {nigauri.org / debian.org}
>GPG ID: 40AD1FA6



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#973728: install fail

[Roger Moseley]

Package: installation-reports

Boot method: CD?
Image version: 
https://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-10.6.0-i386-xfce-CD-1.iso
Date: today

Machine: Sony Vario PCG-9202
Processor: really old
Memory: 128 mb
Partitions: unk

Output of lspci -knn (or lspci -nn): unk

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

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

Comments/Problems: Did not detect the D-Link DWL-650 aircard. Driver was 
available on USB stick, but was not detected. All the steps and the screen text 
made sense, it just couldn't proceed. Install was being done in Low Memory mode.

Bug#973718: blueman: CVE-2020-15238

[Nobuhiro Iwamatsu]

Hi,

Sorry,.I will check this,If there is no problem, upload it.

Best regards,
  Nobuhiro

2020年11月4日(水) 6:17 Christopher Schramm :

>
> Hi Salvatore,
>
> 2.1.4-1 is waiting at https://mentors.debian.net/package/blueman/. I can
> add the CVE number and / or this bug to the changelog if you like.
>
> Unfortunately my sponsor Nobuhiro seems to be unavailable.
>
> Regards



--
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#957571: mtpaint: diff for NMU version 3.40-3.1

[Sudip Mukherjee]

Control: tags 957571 + patch
Control: tags 957571 + pending
--

Dear maintainer,

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

--
Regards
Sudip

diff -Nru mtpaint-3.40/debian/changelog mtpaint-3.40/debian/changelog
--- mtpaint-3.40/debian/changelog   2016-04-07 10:49:10.0 +0100
+++ mtpaint-3.40/debian/changelog   2020-11-03 23:04:37.0 +
@@ -1,3 +1,10 @@
+mtpaint (3.40-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957571)
+
+ -- Sudip Mukherjee   Tue, 03 Nov 2020 23:04:37 
+
+
 mtpaint (3.40-3) unstable; urgency=medium
 
   * Bump Standards-Version to 3.9.7. No changes were needed.
diff -Nru mtpaint-3.40/debian/rules mtpaint-3.40/debian/rules
--- mtpaint-3.40/debian/rules   2016-04-07 10:22:59.0 +0100
+++ mtpaint-3.40/debian/rules   2020-11-03 22:58:01.0 +
@@ -2,6 +2,7 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
+export DEB_CFLAGS_MAINT_APPEND = -fcommon
 %:
dh $@
 

Bug#973727: ITP: ruby-gh -- multi-layer client for the GitHub API v3

[Daniel Leidert]

Package: wnpp
Severity: wishlist
Owner: Daniel Leidert 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ruby 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: ruby-gh
  Version : 0.18.0
  Upstream Author : Konstantin Haase
* URL : https://github.com/travis-ci/gh
* License : MIT/X
  Programming Lang: Ruby
  Description : multi-layer client for the GitHub API v3

This is a highly flexible, layered, low-level GitHub client library for the
GitHub API v3, trying to get out of your way and let you get to the GitHub
data as simple as possible. Unless you add layers, you will end up with
Hashes and Arrays. The approach and API should be familiar from projects like
Rack or Faraday.

This package is a dependency for the Ruby travis client.
https://github.com/travis-ci/travis.rb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl+h4SsACgkQS80FZ8KW
0F0mlg//SsCMGoNgdtzfRJcn3/2ilpnCTnqAY2AIAGGDas1Rd0LEroVKFmqh5Yfp
+o6YlwnND4xh4Z0pvzgzDyLsZHOqLV7FbErSYi69+6guhAN1Xc9yrD37BYxOm0bq
9M9lhGeRk2Y0Tj5splmhE/5rI1hsTVa81t/N7jA2pbjo0htRY8WsM3OZzkkDKDlC
2de1T47OoofTvW6XLUkKDOJCYacuZcE2vqO/xi/n6PCEPLMUFPCkqqvFV6ZKxXWW
LOJu112kg/OWPPSjLQnBBuLBqhbcKG8gcIkGS+mIvvzbemqqVSryU1Xt5uKXrwoT
76ssue5dmAEc3d0yuGWx2uiFC3g1KbbThVOut3zyZIbdd5j32vqxBo3OTbUATOx4
k15PZYahfVRzqQ91jT9K6WI8KZNiwIyDUQhJGhw9gxJjPtdSAfvUxbF733QUtL6l
aLORzdXT+3W3+eDQYkkn2IGwjkuzXopo1kD5kMHCc0nA1eSJKgWzwxG9OV7vzwfk
csVIDro9oEV+AcIrULE8mt1sjxNiUfl8aJofTOU3exphchs0QQRbQDyTtVajqAx6
c5IOVAyGNZbcphbxOua0BUIQyRykbyBETi31rbyukejPbfXAUQjT5FzFEq4sltjG
YfKUk9kGcPOFvGob5gmvsc54zbn7sIm36z65d5kgt1hHoQGyXr8=
=AMRJ
-END PGP SIGNATURE-

Bug#973726: ITP: ring-basic-authentication-clojure -- ring middleware to enforce basic authentication

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: ring-basic-authentication-clojure
  Version : 1.1.0
  Upstream Author : Remco van t Veer 
* URL : https://github.com/remvee/ring-basic-authentication
* License : EPL-1.0
  Programming Lang: Clojure
  Description : ring middleware to enforce basic authentication

 Ring middleware to enforce basic authentication as described in RFC2617
 section 2.

Note: This is a dependency for Puppet-server 6.

Bug#957762: rgbpaint: diff for NMU version 0.8.7-6.1

[Sudip Mukherjee]

Control: tags 957762 + patch
Control: tags 957762 + pending
--

Dear maintainer,

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

--
Regards
Sudip

diff -Nru rgbpaint-0.8.7/debian/changelog rgbpaint-0.8.7/debian/changelog
--- rgbpaint-0.8.7/debian/changelog 2016-04-06 15:04:37.0 +0100
+++ rgbpaint-0.8.7/debian/changelog 2020-11-03 22:46:50.0 +
@@ -1,3 +1,10 @@
+rgbpaint (0.8.7-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957762)
+
+ -- Sudip Mukherjee   Tue, 03 Nov 2020 22:46:50 
+
+
 rgbpaint (0.8.7-6) unstable; urgency=low
 
   * Set Standards-Version to 3.9.7, no changes.
diff -Nru rgbpaint-0.8.7/debian/rules rgbpaint-0.8.7/debian/rules
--- rgbpaint-0.8.7/debian/rules 2016-04-06 11:15:53.0 +0100
+++ rgbpaint-0.8.7/debian/rules 2020-11-03 22:34:54.0 +
@@ -4,6 +4,8 @@
 
 include /usr/share/dpkg/buildflags.mk
 
+export DEB_CFLAGS_MAINT_APPEND = -fcommon
+
 %:
dh $@
 

Bug#973725: nutsqlite missing dependency

[Étienne Mollier]

Package: nutsqlite
Version: 2.0.6-2
Severity: important

The "nutsqlite" package is missing "tcl-thread" as dependency.
This has initially been caught by Flavio Visentin, thanks for
your report:


https://alioth-lists.debian.net/pipermail/debian-med-packaging/2020-November/085939.html

Quoting Flavio Visentin:
> Hi,
> the nut package, at least in the version 2.0.6-1 in Sid, should depend 
> on the package tcl-thread, which is not installed by default.
> 
> After running update-nut, the first invocation of nut gives the 
> following output:
> 
> 21:56 visentin at zipwks:~$ update-nut
> 21:56 visentin at zipwks:~$ nut
> can't find package Thread
>  while executing
> "package require Thread"
>  ("eval" body line 30)
>  invoked from within
> "eval $code"
>  invoked from within
> "if {[catch { db eval {select code from z_tcl_code where name = 'Main'} 
> { } }]} {
>   package require Tk
>   set ::magnify [expr {[winfo vrootheight .] / 711..."
>  (file "/usr/bin/nut" line 51)
> 
> After installing tcl-thread it works.
> 
> -- 
> Flavio Visentin
> 
> There are only 10 types of people in this world:
> those who understand binary, and those who don't.

Bug#973724: RFS: hcloud-python/1.10.0-1 -- official client library for Hetzner Cloud

[Leo Antunes]

Package: sponsorship-requests
Severity: wishlist

Dear Maintainers,

I am looking for a sponsor for my package "hcloud-python":

* Package name: hcloud-python
  Version : 1.10.0-1
  Upstream Author : Hetzner Cloud GmbH
* URL : https://github.com/hetznercloud/hcloud-python
* License : MIT
  Section : python

It builds those binary packages:

  python3-hcloud - official client library for Hetzner Cloud

For more info: https://mentors.debian.net/package/hcloud-python


Alternatively, download it with dget:

dget -x 
https://mentors.debian.net/debian/pool/main/h/hcloud-python/hcloud-python_1.10.0-1.dsc


Cheers,
Leo Antunes



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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_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

Bug#973622: closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#973622: fixed in lumpy-sv 0.3.1+dfsg-3)

[Andreas Beckmann]

Control: found -1 0.3.1+dfsg-3

The problem persists.

Andreas

Bug#971433: libcharls-dev: Problem with latest unstable install

[Andreas Beckmann]

Followup-For: Bug #971433

The problem has reappeared in the -6 upload.


Andreas

Bug#973723: libcharls-dev ships libcharls.so which is also in libdcmtk-dev

[Adrian Bunk]

Package: libcharls-dev
Version: 2.1.0+dfsg-6
Severity: serious

Unpacking libcharls-dev:amd64 (2.1.0+dfsg-6) over (2.1.0+dfsg-5) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-46o0f4/00-libcharls-dev_2.1.0+dfsg-6_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/libcharls.so', which is also in 
package libdcmtk-dev 3.6.4-2.1+b1

Bug#973701: [Pkg-utopia-maintainers] Bug#973701: network-manager: systemctl restart ModemManager.service wipes /etc/resolve.conf (almost) clean

[Cristian Ionescu-Idbohrn]

On Tue, 3 Nov 2020, Michael Biebl wrote:
> 
> This bug report doesn't contain any relevant information to be useful

Bisides the expected comment, what "relevant information" would I need 
to provide to make this bug report useful?  I'd be more than happy to 
provide it.


-- 
Cristian

Bug#971788: marked as done (libnvidia-rtcore: Broken dependnecies: dependant libgcc-s1 version is unavailable)

[Andreas Beckmann]

On 11/3/20 9:24 PM, Atamert Ölçgen wrote:
> As of now I still can't upgrade to 450.80.*.
> https://packages.debian.org/buster-backports/libnvidia-rtcore also
> lists 450.66-1~bpo10+1 with the missing dependency. Am I missing something?

Please wait some hours until the package has been built and distributed
to the mirrors ;-)

Andreas

Bug#973481: Packaging is done

[Geert Stappers]

Hi,

Ed told me that the packaging is done.

So the next is that I will be reviewing that.



Regards
Geert Stappers
New to rust in debian
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#973417: AWS // Fixed by updating instance type

[TechAN]

Hi,

I add the same issue on AWS Xen powered instances. (t2, m4, c4, r4, ...). 
Updating instances to newer family powered by Nitro (t3, m5, c5, r5, ...) fixed 
the issue. 

Envoyé de mon iPhone

Bug#973722: mirror submission for mirror.serverion.com

[Serverion]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.serverion.com
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Serverion 
Country: NL Netherlands
Location: The Hague
Sponsor: Serverion https://www.serverion.com




Trace Url: http://mirror.serverion.com/debian/project/trace/
Trace Url: 
http://mirror.serverion.com/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.serverion.com/debian/project/trace/mirror.serverion.com

Bug#973721: libssreflect-coq: Depends: coq-8.12.0+4.08.1 but it is not installable

[Sebastian Ramacher]

Package: libssreflect-coq
Version: 1.11.0-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

$ apt install libssreflect-coq
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libssreflect-coq : Depends: coq-8.12.0+4.08.1 but it is not installable
E: Unable to correct problems, you have held broken packages.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#973571: ovmf: does not work with qemu-system-i386 5.1

[dann frazier]

On Tue, Nov 3, 2020 at 12:45 PM Christian Kastner  wrote:
>
> Control: severity -1 wishlist
>
> On 11/2/20 8:44 PM, Ryutaroh Matsumoto wrote:
> > Control: reassign -1 src:edk2> Control: forcemerge -1 842683
> >
> > I am hoping the above control commands merge 973571 and 842683
> > (I don't know how to merge multiple BTS bugs...).
>
> They did merge, but the bug number should have been the other way
> around, I think :-)
>
> The severity is taken from the first bug, which was "important", but as
> the package behaves as designed (it's expressly for 64-bit), I'm afraid
> that "wishlist" remains to be applicable.
>
> However, with the positive results of your experiments, perhaps the
> maintainers are more willing to give the i386 version a try?

Sure - I'll plan to give it a try before the next upload.

  -dann

Bug#973718: blueman: CVE-2020-15238

[Christopher Schramm]

Hi Salvatore,

2.1.4-1 is waiting at https://mentors.debian.net/package/blueman/. I can 
add the CVE number and / or this bug to the changelog if you like.


Unfortunately my sponsor Nobuhiro seems to be unavailable.

Regards

Bug#973720: FTBFS: TestClientRetryWaitCallbackSwitchToDefault fails on 32-bit systems

[Alois Micard]

Source: golang-github-go-resty-resty
Version: 2.3.0-2
Severity: serious
Tags: ftbfs upstream
Justification: fails to build from source
X-Debbugs-Cc: al...@micard.lu

The test TestClientRetryWaitCallbackSwitchToDefault pass on 64-bit systems, but 
fail on 32-bit systems, such as i386, armhf.

Error log:

```
=== RUN   TestClientRetryWaitCallbackSwitchToDefault
resty_test.go:41: Method: GET
resty_test.go:42: Path: /set-retrywaittime-test
resty_test.go:41: Method: GET
resty_test.go:42: Path: /set-retrywaittime-test
resty_test.go:41: Method: GET
resty_test.go:42: Path: /set-retrywaittime-test
resty_test.go:41: Method: GET
resty_test.go:42: Path: /set-retrywaittime-test
resty_test.go:41: Method: GET
resty_test.go:42: Path: /set-retrywaittime-test
resty_test.go:41: Method: GET
resty_test.go:42: Path: /set-retrywaittime-test
retry_test.go:477: Client has slept 1.329608 seconds before retry 3
--- FAIL: TestClientRetryWaitCallbackSwitchToDefault (9.74s)
```

See:
- 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/golang-github-go-resty-resty.html
- 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/golang-github-go-resty-resty.html


--
Aloïs Micard (creekorful) 

GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2

Bug#973527: swi-prolog: regression on 32-bits architectures

[Sebastian Andrzej Siewior]

control: tags -1 = patch

On 2020-11-01 15:59:19 [+0500], Lev Lamberov wrote:
> Hi,
Hi,

> there is a regression on 32-bits architectures [regression]. It should
> be fixed upstream (in b218a30b5e4bb92ddd399238666448a102117bad), but the
> fix is not tested yet. And currently I'm running low on time, so it
> would be nice if someone could at least test the fix, prepare fixed
> package for upload, or even upload NMU (in this case, please, also push
> your changes to the Salsa repository).

I applied the patch, built i386 and can confirm that the patch you
mentioned did solve the problem by running debian/tests/runtests.
I'm attaching the NMU.
Feel free to either grab the needed pieces or telling to NMU it.

> Cheers!
> Lev
> 
Sebastian
diff -Nru swi-prolog-8.2.2+dfsg/debian/changelog swi-prolog-8.2.2+dfsg/debian/changelog
--- swi-prolog-8.2.2+dfsg/debian/changelog	2020-10-29 08:28:15.0 +0100
+++ swi-prolog-8.2.2+dfsg/debian/changelog	2020-11-03 21:49:43.0 +0100
@@ -1,3 +1,11 @@
+swi-prolog (8.2.2+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply a patch from upstream to address a regression on 32bit architectures
+   (Closes: #973527).
+
+ -- Sebastian Andrzej Siewior   Tue, 03 Nov 2020 21:49:43 +0100
+
 swi-prolog (8.2.2+dfsg-1) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru swi-prolog-8.2.2+dfsg/debian/patches/b218a30b5e4bb92ddd399238666448a102117bad.patch swi-prolog-8.2.2+dfsg/debian/patches/b218a30b5e4bb92ddd399238666448a102117bad.patch
--- swi-prolog-8.2.2+dfsg/debian/patches/b218a30b5e4bb92ddd399238666448a102117bad.patch	1970-01-01 01:00:00.0 +0100
+++ swi-prolog-8.2.2+dfsg/debian/patches/b218a30b5e4bb92ddd399238666448a102117bad.patch	2020-11-03 21:37:52.0 +0100
@@ -0,0 +1,34 @@
+From b218a30b5e4bb92ddd399238666448a102117bad Mon Sep 17 00:00:00 2001
+From: Jan Wielemaker 
+Date: Sat, 31 Oct 2020 16:51:28 +0100
+Subject: [PATCH] FIXED: Possible assertion failure in WFS handling for tabling
+ on 32-bit hardware.  Lev Lamberov.
+
+---
+ src/pl-tabling.c | 12 +++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+diff --git a/src/pl-tabling.c b/src/pl-tabling.c
+index ddfc589f04..7d7381acc3 100644
+--- a/src/pl-tabling.c
 b/src/pl-tabling.c
+@@ -1140,8 +1140,18 @@ update_delay_list(worklist *wl, trie_node *answer,
+ 	  }
+ 	  deRef2(>arguments[1], p);
+ 	  if ( isInteger(*p) )
+-	  { assert(isTaggedInt(*p));
++	  {
++#if SIZEOF_VOIDP == 8
++		assert(isTaggedInt(*p));
+ 		an = intToPointer(valInt(*p));
++#else
++		if ( isTaggedInt(*p) )
++		{ an = intToPointer(valInt(*p));
++		} else
++		{ assert(isBignum(*p));
++		  an = intToPointer(valBignum(*p));
++		}
++#endif
+ 		assert(is_ground_trie_node(an));
+ 	  } else
+ 	  { int rc;
diff -Nru swi-prolog-8.2.2+dfsg/debian/patches/series swi-prolog-8.2.2+dfsg/debian/patches/series
--- swi-prolog-8.2.2+dfsg/debian/patches/series	2020-10-29 08:28:15.0 +0100
+++ swi-prolog-8.2.2+dfsg/debian/patches/series	2020-11-03 21:38:00.0 +0100
@@ -1,3 +1,4 @@
 use-local-jquery.diff
 no_extra_documentation.diff
 disable_http_proxy_test.diff
+b218a30b5e4bb92ddd399238666448a102117bad.patch

Bug#973719: tar --exclude parameter not excluding

[Michael P]

Package: tar
Version: 1.30+dfsg-6 & 1.29b-1.1

Use tar for backups. Upgraded a machine from Jesse up to Buster and the
excludes which worked on Jessie are not being processed under Buster.  I
downgraded to Stretch's tar (1.29b-1.1) and the issue persisted.  Excludes
worked again when I downgraded tar to 1.27.1-2+deb8u2.

Sample of the excludes I'm using:
--exclude=*.{dd.gz,dd}
--exclude=*.{E0?,E1?,E2?,E3?,E4?}
--exclude=*.{vdi,tar,tar.gz,tgz,iso}

Bug#973718: blueman: CVE-2020-15238

[Salvatore Bonaccorso]

Source: blueman
Version: 2.1.3-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2.0.8-1
Control: fixed -1 2.0.8-1+deb10u1

Hi,

The following vulnerability was published for blueman.

CVE-2020-15238[0]:
| Blueman is a GTK+ Bluetooth Manager. In Blueman before 2.1.4, the
| DhcpClient method of the D-Bus interface to blueman-mechanism is prone
| to an argument injection vulnerability. The impact highly depends on
| the system configuration. If Polkit-1 is disabled and for versions
| lower than 2.0.6, any local user can possibly exploit this. If
| Polkit-1 is enabled for version 2.0.6 and later, a possible attacker
| needs to be allowed to use the `org.blueman.dhcp.client` action. That
| is limited to users in the wheel group in the shipped rules file that
| do have the privileges anyway. On systems with ISC DHCP client
| (dhclient), attackers can pass arguments to `ip link` with the
| interface name that can e.g. be used to bring down an interface or add
| an arbitrary XDP/BPF program. On systems with dhcpcd and without ISC
| DHCP client, attackers can even run arbitrary scripts by passing
| `-c/path/to/script` as an interface name. Patches are included in
| 2.1.4 and master that change the DhcpClient D-Bus method(s) to accept
| BlueZ network object paths instead of network interface names. A
| backport to 2.0(.8) is also available. As a workaround, make sure that
| Polkit-1-support is enabled and limit privileges for the
| `org.blueman.dhcp.client` action to users that are able to run
| arbitrary commands as root anyway in
| /usr/share/polkit-1/rules.d/blueman.rules.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-15238
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15238
[1] 
https://github.com/blueman-project/blueman/security/advisories/GHSA-jpc9-mgw6-2xwx
[2] https://bugs.launchpad.net/ubuntu/+source/blueman/+bug/1897287
[3] 
https://github.com/blueman-project/blueman/commit/02161d60e8e311b08fb18254615259085fcd668

Regards,
Salvatore

Bug#973717: shotwell: Jpeg file commentary are stored as "binary comment"

[Florian Gruel]

Package: shotwell
Version: 0.30.10-1+b1
Severity: normal

Dear Maintainer,

After importing files from a Canon D 350 adding commentary to files set the 
value to "binary comment".

Setting commentary seams OK with files from android smartphone ...

On another computer with stable version, this doesn't happen



-- Package-specific info:

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

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

Versions of packages shotwell depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-1
ii  dbus-x11 [dbus-session-bus]   1.12.20-1
ii  dconf-cli 0.38.0-1
ii  libc6 2.31-4
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libexif12 0.6.22-2
ii  libgcr-base-3-1   3.38.0-1
ii  libgcr-ui-3-1 3.38.0-1
ii  libgdata220.17.13-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-5
ii  libgee-0.8-2  0.20.3-1
ii  libgexiv2-2   0.12.1-1
ii  libglib2.0-0  2.66.2-1
ii  libgphoto2-6  2.5.26-2
ii  libgphoto2-port12 2.5.26-2
ii  libgstreamer-plugins-base1.0-01.18.1-1
ii  libgstreamer1.0-0 1.18.1-1
ii  libgtk-3-03.24.23-2
ii  libgudev-1.0-0234-1
ii  libjson-glib-1.0-01.6.0-1
ii  libpango-1.0-01.46.2-1
ii  libpangocairo-1.0-0   1.46.2-1
ii  libraw20  0.20.2-1
ii  librsvg2-common   2.50.1+dfsg-1
ii  libsoup2.4-1  2.72.0-2
ii  libsqlite3-0  3.33.0-1
ii  libwebkit2gtk-4.0-37  2.30.2-1
ii  libxml2   2.9.10+dfsg-6.2
ii  shotwell-common   0.30.10-1

shotwell recommends no packages.

shotwell suggests no packages.

-- no debconf information

Bug#972802: [Pkg-rust-maintainers] Bug#972802: rust-webpki-roots: duplicates ca-certificates, remove from Debian?

[kpcyrd]

On Sat, Oct 24, 2020 at 11:50:14AM +0800, Paul Wise wrote:
> > This is a very non-trivial downstream patch though, the project I'm
> > trying to package runs in a sandbox and loading certificates from disk
> > at runtime is not possible without redesigning some things.
> 
> One option to solve this would be to have src:rust-webpki-roots provide
> webpki-roots-build containing build.py and then have ca-certificates
> build-dep on webpki-roots, run build.py and build a binary package
> containing the generated rust code. That seems a bit ick though.
> 
> Is there any chance of webpki/rustls upstream switching from embedding
> to runtime loading of certs like other TLS stacks do?

It's more complicated than that, there's rustls-native-certs to use the
local certificate store, but the patch would be so invasive that debian
would effectively maintain a fork. At the time of writing webpki-roots
has 85 reverse dependencies on crates.io, while rustls-native-certs has
13.

rustls-native-certs compares itself to webpki-roots in the readme, I
think this bit is interesting:

> Cons:
> [...]
> - The quality of the ca-certificates package on debian-based Linux
> distributions is poor. At the time of writing, this ships many
> certificates not included in the Mozilla set, either because they
> failed an audit and were withdrawn[1] or were removed for
> mississuance[2].

[1]: https://bugs.mozilla.org/show_bug.cgi?id=1448506
[2]: https://bugs.mozilla.org/show_bug.cgi?id=1552374

Bug#973716: src:python-livereload: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: python-livereload
Version: 2.6.1-3
Severity: serious
Control: close -1 2.6.3-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 970495

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:python-livereload in its current version in unstable has been trying
to migrate for 60 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=python-livereload




signature.asc
Description: OpenPGP digital signature

Bug#921178: Re: Bug#940914: uno-libs3: Segfault on launch in cppu::_copyConstructAnyFromData

[Witold Baryluk]

Ok. Good to know.

I will try to construct more exact instructions with stable reproduction method.

Thanks Rene, for testing.

On Tue, 3 Nov 2020 at 05:52, Rene Engelhard  wrote:
>
> Hi,
>
> Am 03.11.20 um 06:35 schrieb Rene Engelhard:
> >> As for reproduction, I believe the easiest is to grab the Debian live
> >> CD image and run it in qemu -kvm, and it will reproduce. It does for
> >> me. If you can't, please let me know.
> > Ah, Live?
> >
> > Does it only happen in Live and not in "real" systems?
> >
> > Will try
>
> Just works fine on debian-live-10.6.0-amd64-gnome.iso
>
>
> Regards,
>
>
> Rene
>

Bug#971595: mupdf: diff for NMU version 1.17.0+ds1-1.1

[Salvatore Bonaccorso]

Control: tags 971595 + patch
Control: tags 971595 + pending


Dear maintainer,

I've prepared an NMU for mupdf (versioned as 1.17.0+ds1-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I should
delay it longer.

Regards,
Salvatore
diff -Nru mupdf-1.17.0+ds1/debian/changelog mupdf-1.17.0+ds1/debian/changelog
--- mupdf-1.17.0+ds1/debian/changelog	2020-08-06 14:48:09.0 +0200
+++ mupdf-1.17.0+ds1/debian/changelog	2020-11-03 21:09:06.0 +0100
@@ -1,3 +1,11 @@
+mupdf (1.17.0+ds1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Detect/avoid overflow when calculating sizes of pixmaps (CVE-2020-26519)
+(Closes: #971595)
+
+ -- Salvatore Bonaccorso   Tue, 03 Nov 2020 21:09:06 +0100
+
 mupdf (1.17.0+ds1-1) unstable; urgency=medium
 
   [ Bastian Germann ]
diff -Nru mupdf-1.17.0+ds1/debian/patches/0011-Bug-702857-Detect-avoid-overflow-when-calculating-si.patch mupdf-1.17.0+ds1/debian/patches/0011-Bug-702857-Detect-avoid-overflow-when-calculating-si.patch
--- mupdf-1.17.0+ds1/debian/patches/0011-Bug-702857-Detect-avoid-overflow-when-calculating-si.patch	1970-01-01 01:00:00.0 +0100
+++ mupdf-1.17.0+ds1/debian/patches/0011-Bug-702857-Detect-avoid-overflow-when-calculating-si.patch	2020-11-03 21:09:06.0 +0100
@@ -0,0 +1,50 @@
+From: Robin Watts 
+Date: Fri, 25 Sep 2020 13:19:48 +0100
+Subject: Bug 702857: Detect/avoid overflow when calculating sizes of pixmaps.
+Origin: https://git.ghostscript.com/?p=mupdf.git;a=commit;h=af1e390a2c7abceb32676ec684cd1dbb92907ce8
+Bug: https://bugs.ghostscript.com/show_bug.cgi?id=702937
+Bug-Debian: https://bugs.debian.org/971595
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2020-26519
+
+Throw an error when trying to allocate an overly large pixmap.
+---
+ source/fitz/pixmap.c | 12 
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+diff --git a/source/fitz/pixmap.c b/source/fitz/pixmap.c
+index f847a747323e..66873d214628 100644
+--- a/source/fitz/pixmap.c
 b/source/fitz/pixmap.c
+@@ -76,12 +76,12 @@ fz_new_pixmap_with_data(fz_context *ctx, fz_colorspace *colorspace, int w, int h
+ 	}
+ 
+ 	pix->samples = samples;
+-	if (!samples)
++	if (!samples && pix->h > 0 && pix->w > 0)
+ 	{
+ 		fz_try(ctx)
+ 		{
+-			if (pix->stride - 1 > INT_MAX / pix->n)
+-fz_throw(ctx, FZ_ERROR_GENERIC, "overly wide image");
++			if (pix->stride > INT_MAX / pix->h)
++fz_throw(ctx, FZ_ERROR_GENERIC, "Overly large image");
+ 			pix->samples = Memento_label(fz_malloc(ctx, pix->h * pix->stride), "pixmap_data");
+ 		}
+ 		fz_catch(ctx)
+@@ -102,8 +102,12 @@ fz_new_pixmap(fz_context *ctx, fz_colorspace *colorspace, int w, int h, fz_separ
+ {
+ 	int stride;
+ 	int s = fz_count_active_separations(ctx, seps);
++	int n;
+ 	if (!colorspace && s == 0) alpha = 1;
+-	stride = (fz_colorspace_n(ctx, colorspace) + s + alpha) * w;
++	n = fz_colorspace_n(ctx, colorspace) + s + alpha;
++	if (w > INT_MAX / n)
++		fz_throw(ctx, FZ_ERROR_GENERIC, "Overly wide image");
++	stride = n * w;
+ 	return fz_new_pixmap_with_data(ctx, colorspace, w, h, seps, alpha, stride, NULL);
+ }
+ 
+-- 
+2.29.1
+
diff -Nru mupdf-1.17.0+ds1/debian/patches/series mupdf-1.17.0+ds1/debian/patches/series
--- mupdf-1.17.0+ds1/debian/patches/series	2020-08-06 01:22:24.0 +0200
+++ mupdf-1.17.0+ds1/debian/patches/series	2020-11-03 21:09:06.0 +0100
@@ -7,3 +7,4 @@
 0007-mupdf-x11-does-not-need-to-link-to-libcrypto.patch
 0008-Build-mupdf-without-executable-stack.patch
 0010-Prevent-thirdparty-archive-build.patch
+0011-Bug-702857-Detect-avoid-overflow-when-calculating-si.patch

Bug#971788: marked as done (libnvidia-rtcore: Broken dependnecies: dependant libgcc-s1 version is unavailable)

[Atamert Ölçgen]

Hi Andreas,
Thanks a lot for looking into this.

As of now I still can't upgrade to 450.80.*.
https://packages.debian.org/buster-backports/libnvidia-rtcore also
lists 450.66-1~bpo10+1 with the missing dependency. Am I missing something?

On Tue, Nov 3, 2020 at 11:51 AM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Tue, 3 Nov 2020 09:46:59 +0100
> with message-id 
> and subject line Re: Bug#971788: libnvidia-rtcore: Broken dependnecies:
> dependant libgcc-s1 version is unavailable
> has caused the Debian Bug report #971788,
> regarding libnvidia-rtcore: Broken dependnecies: dependant libgcc-s1
> version is unavailable
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 971788: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971788
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Aidan Gauland 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Wed, 7 Oct 2020 22:00:34 +1300
> Subject: libnvidia-rtcore: Broken dependnecies: dependant libgcc-s1
> version is unavailable
> Package: libnvidia-rtcore
> Version: 450.66-1~bpo10+1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> The current buster-backports version of libnvidia-rtcore depends upon
> libgcc-s1 >= 4.2 which is unavailable in buster or buster-backports,
> making this package impossible to install.
>
> It looks like either gcc-10 needs to be backported to buster, or
> libnvidia-rtcore needs to be ported to a version of gcc available in
> buster.
>
> Regards,
> Aidan Gauland
>
>
>
> -- System Information:
> Debian Release: 10.6
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.7.0-0.bpo.2-amd64 (SMP w/32 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_NZ.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 libnvidia-rtcore depends on:
> ii  libc6  2.28-10
> pn  libgcc-s1  
> ii  libgcc11:8.3.0-6
>
> libnvidia-rtcore recommends no packages.
>
> libnvidia-rtcore suggests no packages.
>
>
>
> -- Forwarded message --
> From: Andreas Beckmann 
> To: Aidan Gauland , 971788-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Tue, 3 Nov 2020 09:46:59 +0100
> Subject: Re: Bug#971788: libnvidia-rtcore: Broken dependnecies: dependant
> libgcc-s1 version is unavailable
> On 10/7/20 11:00 AM, Aidan Gauland wrote:
> > The current buster-backports version of libnvidia-rtcore depends upon
> > libgcc-s1 >= 4.2 which is unavailable in buster or buster-backports,
> > making this package impossible to install.
>
> The package was built in sid instead of buster by accident and picked up
> that wrong dependency.
> This is fixed with new version just uploaded to buster-backports.
>
> Andreas



-- 
Kind Regards,
Atamert Ölçgen

◻◼◻
◻◻◼
◼◼◼

www.muhuk.com

Bug#973549: wine-development: 000d:err:menubuilder:init_xdg error looking up the desktop directory

[Patrice Duroux]

Ok, I found a very easy way to reproduce this «bug» error message.
Run a first (without ~/.wine) wine having in .config/user-dirs.dirs something
like:
XDG_DESKTOP_DIR="$HOME/Desktop"
Then delete (rm -rf) this $HOME/Desktop and update .config/user-dirs.dirs to :
XDG_DESKTOP_DIR="$HOME/"
and then run wine again.
Conclusion: wine is keeping the first value in ~/.wine and does not update it on
the next run for probably some (good?) reason.

Bug#973702: licensecheck should read "license" field from package.json files

[Jonas Smedegaard]

Quoting Xavier (2020-11-03 20:28:02)
> 
> 
> Le 3 novembre 2020 19:50:52 GMT+01:00, Jonas Smedegaard  a 
> écrit :
> >Quoting Xavier (2020-11-03 18:35:48)
> >> Le 03/11/2020 à 18:30, Jonas Smedegaard a écrit :
> >> > Quoting Jonas Smedegaard (2020-11-03 17:19:10)
> >> >> Quoting Xavier Guimard (2020-11-03 17:07:02)
> >> >>> when launching licensecheck in a nodejs module, I'd like to see 
> >> >>> licensecheck reveals which license is used in package.json
> >> >>
> >> >> Licensecheck currently operates on files.
> >> >>
> >> >> package.json contains a field to state license for a _project_ 
> >> >> which is something different.
> >> >>
> >> >> How would you expect licensecheck would handle that?

> For me, we can just say that this file is covered by license. This is 
> the same case as "License" file (whole project), isn't it?

Ah ok, so this issue is not that licensecheck should understand 
project-wide licensing, but simply that licensecheck should recognize 
JSON format of nodejs "package.json" and to list _that_ file as having 
the license.

Makes sense.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#968335: kernel crash: WARNING: CPU: 0 PID: 0 at lib/percpu-refcount.c:155 percpu_ref_switch_to_atomic_rcu+0xf8/0x120

[tobias]

i upgraded myself today to 4.19.0-12 (or 4.19.152-1 according to 
upstream version numbers)

no issue yet.

this blog contains some interesting info: http://blog.pi3.com.pl/?p=720
both CVE's mentioned are fixed now in debian
https://security-tracker.debian.org/tracker/CVE-2020-25220
https://security-tracker.debian.org/tracker/CVE-2020-14356

so i think it looks good.

Tobias.

Bug#973701: [Pkg-utopia-maintainers] Bug#973701: network-manager: 'systemctl restart ModemManager.service' wipes /etc/resolve.conf (almost) clean

[Michael Biebl]

Control: tags -1 + moreinfo

Am 03.11.20 um 16:45 schrieb Cristian Ionescu-Idbohrn:

Package: network-manager
Version: 1.27.91-1
Severity: grave

/etc/resolve.conf includes the expected configuration (WRT
nameservers) on bootup.

After upgrading network-manager and restarting it, /etc/resolve.conf
(which is a symlink to /run/NetworkManager/resolv.conf) is basically
wiped out.  Includes only this:

# Generated by NetworkManager

Rebooting brings things to normal.  Still, this isn't wintendo.  I'd
expect better.

There are some workarounds (suggested in some other bug reports) that
bring the system back to an usable state, but far away from perfect
(dhclient wlan0).  Duplicated home router nameserver addresses in
/etc/resolv.conf:

nameserver 192.168.0.1
nameserver 192.168.0.1

which is not what my configuration is.


This bug report doesn't contain any relevant information to be useful

Bug#973682: libreoffice-common: bash-completion for .pdf files

[Rene Engelhard]

tag 973682 + pending

thanks


Hi,

Am 03.11.20 um 09:34 schrieb Félix Sipma:
> As libreoffice-pdfimport functionality has been merged in the main 
> packages, it would be nice if pdf filenames could be completed with 
> bash-completion.
>
> "$ libreoffice " would list .pdf files in addition to .doc, .docx, 
> .odt, .txt, .jpg, etc.

... for libreoffice and lodraw, yes.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=8ef56c7cb4008c6290da82b305ec2deefc8d94d5


Will be in 7.1. (Maybe I#öö backport it for the 7.0.x Debian packages.)


Regards,


Rene

Bug#973571: ovmf: does not work with qemu-system-i386 5.1

[Christian Kastner]

Control: severity -1 wishlist

On 11/2/20 8:44 PM, Ryutaroh Matsumoto wrote:
> Control: reassign -1 src:edk2> Control: forcemerge -1 842683
>
> I am hoping the above control commands merge 973571 and 842683
> (I don't know how to merge multiple BTS bugs...).

They did merge, but the bug number should have been the other way
around, I think :-)

The severity is taken from the first bug, which was "important", but as
the package behaves as designed (it's expressly for 64-bit), I'm afraid
that "wishlist" remains to be applicable.

However, with the positive results of your experiments, perhaps the
maintainers are more willing to give the i386 version a try?

Bug#973645: transition: log4cplus

[Tobias Frost]

Am 3. November 2020 10:35:16 MEZ schrieb Sebastian Ramacher 
:
>Control: forwarded -1
>https://release.debian.org/transitions/html/auto-log4cplus.html
>Control: tags -1 + confirmed
>
>please go ahead with the upload to unstable.
>
>Cheers

Thanks Sebastian!

uploaded and all buildds are happy already.

Bug#973702: licensecheck should read "license" field from package.json files

[Xavier]

Le 3 novembre 2020 19:50:52 GMT+01:00, Jonas Smedegaard  a 
écrit :
>Quoting Xavier (2020-11-03 18:35:48)
>> Le 03/11/2020 à 18:30, Jonas Smedegaard a écrit :
>> > Quoting Jonas Smedegaard (2020-11-03 17:19:10)
>> >> Quoting Xavier Guimard (2020-11-03 17:07:02)
>> >>> when launching licensecheck in a nodejs module, I'd like to see 
>> >>> licensecheck reveals which license is used in package.json
>> >>
>> >> Licensecheck currently operates on files.
>> >>
>> >> package.json contains a field to state license for a _project_ which 
>> >> is something different.
>> >>
>> >> How would you expect licensecheck would handle that?
>> > 
>> > Maybe the above came across as needlessly agressive.
>> > 
>> > Thanks for reporting this.  Reporting it is appreciated on its own - 
>> > you need not "defend" this issue.
>> > 
>> > I agree that it would be nice if licensecheck could recognize 
>> > copyright and licensing information in all the many forms they are 
>> > hinted - including project-wide hints.
>> > 
>> > What I meant to ask is if you have some ideas how licensecheck could 
>> > sensibly report such non-file-specific hints?
>> 
>> Hi,
>> 
>> thanks for taking care of this and licensecheck! I never take a look 
>> at how licensecheck works, so no idea for now, but I'll try to 
>> understand licensecheck, then search how we could do this
>
>I don't mean how to codify.
>
>I just mean what could the output from licensecheck look like.
>
>
> - Jonas

For me, we can just say that this file is covered by license. This is the same 
case as "License" file (whole project), isn't it?

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Bug#972514: Newest update breaks CUDA

[Andreas Beckmann]

Please file a new bug s.t. we can continue discussion there.

On 11/3/20 2:01 PM, Joel Ray Holveck wrote:
> Thanks for the new version!  But it seems to introduce a regression.
> 
> After installing it on my bullseye box, I couldn't run CUDA programs

Andreas

PS: please also try the 455.38 driver from experimental

Bug#957439: libforms: ftbfs with GCC-10

[Peter S Galbraith]

Thanks for your upload. Real life took over again. :-(

Want to take over the package? :-)

Peter

> On Tue, 2020-08-25 at 17:30 -0400, Peter S Galbraith wrote:
> 
> > I am on vacation so *should* have time to look into this soonish.
> 
> Did you get a chance to look at the libforms FTBFS with GCC-10?
> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise

Bug#973549: wine-development: 000d:err:menubuilder:init_xdg error looking up the desktop directory

[Patrice Duroux]

Hi,

Working on this today, I removed  ~/.wine and start again to run wine on same
.exe and did not get any more those messages and got the right .desktop file in
place.

But now there are some other messages:

wine: created the configuration directory '/home/patrice/.wine'
0012:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub,
hres=0x80004002
0012:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-
11ce-8034-00aa006009fa}, 80004002
0012:err:ole:get_local_server_stream Failed: 80004002
0014:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub,
hres=0x80004002
0014:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-
11ce-8034-00aa006009fa}, 80004002
0014:err:ole:get_local_server_stream Failed: 80004002
Could not find Wine Gecko. HTML rendering will be disabled.
Could not find Wine Gecko. HTML rendering will be disabled.
wine: configuration in L"/home/patrice/.wine" has been updated.
get_CurrentProfileTypes failed: 0x80004001
get_CurrentProfileTypes failed: 0x80004001


Probably some package updates changed the situation.

So sorry for the noise, I will close this issue.

Thanks,
Patrice

Bug#973680: virtinst does not recognize UEFI ROM for armhf

[Ryutaroh Matsumoto]

Control: tags -1 + fixed-upstream

Fixed in upstream as
https://github.com/virt-manager/virt-manager/issues/174

Ryutaroh

Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-friendly

[Boyuan Yang]

Package: fwupd-amd64-signed
Severity: grave
Version: 1.4.6+2
X-Debbugs-CC: 93...@debian.org mario.limoncie...@dell.com

Dear EFI Team,

Package fwupd-amd64-signed currently cannot be installed on Debian
Unstable/Sid. It depends on fwupd (= 1.4.6-2) while Sid only has fwupd
(= 1.4.6-2+b1).

It seems obvious that such dependency relationship made fwupd/fwupd-
amd64-signed not binNMU-friendly. Please consider setting a version
range to allow binNMU-ed package to satisfy the dependency
relationship.

Thanks,
Boyuan Yang


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

Bug#919532: Problems with hfsprogs on G5 Power Macs (ppc64)

[Frank Scheiner]

Hi Adrian,

On 01.11.20 20:07, John Paul Adrian Glaubitz wrote:

I just uploaded a new upstream release, version 540.1.


Great!


Please check whether this version fixes the problem for you.


I will do. I just don't know, how to break my HFS partition, so
`fsck.hfs` has something to fix. But maybe these segfaults also happened
when trying to check clean FSes.

UPDATE: Indeed, [1] says so. :-)

Cheers,
Frank

[1]: https://lists.debian.org/debian-powerpc/2018/12/msg00053.html

Bug#973702: licensecheck should read "license" field from package.json files

[Jonas Smedegaard]

Quoting Xavier (2020-11-03 18:35:48)
> Le 03/11/2020 à 18:30, Jonas Smedegaard a écrit :
> > Quoting Jonas Smedegaard (2020-11-03 17:19:10)
> >> Quoting Xavier Guimard (2020-11-03 17:07:02)
> >>> when launching licensecheck in a nodejs module, I'd like to see 
> >>> licensecheck reveals which license is used in package.json
> >>
> >> Licensecheck currently operates on files.
> >>
> >> package.json contains a field to state license for a _project_ which 
> >> is something different.
> >>
> >> How would you expect licensecheck would handle that?
> > 
> > Maybe the above came across as needlessly agressive.
> > 
> > Thanks for reporting this.  Reporting it is appreciated on its own - 
> > you need not "defend" this issue.
> > 
> > I agree that it would be nice if licensecheck could recognize 
> > copyright and licensing information in all the many forms they are 
> > hinted - including project-wide hints.
> > 
> > What I meant to ask is if you have some ideas how licensecheck could 
> > sensibly report such non-file-specific hints?
> 
> Hi,
> 
> thanks for taking care of this and licensecheck! I never take a look 
> at how licensecheck works, so no idea for now, but I'll try to 
> understand licensecheck, then search how we could do this

I don't mean how to codify.

I just mean what could the output from licensecheck look like.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#973543: nvidia-cuda-toolkit: CVE-2020-5991

[Andreas Beckmann]

Control: found -1 10.0.130-1

On 11/1/20 3:51 PM, Salvatore Bonaccorso wrote:
> The following vulnerability was published for nvidia-cuda-toolkit.
> 
> I have no further details apart what is in [1], which seem to indicate
> Operating System Windows only. Do you find more information on that?

That's also all I could find so far. But I can't really imagine that the
NVJPEG library has windows specific code ... (unlike some driver
components). So working towards 11.1...


Andreas

Bug#936241: broctl: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Mon, Oct 14, 2019 at 07:23:54PM -0400, Scott Kitterman wrote:
> It looks like broctl is replaced by zeekctl upstream:
> 
> https://github.com/zeek/zeekctl
> 
> It does support python3, so it'd be great to see this updated to the newer 
> version.

zeekctl is in experimental for a few months, can broctl be removed now?

Cheers,
Moritz

Bug#117318: Andreas Hillebrand

[Katya Honey]

Ich bin sicher, dass Sie und ich die gleichen Interessen haben werden!!! Ich 
habe dich bemerkt sofort und entschieden, Ihnen zu schreiben!!! Ich frage dich, 
sagen Sie mir deinen Namen und welchem Ort wohnst du??


Was ist Ihr Alter?? Ich würde gerne glauben, dass Sie meine Photo attraktiv 
fanden!!! Ich denke, dass es ein gegenseitiges Mitgefühl zwischen Ihnen und mir 
auftreten wird!!!


Alle Menschen aller Altersgruppen träumen davon einen Partner, mit der Sie 
chatten und verschiedene Themen besprechen können!!! Im Welt ist nicht genug 
Glück und Freimütigkeit!!! Absolut jeder will jemanden finden, die kümmert und 
schätzt!!!


Was denken du darüber?? Ich werde dir um mein Ziel sagen!!! Ich bin auf der 
Suche nach einen guten Mann oder nur einen ansprechend Gesprächspartner!!! Wenn 
Sie an einer guten Dialog wünschen, antworten Sie mir und sagen Sie mir mehr 
über Ihren Charakter!!!


Ich hoffe, dass ich mich nicht von Ihnen enttäuscht sein werde und du ein 
anständiger Mensch bist!!! Nenn mich Kateryna!!! Ich werde auf deinen Brief 
freuen!!!


Lassen Sie sich nicht entmutigen, wenn werde ich Ihnen nicht sofort 
beantworten, weil ich in dieser Zeit beschäftigt bin!!! Aber ich werde Ihnen 
später beantworten!!! Bitte antworten Sie mir!!!






Stack Exchange Network

Stack Exchange network consists of 175 Q communities including Stack 
Overflow, the largest, most trusted online community for developers to learn, 
share their knowledge, and build their careers.

Visit Stack Exchange

Loading

  1.
  2.  0
  3.  +0
  4.
 *   TourStart here for a quick overview

Bug#973714: Depends on argyll which is going away

[Moritz Muehlenhoff]

Package: displaycal
Severity: serious

argyll is filed for removal from the archive (#966416), but displaycal
depends on it.

Cheers,
Moritz

Bug#973713: Suggests argyll which is going away

[Moritz Muehlenhoff]

Package: colorhug-client
Severity: normal

argyll is filed for removal from the archive (#966416), but colorhug-client 
still
Suggests: it.

Cheers,
Moritz

Bug#973712: Depends on argyll which is going away

[Moritz Muehlenhoff]

Package: colord-sensor-argyll
Severity: serious

argyll is filed for removal from the archive (#966416), but colord-sensor-argyll
depends on it.

Cheers,
Moritz

Bug#973710: kdenlive: Kdenlive speed up feature requires building MLT with rubberband for pitch compensation

[hyiltiz]

Package: kdenlive
Version: 20.08.2-1
Severity: normal
X-Debbugs-Cc: hyil...@gmail.com

Kdenlive "Change Speed" of a clip feature requires building MLT with rubberband
libmlt and librubberband are packaged separately for Debian. Steps to reproduce:

1. Open Kdenlive.
2. Import a media file (audio or video) into the Project Bin.
3. Drag the media file into the track/timeline.
4. Right click the track to open the Context menu and click "Change speed"
5. "Pitch compensation" option is unavailable (grayed out), and tool-tip text 
says
"MLT must be compiled with rubberband library to enable pitch correction"

librubberband2 was already installed. Installing rubberband-cli then restarting
kdenlive didn't solve the issue. I downloaded the source of libmlt6 and built
it, with --enable-glp, --enable-gpl3 and --enable-luma (--enable-gpl covered
rubberband). Compiling required installing a few packages such as
librubberband-dev. "make install" as root installed libmlt .so files into
/usr/local/lib/ and after a reboot, Kdenlive simply crashed to open. Renaming
/usr/local/lib/mlt fixed the crash. I moved the manually built libraries into
/usr/lib/x86_.../mlt and pointed the symlinks under /usr/lib/x86_.../ about
libmlt appropriately, but kdenlive still crashed.

Maybe it was assumed that Kdenlive could use the librubberband2 package and thus
libmlt was built without it, but kdenlive actually requires libmlt itself to be
built with rubberband?


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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER
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 kdenlive depends on:
ii  ffmpeg 7:4.3.1-5
ii  gstreamer1.0-plugins-bad   1.18.0-2+b1
ii  kded5  5.74.0-2
ii  kdenlive-data  20.08.2-1
ii  kinit  5.74.0-2
ii  kio5.74.0-2
ii  libc6  2.31-4
ii  libkf5archive5 5.74.0-2
ii  libkf5bookmarks5   5.74.0-2
ii  libkf5completion5  5.74.0-2
ii  libkf5configcore5  5.74.0-2
ii  libkf5configgui5   5.74.0-2
ii  libkf5configwidgets5   5.74.0-2
ii  libkf5coreaddons5  5.74.0-2
ii  libkf5crash5   5.74.0-2
ii  libkf5dbusaddons5  5.74.0-2
ii  libkf5declarative5 5.74.0-2
ii  libkf5filemetadata35.74.0-2
ii  libkf5guiaddons5   5.74.0-3
ii  libkf5i18n55.74.0-3
ii  libkf5iconthemes5  5.74.0-2
ii  libkf5itemviews5   5.74.0-2
ii  libkf5jobwidgets5  5.74.0-2
ii  libkf5kiocore5 5.74.0-2
ii  libkf5kiofilewidgets5  5.74.0-2
ii  libkf5kiowidgets5  5.74.0-2
ii  libkf5newstuff55.74.0-2
ii  libkf5notifications5   5.74.0-2
ii  libkf5notifyconfig55.74.0-2
ii  libkf5purpose-bin  5.74.0-2
ii  libkf5purpose5 5.74.0-2
ii  libkf5service-bin  5.74.0-2
ii  libkf5service5 5.74.0-2
ii  libkf5solid5   5.74.0-2
ii  libkf5widgetsaddons5   5.74.0-3
ii  libkf5xmlgui5  5.74.0-2
ii  libmlt++3  6.22.1-3
ii  libmlt66.22.1-3
ii  libqt5concurrent5  5.14.2+dfsg-6
ii  libqt5core5a   5.14.2+dfsg-6
ii  libqt5dbus55.14.2+dfsg-6
ii  libqt5gui5 5.14.2+dfsg-6
ii  libqt5multimedia5  5.14.2-3
ii  libqt5network5 5.14.2+dfsg-6
ii  libqt5qml5 5.14.2+dfsg-3
ii  libqt5quick5   5.14.2+dfsg-3
ii  libqt5quickcontrols2-5 5.14.2+dfsg-2
ii  libqt5quickwidgets55.14.2+dfsg-3
ii  libqt5svg5 5.14.2-2
ii  libqt5webkit5  5.212.0~alpha4-5
ii  libqt5widgets5 5.14.2+dfsg-6
ii  libqt5xml5 5.14.2+dfsg-6
ii  librttr-core0.9.6  0.9.6+dfsg1-3
ii  libstdc++6 10.2.0-15
ii  melt   6.22.1-3
ii  qml-module-qtgraphicaleffects  5.14.2-2
ii  qml-module-qtqml-models2   5.14.2+dfsg-3
ii  qml-module-qtquick-controls5.14.2-2
ii  qml-module-qtquick-controls2   5.14.2+dfsg-2
ii  qml-module-qtquick-dialogs 5.14.2-2
ii  qml-module-qtquick-layouts 5.14.2+dfsg-3
ii  qml-module-qtquick-window2 5.14.2+dfsg-3
ii  qml-module-qtquick25.14.2+dfsg-3

Versions of packages kdenlive recommends:
ii  breeze-icon-theme  4:5.74.0-2
pn  dvdauthor  
pn  dvgrab 
ii  frei0r-plugins 1.7.0-1
ii  genisoimage9:1.1.11-3.1
ii  

Bug#973709: RM: vnc-java -- NBS; dead upstream, no reverse dependencies, better alternatives exist

[Sven Geuer]

Package: ftp.debian.org
Severity: normal

Dear FTP Masters,

upstream for vnc-java is not available anymore.
No packages depend on vnc-java.
vnc-java's features are covered by tightvnc-java.
The maintainer agrees to remove the package:

On Sunday, 2020-11-01, 09:45 +0100 Ola Lundqvist wrote:
> Hi
>
> Transitional is the safest approach but I can live with removing it.
>
> / Ola

This email snippet can be looked up in the Debian Remote mailing list as part
of the 'Thoughts about vnc-java' thread [1].

Please remove vnc-java from unstable.

Regards,
Sven

[1] https://lists.debian.org/debian-remote/2020/11/msg0.html

Bug#973702: licensecheck should read "license" field from package.json files

[Xavier]

Le 03/11/2020 à 18:30, Jonas Smedegaard a écrit :
> Quoting Jonas Smedegaard (2020-11-03 17:19:10)
>> Quoting Xavier Guimard (2020-11-03 17:07:02)
>>> when launching licensecheck in a nodejs module, I'd like to see 
>>> licensecheck reveals which license is used in package.json
>>
>> Licensecheck currently operates on files.
>>
>> package.json contains a field to state license for a _project_ which 
>> is something different.
>>
>> How would you expect licensecheck would handle that?
> 
> Maybe the above came across as needlessly agressive.
> 
> Thanks for reporting this.  Reporting it is appreciated on its own - you 
> need not "defend" this issue.
> 
> I agree that it would be nice if licensecheck could recognize copyright 
> and licensing information in all the many forms they are hinted - 
> including project-wide hints.
> 
> What I meant to ask is if you have some ideas how licensecheck could 
> sensibly report such non-file-specific hints?

Hi,

thanks for taking care of this and licensecheck! I never take a look at
how licensecheck works, so no idea for now, but I'll try to understand
licensecheck, then search how we could do this

Cheers,
Xavier

Bug#973702: licensecheck should read "license" field from package.json files

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2020-11-03 17:19:10)
> Quoting Xavier Guimard (2020-11-03 17:07:02)
> > when launching licensecheck in a nodejs module, I'd like to see 
> > licensecheck reveals which license is used in package.json
> 
> Licensecheck currently operates on files.
> 
> package.json contains a field to state license for a _project_ which 
> is something different.
> 
> How would you expect licensecheck would handle that?

Maybe the above came across as needlessly agressive.

Thanks for reporting this.  Reporting it is appreciated on its own - you 
need not "defend" this issue.

I agree that it would be nice if licensecheck could recognize copyright 
and licensing information in all the many forms they are hinted - 
including project-wide hints.

What I meant to ask is if you have some ideas how licensecheck could 
sensibly report such non-file-specific hints?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#973708: gcc-10: 10.2.0-15 to 10.2.0-16 regression results in ICE with #line 0

[Dustin Brody]

Package: gcc-10
Version: 10.2.0-16
Severity: normal
X-Debbugs-Cc: anda...@parsoma.net

Dear Maintainer,

Compiling the test program provided triggers an ICE in gcc-10 10.2.0-16,
but not 10.2.0-15. It's a reduction from generated code, from Nim. While
this does suggest that the code generation from Nim's less than perfect,
it's unclear that an ICE is the best way for gcc to respond.

$ cat testcase.c 
void function() { if (0) {
#line 0 "can be anything"
}}
$ gcc --version
gcc (Debian 10.2.0-15) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -c -g3 -Og testcase.c
$ # this is expected outcome
$ # also, this indicates it's a regression from 10.2.0-15 to 10.2.0-16
$ # update to current sid version of gcc-10
$ gcc --version
gcc (Debian 10.2.0-16) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -c -g3 -Og testcase.c
during RTL pass: final
can be anything: In function ‘function’:
can be anything: internal compiler error: in notice_source_line, at final.c:3237
0x6408a3 notice_source_line
../../src/gcc/final.c:3237
0xc667cd final_scan_insn_1
../../src/gcc/final.c:2420
0xc67b4b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../src/gcc/final.c:3152
0xc67c56 final_1
../../src/gcc/final.c:2020
0xc689c6 rest_of_handle_final
../../src/gcc/final.c:4658
0xc689c6 execute
../../src/gcc/final.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Whatever "#line 0" should do, triggering an ICE probably isn't it.

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

Kernel: Linux 5.9.0-1-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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-10 depends on:
ii  binutils   2.35.1-2
ii  cpp-10 10.2.0-16
ii  gcc-10-base10.2.0-16
ii  libc6  2.31-4
ii  libcc1-0   10.2.0-16
ii  libgcc-10-dev  10.2.0-16
ii  libgcc-s1  10.2.0-16
ii  libgmp10   2:6.2.0+dfsg-6
ii  libisl22   0.22.1-1
ii  libmpc31.2.0-1
ii  libmpfr6   4.1.0-3
ii  libstdc++6 10.2.0-16
ii  libzstd1   1.4.5+dfsg-4
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages gcc-10 recommends:
ii  libc6-dev  2.31-4

Versions of packages gcc-10 suggests:
pn  gcc-10-doc   
pn  gcc-10-locales   
pn  gcc-10-multilib  

-- no debconf information

Bug#973707: ITP: kel-agent -- An agent program for translating between amateur radio installed programs and WebSockets

[Chris Keller]

Package: wnpp
Severity: wishlist
Owner: Chris Keller 

* Package name: kel-agent
  Version : 0.0~git20201103.9b8976a-1
  Upstream Author : K0SWE
* URL : https://github.com/k0swe/kel-agent
* License : Apache-2.0
  Programming Lang: Go
  Description : An agent program for translating between amateur
radio installed programs and WebSockets

 kel-agent An agent program for translating between various amateur radio
 installed programs and WebSockets.  This will allow the creation of
 cloud-based amateur radio applications while using integration points
 only available through local processes.
 .
 Architecture
 .
 At first this will support receiving status and log messages from
 WSJT-X. Planned support includes rigctld and Ham Radio Deluxe for
 transceiver remote control.  Running on localhost In the simplest case,
 kel-agent is running on the same computer as your radio programs and
 browser. In this case, you can have kel-agent bind to localhost which
 will only allow programs on the same computer to connect. This is
 straightforward, safe and the default.
 .
 .
 $ kel-agent 2020/10/10 18:50:32 kel-agent ready to serve at
 ws://localhost:8081
 .
Running on another machine If you want to run your radio programs
 and kel-agent on one computer and your browser on another, this is
 possible. There are a couple of approaches. Neither is super easy,
 which I hope to fix.
 .
 NOTE: I do not recommend serving this in a way that's exposed to the
 internet because there is no authentication. If exposed to the internet,
 anyone could potentially initiate transmissions with your radio.  SSH port
 forwarding This method is relatively simple and quick to execute, but
 is more brittle than serving secure websockets because there is some
 setup each time you want to use the agent remotely, and conceptually
 a little harder. Your remote machine must be running an SSH server for
 this to work.
 .
 On the remote machine with your radio software, run kel-agent normally. It
 can be bound to localhost.
 .
 .
 $ kel-agent 2020/10/10 18:50:32 kel-agent ready to serve at
 ws://localhost:8081
 .
 .
 On the machine with your browser, start a command line and establish an
 SSH tunnel with port forwarding:
 .
 .
 $ ssh -N -L localhost:8081:localhost:8081 radio-pi
 .
 .
 The first localhost:8081 means "on this (browser) machine, bind to port
 8081 and only expose to localhost so other computers can't use it." The
 second localhost:8081 means "once you log into the remote computer, start
 forwarding traffic to port 8081 on its (remote) localhost." Finally,
 radio-pi in my example is the remote hostname which is running kel-agent
 and the SSH server.
 .
 The command will look like it's not doing anything; just let it run,
 and the tunnel will stay open.
 .
 Now your web application can be configured to connect to
 localhost. Traffic bound for localhost:8081 will get securely forwarded
 to the remote machine. Both the browser and kel-agent think they're
 talking to local processes, and you won't get mixed content warnings.
 Secure Websocket with TLS This method needs a little more set up ahead
 of time, but is easier to use once it's set up.
 .
 First, you'll need kel-agent to bind to 0.0.0.0 to allow connections
 from other computers.  Second, due to the mixed content policy which is
 standard in web browsers, you'll need to specify a TLS certificate and
 private key. Eventually I hope to make this easy, but for now you'll
 need to follow https://stackoverflow.com/a/60516812/587091. In short,
 • generate a CA key and root certificate, then• a server key and
 certificate signing request with the server's hostname,• sign the
 request to generate the server certificate, then finally• install the
 root certificate in your browser's trusted authorities.  Yeah, I really
 need to make this easier.
 .
 .
 $ kel-agent -host 0.0.0.0:8081 -key server.key -cert server.crt 2020/10/10
 19:05:39 kel-agent ready to serve at wss://0.0.0.0:8081
 .
 .
 Once running this way, your web application can be configured to
 connect directly to the remote computer.  Allowed origins As part of
 the same-origin policy which is standard in web browsers, kel-agent
 will only accept browser connections from certain origins (basically,
 websites). By default, only the website https://log.k0swe.radio plus
 some local developer addresses are allowed to connect to kel-agent,
 but this can be customized if others develop web applications that use
 kel-agent. I'm happy to accept pull requests to expand the default list!
 .
 .
 $ kel-agent -origins "https://log.k0swe.radio,https://someother.nifty.app;
 2020/10/10 19:18:52 Allowed origins are [https://log.k0swe.radio
 https://someother.nifty.app]

Bug#972620: dwarf-column-info patch

[Drake Diedrich]

I've had this for a while too and been looking. Not all versions of clang
have -dwarf-column-info, and the clang version just changed.  What worked
for me was just deleting it from intel-opencl-clang.
intel-grahics-compiler validates the flag and passes the errors back up,
but isn't where the flag is added to the compiler options.  Changing
intel-opencl-clang allowed compiles again.  I don't know what the
consequences are for debugging and profiling (since I haven't used those),
but not compiling is worse.

--- intel-opencl-clang-11.0~git20200922.orig/options_compile.cpp
+++ intel-opencl-clang-11.0~git20200922/options_compile.cpp
@@ -178,7 +178,6 @@ std::string EffectiveOptionsFilter::proc
   effectiveArgs.push_back("-cl-kernel-arg-info");
   effectiveArgs.push_back("-fno-validate-pch");
   effectiveArgs.push_back("-fno-caret-diagnostics");
-  effectiveArgs.push_back("-dwarf-column-info");

   if (std::find_if(effectiveArgs.begin(), effectiveArgs.end(),
[](const ArgsVector::value_type& a) {

Bug#973706: buster-pu: package lttng-modules/2.10.8-1

[Michael Jeanson]

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

Hi,

The attached diff fixes a build failure of the dkms modules on the
4.19.0-11 buster linux kernel. This was reported at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972321

I'd appreciate if you consider allowing this upload to buster.

Thanks,

Michael
diff -Nru lttng-modules-2.10.8/debian/changelog 
lttng-modules-2.10.8/debian/changelog
--- lttng-modules-2.10.8/debian/changelog   2018-11-02 16:13:20.0 
-0400
+++ lttng-modules-2.10.8/debian/changelog   2020-11-03 11:46:36.0 
-0500
@@ -1,3 +1,10 @@
+lttng-modules (2.10.8-1+deb10u1) buster; urgency=medium
+
+  * [5c8aed8] Update debian/gbp.conf for buster
+  * [16882db] Fix build on >= 4.19.0-10 kernels (Closes: #972321)
+
+ -- Michael Jeanson   Tue, 03 Nov 2020 11:46:36 -0500
+
 lttng-modules (2.10.8-1) unstable; urgency=medium
 
   * [7037820] New upstream version 2.10.8
diff -Nru lttng-modules-2.10.8/debian/gbp.conf 
lttng-modules-2.10.8/debian/gbp.conf
--- lttng-modules-2.10.8/debian/gbp.conf2018-07-04 11:21:39.0 
-0400
+++ lttng-modules-2.10.8/debian/gbp.conf2020-11-03 11:30:17.0 
-0500
@@ -1,3 +1,3 @@
 [DEFAULT]
-upstream-branch=upstream/latest
-debian-branch=debian/sid
+upstream-branch=upstream/2.10.8
+debian-branch=debian/buster
diff -Nru 
lttng-modules-2.10.8/debian/patches/0001-fix-writeback-Fix-sync-livelock-due-to-b_dirty_time-.patch
 
lttng-modules-2.10.8/debian/patches/0001-fix-writeback-Fix-sync-livelock-due-to-b_dirty_time-.patch
--- 
lttng-modules-2.10.8/debian/patches/0001-fix-writeback-Fix-sync-livelock-due-to-b_dirty_time-.patch
 1969-12-31 19:00:00.0 -0500
+++ 
lttng-modules-2.10.8/debian/patches/0001-fix-writeback-Fix-sync-livelock-due-to-b_dirty_time-.patch
 2020-11-03 11:30:17.0 -0500
@@ -0,0 +1,122 @@
+From 8e6be22dd4bf96b08447d075ce2fe3916f47764b Mon Sep 17 00:00:00 2001
+From: Michael Jeanson 
+Date: Mon, 31 Aug 2020 14:16:01 -0400
+Subject: [PATCH] fix: writeback: Fix sync livelock due to b_dirty_time
+ processing (v5.9)
+
+See upstream commit:
+
+  commit f9cae926f35e8230330f28c7b743ad088611a8de
+  Author: Jan Kara 
+  Date:   Fri May 29 16:08:58 2020 +0200
+
+writeback: Fix sync livelock due to b_dirty_time processing
+
+When we are processing writeback for sync(2), move_expired_inodes()
+didn't set any inode expiry value (older_than_this). This can result in
+writeback never completing if there's steady stream of inodes added to
+b_dirty_time list as writeback rechecks dirty lists after each writeback
+round whether there's more work to be done. Fix the problem by using
+sync(2) start time is inode expiry value when processing b_dirty_time
+list similarly as for ordinarily dirtied inodes. This requires some
+refactoring of older_than_this handling which simplifies the code
+noticeably as a bonus.
+
+Change-Id: I99e505965d278565ae512a30842cdce888e0c84a
+Signed-off-by: Michael Jeanson 
+Signed-off-by: Mathieu Desnoyers 
+---
+ .../events/lttng-module/writeback.h   | 46 +--
+ 1 file changed, 33 insertions(+), 13 deletions(-)
+
+diff --git a/instrumentation/events/lttng-module/writeback.h 
b/instrumentation/events/lttng-module/writeback.h
+index c472b33..353d58a 100644
+--- a/instrumentation/events/lttng-module/writeback.h
 b/instrumentation/events/lttng-module/writeback.h
+@@ -371,34 +371,55 @@ 
LTTNG_TRACEPOINT_EVENT_WBC_INSTANCE(wbc_balance_dirty_wait, writeback_wbc_balanc
+ #endif
+ LTTNG_TRACEPOINT_EVENT_WBC_INSTANCE(wbc_writepage, writeback_wbc_writepage)
+ 
+-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,1,0))
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(5,9,0) || \
++  LTTNG_KERNEL_RANGE(5,8,6, 5,9,0) || \
++  LTTNG_KERNEL_RANGE(5,4,62, 5,5,0) || \
++  LTTNG_KERNEL_RANGE(4,19,143, 4,20,0) || \
++  LTTNG_KERNEL_RANGE(4,14,196, 4,15,0) || \
++  LTTNG_KERNEL_RANGE(4,9,235, 4,10,0) || \
++  LTTNG_KERNEL_RANGE(4,4,235, 4,5,0) || \
++  LTTNG_UBUNTU_KERNEL_RANGE(4,15,18,119, 4,16,0,0))
++LTTNG_TRACEPOINT_EVENT(writeback_queue_io,
++  TP_PROTO(struct bdi_writeback *wb,
++   struct wb_writeback_work *work,
++   unsigned long dirtied_before,
++   int moved),
++  TP_ARGS(wb, work, dirtied_before, moved),
++  TP_FIELDS(
++  ctf_array_text(char, name, dev_name(wb->bdi->dev), 32)
++  ctf_integer(unsigned long, older, dirtied_before)
++  ctf_integer(int, moved, moved)
++  )
++)
++#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(3,2,0))
+ LTTNG_TRACEPOINT_EVENT(writeback_queue_io,
+   TP_PROTO(struct bdi_writeback *wb,
+-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,2,0))
+struct wb_writeback_work *work,
+-#else
+-   unsigned long *older_than_this,
+-#endif
+int moved),
+-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,2,0))
+  

Bug#971032: New upstream dev release available

[John Scott]

On Wednesday, October 28, 2020 12:59:38 PM EST John Scott wrote:
> Cygwin doesn't work under the current version of Wine

I was probably wrong about this. I built Wine 5.20 which worked and started 
backtracking to 5.5, but then that worked too. Unless it made some change to 
my Wine configuration stepping through the versions, it might've also been an 
IPv4/IPv6 or Cygwin mirror list issue.

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

Bug#972478: libjogl2-java, build-depends no longer satisfiable on 32-bit architectures.

[peter green]

severity 972478 serious
thanks

sorry forgot the severity when filing this bug.

Firstly https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972432 needs to be 
actioned by the ftpmasters.


This has been done, however checking the britney logs afterwards has revealed 
another issue, for which
I have just filed a bug.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973703

Bug#973705: RFA: django-qr-code -- Tools for displaying QR codes on your Django site

[Mattia Rizzolo]

Package: wnpp

I request an adopter for the django-qr-code package.

The package description is:
 This is an application that provides tools for displaying QR codes
 on your Django site.
 .
 This app makes no usage of the Django models and therefore do not
 use any database.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#973704: RFA: segno -- Python QR Code and Micro QR Code encoder

[Mattia Rizzolo]

Package: wnpp

I request an adopter for the segno package.

The package description is:
 Pure Python QR Code generator with no dependencies.
 .
 This package implements ISO/IEC 18004:2015(E) "QR Code bar code symbology
 specification" and produces QR Codes and Micro QR Codes with nearly no effort.
 It supports the Structured Append mode which splits a message across several
 QR codes.
 .
 Segno (Italian for "sign" / "symbol") provides several serialization formats
 like Scalable Vector Graphics (SVG), Encapsulated PostScript (EPS), Portable
 Network Graphics (PNG), Portable Document Format (PDF), Netpbm (PAM, PBM,
 PPM), LaTeX (PGF/TikZ), X PixMap (XBM), and X Bitmap (XPM) etc. None of these
 serializers require an external lib. Further, it provides several high level
 functions to create QR Codes which encode contact data (vCard, MeCard), EPC QR
 Codes, or WIFI QR Codes.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#973703: cantor-backend-scilab: dependency no longer available on i386 and armhf

[peter green]

Package: cantor-backend-scilab
Version: 4:20.04.3-1
Severity: serious

As a result of swt dropping support for 32-bit targets, libjogl2-java can no 
longer be built on i386 and armhf and the
existing binaries have been removed in unstable. This in turn has lead to the 
removal of scilab on those architectures.

Please adjust the architecture list for cantor-backend-scilab accordingly.

Bug#973702: licensecheck should read "license" field from package.json files

[Jonas Smedegaard]

Quoting Xavier Guimard (2020-11-03 17:07:02)
> when launching licensecheck in a nodejs module, I'd like to see 
> licensecheck reveals which license is used in package.json

Licensecheck currently operates on files.

package.json contains a field to state license for a _project_ which is 
something different.

How would you expect licensecheck would handle that?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#973700: RFP: nodejs-client (?) -- a client for browser's extensions

[Xavier]

Le 03/11/2020 à 16:39, Janusz S. Bień a écrit :
> Package: wnpp
> Severity: wishlist
> 
> * Package name: nodejs-client (?)
>   Version : 
>   Upstream Author : Andy Portmen
> * URL or Web page : https://github.com/andy-portmen/native-client
> * License : 
>   Description : a client for browser's extensions
> 
> Together with
> 
> https://github.com/andy-portmen/external-application-button
> 
> it allows to circumvent the lack of NSAPI plugins.

Hi,

Could you explain more what is the benefit of this in Debian ?

Bug#973702: licensecheck should read "license" field from package.json files

[Xavier Guimard]

Package: licensecheck
Version: 3.0.47-1
Severity: minor

Hi,

when launching licensecheck in a nodejs module, I'd like to see
licensecheck reveals which license is used in package.json

Cheers,
Xavier

Bug#973701: network-manager: 'systemctl restart ModemManager.service' wipes /etc/resolve.conf (almost) clean

[Cristian Ionescu-Idbohrn]

Package: network-manager
Version: 1.27.91-1
Severity: grave

/etc/resolve.conf includes the expected configuration (WRT
nameservers) on bootup.

After upgrading network-manager and restarting it, /etc/resolve.conf
(which is a symlink to /run/NetworkManager/resolv.conf) is basically
wiped out.  Includes only this:

# Generated by NetworkManager

Rebooting brings things to normal.  Still, this isn't wintendo.  I'd
expect better.

There are some workarounds (suggested in some other bug reports) that
bring the system back to an usable state, but far away from perfect 
(dhclient wlan0).  Duplicated home router nameserver addresses in 
/etc/resolv.conf:

nameserver 192.168.0.1
nameserver 192.168.0.1

which is not what my configuration is.


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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 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) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages network-manager depends on:
ii  adduser  3.118
ii  dbus 1.12.20-1
ii  libaudit11:2.8.5-3.1
ii  libbluetooth35.55-1
ii  libc62.31-4
ii  libcurl3-gnutls  7.72.0-1
ii  libglib2.0-0 2.66.1-2
ii  libgnutls30  3.6.15-4
ii  libjansson4  2.13.1-1
ii  libmm-glib0  1.14.6-0.1
ii  libndp0  1.6-1+b1
ii  libnewt0.52  0.52.21-4+b2
ii  libnm0   1.27.91-1
ii  libpam-systemd   246.6-2
ii  libpsl5  0.21.0-1.1
ii  libreadline8 8.0-4
ii  libselinux1  3.1-2+b1
ii  libsystemd0  246.6-2
ii  libteamdctl0 1.31-1
ii  libudev1 246.6-2
ii  libuuid1 2.36-3+b2
ii  policykit-1  0.105-29
ii  udev 246.6-2
ii  wpasupplicant2:2.9.0-15

Versions of packages network-manager recommends:
ii  crda 4.14+git20191112.9856751-1
ii  dnsmasq-base [dnsmasq-base]  2.82-1
ii  iptables 1.8.5-3
ii  modemmanager 1.14.6-0.1
pn  ppp  

Versions of packages network-manager suggests:
ii  isc-dhcp-client  4.4.1-2.1+b2
pn  libteam-utils

-- no debconf information


Cheers,

-- 
Cristian

Bug#973612: [Debian-med-packaging] Bug#973612: I'm afrait I did some kind of sabotage by upgrading civetweb ... [karsten.hilb...@gmx.net: Bug#973612: orthanc: libcivetweb version mismatch]

[Sébastien Jodogne]

Hello,

After some investigation, I think that this issue comes from the fact
that the "libcivetweb1" package (as of version 1.13+dfsg-2) doesn't
contain a symbolic link from "libcivetweb.so.1" to "libcivetweb.so.1.13.0".

Because of this missing symbolic link, Orthanc is linked against one
single version of the civetweb shared library (namely,
"libcivetweb.so.1.13.0"), and this library might be unavailable if an
earlier version of "libcivetweb1" was installed beforehand (in Karsten's
case, "libcivetweb.so.1.11.0"), even if the two versions are binary
compatible.

I feel like this corresponds to the warning
"package-name-doesnt-match-sonames" that was reported by Lintian.

In order to solve this issue, I've just submitted a new release of
civetweb (1.13+dfsg-3) that creates the missing symbolic link
"libcivetweb.so.1" by appropriately setting the SOVERSION in CMake,
which required a patch [1].

When Orthanc will be compiled against this new version of civetweb, it
should hopefully be linked against "libcivetweb.so.1" instead of
"libcivetweb.so.1.13.0", making it compatible with a whole range of
versions of civetweb, and it should thus be possible to upgrade civetweb
without breaking Orthanc. If this is indeed the case, I'll soon be able
to make a new release of Orthanc that fixes this issue.

These thoughts might seem trivial to many of you, but I wanted to share
them if someone else meets a similar problem in another context.

Best Regards,
Sébastien-

[1]
https://salsa.debian.org/med-team/civetweb/-/commit/ccb62139b6139ea6efc2432c12018de6e3c16003


On 3/11/20 14:11, Andreas Tille wrote:
> [including the list again]
> Hi Sébastien,
> 
> On Mon, Nov 02, 2020 at 04:39:31PM +0100, Sébastien Jodogne wrote:
>> To be fair, I am unsure to understand the issue and how to fix it...
>>
>> Should I simply modify the "Build-Depends" of the orthanc package to the
>> fix the version of civetweb to 1.13 (i.e. "libcivetweb-dev (= 1.13)")? Or
>> set "Depends" to "libcivetweb1 = 1.13"?
> 
> I do not think so.  The packaging process will usually set versioned
> depends correctly.  Moreover at least in theory orthanc should work with
> both libcivetweb1 versions (1.12 and 1.13) since the soversion was not
> bumped.  To verify this I added a symbols file to 1.12 first and after
> checking that there are only some new symbols in 1.13 I considered it
> harmless to upload (which was obviously wrong).
>  
>> This sounds very strange to me: I would have expected that, as the orthanc
>> package was built against civetweb 1.13 (which is implied by the fact that
>> ldd on "/usr/sbin/Orthanc" indicates "libcivetweb.so.1.13.0"), its
>> "Depends" should have automatically been set to "libcivetweb1 >= 1.13"
>> (whereas ">= 1.12" is found in the .deb package).
> 
> I confirm that the build really injects libcivetweb1 (>= 1.12).  I need
> to admit that I do not know those internals but I would assume that as
> long as the soversion is unchanged the smallest possible version number
> is used here.  But I'm unsure.  I think if for whatever reason >= 1.13
> is needed than this has to be specified explicitly.  But please note
> that I never faced this before and clarifying this on debian-mentors
> might be advisable.
> 
>> Please could you explain it to me?
> 
> Not better than above, sorry. :-(
> 
> Kind regards
> 
>Andreas.
>  
>> On Mon, 2 Nov 2020 at 15:36, Andreas Tille  wrote:
>>
>>> Hi Sébastien,
>>>
>>> hopefully that can easily be fixed - sorry for the inconvenience
>>>
>>>  Andreas.
>>>

Bug#973700: RFP: nodejs-client (?) -- a client for browser's extensions

[Janusz S. Bień]

Package: wnpp
Severity: wishlist

* Package name: nodejs-client (?)
  Version : 
  Upstream Author : Andy Portmen
* URL or Web page : https://github.com/andy-portmen/native-client
* License : 
  Description : a client for browser's extensions

Together with

https://github.com/andy-portmen/external-application-button

it allows to circumvent the lack of NSAPI plugins.

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#973492: abseil: Please consider explicitly enable -latomic with armel build

[Benjamin Barenblat]

Control: owner 973492 !
Control: tags 973492 + upstream
Control: forwarded 973492 https://github.com/abseil/abseil-cpp/issues/836

Indeed, some of the shared libraries need to be built with -latomic on
armel. In addition, the CMake support files that get installed with
libabsl-dev should probably specify -latomic on armel; otherwise,
anybody using CMake to link statically will run into the same issue. I
think a single patch might be able to do both of these; I’m going to do
some more research this week and see if I can make it happen.

I’ll plan to do an upload on Friday at the latest; if that’s too far in
the future, let me know, and I’ll do a stopgap upload to fix the libgav1
FTBFS.


signature.asc
Description: PGP signature

Bug#834129: pgadmin4 adopter wanted

[Christoph Berg]

Re: William Bonnet
> First of all i do apologize for my late answer, something went wrong on my 
> side with email delivery... :(

Hi William,

the last week was very busy and I was just too tired to answer
earlier, sorry for that.

> In short :) i know what i am doing by applying to maintain a PG tool package 
> :) it is going to be a lot of work, and i have checked that enough free time 
> time in the coming months to handle this.

That sounds perfect. Thanks for volunteering.

> I was expecting to have this work to do and of course to with Ubuntu and 
> Postgresql maintainers and community.

Ideally the package would be included in Debian and Ubuntu, but that
needs the whole "Javascript needs packing and proper licenses" issue
resolved first which will not be easy.

Until that happens, we have the packages on apt.postgresql.org, where
it is built for the Debian and Ubuntu distributions.

Another question is if "our" package needs adjustments now that
pgadmin4 upstream has published their own packages with a completely
different layout. (At the very least we should probably "Conflict:"
with their packages so users don't get into a mess when they have
installed both. Or maybe that's not a problem and having both works.)

> I propose to start on my side by upgrading  your pckage to latest  restarting 
>  from existing package definition and let you knwow and see how things are 
> going.

The packaging repository is https://salsa.debian.org/postgresql/pgadmin4 .
I suggest you get an account there, and clone the repository to work
on. I can also get you privileges to trigger builds for
https://pgdgbuild.dus.dg-i.net/job/pgadmin4/ and the related build
jobs there.

Christoph

Bug#875306: python-debian: include a type for buildinfo files

[Holger Levsen]

Hi Stuart,

On Tue, Nov 03, 2020 at 10:56:33AM +1100, Stuart Prescott wrote:
> I'll get this merged and released soonish. Hopefully people will start using 
> this class, thinking about more things that it could do, reporting bugs and 
> offering patches :)

cool!

do you have an example where one buildinfo file (from a binNMU) is provided
and the changelog entries are passed back?


-- 
cheers,
Holger

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

“If the fires of 2020 horrify you, consider that, no matter what we do, by
 2050, when the benefits of even fast climate action will only begin to arrive,
 the area burned annually in the (US) West is expected to at least double and
 perhaps quadruple.” (David Wallace-Wells)


signature.asc
Description: PGP signature

Bug#973677: Confirmed even in 5.19.5-2

[Oliver Sander]

I (apparently) solved the problem by updating a few plasma packages to 5.19,
in particular

plasma-workspace
plasma-desktop

(and possibly one or two more).  They are still at 5.17 in unstable.



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#973692: thunderbird: I can't resize the window, part is hidden, can't read emails

[Helen Koike]

Package: thunderbird
Version: 1:78.4.0-1
Followup-For: Bug #973692

Dear Maintainer,

I see the same error reported here:

> xprop -name " - Mozilla Thunderbird" WM_NORMAL_HINTS
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified minimum size: 1014 by 1829
program specified maximum size: 32766 by 32766
program specified base size: 1014 by 1829
window gravity: NorthWest

I can't reduce vertically the size of the window, it hides part of the
window and I can't read part of my email.

Maybe this is related to these issues reported upstream:

https://bugzilla.mozilla.org/show_bug.cgi?id=1674990
https://bugzilla.mozilla.org/show_bug.cgi?id=1674998

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

Kernel: Linux 5.9.0-1-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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages thunderbird depends on:
ii  debianutils 4.11.2
ii  fontconfig  2.13.1-4.2
ii  libatk1.0-0 2.36.0-2
ii  libbotan-2-15   2.15.0+dfsg-2+b1
ii  libbz2-1.0  1.0.8-4
ii  libc6   2.31-4
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libdbus-1-3 1.12.20-1
ii  libdbus-glib-1-20.110-5
ii  libevent-2.1-7  2.1.12-stable-1
ii  libffi7 3.3-4
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.2+dfsg-4
ii  libgcc-s1   10.2.0-16
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-5
ii  libglib2.0-02.66.2-1
ii  libgtk-3-0  3.24.23-2
ii  libicu6767.1-4
ii  libjson-c5  0.15-1
ii  libnspr42:4.29-1
ii  libnss3 2:3.58-1
ii  libpango-1.0-0  1.46.2-1
ii  libstdc++6  10.2.0-16
ii  libvpx6 1.8.2-1
ii  libx11-62:1.6.12-1
ii  libx11-xcb1 2:1.6.12-1
ii  libxcb-shm0 1.14-2
ii  libxcb1 1.14-2
ii  libxext62:1.3.3-1+b2
ii  libxrender1 1:0.9.10-1
ii  psmisc  23.3-1
ii  x11-utils   7.7+5
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2019.10.06-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.5-1
ii  fonts-lyx 2.3.5.2-1
ii  libgssapi-krb5-2  1.17-10
ii  libgtk2.0-0   2.24.32-4

-- no debconf information

Bug#973677: Confirmed even in 5.19.5-2

[Oliver Sander]

I'm seeing the same thin even with libkscreenlocker5 5.19.5-2 from experimental.
The locked screen is completely black, and wiggling the mouse shows the cursor
but nothing else.

My workaround to unlocking the session is to switch to a TTY shell by 
ctrl-shift-2,
and using 'loginctl unlock-session'.



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#973637: flag debian/watch files that use older versions of the format

[Mattia Rizzolo]

On Mon, Nov 02, 2020 at 10:54:11PM +0100, Xavier wrote:
> But version 2 is really deprecated and it's
> not easy to maintain uscan with 4 versions (It took me a lot of hours to
> rewrite old uscan to modern Perl-OO).
> That's why I'd like to see a "error" tag for version ≤ 2.

Right, but currently version=2 is not explicitly marked as "deprecated"
anywhere.

Could you please send a MR updating the docs doing so?
I also think ds_warn() its usage would be good (then tracker.d.o and
others would rely the warning, etc).

> 3. After bullseye release, I'd like to propose to remove version=2
> support from uscan.

+1


For context of d-devel@, version=2 is currently used by a total of 350
packages in the whole archive, I reckon dropping support for it is
totally doable.

I think we can easily:
 1) mark the thing as deprecated in the manpage and warning at runtime
 2) add a note for the next DevNews
 3) wait a few months after the bullseye release
 4) MBF the remaining version=2 packages
 5) wait a few more months
 6) drop the support ~1/~1.5 years from now

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature