Bug#973785: gcc-10: Huge package sizes of gcc-10 and cpp-10 on amd64

2020-11-04 Thread Matthias Klose
On 11/5/20 6:24 AM, jim_p wrote:
> Package: gcc-10
> Version: 10.2.0-16
> Severity: minor
> 
> Dear Maintainer,
> 
> I got today's upgrade to 10.2.0-16 for gcc-10 and cpp-10 in testing amd64 and 
> I
> noticed that the package sizes have increased by a lot! More specifically,
> gcc-10 went from 15MB to 67 and cpp-10 from 7.5MB to 60! Their installed sizes
> sum up to 600+MB now, making them the top 2 packages in dpigs!
> 
> Is that intentional, or is it some bug? Because I also have a i386 machine
> running sid and those 2 remained roughly the same in package and istallation
> size. I don't really mind the size, I just want to see if someone else has
> noticed the same.

 - you could have looked at the bug tracker before filing a report.
 - you could have looked at the changelog before filing a report.



Bug#973788: ITP: r-bioc-rhdf5filters -- GNU R HDF5 compression filters

2020-11-04 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-rhdf5filters -- GNU R HDF5 compression filters
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-bioc-rhdf5filters
  Version : 1.2.0
  Upstream Author : Mike Smith
* URL : https://bioconductor.org/packages/rhdf5filters/
* License : BSD-2-clause
  Programming Lang: GNU R
  Description : GNU R HDF5 compression filters
 This Bioconductor package provides a collection of compression filters for
 use with HDF5 datasets.
 .
 One of the advantages of using HDF5 is that data stored on disk can be
 compressed, reducing both the space required to store them and the time
 needed to read those data. This data compression is applied as part of the
 HDF5 “filter pipeline” that modifies data during I/O operations. HDF5
 includes several filter algorithms as standard, and the version of the
 HDF5 library found in Rhdf5lib is additionally compiled with support for
 the deflate and szip compression filters which rely on third-party
 compression libraries. Collectively HDF5 refer to these as the “internal”
 filters. It is possible to use any combination of these (including none)
 when writing data using rhdf5.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-rhdf5filters


Bug#973787: pipewire crash gnome-shell / gdm on start

2020-11-04 Thread Michael Ott
Package: pipewire
Version: 0.3.14-1
Severity: important

Dear Maintainer,

After updating to 0.3.14 gdm starts normal for one second and then I got a
black screen with blinking cursor. After switch to another terminal and back it
works.

Downgrade to 0.3.12 helps

In syslog I found this error messages:
Nov  5 07:37:30 k-c13 pipewire[3574]: #033[1;33m[W][00558.913878][pulse-
server.c:337 reply_error()] pulse-server 0x56311c0f5110: ERROR tag:7 error:1
(Permission denied)#033[0m
Nov  5 07:37:31 k-c13 pipewire[3574]: #033[1;33m[W][00559.992097][pulse-
server.c:337 reply_error()] pulse-server 0x56311c0f5110: ERROR tag:8 error:1
(Permission denied)#033[0m



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (710, 'unstable'), (670, 'testing'), (660, 'experimental'), (600, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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

Versions of packages pipewire depends on:
ii  init-system-helpers  1.58
ii  libpipewire-0.3-modules  0.3.14-1
ii  pipewire-bin 0.3.14-1

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information



Bug#972854: seems not to work

2020-11-04 Thread Francisco
Hi Daniel,

I'm sorry for the late reply,

> Hi,
>
> I've tried tty-server out, but it seems not to work for me.
>
> I'm using "example.net" in the following commands, but have been using a
> proper dns entry in reality of course.
>
> Also, before making it work "properly" behind an apache reverse proxy
> with proper ssl, I thought I'd just try it out quick
>
> On the server, I did:
>
>  # tty-server -url http://tty.example.net
>  INFO[] Listening on address: http://:80, and TCP://:6543
>
> On the client, I've been using:
>  # tty-share -server tty.example.net:6543 -useTLS false

please, try:
$ tty-share -server tty.example.net:6543 -useTLS=false

>
> Which gives me the following output on the server:
>
>  WARN[0655] Cannot create session with 1.2.3.4:35688. Error:
>  Cannot decode message: invalid character '\x16' looking for beginning
>  of value
>
> And the following output on the client:
>
>  Cannot connect (TLS) to the server (tty.example.net:6543): EOF
>
> Disabling TLS doesn't work then.
>
> Furhter observations:
>
>  * neither '-useTLS false' nor '-useTLS no' work at all when
>being 'reordered', so when calling:
>
>tty-share -useTLS false -server tty.example.net:6543
>
>then all commandline options are ignored entirely and
>a normal session to go.tty-share.com is established,
>eventhough -server has been specified.

hmm, very good, I didn't realize it, thanks a lot,
as a new release has just come out, I will confirm if it remains.

>
>  * the default ports from the server and the client don't seem
>to match; the server by default starts on 6543, the client
>tries by default 7654.

Yes, it is the way the server was configured,
"use nginx as reverse proxy for the web interface at port 5000 (listen at 443,
terminate the TLS, and redirect to localhost:5000)
TLS endpoint at port 7654, and redirect to localhost:6543"

https://github.com/elisescu/tty-server/blob/56e269830bd98411b18f6299761f56ab3a87f82a/README.md

>
>  * it would be nice to have systemd unit files and apache configs
>integrated into the package, so that a 'apt install tty-server'
>works out of the box.

Yes, it is one of the things that are on my To-Do list.

>
> Regards,
> Daniel

Thanks,
-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00



Bug#973759: lintian: False positive: debian-changelog-file-is-a-symlink matches on upstream changelog

2020-11-04 Thread Andreas Metzler
On 2020-11-04 Felix Lechner  wrote:
> On Wed, Nov 4, 2020 at 9:15 AM Andreas Metzler  wrote:
> > However the Debian changelog file is not a symlink, only the upstream
> > one.

> Unfortunately, Lintian cannot tell from an installation package
> (*.deb) whether it was built from a native source package.

Hello,

It does not need to imho. It should simply consider 
/usr/share/doc/package/changelog.Debian.gz as Debian changelog if it
exists and only fall back to /usr/share/doc/package/changelog.gz
otherwise.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



Bug#973786: rclone-browser FTBFS due to -Werror=deprecated-declarations

2020-11-04 Thread Helmut Grohne
Source: rclone-browser
Version: 1.8.0-1.1
Severity: serious
Tags: ftbfs

rclone-browser fails to build from source in unstable:

| [ 48%] Building CXX object src/CMakeFiles/rclone-browser.dir/main_window.cpp.o
| cd /<>/obj-x86_64-linux-gnu/src && /usr/bin/c++ -DQT_CORE_LIB 
-DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB 
-DRCLONE_BROWSER_VERSION=\"1.8.0\" -I/<>/obj-x86_64-linux-gnu/src 
-I/<>/src -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtNetwork -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2   -pedantic -Wall 
-Wextra -Werror -std=c++11 -fPIC -o 
CMakeFiles/rclone-browser.dir/main_window.cpp.o -c 
/<>/src/main_window.cpp
| /<>/src/main_window.cpp: In lambda function:
| /<>/src/main_window.cpp:435:74: error: ‘QStringList 
QString::split(const QString&, QString::SplitBehavior, Qt::CaseSensitivity) 
const’ is deprecated: Use Qt::SplitBehavior variant instead 
[-Werror=deprecated-declarations]
|   435 |   QStringList lines = version.split("\n", 
QString::SkipEmptyParts);
|   |   
   ^
| In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:47,
|  from 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qabstractanimation.h:43,
|  from /usr/include/x86_64-linux-gnu/qt5/QtCore/QtCore:6,
|  from /<>/src/pch.h:9,
|  from /<>/src/icon_cache.h:3,
|  from /<>/src/main_window.h:3,
|  from /<>/src/main_window.cpp:1:
| /usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:604:17: note: declared here
|   604 | QStringList split(const QString , SplitBehavior behavior,
|   | ^
| /<>/src/main_window.cpp: In member function ‘void 
MainWindow::addStream(const QString&, const QString&)’:
| /<>/src/main_window.cpp:1217:43: error: ‘void 
QProcess::start(const QString&, QIODevice::OpenMode)’ is deprecated: Use 
QProcess::start(const QString , const QStringList ,OpenMode 
mode = ReadWrite) instead [-Werror=deprecated-declarations]
|  1217 |   player->start(stream, QProcess::ReadOnly);
|   |   ^
| In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/QtCore:170,
|  from /<>/src/pch.h:9,
|  from /<>/src/icon_cache.h:3,
|  from /<>/src/main_window.h:3,
|  from /<>/src/main_window.cpp:1:
| /usr/include/x86_64-linux-gnu/qt5/QtCore/qprocess.h:168:10: note: declared 
here
|   168 | void start(const QString , OpenMode mode = ReadWrite);
|   |  ^
| cc1plus: all warnings being treated as errors
| make[3]: *** [src/CMakeFiles/rclone-browser.dir/build.make:237: 
src/CMakeFiles/rclone-browser.dir/main_window.cpp.o] Error 1
| make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[2]: *** [CMakeFiles/Makefile2:116: 
src/CMakeFiles/rclone-browser.dir/all] Error 2
| make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[1]: *** [Makefile:152: all] Error 2
| make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j1 "INSTALL=install 
--strip-program=true" returned exit code 2
| make: *** [debian/rules:14: build] Error 25
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Also seen by crossqa at
http://crossqa.debian.net/build/rclone-browser_1.8.0-1.1_armhf_20201031084525.log
since about 3 days and it built successfully about 5 days ago. Likely a
regression introduced by some other package.

Helmut



Bug#785480: Wireshark - Rel 3.2.3-1 - Unable to play back G.729 Codec Calls

2020-11-04 Thread Giel Oberholster (MEA)
Hi Team

I have noticed  that the Linux release of Wireshark prepared for Debian or 
Ubuntu does not contain the ability to playback the  G.729 Codec. At this point 
in time the current status is:

Can analyse the G.711A and G.711U Calls
Can play back the G.711A and G.711U Calls
Can analyse the G.729 codec
Cannot play back the G.729 codec

I engaged with Wireshark and they indicated that the following needs to be 
added to your Wireshark packaging for this to work

  *   bcg729

More and more clients are trying to save on bandwidth by using the G.729 Codec. 
Since this is not available for Linux users it makes live difficult to anlyse 
all criteria on a G.729 call


I have tried the release on Ubuntu and Linux Mint as well, same issue

3.2.3 (Git v3.2.3 packaged as 3.2.3-1)

Compiled (64-bit) with Qt 5.12.8, with libpcap, with POSIX capabilities 
(Linux), with libnl 3, with GLib 2.64.2, with zlib 1.2.11, with SMI 0.4.8, with 
c-ares 1.15.0, with Lua 5.2.4, with GnuTLS 3.6.13 and PKCS #11 support, with 
Gcrypt 1.8.5, with MIT Kerberos, with MaxMind DB resolver, with nghttp2 1.40.0, 
with brotli, with LZ4, with Zstandard, with Snappy, with libxml2 2.9.10, with 
QtMultimedia, without automatic updates, with SpeexDSP (using system library), 
with SBC, with SpanDSP, without bcg729.

Running on Linux 5.4.0-52-generic, with Intel(R) Core(TM) i7-2670QM CPU @ 
2.20GHz (with SSE4.2), with 7844 MB of physical memory, with locale 
en_ZA.UTF-8, with light display mode, without HiDPI, with libpcap version 1.9.1 
(with TPACKET_V3), with GnuTLS 3.6.13, with Gcrypt 1.8.5, with brotli 1.0.7, 
with zlib 1.2.11, binary plugins supported (18 loaded).

Built using gcc 9.3.0.


This functionality is already part of the Windows version of Wireshark since 
release 2.5

Kind Regards


Bug#963320: libtgvoip: FTBFS: AttributeError: module 'string' has no attribute 'maketrans'

2020-11-04 Thread Xavier
Control: tags -1 + moreinfo

Hi,

I'm unable to reproduce the bug: libtgvoip build works fine here. Could
you verify that the bug still exists?

Cheers,
Xavier



Bug#973785: gcc-10: Huge package sizes of gcc-10 and cpp-10 on amd64

2020-11-04 Thread jim_p
Package: gcc-10
Version: 10.2.0-16
Severity: minor

Dear Maintainer,

I got today's upgrade to 10.2.0-16 for gcc-10 and cpp-10 in testing amd64 and I
noticed that the package sizes have increased by a lot! More specifically,
gcc-10 went from 15MB to 67 and cpp-10 from 7.5MB to 60! Their installed sizes
sum up to 600+MB now, making them the top 2 packages in dpigs!

Is that intentional, or is it some bug? Because I also have a i386 machine
running sid and those 2 remained roughly the same in package and istallation
size. I don't really mind the size, I just want to see if someone else has
noticed the same.



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

Kernel: Linux 5.9.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /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:
pn  libc6-dev  

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

-- no debconf information



Bug#973775: licensecheck returns incorrect license

2020-11-04 Thread Sandro Mani

On 05.11.20 03:56, Jonas Smedegaard wrote:

Quoting Sandro Mani (2020-11-04 22:54:56)

Package: licensecheck
Version: 3.1.1

I'm reporting this downstream issue [1], for your evaluation:

Description of problem:

$ licensecheck COPYING
COPYING: Expat License GNU Lesser General Public License, Version 3

Perhaps a bit of a pathological case.

Version-Release number of selected component (if applicable):
licensecheck-3.1.1-3.fc33.noarch
perl-Regexp-Pattern-License-3.4.0-3.fc33.noarch


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1866603

Sorry, I don't understand what is the issue here?

Could you please elaborate - I fail to parse the above "Description of
problem" and fail to find more info at the referenced bugzilla report.
Could very well be me simply missing something obvious - please help me
out...
Looking at the attached COPYING file, I suppose the original reporter 
expected the license to be reported just as


 GNU Lesser General Public License, Version 3

But I'll ask him to provide more info here.

Best
Sandro



Bug#973774: lazpaint: copyright file incorrect

2020-11-04 Thread Johann ELSASS
Hello Joerg,

Ok to change it.

Though I did not find it in the list.
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

How shall I call it in the License field? Would the following be ok?

License: mLGPL-2
 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU Lesser General Public License as published
 by the Free Software Foundation; version 2 with the following modification:
 .
 As a special exception, the copyright holders of this library give you
 permission to link this library with independent modules to produce an
 executable, regardless of the license terms of these independent modules,
 and to copy and distribute the resulting executable under terms of your choice,
 provided that you also meet, for each linked independent module, the terms
 and conditions of the license of that module. An independent module is a
 module which is not derived from or based on this library. If you modify this
 library, you may extend this exception to your version of the library, but
 you are not obligated to do so. If you do not wish to do so, delete this
 exception statement from your version.
 .
 This program is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 GNU Lesser General Public License for more details.
 .
 You should have received a copy of the GNU Lesser General Public License
 along with this program; if not, write to the Free Software Foundation,
 Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 .
 On Debian systems, the full text of the GNU Lesser General Public
 License version 2 can be found in the file
 '/usr/share/common-licenses/LGPL-2'.

License: mLGPL-2+
 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU Lesser General Public License as published
 by the Free Software Foundation; either version 2 of the License, or
 (at your option) any later version, with the following modification:
 .
 As a special exception, the copyright holders of this library give you
 permission to link this library with independent modules to produce an
 executable, regardless of the license terms of these independent modules,
 and to copy and distribute the resulting executable under terms of your choice,
 provided that you also meet, for each linked independent module, the terms
 and conditions of the license of that module. An independent module is a
 module which is not derived from or based on this library. If you modify this
 library, you may extend this exception to your version of the library, but
 you are not obligated to do so. If you do not wish to do so, delete this
 exception statement from your version.
 .
 This program is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 GNU Lesser General Public License for more details.
 .
 You should have received a copy of the GNU Lesser General Public License
 along with this program; if not, write to the Free Software Foundation,
 Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 .
 On Debian systems, the full text of the GNU Lesser General Public
 License version 2 can be found in the file
 '/usr/share/common-licenses/LGPL-2'.

Regards,

-- 
  Johann ELSASS
  circu...@operamail.com



Bug#973783: ovmf: OVMF_CODE_4M.ms.fd does not show BIOS startup screen

2020-11-04 Thread Ryutaroh Matsumoto
Package: ovmf
Version: 2020.08-1
Severity: normal
Control: block 973780 by -1

Dear Maintainer,

When I start QEMU as

cp /usr/share/OVMF/OVMF_VARS_4M.fd /tmp/efivars.fd
qemu-system-x86_64  -net nic,model=virtio -net user \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-pci,rng=rng0,id=rng-device0 \
-drive file=/var/tmp/debian-bullseye-amd64.img,if=virtio,index=0,format=raw \
-drive if=pflash,format=raw,read-only,file=/usr/share/OVMF/OVMF_CODE_4M.fd \
-drive if=pflash,format=raw,file=/tmp/efivars.fd -m 1024 \
-machine q35,smm=on -global driver=cfi.pflash01,property=secure,value=on \
 -cpu max -enable-kvm 

The QEMU image debian-bullseye-amd64 starts fine.
But if I replace OVMF_CODE_4M to OVMD_CODE_4M.ms.fd and
OVMD_VARS_4M.fd to OVMF_VARS_4M.fd,
then no BIOS screen shows up.

When I built an i386 UEFI secure boot ROM at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973571#61
UEFI shell showed up.

I wonder if something wrong in OVMF_VARS_4M.ms.fd...

Best regards, Ryutaroh Matsumoto




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

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

-- no debconf information



Bug#973782: corsix-th: please make the build reproducible

2020-11-04 Thread Phil Morrell
Package: corsix-th
Version: 0.64-1
Severity: wishlist
Tags: upstream help
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org


The salsa-ci [pipeline] fails on reprotest. This means that corsix-th
cannot be built [reproducibly], though it won't show on archive tests
because they only consider packages in main, not contrib.

[pipeline]: https://salsa.debian.org/games-team/corsix-th/-/pipelines/194160
[reproducibly]: https://reproducible-builds.org/

From a diffoscope inspection of the .deb (attached), I can see it is
solely /usr/games/corsix-th that differs. The various differences can, I
think, be entirely explained by the embedding of the [buildpath]. Any
help in identifying further issues or fixing them is much appreciated.

[buildpath]: 
https://tests.reproducible-builds.org/debian/issues/unstable/gcc_captures_build_path_issue.html
--
Phil Morrell (emorrp1)


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

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

Versions of packages corsix-th depends on:
ii  corsix-th-data   0.64-1~bpo10+1
ii  libavcodec58 7:4.1.6-1~deb10u1
ii  libavformat587:4.1.6-1~deb10u1
ii  libavutil56  7:4.1.6-1~deb10u1
ii  libc62.28-10
ii  libfreetype6 2.9.1-3+deb10u2
ii  libgcc1  1:8.3.0-6
ii  liblua5.2-0  5.2.4-1.1+b2
ii  libsdl2-2.0-02.0.9+dfsg1-1
ii  libsdl2-mixer-2.0-0  2.0.4+dfsg1-1
ii  libstdc++6   8.3.0-6
ii  libswresample3   7:4.1.6-1~deb10u1
ii  libswscale5  7:4.1.6-1~deb10u1
ii  lua-filesystem   1.6.3-1
ii  lua-lpeg 1.0.0-2

Versions of packages corsix-th recommends:
ii  game-data-packager   63
ii  theme-hospital-data  49.1
ii  timidity 2.14.0-8

corsix-th suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature


Bug#973775: licensecheck returns incorrect license

2020-11-04 Thread Jonas Smedegaard
Quoting Sandro Mani (2020-11-04 22:54:56)
> Package: licensecheck
> Version: 3.1.1
> 
> I'm reporting this downstream issue [1], for your evaluation:
> 
> Description of problem:
> 
> $ licensecheck COPYING
> COPYING: Expat License GNU Lesser General Public License, Version 3
> 
> Perhaps a bit of a pathological case.
> 
> Version-Release number of selected component (if applicable):
> licensecheck-3.1.1-3.fc33.noarch
> perl-Regexp-Pattern-License-3.4.0-3.fc33.noarch
> 
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1866603

Sorry, I don't understand what is the issue here?

Could you please elaborate - I fail to parse the above "Description of 
problem" and fail to find more info at the referenced bugzilla report. 
Could very well be me simply missing something obvious - please help me 
out...


Kind regards,

 - 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#973781: vmdb2: support of UEFI secure boot

2020-11-04 Thread Ryutaroh Matsumoto
Package: vmdb2
Version: 0.19-1
Severity: wishlist
Control: block 973780 by -1

Dear Maintainer,

When "grub: uefi" is chosen in a vmdb2 yaml, grub-efi-amd64 is installed.
To support UEFI secure boot, additionally grub-efi-amd64-signed and shim-signed
have to be installed.

It would be nice if vmdb2 can make UEFI secure bootable image.

Best regards, Ryutaroh Matsumoto



Bug#973756: Acknowledgement (firejail: fcopy fails to load libpcre2-8.so.0 when running transmission-daemon)

2020-11-04 Thread Mad Horse
Currently transmission-gtk could be run with firejail, and I can use 
transmission-gtk's profile to run transmission-daemon, customized with 
such transmission-gtk.local:



private-bin transmission-daemon
noblacklist ${HOME}/.config/transmission-daemon
whitelist ${HOME}/.config/transmission-daemon




Bug#973780: autopkgtest: support of UEFI secure boot in autopkgtest-virt-qemu

2020-11-04 Thread Ryutaroh Matsumoto
Package: autopkgtest
Version: 5.15
Severity: wishlist

Dear Maintainer,

Currently, Linux kernel in the autopkgtest-virt-qemu runs in
unsecure (unlocked) mode. If it is booted in UEFI secure boot,
the kernel is locked down. It should help exposing unnoticed bugs
in the UEFI secure boot. 

To enable secure boot of a QEMU guest, e.g. for i386, one has to

1. Install grub-efi-ia32 grub-efi-ia32-signed and shim-signed to the testbed.
2. Use OVMF_CODE_4M.ms.fd and OVMF_VARS_4M.ms.fd as UEFI (OVMF) ROM.
3. Start qemu-system-i386 with 
   -machine q35,smm=on -global driver=cfi.pflash01,property=secure,value=on

With the above procedure, the kernel in QEMU guest is locked down
(I verified it with dmesg).

Best regards, Ryutaroh Matsumoto

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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   2.1.11
ii  libdpkg-perl1.20.5
ii  procps  2:3.3.16-5
ii  python3 3.8.2-3
ii  python3-debian  0.1.38

Versions of packages autopkgtest recommends:
ii  autodep8  0.24

Versions of packages autopkgtest suggests:
pn  lxc   
pn  lxd   
ii  ovmf  2020.08-1
ii  qemu-efi-aarch64  2020.08-1
ii  qemu-efi-arm  2020.08-1
ii  qemu-system   1:5.1+dfsg-4+b1
ii  qemu-utils1:5.1+dfsg-4+b1
pn  schroot   
ii  vmdb2 0.19-1

-- no debconf information



Bug#973779: ITP: fonts-sil-scheherazadenew -- Arabic script font designed in the traditional Naskh style

2020-11-04 Thread Bobby de Vos
Package: wnpp
Version N/A; reported 2020-11-04
Severity: wishlist

Greetings,

My team at SIL-WSTech is about to released a font not in Debian,
Scheherazade New, that I would like to package for Debian.

Package name: fonts-sil scheherazadenew
Version : 3.000
Upstream Author : SIL WSTech 
URL : https://software.sil.org/scheherazade/
License : OFL-1.1
Section : fonts
Description : Arabic script font designed in the traditional Naskh style

Scheherazade New, named after the heroine of the classic Arabian Nights
tale, is designed in a similar style to traditional typefaces such as
Monotype Naskh, extended to cover the full Unicode Arabic repertoire.

The goal for this product is to provide a single Unicode-based font
family that contains a comprehensive inventory of glyphs needed for
almost any Arabic-based writing system. This font makes use of
state-of-the-art font technologies to support complex typographic issues.

This font provides a simplified rendering of Arabic script, using basic
connecting glyphs but not including a wide variety of additional
ligatures or contextual alternates (only the required lam-alef
ligatures). This simplified style is often preferred for clarity,
especially in non-Arabic languages, but may be considered unattractive
in more traditional and  literate communities.

Two fonts from this typeface family are included in this release:

 * Scheherazade New Regular
 * Scheherazade New Bold

This release supports virtually all of the Unicode 13.0 Arabic character
repertoire (excluding the Arabic Presentation Forms blocks, which are
not recommended for normal use). Font smarts are implemented using OpenType
and Graphite technologies.

It builds those binary packages:

fonts-sil-scheherazadenew - Arabic script font designed in the
traditional Naskh style

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

https://software.sil.org/scheherazade/

Fabian Greffrath or Daniel Glassey can sponsor this package.

Debian already has the Scheherazade font in the package
fonts-sil-scheherazade. While the new font is an update from the old
font, the sizing of the characters has changed, which would change the
layout of existing documents. Therefore, a new package is proposed.

Regards,
Bobby

-- 
Bobby de Vos
/bobby_de...@sil.org/



signature.asc
Description: OpenPGP digital signature


Bug#973773: libraries in kde?

2020-11-04 Thread Ivan Sergio Borgonovo
I just updated from testing to unstable several qt and kde libraries and 
now kwallet seems to work even with subversion 1.14.0-3.


This is the pretty long list of the packages that were updated from 
testing to unstable.


[UPGRADE] akonadi-backend-sqlite:amd64 4:20.08.2-3 -> 4:20.08.2-3+b1
[UPGRADE] akonadi-server:amd64 4:20.08.2-3 -> 4:20.08.2-3+b1
[UPGRADE] appmenu-gtk-module-common:amd64 0.7.5-1 -> 0.7.6-1
[UPGRADE] appmenu-gtk2-module:amd64 0.7.5-1 -> 0.7.6-1
[UPGRADE] appmenu-gtk3-module:amd64 0.7.5-1 -> 0.7.6-1
[UPGRADE] appmenu-registrar:amd64 0.7.5-1 -> 0.7.6-1
[UPGRADE] bash:amd64 5.1~rc1-2 -> 5.1~rc2-1
[UPGRADE] fcitx-frontend-qt5:amd64 1.2.5-1 -> 1.2.5-1+b1
[UPGRADE] gir1.2-pango-1.0:amd64 1.46.2-1 -> 1.46.2-2
[UPGRADE] ifupdown:amd64 0.8.35+b1 -> 0.8.36
[UPGRADE] installation-report:amd64 2.75 -> 2.76
[UPGRADE] iw:amd64 5.9-2 -> 5.9-3
[UPGRADE] kde-style-qtcurve-qt5:amd64 1.9-7 -> 1.9-7+b1
[UPGRADE] kget:amd64 4:20.08.1-1 -> 4:20.08.2-1
[UPGRADE] kicad:amd64 5.1.7+dfsg1-1 -> 5.1.8+dfsg1-1
[UPGRADE] kicad-demos:amd64 5.1.7+dfsg1-1 -> 5.1.8+dfsg1-1
[UPGRADE] kicad-libraries:amd64 5.1.7+dfsg1-1 -> 5.1.8+dfsg1-1
[UPGRADE] krfb:amd64 4:20.08.1-2 -> 4:20.08.2-1
[UPGRADE] kwin-common:amd64 4:5.17.5-3 -> 4:5.17.5-4
[UPGRADE] kwin-data:amd64 4:5.17.5-3 -> 4:5.17.5-4
[UPGRADE] kwin-wayland:amd64 4:5.17.5-3 -> 4:5.17.5-4
[UPGRADE] kwin-wayland-backend-drm:amd64 4:5.17.5-3 -> 4:5.17.5-4
[UPGRADE] kwin-wayland-backend-wayland:amd64 4:5.17.5-3 -> 4:5.17.5-4
[UPGRADE] kwin-wayland-backend-x11:amd64 4:5.17.5-3 -> 4:5.17.5-4
[UPGRADE] kwin-x11:amd64 4:5.17.5-3 -> 4:5.17.5-4
[UPGRADE] libanalitza8:amd64 4:20.08.0-1 -> 4:20.08.0-1+b1
[UPGRADE] libanalitzagui8:amd64 4:20.08.0-1 -> 4:20.08.0-1+b1
[UPGRADE] libanalitzaplot8:amd64 4:20.08.0-1 -> 4:20.08.0-1+b1
[UPGRADE] libanalitzawidgets8:amd64 4:20.08.0-1 -> 4:20.08.0-1+b1
[UPGRADE] libappmenu-gtk2-parser0:amd64 0.7.5-1 -> 0.7.6-1
[UPGRADE] libappmenu-gtk3-parser0:amd64 0.7.5-1 -> 0.7.6-1
[UPGRADE] libepsilon1:amd64 0.9.2+dfsg-4+b1 -> 0.9.2+dfsg-5
[UPGRADE] libevdev2:amd64 1.9.1+dfsg-1 -> 1.10.0+dfsg-1
[UPGRADE] libfcitx-qt5-1:amd64 1.2.5-1 -> 1.2.5-1+b1
[UPGRADE] libfm-qt6:amd64 0.14.1-12.2 -> 0.14.1-12.2+b1
[UPGRADE] libhidapi-hidraw0:amd64 0.9.0+dfsg-1 -> 0.10.0+dfsg-1
[UPGRADE] libidn2-0:amd64 2.3.0-1 -> 2.3.0-2
[UPGRADE] libkf5akonadiagentbase5:amd64 4:20.08.2-3 -> 4:20.08.2-3+b1
[UPGRADE] libkf5akonadicore5abi2:amd64 4:20.08.2-3 -> 4:20.08.2-3+b1
[UPGRADE] libkf5akonadiprivate5abi2:amd64 4:20.08.2-3 -> 4:20.08.2-3+b1
[UPGRADE] libkf5akonadiwidgets5abi1:amd64 4:20.08.2-3 -> 4:20.08.2-3+b1
[UPGRADE] libkf5akonadixml5:amd64 4:20.08.2-3 -> 4:20.08.2-3+b1
[UPGRADE] libkf5xmlgui-bin:amd64 5.74.0-2 -> 5.74.0-2+b1
[UPGRADE] libkf5xmlgui5:amd64 5.74.0-2 -> 5.74.0-2+b1
[UPGRADE] libkwin4-effect-builtins1:amd64 4:5.17.5-3 -> 4:5.17.5-4
[UPGRADE] libkwineffects12:amd64 4:5.17.5-3 -> 4:5.17.5-4
[UPGRADE] libkwinglutils12:amd64 4:5.17.5-3 -> 4:5.17.5-4
[UPGRADE] libkwinxrenderutils12:amd64 4:5.17.5-3 -> 4:5.17.5-4
[UPGRADE] libmlt6:amd64 1:6.22.1-dmo1 -> 1:6.22.1-dmo2
[UPGRADE] libnetcdf-c++4:amd64 4.2-11+b3 -> 4.2-12
[UPGRADE] libpango-1.0-0:amd64 1.46.2-1 -> 1.46.2-2
[UPGRADE] libpango1.0-0:amd64 1.46.2-1 -> 1.46.2-2
[UPGRADE] libpangocairo-1.0-0:amd64 1.46.2-1 -> 1.46.2-2
[UPGRADE] libpangoft2-1.0-0:amd64 1.46.2-1 -> 1.46.2-2
[UPGRADE] libpangoxft-1.0-0:amd64 1.46.2-1 -> 1.46.2-2
[UPGRADE] libpipewire-0.3-0:amd64 0.3.12-1 -> 0.3.14-1
[UPGRADE] libpoppler-cpp0v5:amd64 20.09.0-2 -> 20.09.0-3
[UPGRADE] libpoppler-glib8:amd64 20.09.0-2 -> 20.09.0-3
[UPGRADE] libpoppler-qt5-1:amd64 20.09.0-2 -> 20.09.0-3
[UPGRADE] libpoppler102:amd64 20.09.0-2 -> 20.09.0-3
[UPGRADE] libpopt0:amd64 1.18-1 -> 1.18-2
[UPGRADE] libproj19:amd64 7.1.1-1 -> 7.2.0-1
[UPGRADE] libqt53danimation5:amd64 5.14.2+dfsg-2 -> 5.15.1+dfsg-3
[UPGRADE] libqt53dcore5:amd64 5.14.2+dfsg-2 -> 5.15.1+dfsg-3
[UPGRADE] libqt53dinput5:amd64 5.14.2+dfsg-2 -> 5.15.1+dfsg-3
[UPGRADE] libqt53dlogic5:amd64 5.14.2+dfsg-2 -> 5.15.1+dfsg-3
[UPGRADE] libqt53drender5:amd64 5.14.2+dfsg-2 -> 5.15.1+dfsg-3
[UPGRADE] libqt5bluetooth5:amd64 5.14.2-2 -> 5.15.1-2
[UPGRADE] libqt5bluetooth5-bin:amd64 5.14.2-2 -> 5.15.1-2
[UPGRADE] libqt5concurrent5:amd64 5.14.2+dfsg-6 -> 5.15.1+dfsg-2
[UPGRADE] libqt5core5a:amd64 5.14.2+dfsg-6 -> 5.15.1+dfsg-2
[UPGRADE] libqt5dbus5:amd64 5.14.2+dfsg-6 -> 5.15.1+dfsg-2
[UPGRADE] libqt5designer5:amd64 5.14.2-3 -> 5.15.1-2
[UPGRADE] libqt5designercomponents5:amd64 5.14.2-3 -> 5.15.1-2
[UPGRADE] libqt5gui5:amd64 5.14.2+dfsg-6 -> 5.15.1+dfsg-2
[UPGRADE] libqt5help5:amd64 5.14.2-3 -> 5.15.1-2
[UPGRADE] libqt5multimedia5:amd64 5.14.2-3 -> 5.15.1-2
[UPGRADE] libqt5multimedia5-plugins:amd64 5.14.2-3 -> 5.15.1-2
[UPGRADE] libqt5multimediagsttools5:amd64 5.14.2-3 -> 5.15.1-2
[UPGRADE] libqt5multimediaquick5:amd64 5.14.2-3 -> 5.15.1-2
[UPGRADE] libqt5multimediawidgets5:amd64 5.14.2-3 -> 5.15.1-2
[UPGRADE] libqt5network5:amd64 5.14.2+dfsg-6 -> 5.15.1+dfsg-2
[UPGRADE] libqt5networkauth5:amd64 5.14.2-2 -> 5.15.1-2

Bug#973080: can't reproduce, see my sbuild (was: Bug#973080: cool-retro-term: FTBFS: Error setting permissions on /<>/debian/tmp/usr/lib/x86_64-linux-gnu/qt5/qml/QMLTermWidget/color-schem

2020-11-04 Thread Axel Beckert
Control: reopen -1
Control: retitle -1 cool-retro-term: Intermittently FTBFS with parallel builds: 
Error setting permissions on  
/<>/debian/tmp/usr/lib/x86_64-linux-gnu/qt5/qml/QMLTermWidget/color-schemes/historic/DarkPicture.schema:
 No such file or directory
Control: severity -1 important

Hi,

Gürkan Myczko schrieb am Wed, Nov 04, 2020 at 02:46:52PM +0100:
> Thanks for your report but I can't reproduce it anymore:
> http://phd-sid.ethz.ch/debian/cool-retro-term/2424/

I still can reproduce it in pbuilder with "pdebuild --debbuildopts
-j32" — but not always, only when building in parallel and even then
just about half of the time:

* I tried building it four times with "pdebuild --debbuildopts
  -j32" and it FTBFS two times.

* I tried building it four times with "pdebuild --debbuildopts
  -j1" and it never FTBFS.

* I tried building it two times with "debuild -uc -us -j64 -b" and it
  FTBFS once.

So I assume this issue is a race condition which solely happens under
parallel builds and then approximately with a 50% chance. Probably an
issue in the upstream build system.

Accordingly one temporary workaround would be to disable parallel
builds for now until the race condition has been found and fixed.

> Thus closing the bug report.

Hence reopening it, but downgrading to important.

Lucas: Feel free to bump the severity again to RC in case you think,
that's still RC.

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



Bug#973778: rust-nitrokey-sys: unsatifiable B-D: librust-bindgen-0.51+default-dev

2020-11-04 Thread Andreas Beckmann
Source: rust-nitrokey-sys
Version: 3.5.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

rust-nitrokey-sys/experimental cannot be built any more since its
B-D: librust-bindgen-0.51+default-dev is no longer available.


Andreas



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

2020-11-04 Thread Daniel Leidert
Am Mittwoch, den 04.11.2020, 10:38 -0300 schrieb Antonio Terceiro:
> On Wed, Nov 04, 2020 at 03:45:34AM +0100, Daniel Leidert wrote:

[ruby-launcher-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.
> 
> when I wrote ruby-launchy-shim, I did it because launchy itself had a
> lot of dependencies, and most if code, just to support other non-Debian
> systems. I don't remember exactly but there was probably other
> compliation that make it so it was easier for me to just write a shim
> that has the same API as the original package and does what is needed on
> Debian.

It now has only one dependency (ruby-addressable).

> I don't really care what happens; if you decide to drop it and replace
> with the real launchy, feel free to go ahead.

I added Provides and Replaces/Breaks fields to ruby-lauchy so both packages can
coexist. 

> Just note that there are a few packages that explicitly depend on -shim:
> 
> $ reverse-depends ruby-launchy-shim
> Reverse-Depends
> * ruby-email-spec
> * ruby-letter-opener

I just built them successfully with ruby-launchy. So maybe we can drop ruby-
launchy-shim in the future.

Regards, Daniel
-- 
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#973777: aravis: new upstream version

2020-11-04 Thread Bastian Germann
Package: aravis
Severity: normal

There is a new release 0.8.2 available at
https://download.gnome.org/sources/aravis/

It is not tagged on GitHub yet, so uscan will not find it.
Please consider changing the watch file to the mentioned location.



Bug#972552: closed by Debian FTP Masters (reply to Julian Andres Klode ) (Bug#972552: fixed in apt 2.1.11)

2020-11-04 Thread Julian Andres Klode
On Thu, Nov 05, 2020 at 12:20:23AM +0200, Otto Kekäläinen wrote:
> Hello!
> 
> I am still seeing this error with latest apt 2.1.11. Should I reopen
> this bug or file a new one?

I know. I haven't made up my mind yet.

There are a ton of issues in that area, and it's entirely possible
we won't make any progress by the bulleye release time, as the code
is very fragile, and this can easily end up breaking stuff.

Like I thought disabling immediate configuration fixes those issues
only to get pointed out a case where disabling immediate configuration
makes it worse.

So, um, yeah, it's complicated, and I'm afraid that at least for
me I might end up having to work on some more urgent stuff before
getting back to this fully.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en



Bug#972552: closed by Debian FTP Masters (reply to Julian Andres Klode ) (Bug#972552: fixed in apt 2.1.11)

2020-11-04 Thread Adam D. Barratt
On Thu, 2020-11-05 at 00:20 +0200, Otto Kekäläinen wrote:
> Hello!
> 
> I am still seeing this error with latest apt 2.1.11. Should I reopen
> this bug or file a new one?

fwiw I have no particular insight in to this bug, I simply replied to
your earlier message because I happened to be aware of what was keeping
2.1.11 out of the archive for a while. So do feel free to stop CCing
me. :-) (I do also follow the deity@ list.)

Regards,

Adam



Bug#973776: relion-cuda: undeclared build-depends

2020-11-04 Thread Andreas Beckmann
Source: relion-cuda
Version: 3.1.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

relion-cuda cannot be built due to some undeclared builds-depends:

CMake Error at /usr/lib/fltk/FLTK-Targets.cmake:99 (message):
  The imported target "fluid" references the file

 "/usr/bin/fluid"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 "/usr/lib/fltk/FLTK-Targets.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /usr/lib/fltk/FLTKConfig.cmake:21 (include)
  /usr/share/cmake-3.18/Modules/FindFLTK.cmake:157 (include)
  CMakeLists.txt:293 (FIND_PACKAGE)


-- Configuring incomplete, errors occurred!


Regarding the B-D: nvidia-cuda-toolkit
* please use nvidia-cuda-toolkit-gcc instead of nvidia-cuda-toolkit
* and use CC=cuda-gcc CXX=cuda-g++ instead of CC=gcc-8 CXX=g++-8
  s.t. the package automatically adjusts to newer cuda releases
  supporting newer compilers.
* and switch to Architecture: any instead of hardcoding a list
  s.t. the package is buildable on all architectures that have
  nvidia-cuda-toolkit available. (There is no need to also upload
  binary packages for non-amd64).
  

Andreas


relion-cuda_3.1.0-1.log.gz
Description: application/gzip


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

2020-11-04 Thread Hilmar Preuße


Control: tags -1 + pending

Am 04.11.2020 um 03:55 teilte Joachim Zobel mit:

Hi,


This is easy to reproduce:


Solved on github. Tag pending.

H.
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature


Bug#972552: closed by Debian FTP Masters (reply to Julian Andres Klode ) (Bug#972552: fixed in apt 2.1.11)

2020-11-04 Thread Otto Kekäläinen
Hello!

I am still seeing this error with latest apt 2.1.11. Should I reopen
this bug or file a new one?

https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1136277
https://salsa.debian.org/mariadb-team/galera-4/-/jobs/1126619

E: Could not configure 'libc6:amd64'.
343E: Could not perform immediate configuration on 'libcrypt1:amd64'.
Please see man 5 apt.conf under APT::Immediate-Configure for details.
(2)
344E: Could not configure 'libc6:amd64'.
345E: Could not perform immediate configuration on 'libtirpc3:amd64'.
Please see man 5 apt.conf under APT::Immediate-Configure for details.
(2)
346E: Could not configure 'libc6:amd64'.
347E: Could not perform immediate configuration on 'libnsl2:amd64'.
Please see man 5 apt.conf under APT::Immediate-Configure for details.
(2)
348E: Could not configure 'libc6:amd64'.
349E: Could not perform immediate configuration on 'libnss-nis:amd64'.
Please see man 5 apt.conf under APT::Immediate-Configure for details.
(2)

On Thu, 29 Oct 2020 at 19:26, Otto Kekäläinen  wrote:
>
> Hello!
>
> I am still seeing this error with latest apt 2.1.11:
>
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1117112
>
> E: Could not configure 'libc6:amd64'.
> W: Could not perform immediate configuration on 'libnss-nis:amd64'.
> Please see man 5 apt.conf under APT::Immediate-Configure for details.
> (2)



Bug#957503: lpe: diff for NMU version 1.2.8-2.1

2020-11-04 Thread Sudip Mukherjee
Control: tags 957503 + patch
Control: tags 957503 + pending
--

Dear maintainer,

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

--
Regards
Sudip

diff -Nru lpe-1.2.8/debian/changelog lpe-1.2.8/debian/changelog
--- lpe-1.2.8/debian/changelog  2016-01-31 04:40:15.0 +
+++ lpe-1.2.8/debian/changelog  2020-11-04 22:05:00.0 +
@@ -1,3 +1,10 @@
+lpe (1.2.8-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957503)
+
+ -- Sudip Mukherjee   Wed, 04 Nov 2020 22:05:00 
+
+
 lpe (1.2.8-2) unstable; urgency=medium
 
   * Fix too specific paths in dh_install file
diff -Nru lpe-1.2.8/debian/patches/fix_gcc-10.patch 
lpe-1.2.8/debian/patches/fix_gcc-10.patch
--- lpe-1.2.8/debian/patches/fix_gcc-10.patch   1970-01-01 01:00:00.0 
+0100
+++ lpe-1.2.8/debian/patches/fix_gcc-10.patch   2020-11-04 22:02:08.0 
+
@@ -0,0 +1,29 @@
+Description: Fix ftbfs with GCC-10
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/957503
+Forwarded: no
+
+---
+
+--- lpe-1.2.8.orig/src/lpe.c
 lpe-1.2.8/src/lpe.c
+@@ -25,6 +25,8 @@
+ #include "strfuncs.h"
+ #include "exports.h"
+ 
++char *LPE_CONFIG_FILE;
++
+ /* A flag indicating a desire to quit the editor.  This is set whenever a
+  * command should cause an exit.
+  */
+--- lpe-1.2.8.orig/src/options.h
 lpe-1.2.8/src/options.h
+@@ -38,6 +38,6 @@
+ /*
+  * Other things that are used in some places...
+  */
+-char *LPE_CONFIG_FILE;
++extern char *LPE_CONFIG_FILE;
+ 
+ #endif /* LPE_OPTIONS_H */
diff -Nru lpe-1.2.8/debian/patches/series lpe-1.2.8/debian/patches/series
--- lpe-1.2.8/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ lpe-1.2.8/debian/patches/series 2020-11-04 22:01:26.0 +
@@ -0,0 +1 @@
+fix_gcc-10.patch



Bug#973772: Acknowledgement (Support filter syntax 'storage/*/debian/*' to only filter debian folder at that path, not root debian/)

2020-11-04 Thread Otto Kekäläinen
While looking deeper it might be that there is some kind of "caching"
going on and a previously filtered source file is re-used and thus the
changed gbp import-orig filter settings don't always take effect.

Also, when doing this I might be required to rename the sources to
~dfsg, so I need to take a step back and rethink my approach here.



Bug#973775: licensecheck returns incorrect license

2020-11-04 Thread Sandro Mani

Package: licensecheck
Version: 3.1.1

I'm reporting this downstream issue [1], for your evaluation:

Description of problem:

$ licensecheck COPYING
COPYING: Expat License GNU Lesser General Public License, Version 3

Perhaps a bit of a pathological case.

Version-Release number of selected component (if applicable):
licensecheck-3.1.1-3.fc33.noarch
perl-Regexp-Pattern-License-3.4.0-3.fc33.noarch


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1866603

DMTCP (and the included MTCP) is free software; you can redistribute it
and/or modify it under the terms of the GNU Lesser General Public License
(LGPL) as published by the Free Software Foundation; either version 3 of the
License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of  MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public License
for more details.

A copy of the LGPL license is contained in the COPYING.LESSER file.

The file include/dmtcp.h is released under MIT/BSD dual license. The user is
allowed to use these files under either license.

Files found in the directory src are Copyright (C) 2006-2014 by Jason
Ansel, Kapil Arya, and Gene Cooperman, except:
- files src/trampolines.* are Copyright (C) 2006-2013 by Tyler Denniston, and
  Kapil Arya
- files plugin/ipc/event/eventwrappers.* are Copyright (C) 2012 by Kapil Arya,
  Gene Cooperman and Rohan Garg.

Files src/mtcp/mtcp_sys.h and src/mtcp/mtcp_util.ic are Copyright (C) 2006-2014 
by Michael Rieker, Gene Cooperman, and Kapil Arya.

Files found in the directory src/jalib are Copyright (C) 2005-2008 by Jason 
Ansel.

Files found in the directory jalib are Copyright (C) 2005-2008 by Jason Ansel.

The contents of files src/mtcp/sysdep-*, src/mtcp/NOTES-x86_64/*.[hS] and
src/glibcsystem.cpp are taken from glibc and is Copyright (C)
1991-2000,2002,2003,2005,2007 Free Software Foundation, Inc.

The contents of the file include/dmtcpalloc.h are Copyright (C) 2002 by
Pete Isensee.

Files found in the directory plugin/ptrace are Copyright (C) 2005-2013 by
Ana-Maria Visan, Kapil Arya, and Gene Cooperman.

Files found in the directory plugin/batch-queue are Copyright (C) 2012-2013 by
Artem Y. Polyakov.

Files found in a subdirectory of the contrib directory are Copyright (C) by the
author of that subdirectory.

File test/syscall-tester.c is Copyright (C) Copyright (C) 1990-2007, Condor
Team, Computer Sciences Department, University of Wisconsin-Madison, WI.

Any remaining files (for building and testing) are Copyright (C) 2006-2008,
2012-2013 Jason Ansel, Kapil Arya, and Gene Cooperman.


Bug#973774: lazpaint: copyright file incorrect

2020-11-04 Thread Joerg Jaspert

Package: lazpaint
Severity: normal

Dear Maintainer,

please fix your copyright file, the whole bgrabitmap subdir is not plain 
LGPL, but with a linking exception added. Please include that 
information.


Thanks.

--
bye, Joerg



Bug#834724:

2020-11-04 Thread Maris Cinis
maris


Bug#973759: lintian: False positive: debian-changelog-file-is-a-symlink matches on upstream changelog

2020-11-04 Thread Felix Lechner
Hi Andreas,

On Wed, Nov 4, 2020 at 9:15 AM Andreas Metzler  wrote:
>
> However the Debian changelog file is not a symlink, only the upstream
> one.

Unfortunately, Lintian cannot tell from an installation package
(*.deb) whether it was built from a native source package. Possible
solutions are:

1. Via policy, prescribe a constant basename for Debian changelogs,
regardless of "nativeness".
2. In installation packages, add information about nativeness to the
control files in DEBIAN/.

Kind regards
Felix Lechner



Bug#973773: lost support with kwallet

2020-11-04 Thread Ivan Sergio Borgonovo

Package: subversion
Version: 1.14.0-3

upgrading from 1.14.0-2+b1 svn can't use kwallet.

It keeps asking for the password.

Downgrading subversion and libsvn1 things work as usual.

thanks

--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net



Bug#973772: Support filter syntax 'storage/*/debian/*' to only filter debian folder at that path, not root debian/

2020-11-04 Thread Otto Kekäläinen
Package: git-buildpackage
Version: 0.9.19-1
Severity: normal

While packaging MariaDB 10.5 I tried to filter out excess debian
folders from upstream sources at paths storage/maria/libmarias3/debian
and 
storage/mroonga/vendor/groonga/vendor/plugins/groonga-normalizer-mysql/packages/debian.

To do this I defined 'storage/*/debian*' as a filter rule in gbp.conf.

While running 'gbp import-orig' there was:

gbp:debug: tar ['--exclude=CVS', '--exclude=*.bak', '--exclude=*~',
'--exclude=.cvsignore', '--exclude=.#*', '--exclude=autom4te/*',
'--exclude=autom4te.cache/*', '--exclude=.svn',
'--exclude=storage/*/debian/*', '--exclude=extra/readline/*',
'--exclude=extra/wolfssl/*', '--exclude=storage/columnstore/*', '-C',
'../tmppvw2f6wv', '-a', '-xf', '../mariadb-10.5_10.5.7.orig.tar.gz']
[]

However, in the resulting upstream branch gbp ends up deleting all
*/debian/* paths, including the actual root debian/ folder, which was
not the intent:

git show --stat
...
 debian/additions/debian-start  |48 -
 debian/additions/debian-start.inc.sh   |79 -
 debian/additions/echo_stderr   | 2 -
 debian/additions/innotop/changelog.innotop |   441 -
 debian/additions/innotop/innotop   |
12249 
 debian/additions/innotop/innotop.1 |  2200 --
 debian/additions/mariadb-report|  1597 -
 debian/additions/mariadb-report.1  |   180 -
 debian/additions/mariadb.cnf   |29 -
 debian/additions/mariadb.conf.d/50-client.cnf  |19 -
 debian/additions/mariadb.conf.d/50-mysql-clients.cnf   |22 -
 debian/additions/mariadb.conf.d/50-mysqld_safe.cnf |28 -
...
etc


I would like to keep:
debian/*

But remove:
storage/maria/libmarias3/debian/*
storage/mroonga/vendor/groonga/vendor/plugins/groonga-normalizer-mysql/packages/debian/*

Using the filter rule exclude=storage/*/debian/*' did not achieve this.



Bug#962430: marked as done (ebook2cw FTCBFS: strips with the build architecture strip)

2020-11-04 Thread Christoph Berg
Hi,

are you interested in putting the package into the
debian-hamradio-maintainers group on salsa?

73,
Christoph DF7CB



Bug#973771: RM: r-cran-sem [armel] -- RoQA; arch:all dependency not installable on armel

2020-11-04 Thread Paul Gevers
Package: ftp.debian.org
X-Debbugs-Cc: r-cran-...@packages.debian.org
Severity: normal

Dear ftp-masters,

r-cran-sem has a dependency on r-cran-arm (arch:all). The latter package
recently gained a dependency on r-cran-hmisc which is not available on
armel, because it requires nodejs to build. As r-cran-sem is not
installable, I suggest to remove it. r-cran-sem can't be built again on
armel because it Build-Depends on r-cran-mi (arch:all) which has a
dependency on r-cran-arm too.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#954273: simka: arm64 autopkgtest time out

2020-11-04 Thread Bernhard Übelacker
Dear Maintainer,
I tried to have a look at this hanging test and could
reproduce a hang at this backtrace [1].

The loop in [2] gets not left because the result of the fgetc call
gets stored in a variable of type char and later compared to EOF.
It seems to be an issue with not being explicit
about signed/unsigned char with this variable.

At least using the type int makes the test finish and pass,
when libgatbcore3 is built with attached patch.

Kind regards,
Bernhard


[1]
(gdb) bt
#0  gatb::core::system::impl::CommonFile::gets (this=0x55839ffbb0, 
s=, size=) at 
./gatb-core/src/gatb/system/impl/FileSystemCommon.hpp:103
#1  0x0076c633ee38 in gatb::core::bank::impl::BankAlbum::BankAlbum 
(this=this@entry=0x55839fc860, 
name="/tmp/autopkgtest.iSjXKJ/autopkgtest_tmp/simka_temp_output/simka_output_temp//input/A",
 deleteIfExists=deleteIfExists@entry=false, __in_chrg=, 
__vtt_parm=) at ./gatb-core/src/gatb/bank/impl/BankAlbum.cpp:64
#2  0x0076c633f6a4 in 
gatb::core::bank::impl::BankAlbumFactory::createBank (this=, 
uri="/tmp/autopkgtest.iSjXKJ/autopkgtest_tmp/simka_temp_output/simka_output_temp//input/A")
 at ./gatb-core/src/gatb/bank/impl/BankAlbum.cpp:343
#3  0x0076c633c1a8 in gatb::core::bank::impl::Bank::_open_ 
(this=this@entry=0x555bb42388 
, 
uri="/tmp/autopkgtest.iSjXKJ/autopkgtest_tmp/simka_temp_output/simka_output_temp//input/A")
 at ./gatb-core/src/gatb/bank/impl/Bank.cpp:150
#4  0x00555bb0b704 in gatb::core::bank::impl::Bank::open 
(uri="/tmp/autopkgtest.iSjXKJ/autopkgtest_tmp/simka_temp_output/simka_output_temp//input/A")
 at /usr/include/gatb/bank/impl/Bank.hpp:135
#5  SimkaAlgorithm<32ul>::isInputValid (this=0x7fd3195140) at 
/build/simka-C4DX5D/simka-1.5.2/src/core/SimkaAlgorithm.cpp:362
#6  0x00555baf9264 in SimkaPotaraAlgorithm<32ul>::execute 
(this=0x7fd3195140) at /build/simka-C4DX5D/simka-1.5.2/src/SimkaPotara.hpp:413
#7  0x00555badc9e4 in Functor<32ul>::operator() (this=, 
p=...) at /build/simka-C4DX5D/simka-1.5.2/src/SimkaPotara.cpp:111
#8  
gatb::core::tools::math::IntegerTemplate, 
mpl_::int_<64>, mpl_::int_<96>, mpl_::int_<128> > >::Apply, mpl_::int_<64>, mpl_::int_<96>, 
mpl_::int_<128> >, false>::execute (params=..., kmerSize=) at 
/usr/include/gatb/tools/math/Integer.hpp:463
#9  
gatb::core::tools::math::IntegerTemplate, 
mpl_::int_<64>, mpl_::int_<96>, mpl_::int_<128> > >::apply 
(params=..., kmerSize=) at 
/usr/include/gatb/tools/math/Integer.hpp:84
#10 SimkaPotara::execute (this=) at 
/build/simka-C4DX5D/simka-1.5.2/src/SimkaPotara.cpp:140
#11 0x0076c6428020 in gatb::core::tools::misc::impl::Tool::run 
(this=0x7fd31955d8, input=) at 
./gatb-core/src/gatb/tools/misc/impl/Tool.cpp:158
#12 0x0076c64277c8 in gatb::core::tools::misc::impl::Tool::run 
(this=0x7fd31955d8, argc=7, argv=0x7fd3195848) at 
./gatb-core/src/gatb/tools/misc/impl/Tool.cpp:112
#13 0x00555bad97bc in main (argc=7, argv=0x7fd3195848) at 
/usr/include/c++/10/ext/new_allocator.h:79


[2] 
https://sources.debian.org/src/gatb-core/1.4.2+dfsg-5/gatb-core/src/gatb/system/impl/FileSystemCommon.hpp/#L103

Description: Use int as return of fgetc

Author: Bernhard Übelacker 
Bug-Debian: https://bugs.debian.org/954273
Forwarded: no
Last-Update: 2020-11-03

Index: gatb-core-1.4.2+dfsg/gatb-core/src/gatb/system/impl/FileSystemCommon.hpp
===
--- gatb-core-1.4.2+dfsg.orig/gatb-core/src/gatb/system/impl/FileSystemCommon.hpp
+++ gatb-core-1.4.2+dfsg/gatb-core/src/gatb/system/impl/FileSystemCommon.hpp
@@ -100,7 +100,7 @@ public:
 result = strlen (tmp);
 
 /** we skip all characters until we reach the next '\n'. */
-if (result > 0)  {  for (char c = tmp[result-1];  c !='\n' &&  c!=EOF;  c = fgetc (getHandle()))  {}  }
+if (result > 0)  {  for (int c = tmp[result-1];  c !='\n' &&  c!=EOF;  c = fgetc (getHandle()))  {}  }
 }
 
 /** We return the result. */


# Unstable chroot 2020-11-03 running on Android/LineageOS kernel


root@localhost:~# lscpu
Architecture: aarch64
CPU op-mode(s):   32-bit, 64-bit
Byte Order:   Little Endian
CPU(s):   8
On-line CPU(s) list:  4,5
Off-line CPU(s) list: 0-3,6,7
Thread(s) per core:   1
Core(s) per socket:   2
Socket(s):1
Vendor ID:ARM
Model:1
Model name:   Cortex-A53
Stepping: r0p1
CPU max MHz:  1113,6000
CPU min MHz:  249,6000
Flags:fp asimd evtstrm aes pmull sha1 sha2 crc32
root@localhost:~# uname -a
Linux localhost 3.10.108-g5285e19 #1 SMP PREEMPT Fri Oct 26 18:55:56 CEST 2018 
aarch64 GNU/Linux


apt update
apt dist-upgrade


apt install mc htop psmisc net-tools strace quilt autopkgtest gdb valgrind 
simka simkamin simka-dbgsym libgatbcore3-dbgsym
apt build-dep simka
apt build-dep gatb-core




mkdir /home/media_rw/source/libgatbcore3/orig -p
cd

Bug#973770: cimg: CVE-2020-25693

2020-11-04 Thread Salvatore Bonaccorso
Source: cimg
Version: 2.8.4+dfsg-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/dtschump/CImg/pull/295
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for cimg.

CVE-2020-25693[0]

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-25693
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25693
[1] https://github.com/dtschump/CImg/pull/295
[2] https://bugs.launchpad.net/ubuntu/+source/cimg/+bug/1900983
[3] 
https://github.com/dtschump/CImg/commit/4f184f89f9ab6785a6c90fd238dbaa6d901d3505

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#970643: "pytest" command is missing

2020-11-04 Thread Novy, Ondrej
Hi,

Antonio Terceiro píše v St 04. 11. 2020 v 14:01 -0300:
> Could you ellaborate? Maybe we should have a discussion in the Pythonteam so
> that we implement consistent practices. For example, `gunicorn`and `pip` now
> point to their python3 versions, but you are saying thatpytest will not do
> that, what maybe creates more confusion given Debianbullseye will not support
> any other Python.

"pytest" in buster now points to python2 version of pytest and "pytest-3" points
to python3 version. To prevent confusion after upgrade I want to keep one stable
release with pytest cmd "unoccupied" and keep pytest-3.

Bullseye will support Python2 interpreter so user can keep python-pytest package
installed from buster.


-- 
Best regards Ondřej Nový



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


Bug#973769: spice-vdagent: CVE-2020-25650 CVE-2020-25651 CVE-2020-25652 CVE-2020-25653

2020-11-04 Thread Salvatore Bonaccorso
Source: spice-vdagent
Version: 0.20.0-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for spice-vdagent.

CVE-2020-25650[0]:
| Memory DoS via Arbitrary Entries in active_xfers Hash Table

CVE-2020-25651[1]:
| Possible File Transfer DoS and Information Leak via active_xfers
| Hash Map

CVE-2020-25652[2]:
| Possibility to Exhaust File Descriptors in vdagentd

CVE-2020-25653[3]:
| UNIX Doman Socket Peer PID Retrieved via SO_PEERCRED is Subject to
| Race Condition

Altough the security-tracker lists all the individual commits all of
the commits mentioned in the oss-security post should be taken:

https://gitlab.freedesktop.org/spice/linux/vd_agent/-/commit/ce144335ff45b16be2241c45a683cc01e0f50558
https://gitlab.freedesktop.org/spice/linux/vd_agent/-/commit/1a8b93ca6ac0b690339ab7f0afc6fc45d198d332
https://gitlab.freedesktop.org/spice/linux/vd_agent/-/commit/9d35d8a86fb310fc1f29d428c0a96995948d2357
https://gitlab.freedesktop.org/spice/linux/vd_agent/-/commit/91caa9223857708475d29df1768208fed1675340
https://gitlab.freedesktop.org/spice/linux/vd_agent/-/commit/51c415df82a52e9ec033225783c77df95f387891
https://gitlab.freedesktop.org/spice/linux/vd_agent/-/commit/5c50131797e985d0a5654c1fd7000ae945ed29a7
https://gitlab.freedesktop.org/spice/linux/vd_agent/-/commit/812ca777469a377c84b9861d7d326bfc72563304
https://gitlab.freedesktop.org/spice/linux/vd_agent/-/commit/e4bfd1b632b6c14e8411dbe3565115a78cd3d256
https://gitlab.freedesktop.org/spice/linux/vd_agent/-/commit/b7db1c20c9f80154fb54392eb44add3486d3e427
https://gitlab.freedesktop.org/spice/linux/vd_agent/-/commit/5094d5cfe66748dffcca8529745f8b3c76195d7a

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-25650
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25650
[1] https://security-tracker.debian.org/tracker/CVE-2020-25651
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25651
[2] https://security-tracker.debian.org/tracker/CVE-2020-25652
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25652
[3] https://security-tracker.debian.org/tracker/CVE-2020-25653
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25653
[4] https://www.openwall.com/lists/oss-security/2020/11/04/1

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#973768: rust-num-traits FTBFS: missing comma in Depends

2020-11-04 Thread Adrian Bunk
Source: rust-num-traits
Version: 0.2.11-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=rust-num-traits=sid

...
   dh_gencontrol -a -O--buildsystem=cargo
dpkg-gencontrol: warning: can't parse dependency librust-autocfg-1+default-dev
librust-libm-0.2+default-dev
dpkg-gencontrol: error: parsing package 'librust-num-traits-dev' Depends field: 
,
librust-autocfg-1+default-dev
librust-libm-0.2+default-dev
dh_gencontrol: error: dpkg-gencontrol -plibrust-num-traits-dev 
-ldebian/changelog -Tdebian/librust-num-traits-dev.substvars 
-Pdebian/librust-num-traits-dev returned exit code 25
dh_gencontrol: error: Aborting due to earlier error
make: *** [debian/rules:3: binary-arch] Error 25



Depends:
 ${misc:Depends},
 librust-autocfg-1+default-dev
 librust-libm-0.2+default-dev

There is a comma missing.



Bug#973767: dolfin FTBFS: The MPI_Comm_rank() function was called before MPI_INIT was invoked.

2020-11-04 Thread Adrian Bunk
Source: dolfin
Version: 2019.2.0~git20200629.946dbd3-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=dolfin

...
 3/51 Test  #13: demo_eigenvalue_serial ***Failed0.02 
sec
*** The MPI_Comm_rank() function was called before MPI_INIT was invoked.
*** This is disallowed by the MPI standard.
*** Your MPI job will now abort.
[x86-csail-01:13764] Local abort before MPI_INIT completed completed 
successfully, but am not able to aggregate error messages, and not able to 
guarantee that all other processes were killed!
...
48/51 Test #101: demo_waveguide_serial .***Failed0.02 
sec
*** The MPI_Comm_rank() function was called before MPI_INIT was invoked.
*** This is disallowed by the MPI standard.
*** Your MPI job will now abort.
[x86-csail-01:15044] Local abort before MPI_INIT completed completed 
successfully, but am not able to aggregate error messages, and not able to 
guarantee that all other processes were killed!
...
The following tests FAILED:
 13 - demo_eigenvalue_serial (Failed)
101 - demo_waveguide_serial (Failed)
Errors while running CTest
make[1]: *** [debian/rules:237: override_dh_auto_test-arch] Error 8



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

2020-11-04 Thread Cristian Ionescu-Idbohrn
On Tue, 3 Nov 2020, Michael Biebl wrote:
> Am 03.11.2020 um 22:58 schrieb 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.
> 
> Anything which would make this bug report more more useful. Leave 
> out any snide remarks and stupid comments if you can.

One more thing.

"snide remarks and stupid comments"?  What kind of comments are 
tolerated in these bug reports or on the mailinglists?

In this particular case, I find out that rebooting makes my 
networkmanager problems go away, but restarting the service _breaks_
the OS.

IMO, my remarks and comments are all _but_ snide and stupid.  The 
problem here, as I see it, is this maintainer's _arrogant_ attitude.  

Period.

I'd like to see the leader's comment this, but I doubt he will.


-- 
Cristian



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

2020-11-04 Thread Limonciello, Mario
> -Original Message-
> From: Boyuan Yang 
> Sent: Tuesday, November 3, 2020 23:45
> To: Limonciello, Mario; 973...@bugs.debian.org
> Subject: Re: Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-
> friendly
> 
> 
> [EXTERNAL EMAIL]
> 
> 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

I think the problem here is that the EFI binary sign process just didn't
run.  @Steve McIntyre is that supposed to be automatic now?  Or still manual?


Bug#945001: grub-efi-amd64: GRUB-EFI messes up boot variables

2020-11-04 Thread MiloMak

  
  
i did an upgrade in sid and this still
  showed up as a bug
  
  [UPGRADE] grub-efi:amd64 2.02+dfsg1-20+deb10u2 -> 2.04-9
  
  did the upgrade and was able to boot

  




Bug#947097: ITP: scikit-build -- build system generator for Python C/C++/Fortran/Cython extensions

2020-11-04 Thread Håvard Flaget Aasen
ons. 4. nov. 2020 kl. 14:36 skrev Emmanuel Arias :
>
> Hi Håvard,
>
> How is the process of this packaging?
>
> python-blosc need skbuild  as build-depends.
>
> Cheers,
> eamanu


Hi Emmanuel,

I actually filed this ITP because of python-blosc, but haven't done
much with it after that. I actually thought of removing myself as
owner of the bug.

Do you wish to take ownership of this ITP bug and package?
The work I have done is here [1]. Looking at it now, I'm seeing that
the version is older than the current release.

Regards,
Håvard

[1] https://salsa.debian.org/haava/scikit-build



Bug#973527: [Debian FTP Masters] Accepted swi-prolog 8.2.2+dfsg-1.1 (source) into unstable

2020-11-04 Thread Sebastian Andrzej Siewior
On 2020-11-04 20:38:43 [+0500], Lev Lamberov wrote:
> Yes, I see. I've reported it upstream. Looks like another regression on
> 32-bits architectures (the same is for armhf). So, I'll reopen the bug
> report.

Great, thanks. If need someone to test or so, just give me a ping.

Sebastian



Bug#973757: SyntaxWarning

2020-11-04 Thread Simon Cross
Being addressed in https://github.com/edgewall/genshi/pull/33.



Bug#973485: gdm3 starts gnome instead of .xsession even when "Default X11 session" is selected

2020-11-04 Thread Simon McVittie
On Mon, 02 Nov 2020 at 11:46:55 +, Simon McVittie wrote:
> On Sat, 31 Oct 2020 at 16:35:27 +0100, Christoph Berg wrote:
> > gdm3 does not start my ~/.xsession anymore but boots gnome instead.
> 
> I think the root cause might be
> . Do you see
> "has_option: not found" in the system log (systemd Journal or syslog)
> during login? If you apply the patch from that bug to /etc/gdm3/Xsession,
> does that work? It seems to work for me, with my openbox-based reproducer.

Please try with gdm3_3.38.2-1 when it becomes available on your mirror.

smcv



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

2020-11-04 Thread Norbert Preining
On Wed, 04 Nov 2020, Hilmar Preuße wrote:
> > In [1] Norbert suggested to replace SELFAUTOPARENT by TEXMFROOT.

Oh that one  forgot about it already ;-) Yes, all of them need to be
replaced with TEXMFROOT which correctly gives /usr/share/texlive

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13



Bug#971061: git-remote-hg: Mercurial no longer supports Python 2

2020-11-04 Thread Simon McVittie
Control: tags -1 + patch fixed-upstream

On Sat, 26 Sep 2020 at 21:06:28 -0400, Full Name wrote:
> The mercurial package in unstable no longer ships a Python 2
> compatible module. This leaves git-remote-hg unable to run.
> 
> Please upgrade git-remote-hg to 1.0.2, which supports Python 3.

On Sun, 06 Sep 2020 at 18:58:57 +0800, Paul Wise wrote:
> git-remote-hg has been ported to Python 3 but the shebang remains using
> /usr/bin/env python and upstream cites PEP 394 while suggesting that it
> is the job of the package maintainer to set the shebang to Python 3 on
> distributions that no longer ship an unversioned python in $PATH.

I've prepared a package of the latest upstream release 1.0.2.1. Only
lightly tested, but it seems to work well enough to clone SDL.

https://salsa.debian.org/debian/git-remote-hg/-/merge_requests/2

smcv



Bug#973757: SyntaxWarning in filters/i18n.py

2020-11-04 Thread Simon Cross
The SyntaxWarning is technically correct -- we should use != in this
case, not identity comparison. Since the code is question hasn't
changed since 2008, I suspect the warning is because the syntax
checker in Python got better, not that Genshi changed.

Because Python caches small strings the code likely works, but it is
bad practice to rely on this. Will fix upstream, but it doesn't seem
worth an immediate new release.



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

2020-11-04 Thread Limonciello, Mario
> 
> On Wed, Nov 04, 2020 at 06:30:54PM +, Limonciello, Mario wrote:
> >> 在 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
> >
> >I think the problem here is that the EFI binary sign process just didn't
> >run.  @Steve McIntyre is that supposed to be automatic now?  Or still manual?
> 
> I saw earlier that it's just happened. It's still run manually. What
> we've done for the other -signed packages to deal with the delay and
> potentially inconsistent versioning is change the dependencies.
> Instead of depending on *exactly* the same version as the signed
> package (==), we switch to >= so that a delay in the new -signed
> package being processed won't break installations.
> 

99.9% of the time that's probably sufficient.  But the moment the structure
of the NVRAM variable used by linux user space and EFI application changes
this would break.  So because of that it's safer to block installation.


Bug#973337: dh-runit: autopkgtest-virt-lxc failure on armhf and armel

2020-11-04 Thread Lorenzo Puliti
Source: dh-runit
Followup-For: Bug #973337
X-Debbugs-Cc: plore...@disroot.org
Control: found -1 2.10.0


Hello,

sorry for the late response.
There are outstanding issues with ghc and arm architectures, see #954190 for 
example.
For now, the only thing that i can do form dh-runit side is to properly declare 
the autopkgtest non compatible with armel and armhf, so that it will be auto 
skipped :/

Regards,
Lorenzo



Bug#973766: Consider taking the Fedora patches to enable modern encryption options.

2020-11-04 Thread Christopher Jones
Package: vsftpd
Version: 3.0.3-12

Fedora have a number of patches available via 
https://src.fedoraproject.org/rpms/vsftpd/tree/master that enable modern 
encryption standards and make the defualt ssl implementation TLS V1.2.

Please consider including these or similar patches in your package.

SSL V2, V3, and TLSV1.0 which are the only current config options provided by 
this package are all deprecated and should be considered insecure at this point.

Many thanks!

—
Chris


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

2020-11-04 Thread Steve McIntyre
On Wed, Nov 04, 2020 at 06:30:54PM +, Limonciello, Mario wrote:
>> 在 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
>
>I think the problem here is that the EFI binary sign process just didn't
>run.  @Steve McIntyre is that supposed to be automatic now?  Or still manual?

I saw earlier that it's just happened. It's still run manually. What
we've done for the other -signed packages to deal with the delay and
potentially inconsistent versioning is change the dependencies.
Instead of depending on *exactly* the same version as the signed
package (==), we switch to >= so that a delay in the new -signed
package being processed won't break installations. 

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
handing rope-creating factories for users to hang multiple
instances of themselves.



Bug#973765: linux-image-5.9.0-1-amd64: Apple NVMe SSD controller fails to start

2020-11-04 Thread Harold R. Grove
Package: linux-image-5.9.0-1-amd64
Severity: critical
Justification: breaks the whole system
X-Debbugs-Cc: rgr...@rsu20.org

Dear Maintainer,

Updating to any Linux kernel after 5.7.0-2-amd64 makes the NVMe SSD on Apple 
MacBookAir7,1 fail to start. 
dmesg spits out:
[   64.565416] nvme nvme0: controller is down; will reset: CSTS=0x3, 
PCI_STATUS=0x10
[   64.645531] nvme nvme0: detected Apple NVMe controller, set queue depth=2 to 
work around controller resets
[   80.149335] nvme nvme0: Device not ready; aborting reset, CSTS=0x3
[   80.149373] nvme nvme0: Removing after probe failure status: -19
[   80.173515] blk_update_request: I/O error, dev nvme0n1, sector 2056 op 
0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[   80.173611] blk_update_request: I/O error, dev nvme0n1, sector 0 op 
0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0
[   80.173623] blk_update_request: I/O error, dev nvme0n1, sector 208768 op 
0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[   80.173638] Buffer I/O error on dev nvme0n1p1, logical block 1, async page 
read
[   80.173873] Buffer I/O error on dev nvme0n1p2, logical block 25584, async 
page read


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

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

Versions of packages linux-image-5.9.0-1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.137
ii  kmod27+20200310-2
ii  linux-base  4.6

Versions of packages linux-image-5.9.0-1-amd64 recommends:
ii  apparmor 2.13.4-3
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.9.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-efi-amd64  2.04-8
pn  linux-doc-5.9   



Bug#790037: spamass-milter: Erronius message about ENVRCPT

2020-11-04 Thread Horne, Nigel (GSFC-580.0)[Arctic Slope Technical Services, Inc.]
So that you know, it’s still happening.


Bug#954273: simka: arm64 autopkgtest time out

2020-11-04 Thread Paul Gevers
Hi,

On 04-11-2020 17:47, Bernhard Übelacker wrote:
> I tried to have a look at this hanging test and could
> reproduce a hang at this backtrace [1].
> 
> The loop in [2] gets not left because the result of the fgetc call
> gets stored in a variable of type char and later compared to EOF.
> It seems to be an issue with not being explicit
> about signed/unsigned char with this variable.
> 
> At least using the type int makes the test finish and pass,
> when libgatbcore3 is built with attached patch.

I hope this fixes the issue on ppc64el too. That arch also timed out.
(armhf failed for a different reason).

Paul



signature.asc
Description: OpenPGP digital signature


Bug#973764: ITP: nim-kexpr -- kexpr math expressions for nim

2020-11-04 Thread Steffen Moeller
Package: wnpp
Severity: wishlist

Subject: ITP: nim-kexpr -- kexpr math expressions for nim
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: nim-kexpr
  Version : 0.0.2
  Upstream Author : Brent Pedersen <@brentp>
* URL : https://github.com/brentp/kexpr-nim
* License : MIT
  Programming Lang: C
  Description : kexpr math expressions for nim
 This panim wrapper for Heng Li's kexpr math expression library.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/med-team/nim-kexpr



Bug#973763: fatal error (SIGSEGV) while running jitsi-videobridge2

2020-11-04 Thread Chris Trimble

Followup-For: Bug #966508
Package: openjdk-11-jre
Version: 11.0.9+11-1~deb10u1

Package: openjdk-11-jre
Version: 11.0.8+10

Hello Maintainer,
    I have first saw evidence of this bug when a file called
hs_err_pid20947.log (attached) appeared in my ~/Home folder. I'm
not too sure, but I think the log occurred during a system update. Then, I
noticed a website needing JavaScript was not loading properly. I read 
the .log

file, and noticed this line:

_
Java VM: OpenJDK 64-Bit Server VM (11.0.8+10-post-Debian-1deb10u1, mixed 
mode,

sharing, tiered, compressed oops, g1 gc, linux-amd64)
_

    So, thinking VirtualBox might have to do with it some-how, I 
removed

VirtualBox-6.1, then auto-removed the packages and purged VirtualBox-6.1. I
think this did the trick, the site loaded up good; no reboot needed 
either. In

total, I got rid of:

_
virtualbox-6.1 gir1.2-ibus-1.0 ibus ibus-clutter ibus-gtk ibus-gtk3 
im-config

libclutter-imcontext-0.1-0 libclutter-imcontext-0.1-bin libibus-1.0-5
libqt5opengl5 libsdl-ttf2.0-0 libxcb-xtest0 linux-headers-4.19.0-10-amd64
linux-headers-4.19.0-10-common linux-headers-amd64 
linux-image-4.19.0-10-amd64

_

    If I'm on to something, then perhaps this bug lies in how 
openjdk-11
interacts with the virtual machine packages; I know some of them go 
pretty deep

into the system. It's my first bug report, but I hope in proves
helpful so we can fix the problem.


Best Regards,

Chris Trimble



-- 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 4.19.0-12-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openjdk-11-jre depends on:
ii  libc6    2.28-10
ii  libgif7  5.1.4-3
ii  libgl1   1.1.0-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libpng16-16  1.6.36-6
ii  libx11-6 2:1.6.7-1+deb10u1
ii  libxext6 2:1.3.3-1+b2
ii  openjdk-11-jre-headless  11.0.9+11-1~deb10u1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages openjdk-11-jre recommends:
ii  fonts-dejavu-extra   2.37-1
ii  libatk-wrapper-java-jni  0.33.3-22

openjdk-11-jre suggests no packages.
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x7fbc8c3c2ea1, pid=20947, tid=20966
#
# JRE version: OpenJDK Runtime Environment (11.0.8+10) (build 11.0.8+10-post-Debian-1deb10u1)
# Java VM: OpenJDK 64-Bit Server VM (11.0.8+10-post-Debian-1deb10u1, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C  [libjimage.so+0x2ea1]
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   https://bugs.debian.org/openjdk-11
#

---  S U M M A R Y 

Command Line: abort -Dorg.openoffice.native= -Duser.language=en -Duser.country=US -Duser.language.display=en -Duser.country.display=US -Xss8388608 

Host: 


Bug#973762: transition: ace

2020-11-04 Thread Sudip Mukherjee
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,

A transition request for 'ace' please.
Small transition with only two affected packages: diagnostics, ivtools.
Both of them builds fine with ace 6.5.12+dfsg-1 version in experimental.

The autogenerated ben tracker looks good. Please consider 'ace' for
transition.
Thanks in advance.

-- 
Regards
Sudip



Bug#973761: ITP: golang-github-xtls-go -- go library of xTLS

2020-11-04 Thread Roger Shimizu
Package: wnpp
Severity: wishlist
Owner: Roger Shimizu 

* Package name: golang-github-xtls-go
  Version : 0.0~git20201101.207fdca-1
  Upstream Author : XTLS Project
* URL : https://github.com/XTLS/Go
* License : BSD-3-clause
  Programming Lang: Go
  Description : go library of xTLS

This is a dependency of golang-v2ray.



Bug#973754: reposurgeon: slightly incorrect output for "repotool initialize "

2020-11-04 Thread Vincent Lefevre
Control: tags -1 fixed-upstream

On 2020-11-04 15:17:34 +0100, Vincent Lefevre wrote:
> $ repotool initialize mpfr
> repotool: what VCS do you want to convert from? svn
> repotool: what VCS do you want to convert to? git
> repotool: generating Makefile, some variables in it need to be set.
> repotool: generating a stub options file.
> repotool: generating a stub options file.
> 
> Note the duplicated line at the end. There's actually a stub lift file
> (mpfr.lift) and a stub options file (mpfr.opts).

I suppose that this is an upstream bug. I cannot reproduce it
with reposurgeon from git master (where an additional file is
now generated, BTW).

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



Bug#973752: reposurgeon: "repotool initialize" failure

2020-11-04 Thread Vincent Lefevre
Control: tags -1 upstream
Control: forwarded -1 https://gitlab.com/esr/reposurgeon/-/issues/304

On 2020-11-04 15:09:29 +0100, Vincent Lefevre wrote:
> When I run "repotool initialize" from an empty directory, I get:
> 
> $ repotool initialize
> repotool: initialize requires a project name.

I can reproduce this bug when using reposurgeon from git master,
and the documentation hasn't changed. So I've reported the bug
upstream.

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



Bug#973740: gnome-shell: segfault in libmozjs-78.so.78.3.0

2020-11-04 Thread Simon McVittie
Control: retitle -1 gnome-shell: segfault in libmozjs-78.so.78.3.0 when 
proprietary NVIDIA driver is used

On Wed, 04 Nov 2020 at 11:54:52 +0100, Jorge Cardona wrote:
> I removed nvidia-xconfig, xserver-xorg-video-nvidia, nvidia-driver and the
> system is working fine now.

Since the backtrace doesn't involve the NVIDIA driver, either it's
coincidence or memory corruption.

How reliably did this crash happen when you were using the NVIDIA driver?

If you restart GNOME Shell repeatedly (perhaps log in to GNOME and log
back out, 10 times) using the open-source Nouveau driver, does it seem
reliable?

smcv



Bug#970643: "pytest" command is missing

2020-11-04 Thread Antonio Terceiro
On Mon, Oct 12, 2020 at 11:52:25AM +, Novy, Ondrej wrote:
> Tags: wontfix
> 
> Hi,
> 
> this is not bug, but feature :).
> 
> To prevent confusion I want to ship pytest-3 cli (and not pytest) with 
> bullseye
> stable release. We can reconsider this after bullseye release.

Could you ellaborate? Maybe we should have a discussion in the Python
team so that we implement consistent practices. For example, `gunicorn`
and `pip` now point to their python3 versions, but you are saying that
pytest will not do that, what maybe creates more confusion given Debian
bullseye will not support any other Python.


signature.asc
Description: PGP signature


Bug#973759: lintian: False positive: debian-changelog-file-is-a-symlink matches on upstream changelog

2020-11-04 Thread Andreas Metzler
Package: lintian
Version: 2.100.0
Severity: normal

For exim4 lintian now warns:
W: exim4-daemon-heavy: debian-changelog-file-is-a-symlink changelog.gz
N:
W: debian-changelog-file-is-a-symlink
N:
N:   The Debian changelog file is a symlink to a file in a different
N:   directory or not found in this package.
[...]

However the Debian changelog file is not a symlink, only the upstream
one.

cu Andreas



Bug#973742: Boot output

2020-11-04 Thread Gregor Horvath
Am Wed, 04 Nov 2020 15:40:24 +
schrieb Ben Hutchings :

> Control: tag -1 moreinfo
> 
> On Wed, 2020-11-04 at 12:27 +0100, deb...@gregor-horvath.com wrote:
> [...]
> > Starting kernel ...
> > ��r���º��/cpus/cpu@0 missing clock-frequency property
> > [0.072909] /cpus/cpu@1 missing clock-frequency property
> > [1.806132] sr_init: platform driver register failed for SR
> > [1.816144] Failed to execute /init (error -2)  
> 
> Are these error messages also logged by the working kernel, or are
> they new?

boot message of the working kernel:

U-Boot 2016.11+dfsg1-4 (Mar 27 2017 - 18:39:51 +) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
Model: Olimex A20-Olinuxino Micro
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
*** Warning - bad CRC, using default environment

Setting up a 1024x768 vga console (overscan 0x0)
In:serial
Out:   vga
Err:   vga
SCSI:  Target spinup took 0 ms.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst 
Net:   eth0: ethernet@01c5
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:2...
Found U-Boot script /boot.scr
2464 bytes read in 73 ms (32.2 KiB/s)
## Executing script at 4310
Mainline u-boot / new-style environment detected.
3836080 bytes read in 502 ms (7.3 MiB/s)
35271 bytes read in 232 ms (148.4 KiB/s)
16947432 bytes read in 1488 ms (10.9 MiB/s)
Booting Debian 4.9.0-13-armmp-lpae from mmc 0:2...
## Flattened Device Tree blob at 4300
   Booting using the fdt blob at 0x4300
   Loading Ramdisk to 48fd6000, end 49fff8e8 ... OK
   Loading Device Tree to 48fca000, end 48fd59c6 ... OK

Starting kernel ...

[0.073034] /cpus/cpu@0 missing clock-frequency property
[0.073073] /cpus/cpu@1 missing clock-frequency property
[1.792129] sr_init: platform driver register failed for SR
[2.742847] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 8, RTO !!
[2.761214] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 8, RTO !!
eth set gpio 17 to 0
/dev/mmcblk0p3: clean, 74944/402400 files, 806103/1608192 blocks
[5.739075] ata1: exception Emask 0x10 SAct 0x0 SErr 0x10002 action 0xe 
frozen
[5.746414] ata1: irq_stat 0x0040, PHY RDY changed
[5.751605] ata1: SError: { RecovComm PHYRdyChg }

Debian GNU/Linux 9 SrvInt01 ttyS0

> 
> > [1.820753] Kernel panic - not syncing: No working init found.
> > Try passing init= option to kernel. See Linux
> > Documentation/init.txt for guidance. [1.833873] CPU: 1 PID: 1
> > Comm: swapper/0 Not tainted 4.9.0-14-armmp-lpae #1 Debian 4.9.240-2
> > [1.842385] Hardware name: Allwinner sun7i (A20) Family
> > [1.847645] [] (unwind_backtrace) from []
> > (show_stack+0x20/0x24) [1.855391] [] (show_stack)
> > from [] (dump_stack+0xc4/0xd8) [1.862617]
> > [] (dump_stack) from [] (panic+0x100/0x28c)
> > [1.869585] [] (panic) from []
> > (kernel_init+0x110/0x120) [1.876633] [] (kernel_init)
> > from [] (ret_from_fork+0x14/0x34) [1.884205] CPU0:
> > stopping  
> 
> This suggest to me that the initramfs is incomplete.  Is the /boot
> partition (or root partition, if /boot is not separate) full?

no, see:

$ df -h
Dateisystem  Größe Benutzt Verf. Verw% Eingehängt auf
udev  482M   0  482M0% /dev
tmpfs 100M7,9M   92M8% /run
/dev/mmcblk0p36,0G3,0G  2,8G   52% /
tmpfs 499M4,0K  499M1% /dev/shm
tmpfs 5,0M   0  5,0M0% /run/lock
tmpfs 499M   0  499M0% /sys/fs/cgroup
/dev/mmcblk0p2237M 58M  167M   26% /boot
/dev/mapper/inthdd_crypt  294G 70G  209G   26% /mnt/inthdd
tmpfs 100M   0  100M0% /run/user/1000

Thank you!
Greg


pgpvpgMFecNFu.pgp
Description: Digitale Signatur von OpenPGP


Bug#947097: Fwd: ITP: scikit-build -- build system generator for Python C/C++/Fortran/Cython extensions

2020-11-04 Thread Emmanuel Arias
Control: owner -1 Emmanuel Arias 

Sorry, replying also to bts


-- Forwarded message -
From: Emmanuel Arias 
Date: Wed, Nov 4, 2020 at 1:07 PM
Subject: Re: ITP: scikit-build -- build system generator for Python
C/C++/Fortran/Cython extensions
To: Håvard Flaget Aasen 


Hi,

thanks for your reply.

Yes I can continue the work.

Thanks!
Emmanuel
On Wed, Nov 4, 2020 at 12:55 PM Håvard Flaget Aasen 
wrote:

> ons. 4. nov. 2020 kl. 14:36 skrev Emmanuel Arias :
> >
> > Hi Håvard,
> >
> > How is the process of this packaging?
> >
> > python-blosc need skbuild  as build-depends.
> >
> > Cheers,
> > eamanu
>
>
> Hi Emmanuel,
>
> I actually filed this ITP because of python-blosc, but haven't done
> much with it after that. I actually thought of removing myself as
> owner of the bug.
>
> Do you wish to take ownership of this ITP bug and package?
> The work I have done is here [1]. Looking at it now, I'm seeing that
> the version is older than the current release.
>
> Regards,
> Håvard
>
> [1] https://salsa.debian.org/haava/scikit-build
>


Bug#973758: In debian buster: libvirtd fails to release lock on resources and crashes

2020-11-04 Thread Katerina Koukiou
Package: libvirt0
Architecture: amd64
Version: 5.0.0-4+deb10u1

In the cockpit [1] project, I have noticed sometimes this libvirt
crash in our CI tests. It seems like libivirt crashes when test tests
try to remove all libvirt resources available on the system,
thus it performs, virsh destroy/undefined, virsh pool-destroy/undefine
etc for all resources at the end of each test.

I know the reproducer is really value but maybe you can take a look in
the following stack trace, I got it with debug symbols installed:

root@debian:/home/admin/libvirtd# gdb /usr/sbin/libvirtd
core.libvirtd.1002.6d98a59e010946b29e1cddaa8e44bd2c.12589.160448384400
...
Reading symbols from /usr/sbin/libvirtd...Reading symbols from
/usr/lib/debug/.build-id/17/171df3fcb3a47a224d747b795dff324fa96157.debug...done.
done.
[New LWP 13800]
[New LWP 12591]
[New LWP 12592]
[New LWP 12593]
[New LWP 12594]
[New LWP 12595]
[New LWP 12596]
[New LWP 12597]
[New LWP 12598]
[New LWP 12599]
[New LWP 12600]
[New LWP 12605]
[New LWP 12606]
[New LWP 12607]
[New LWP 12608]
[New LWP 12609]
[New LWP 12589]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/libvirtd --timeout=30'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __GI___pthread_mutex_lock (mutex=mutex@entry=0x0) at
../nptl/pthread_mutex_lock.c:67
67../nptl/pthread_mutex_lock.c: No such file or directory.
[Current thread is 1 (Thread 0x7f7783fff700 (LWP 13800))]
(gdb) bt full
#0  __GI___pthread_mutex_lock (mutex=mutex@entry=0x0) at
../nptl/pthread_mutex_lock.c:67
type = 
__PRETTY_FUNCTION__ = "__pthread_mutex_lock"
id = 
#1  0x7f77b21004d5 in virMutexLock (m=m@entry=0x0) at
../../../src/util/virthread.c:89
No locals.
#2  0x7f77a843b4de in qemuDriverLock (driver=0x0) at
../../../src/qemu/qemu_conf.c:1062
No locals.
#3  virQEMUDriverGetConfig (driver=0x0) at ../../../src/qemu/qemu_conf.c:1062
conf = 
#4  0x7f77a848029c in qemuStateStop () at
../../../src/qemu/qemu_driver.c:998
ret = -1
conn = 
numDomains = 0
i = 
state = 32631
domains = 0x0
flags = 0x0
cfg = 
__FUNCTION__ = "qemuStateStop"
#5  0x7f77b229845f in virStateStop () at ../../../src/libvirt.c:737
i = 8
ret = 0
#6  0x55cbb217c3fd in daemonStopWorker (opaque=0x55cbb334a500) at
../../../src/remote/remote_daemon.c:725
__x = 
dmn = 0x55cbb334a500
__func__ = "daemonStopWorker"
#7  0x7f77b2100382 in virThreadHelper (data=) at
../../../src/util/virthread.c:206
args = 0x0
local = {func = 0x55cbb217c3c0 , funcName =
0x55cbb21af004 "daemonStopWorker", worker = false, opaque =
0x55cbb334a500}
#8  0x7f77b1771fa3 in start_thread (arg=) at
pthread_create.c:486
ret = 
pd = 
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140151292425984,
7462251322524822461, 140733687626798, 140733687626799,
140151292425984, 140151561871456, -7394846862332138563,
-7394808450710639683}, mask_was_saved = 0}}, priv = {
pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup =
0x0, canceltype = 0}}}
not_first_call = 
#9  0x7f77b16964cf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.


Let me know if I can help any furthet for debugging,
Katerina

[1]: https://github.com/cockpit-project/cockpit/



Bug#973742: Boot output

2020-11-04 Thread Ben Hutchings
Control: tag -1 moreinfo

On Wed, 2020-11-04 at 12:27 +0100, deb...@gregor-horvath.com wrote:
[...]
> Starting kernel ...
> ��r���º��/cpus/cpu@0 missing clock-frequency property
> [0.072909] /cpus/cpu@1 missing clock-frequency property
> [1.806132] sr_init: platform driver register failed for SR
> [1.816144] Failed to execute /init (error -2)

Are these error messages also logged by the working kernel, or are they
new?

> [1.820753] Kernel panic - not syncing: No working init found.  Try 
> passing init= option to kernel. See Linux Documentation/init.txt for guidance.
> [1.833873] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.9.0-14-armmp-lpae 
> #1 Debian 4.9.240-2
> [1.842385] Hardware name: Allwinner sun7i (A20) Family
> [1.847645] [] (unwind_backtrace) from [] 
> (show_stack+0x20/0x24)
> [1.855391] [] (show_stack) from [] 
> (dump_stack+0xc4/0xd8)
> [1.862617] [] (dump_stack) from [] (panic+0x100/0x28c)
> [1.869585] [] (panic) from [] 
> (kernel_init+0x110/0x120)
> [1.876633] [] (kernel_init) from [] 
> (ret_from_fork+0x14/0x34)
> [1.884205] CPU0: stopping

This suggest to me that the initramfs is incomplete.  Is the /boot
partition (or root partition, if /boot is not separate) full?

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.




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


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

2020-11-04 Thread Ben Hutchings
Control: reassign -1 hw-detect 1.141

On Wed, 2020-11-04 at 09:19 -0500, Brandon Werner wrote:
> 
> On Wed, Nov 4, 2020, at 1:13 AM, Brandon Werner wrote:
> > 
> > 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.
> It looks like what is happening is that the driver prints its
> messages to dmesg with a different name than what the module is
> actually called.

There is no rule in Linux that a driver has to have the same name as
the module that contains it.  (In fact, a single module can contain
multiple drivers, in which cae they cannot all use the same name as the
module.)

>  When it prints its messages about missing firmware, it uses
> rtl_8821ce. The installer matches on that when unloading and loading
> modules to get the missing firmware, which results in an incorrect
> module name being used. Is there a list of cases in the installer for
> this? It needs to use rtw88_8821ce when it unloads and reloads the
> module.

I don't know this part of the installer.  But I think it would be a
mistake to use a mapping table; instead the installer should look at
metadata provided by the kernel.  All drivers in a loaded module should
be listed under /sys/module//drivers, and the installer
could use that to map a driver name to its module name.

Ben.

> > > 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.
-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.




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


Bug#973527: [Debian FTP Masters] Accepted swi-prolog 8.2.2+dfsg-1.1 (source) into unstable

2020-11-04 Thread Lev Lamberov
Ср 04 ноя 2020 @ 14:07 Sebastian Andrzej Siewior :

> On 2020-11-04 16:43:53 [+0500], Lev Lamberov wrote:
>> Sebastian, thank you very much!
>
> You are welcome. However autopkgtest isn't happy according to
>
> https://ci.debian.net/data/autopkgtest/testing/i386/s/swi-prolog/7945032/log.gz

Yes, I see. I've reported it upstream. Looks like another regression on
32-bits architectures (the same is for armhf). So, I'll reopen the bug
report.

> I just re-run it here and I see the same part so it is not just a
> glitch:
> |Running scripts from table_tests .DIFFERS: 24 common, 1 extra, 1 missing
> |EXTRA:
> |   < remaining(2)
> |MISSING:
> |   > remaining(0)
> |ERROR: /usr/lib/swi-prolog/test/Tests/xsb/table_tests/xsb_test_tables.pl:80:
> | test abol_test3b: failed
> |
> |..
> |Script /usr/lib/swi-prolog/test/Tests/xsb/table_tests/xsb_test_tables.pl 
> failed
>
>> Cheers!
>> Lev
>
> Sebastian



Bug#968414: apt: [INTL:pt] Update on Portuguese translation of manpage

2020-11-04 Thread David Kalnischkies
Control: tags -1 - moreinfo + l10n patch

Hi,

On Sat, Aug 15, 2020 at 11:27:49AM +0200, Julian Andres Klode wrote:
> On Fri, Aug 14, 2020 at 11:31:58PM +0100, Américo Monteiro wrote:
> > Updated Portuguese translation for  apt's manpage
> > Translator: Américo Monteiro 
> > Feel free to use it.
[…]
> We cannot merge unreviewed translations from unknown
> third parties.

Sorry for taking so long to get back on this…

Julian seems to have accidentally looking at the program translation
po-file, not the manpage translation where you are recorded as the last
translator, so I just went ahead and pushed the update to git, so it
should be part of the next release (if all goes well an automatic mail
should come in soon sort-of duplicating this one here).


Sorry again, thanks for your work & best regards

David Kalnischkies


signature.asc
Description: PGP signature


Bug#849752: dpkg-source: Provide better error message when .orig-tarball is missing

2020-11-04 Thread Guillem Jover
On Mon, 2020-11-02 at 21:08:11 +0800, Drew Parsons wrote:
> On 2020-11-02 17:50, Guillem Jover wrote:
> > On Mon, 2020-11-02 at 14:31:31 +0800, Drew Parsons wrote:
> > > Now it does not even report "...orig.tar.gz: No such file or
> > > directory" !!
> > 
> > Oh, that's a regression in dpkg-source 1.20.0, I've fixed this now
> > locally and will be included in the next release. In addition to the
> > wrong file copy error on missing orig tarballs.

> Does that fix include an option (and/or lintianrc setting) for specifying a
> directory for orig tarballs?
> For me, I'd set it as "lintian -t.."  to use the directory above.

> Felix indicated he might have had a patch in mind for that in message#103.

Ah, I'd probably keep this report for the error message, as that's
what the title was about, and let bug #865430 for such option or
similar, even though this one was filed earlier, but only reassigned
later. :)

Thanks,
Guillem



Bug#973748: sddm: CVE-2020-28049: local privilege escalation due to race condition in creation of the Xauthority file

2020-11-04 Thread Salvatore Bonaccorso
Hi,

On Wed, Nov 04, 2020 at 01:52:12PM +0100, Salvatore Bonaccorso wrote:
> Source: sddm
> Version: 0.18.1-1
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerability was published for sddm.
> 
> CVE-2020-28049[0]:
> | local privilege escalation due to race condition in creation of the
> | Xauthority file
> 
> 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-28049
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28049
> [1] 
> https://github.com/sddm/sddm/commit/be202f533ab98a684c6a007e8d5b4357846bc222
> [2] https://bugzilla.suse.com/show_bug.cgi?id=1177201
> [3] https://www.openwall.com/lists/oss-security/2020/11/04/2

Attached the debdiff as to be used for the buster-security update.

Regards,
Salvatore
diff -Nru sddm-0.18.0/debian/changelog sddm-0.18.0/debian/changelog
--- sddm-0.18.0/debian/changelog2018-07-22 13:26:44.0 +0200
+++ sddm-0.18.0/debian/changelog2020-11-04 15:29:27.0 +0100
@@ -1,3 +1,11 @@
+sddm (0.18.0-1+deb10u1) buster-security; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * Fix X not having access control on startup (CVE-2020-28049)
+(Closes: #973748)
+
+ -- Salvatore Bonaccorso   Wed, 04 Nov 2020 15:29:27 +0100
+
 sddm (0.18.0-1) unstable; urgency=medium
 
   [ Simon Quigley ]
diff -Nru 
sddm-0.18.0/debian/patches/06_Fix-X-not-having-access-control-on-startup.diff 
sddm-0.18.0/debian/patches/06_Fix-X-not-having-access-control-on-startup.diff
--- 
sddm-0.18.0/debian/patches/06_Fix-X-not-having-access-control-on-startup.diff   
1970-01-01 01:00:00.0 +0100
+++ 
sddm-0.18.0/debian/patches/06_Fix-X-not-having-access-control-on-startup.diff   
2020-11-04 15:29:27.0 +0100
@@ -0,0 +1,93 @@
+From: Fabian Vogt 
+Date: Tue, 6 Oct 2020 21:21:38 +0200
+Subject: Fix X not having access control on startup
+Origin: 
https://github.com/sddm/sddm/commit/be202f533ab98a684c6a007e8d5b4357846bc222
+Bug: https://bugzilla.suse.com/show_bug.cgi?id=1177201
+Bug-Debian: https://bugs.debian.org/973748
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2020-28049
+
+If the auth file is empty, X allows any local application (= any user on the
+system) to connect. This is currently the case until X wrote the display
+number to sddm and sddm used that to write the entry into the file.
+To work around this chicken-and-egg problem, make use of the fact that X
+doesn't actually look at the display number in the passed auth file and just
+use :0 unconditionally. Also make sure that writing the entry was actually
+successful.
+
+CVE-2020-28049
+---
+ src/daemon/XorgDisplayServer.cpp | 25 -
+ src/daemon/XorgDisplayServer.h   |  2 +-
+ 2 files changed, 21 insertions(+), 6 deletions(-)
+
+--- a/src/daemon/XorgDisplayServer.cpp
 b/src/daemon/XorgDisplayServer.cpp
+@@ -87,7 +87,7 @@ namespace SDDM {
+ return m_cookie;
+ }
+ 
+-void XorgDisplayServer::addCookie(const QString ) {
++bool XorgDisplayServer::addCookie(const QString ) {
+ // log message
+ qDebug() << "Adding cookie to" << file;
+ 
+@@ -103,13 +103,13 @@ namespace SDDM {
+ 
+ // check file
+ if (!fp)
+-return;
++return false;
+ fprintf(fp, "remove %s\n", qPrintable(m_display));
+ fprintf(fp, "add %s . %s\n", qPrintable(m_display), 
qPrintable(m_cookie));
+ fprintf(fp, "exit\n");
+ 
+ // close pipe
+-pclose(fp);
++return pclose(fp) == 0;
+ }
+ 
+ bool XorgDisplayServer::start() {
+@@ -126,6 +126,15 @@ namespace SDDM {
+ // log message
+ qDebug() << "Display server starting...";
+ 
++// generate auth file.
++// For the X server's copy, the display number doesn't matter.
++// An empty file would result in no access control!
++m_display = QStringLiteral(":0");
++if(!addCookie(m_authPath)) {
++qCritical() << "Failed to write xauth file";
++return false;
++}
++
+ if (daemonApp->testing()) {
+ QStringList args;
+ args << m_display << QStringLiteral("-ac") << 
QStringLiteral("-br") << QStringLiteral("-noreset") << 
QStringLiteral("-screen") << QStringLiteral("800x600");
+@@ -210,8 +219,14 @@ namespace SDDM {
+ emit started();
+ }
+ 
+-// generate auth file
+-addCookie(m_authPath);
++// The file is also used by the greeter, which does care about the
++// display number. Write the proper entry, if it's different.
++if(m_display != QStringLiteral(":0")) {
++if(!addCookie(m_authPath)) {
++qCritical() 

Bug#973757: python3-genshi: SyntaxWarning: "is not" with a literal. Did you mean "!="

2020-11-04 Thread Guillem Jover
Package: python3-genshi
Version: 0.7.4-1
Severity: normal

Hi!

While upgrading I got this warning:

  Setting up python3-genshi (0.7.4-1) ...
  /usr/lib/python3/dist-packages/genshi/filters/i18n.py:349: SyntaxWarning: "is 
not" with a literal. Did you mean "!="? assert numeral is not '', "at least 
pass the numeral param"
  /usr/lib/python3/dist-packages/genshi/filters/i18n.py:349: SyntaxWarning: "is 
not" with a literal. Did you mean "!="? assert numeral is not '', "at least 
pass the numeral param"

Thanks,
Guillem



Bug#972503: ITP: LazPaint -- Image editor with raster and vector layers

2020-11-04 Thread Tobias Frost
Control: tags -1 pending

In NEW now; so its just waiting until ftp-masters are checking it.

--
tobi



Bug#960742: RFS: lazpaint/6.4.1-1 [ITP] -- Graphics viewer and editor

2020-11-04 Thread Tobias Frost
Package: sponsorship-requests
Followup-For: Bug #960742
Control: close -1

uploading right now.

Thanks Gürkan and Johann for driving this!

-- 
tobi


Bug#973756: firejail: fcopy fails to load libpcre2-8.so.0 when running transmission-daemon

2020-11-04 Thread Mad Horse

Package: firejail
Version: 0.9.64-1
Severity: normal

Dear Maintainer,

Executing transmission-cli or transmission-daemon with firejail results
following error:

/run/firejail/lib/fcopy: error while loading shared libraries: 
libpcre2-8.so.0:

cannot open shared object file: No such file or directory
Error: failed to run /run/firejail/lib/fcopy




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

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

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

Versions of packages firejail depends on:
ii libapparmor1 2.13.5-1
ii libc6 2.31-4
ii libselinux1 3.1-2+b1

Versions of packages firejail recommends:
ii firejail-profiles 0.9.64-1
ii iproute2 5.9.0-1
ii iptables 1.8.5-3
ii xauth 1:1.0.10-1
ii xdg-dbus-proxy 0.1.2-1
ii xpra 3.0.9+dfsg1-1+b3
ii xserver-xephyr 2:1.20.8-2

firejail suggests no packages.

-- no debconf information



Bug#973755: git-buildpackage: gbp clone and import-* should defuse git attributes

2020-11-04 Thread Andrej Shadura
Package: git-buildpackage
Version: 0.9.20
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Quite a lot of packages ship .gitattributes in their tarballs, leading
to strange effects while building packages and, most importantly,
leading to the imports not creating Git trees identical to the tarballs.

A remedy to this would be git-buildpackage creating .git/info/attributes
with this content:

* -text -eol -crlf -ident -filter -working-tree-encoding

This disables any transformation of the version-controlled file.

Even better would be if gbp created the Git trees manually using
low-level Git commands which don’t take Git attributes into account.

Fixing this bug will also fix #719363.

Thanks!

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl+iwmgUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdK54gf+LrySXu92wrOwRpzkvBl7lccHRTw0
2a1QXSJHeDw5wwqXyO3K1lwRxQFx8vwdnEpqKmTOG4IboW9r9rKHqllhdy0UD4JM
I1/LDbPB34czsao0EEjrbRorlT0dvz1GRe0c2i0B0bEPwklKntRK1MQUJJuYxszo
XE8ONoCryEtVLODgWRv4rHPCdfOIWQmQFPloakyi91v2UWJDPzaw5Tjqvur7l+qI
mb3rP9M3WWIfIsit/+13gl2xIt6eb1TE1+wswXQVf2Zz6QZvT1Ixxb0jGoww9q4w
jMRrDKOD3WuBH3Fbiq60XYSyTSvv4cPaeGmBw7yrxkKZsw3aa/Fx6Q7Zdw==
=3ONe
-END PGP SIGNATURE-


Bug#972672: bash SIGSEGV related to locale

2020-11-04 Thread Chet Ramey
On 11/4/20 7:16 AM, Thomas Schwinge wrote:

>> I suspect that the bug is the "len" argument on the previous line
>>   n = wcsrtombs(pathname, (const wchar_t **), len, );
>>
>> Here "len" is byte length obtained for the original string from
>> strlen(). But the call seems to expect the length of the wide character
>> version in wpathname which was obtained above with xdupmbstowcs(), and
>> so the code should use the return value of that function (in variable
>> n) instead of len. Using too long a length makes wcsrtombs() set the
>> pointer to NULL when it continues to a zero character.
> 
> So this is different from the change that Chet (CCed) applied to upstream
> bash-5.1-rc2, 'lib/glob/glob.c':
> 
> (via ).
> 
> I cannot comment on the details, as I'm not at all familiar with these
> string APIs.  Chet?

The prototype for wcsrtombs is (simplified):

size_t wcsrtombs(char *dst, wchar_t **src, size_t len, mbstate_t *ps)

In the prototype, LEN is the maximum number of bytes to store in DST.

In bash, since LEN is set from the number of bytes in the original
pathname, and the possibly-modified multibyte character pathname cannot
contain more than that number of bytes, LEN is appropriate.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



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

2020-11-04 Thread Cristian Ionescu-Idbohrn
On Wed, 4 Nov 2020, Michael Biebl wrote:
> 
> Is NM the sole application touching /etc/resolv.conf?
> No other application adding entries to /etc/resolv.conf which NM 
> doesn't know about?

I don't know.  Is there a way to find out?

The mark in /etc/resolv.conf:

# Generated by NetworkManager

clearly points to NetworkManager.  Is:

dbus-daemon[1092]: [system] Activation via systemd failed for unit 
'dbus-org.freedesktop.resolve1.service': Unit 
dbus-org.freedesktop.resolve1.service not found.

expected behaviour?


-- 
Cristian



Bug#973741: gitlab: Yarn hasn't been able to find a cache folder it can use

2020-11-04 Thread Dragos Jarca

Package: gitlab
Version: 13.3.8-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Upgrade to 13.3.8.1 failed:

Installing node modules...
+ runuser -u gitlab -- sh -c install -d /var/lib/gitlab/.node_modules
+ runuser -u gitlab -- sh -c install -d /var/lib/gitlab/.cache
+ runuser -u gitlab -- sh -c yarnpkg install
yarn install v1.22.4
warning Skipping preferred cache folder "/var/lib/gitlab/.cache/yarn" 
because it is not writable.
warning Skipping preferred cache folder "/tmp/.yarn-cache-131" because 
it is not writable.
warning Skipping preferred cache folder "/tmp/.yarn-cache" because it is 
not writable.
error Yarn hasn't been able to find a cache folder it can use. Please 
use the explicit --cache-folder option to tell it what location to use, 
or make one of the preferred locations writable.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation 
about this command.

dpkg: error processing package gitlab (--configure):
 installed gitlab package post-installation script subprocess returned 
error exit status 1

Processing triggers for man-db (2.9.3-2) ...
Errors were encountered while processing:
 gitlab
E: Sub-process /usr/bin/dpkg returned an error code (1)

The problem is related to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972952 - yarnpkg isn't 
compatible with recent node-mkdirp and 
https://github.com/yarnpkg/yarn/issues/8417 - mkdirp module is obsolete 
#8417.


Please help to find a solution.

Best Regards,
Dragos

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

Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.UTF-8), LANGUAGE not set

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

Versions of packages gitlab depends on:
ii  asciidoctor  2.0.10-2
ii  bc 1.07.1-2+b2
ii  bundler  2.1.4-2
ii  bzip2    1.0.8-4
ii  dbconfig-pgsql   2.0.14
ii  debconf [debconf-2.0]    1.5.74
ii  gitlab-common 13.2.1+dfsg-3
ii  gitlab-workhorse 8.39.0+debian-1
ii  libjs-bootstrap4 [node-bootstrap] 4.5.2+dfsg1-1
ii  libjs-codemirror [node-codemirror]   5.57.0-1
ii  libjs-popper.js [node-popper.js] 1.16.1+ds-1
pn  libjs-uglify 
ii  libruby2.7 [ruby-json]   2.7.2-3
ii  lsb-base 11.1.0
ii  nginx    1.18.0-6
ii  nginx-extras [nginx] 1.18.0-6
pn  node-autosize 
ii  node-axios 0.21.0+dfsg-1
ii  node-babel-loader    8.1.0-3
ii  node-babel7 7.12.4+~cs142.117.99-1
ii  node-brace-expansion 2.0.0-1
ii  node-cache-loader    4.1.0-1
ii  node-chart.js 2.9.3+dfsg-3
pn  node-clipboard 
ii  node-compression-webpack-plugin  3.0.1-1
ii  node-core-js 3.6.5-1
ii  node-css-loader  3.2.1-1
ii  node-d3  5.16.0-1
ii  node-d3-scale    2.2.2-2
ii  node-d3-selection    1.4.0-5
pn  node-dateformat 
pn  node-deckar01-task-list 
pn  node-exports-loader 
pn  node-fuzzaldrin-plus 
ii  node-glob    7.1.6-3
pn  node-imports-loader 
pn  node-jed 
ii  node-jquery 3.5.1+dfsg-4
pn  node-jqery-ujs 
pn  node-js-cookie 
pn  node-jszip 
pn  node-jszip-utils 
ii  node-lodash 4.17.20+dfsg-1
pn  node-marked 
pn  node-mousetrap 
ii  node-prismjs 1.11.0+dfsg-4
ii  node-prosemirror-markdown    1.4.4-2
pn  node-prosemirror-model 
pn  node-raven-js 
pn  node-three-orbit-controls 
pn  node-three-stl-loader 
pn  node-timeago.js 
pn  node-underscore 
pn  node-url-loader 
ii  node-vue 2.6.12+dfsg-1
pn  node-vue-resource 
pn  node-webpack-stats-plugin 
ii  node-worker-loader   2.0.0-3
pn  node-xterm 
ii  nodejs 12.19.0~dfsg-1
ii  openssh-client   1:8.3p1-1
ii  postfix [mail-transport-agent]   3.5.6-1
ii  postgresql-client    13+221
ii  postgresql-client-13 [postgresql-client] 13.0-4
ii  postgresql-contrib   13+221
ii  puma 4.3.6-1+b1
ii  rake 13.0.1-4
ii  redis-server 5:6.0.9-1
ii  ruby 1:2.7+1
pn  ruby-ace-rails-ap 
pn  ruby-acme-client 

Bug#947097: ITP: scikit-build -- build system generator for Python C/C++/Fortran/Cython extensions

2020-11-04 Thread Emmanuel Arias
Hi Håvard,

How is the process of this packaging?

python-blosc need skbuild  as build-depends.

Cheers,
eamanu


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

2020-11-04 Thread Brandon Werner



On Wed, Nov 4, 2020, at 1:13 AM, Brandon Werner wrote:
> 
> 
> 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.
It looks like what is happening is that the driver prints its messages to dmesg 
with a different name than what the module is actually called. When it prints 
its messages about missing firmware, it uses rtl_8821ce. The installer matches 
on that when unloading and loading modules to get the missing firmware, which 
results in an incorrect module name being used. Is there a list of cases in the 
installer for this? It needs to use rtw88_8821ce when it unloads and reloads 
the module.
> > 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#973754: reposurgeon: slightly incorrect output for "repotool initialize "

2020-11-04 Thread Vincent Lefevre
Package: reposurgeon
Version: 4.4-1
Severity: minor

I got the following:

$ repotool initialize mpfr
repotool: what VCS do you want to convert from? svn
repotool: what VCS do you want to convert to? git
repotool: generating Makefile, some variables in it need to be set.
repotool: generating a stub options file.
repotool: generating a stub options file.

Note the duplicated line at the end. There's actually a stub lift file
(mpfr.lift) and a stub options file (mpfr.opts).

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 reposurgeon depends on:
ii  libc62.31-4
ii  python3  3.8.6-1
ii  tzdata   2020d-1

Versions of packages reposurgeon recommends:
pn  cvs-fast-export  
ii  git  1:2.29.1-1

Versions of packages reposurgeon suggests:
pn  brz 
pn  darcs   
pn  fossil  
pn  hg-fast-export  
ii  subversion  1.14.0-2+b1

-- no debconf information

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



Bug#973753: ITP: nim-lapper -- simple, fast interval searches for nim

2020-11-04 Thread Steffen Moeller
Package: wnpp
Severity: wishlist

Subject: ITP: nim-lapper -- simple, fast interval searches for nim
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: nim-lapper
  Version : 0.1.6+git20200609.d82bbc7
  Upstream Author : Brent S. Pedersen
* URL : https://github.com/brentp/nim-lapper
* License : Expat
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : simple, fast interval searches for nim
 This package uses a binary search in a sorted list of intervals along
 with knowledge of the longest interval.  It works when the size of the
 largest interval is smaller than the average distance between intervals.
 As that ratio of largest-size::mean-distance increases, the performance
 decreases.  On realistic (for my use-case) data, this is 1000 times
 faster to query results and >5000 times faster to check for presence
 than a brute-force method.
 .
 Lapper also has a special case `seek` method when we know that the
 queries will be in order.  This method uses a cursor to indicate that
 start of the last search and does a linear search from that cursor to
 find matching intervals. This gives an additional 2-fold speedup over
 the `find` method.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/med-team/nim-lapper



Bug#973752: reposurgeon: "repotool initialize" failure

2020-11-04 Thread Vincent Lefevre
Package: reposurgeon
Version: 4.4-1
Severity: minor

When I run "repotool initialize" from an empty directory, I get:

$ repotool initialize
repotool: initialize requires a project name.

Since "repotool initialize" (with no other arguments) is what is
documented in repository-editing.adoc, there should not be an error.

Giving a project name solves the problem.

Note that the current version in Debian, 4.4, is far behind the
current upstream version (4.19).

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 reposurgeon depends on:
ii  libc62.31-4
ii  python3  3.8.6-1
ii  tzdata   2020d-1

Versions of packages reposurgeon recommends:
pn  cvs-fast-export  
ii  git  1:2.29.1-1

Versions of packages reposurgeon suggests:
pn  brz 
pn  darcs   
pn  fossil  
pn  hg-fast-export  
ii  subversion  1.14.0-2+b1

-- no debconf information

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



Bug#973751: util-linux: flock --conflict-exit-code returns number modulus 255

2020-11-04 Thread Jean-Michel Vourgère
Package: util-linux
Version: 2.36-3+b2
Severity: normal

Dear Maintainer,

When using flock --nonblock --conflict-exit-code 600 on a locked file, the
returned value is 88.

I expected it to be 600.

This can re reproducted by runing:
$ flock --nonblock --conflict-exit-code 600 test.lock -c "sleep 10"&
a few times in a shell.

flock should fail immediatly if the number parameter is out of
acceptable range and will never be returned.

Additionnally, flock(1) should document the fact that number must be <=
255.


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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (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 util-linux depends on:
ii  libaudit1  1:2.8.5-3.1
ii  libblkid1  2.36-3+b2
ii  libc6  2.31-4
ii  libcap-ng0 0.7.9-2.2
ii  libcrypt1  1:4.4.17-1
ii  libmount1  2.36-3+b2
ii  libpam0g   1.3.1-5
ii  libselinux13.1-2+b1
ii  libsmartcols1  2.36-3+b2
ii  libsystemd0246.6-2
ii  libtinfo6  6.2+20200918-1
ii  libudev1   246.6-2
ii  libuuid1   2.36-3+b2
ii  login  1:4.8.1-1
ii  zlib1g 1:1.2.11.dfsg-2

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.1-2
ii  kbd 2.3.0-3
ii  util-linux-locales  2.36-3

-- no debconf information



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

2020-11-04 Thread Cristian Ionescu-Idbohrn
On Tue, 3 Nov 2020, Michael Biebl wrote:
>
> Anything which would make this bug report more more useful. Leave
> out any snide remarks and stupid comments if you can.

Alright, one stupid thing is the subject line.  Should be:

# systemctl restart NetworkManager.service

instead (cut/paste error).

That empties the contents of:

/etc/resolv.conf -> /run/NetworkManager/resolv.conf

I can reliably reproduce that.

More info:

This is a laptop and I'm using its wireless network interface,
configured to use dhcp to get the parameters from my home router.

The primary dns is the router itself, 192.168.0.1.  Besides, I locally
configured an additional (secondary) dns 9.9.9.9.  `nmcli' confirms
that:

# nmcli
...
DNS configuration:
servers: 192.168.0.1 9.9.9.9
interface: wlo1

Still, /etc/resolv.conf is emptied after a service restart.

Looking at the journal, I see:

Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4987] 
dhcp4 (wlo1): option dhcp_lease_time  => '4294967295'
--> Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4987] 
dhcp4 (wlo1): option domain_name_servers  => '192.168.0.1 192.168.0.1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4988] 
dhcp4 (wlo1): option host_name=> 'debian'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4988] 
dhcp4 (wlo1): option ip_address   => '192.168.0.2'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4988] 
dhcp4 (wlo1): option next_server  => '192.168.0.1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4989] 
dhcp4 (wlo1): option requested_broadcast_address => '1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4989] 
dhcp4 (wlo1): option requested_domain_name => '1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4989] 
dhcp4 (wlo1): option requested_domain_name_servers => '1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4989] 
dhcp4 (wlo1): option requested_domain_search => '1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4990] 
dhcp4 (wlo1): option requested_host_name  => '1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4990] 
dhcp4 (wlo1): option requested_interface_mtu => '1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4990] 
dhcp4 (wlo1): option requested_ms_classless_static_routes => '1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4991] 
dhcp4 (wlo1): option requested_nis_domain => '1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4991] 
dhcp4 (wlo1): option requested_nis_servers => '1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4991] 
dhcp4 (wlo1): option requested_ntp_servers => '1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4991] 
dhcp4 (wlo1): option requested_rfc3442_classless_static_routes => '1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4992] 
dhcp4 (wlo1): option requested_root_path  => '1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4992] 
dhcp4 (wlo1): option requested_routers=> '1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4992] 
dhcp4 (wlo1): option requested_static_routes => '1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4992] 
dhcp4 (wlo1): option requested_subnet_mask => '1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4993] 
dhcp4 (wlo1): option requested_time_offset => '1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4993] 
dhcp4 (wlo1): option requested_wpad   => '1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4993] 
dhcp4 (wlo1): option routers  => '192.168.0.1'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4993] 
dhcp4 (wlo1): option subnet_mask  => '255.255.255.0'
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.4994] 
dhcp4 (wlo1): state changed unknown -> bound
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.5042] 
device (wlo1): state change: ip-config -> ip-check (reason 'none', 
sys-iface-state: 'managed')
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.5101] 
device (wlo1): state change: ip-check -> secondaries (reason 'none', 
sys-iface-state: 'managed')
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.5111] 
device (wlo1): state change: secondaries -> activated (reason 'none', 
sys-iface-state: 'managed')
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.5129] 
manager: NetworkManager state is now CONNECTED_LOCAL
Nov 04 09:47:04 debian NetworkManager[2085]:   [1604479624.5207] 
manager: NetworkManager state is now CONNECTED_SITE
Nov 04 09:47:04 debian NetworkManager[2085]:   

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

2020-11-04 Thread Antonio Terceiro
Hi Daniel,

On Wed, Nov 04, 2020 at 03:45:34AM +0100, Daniel Leidert wrote:
> 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.

when I wrote ruby-launchy-shim, I did it because launchy itself had a
lot of dependencies, and most if code, just to support other non-Debian
systems. I don't remember exactly but there was probably other
compliation that make it so it was easier for me to just write a shim
that has the same API as the original package and does what is needed on
Debian.

I don't really care what happens; if you decide to drop it and replace
with the real launchy, feel free to go ahead.

Just note that there are a few packages that explicitly depend on -shim:

$ reverse-depends ruby-launchy-shim
Reverse-Depends
* ruby-email-spec
* ruby-letter-opener



signature.asc
Description: PGP signature


Bug#972585: Patch proposition to clean temporary git checkout

2020-11-04 Thread Julien Puydt
Hi,

I was busier than expected, but here is a patch proposition.

Cheers,

JP
Description: fix bug #972585
Author: Julien Puydt
Forwarded: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972585

--- devscripts-2.20.4.orig/lib/Devscripts/Uscan/Downloader.pm
+++ devscripts-2.20.4/lib/Devscripts/Uscan/Downloader.pm
@@ -188,6 +188,8 @@
 uscan_die "Unknown suffix file to repack: $suffix";
 }
 chdir "$curdir" or uscan_die("Unable to chdir($curdir): $!");
+
+	uscan_exec_no_fail('rm', '-fr', $gitrepo_dir);
 }
 return 1;
 }


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

2020-11-04 Thread Hilmar Preuße


Am 04.11.2020 um 14:32 teilte Hilmar Preuße mit:

Hi Norbert,


In the perl script the variable SELFAUTOPARENT expands to "/".

hille@debian-amd64-sid:/etc$ kpsewhich -var-value=SELFAUTOPARENT /

Hence the perl module is not found.
In [1] Norbert suggested to replace SELFAUTOPARENT by TEXMFROOT.


H.

[1] https://tug.org/pipermail/tex-live/2020-May/045767.html
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature


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

2020-11-04 Thread Hilmar Preuße


Am 04.11.2020 um 03:55 teilte Joachim Zobel mit:

Hi,

> $ 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




BEGIN failed--compilation aborted at /usr/bin/bbl2bib line 110.


In the perl script the variable SELFAUTOPARENT expands to "/".

hille@debian-amd64-sid:/etc$ kpsewhich -var-value=SELFAUTOPARENT
/

Hence the perl module is not found.

H.
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature


Bug#970227: Debugging vs Optimization

2020-11-04 Thread Barak A. Pearlmutter
Thanks for noticing that unfortunate interaction.

These should ideally be largely orthogonal, of course.
I'll check w/ upstream and see what the right thing is.
Maybe they can add a half-hearted-debugging option, which enables
debugging stuff that won't interfere with optimization or performance.

Cheers.

--Barak.



Bug#901307: sphinx-gallery: please make the build mostly reproducible

2020-11-04 Thread Chris Lamb
Chris Lamb wrote:

> [..]

Friendly ping on this?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-



  1   2   >