Bug#980671: bmtk: FTBFS: Signal: Aborted (6)

[Andreas Tille]

Control: severity -1 important

On Thu, Jan 21, 2021 at 10:49:20PM +0100, Étienne Mollier wrote:
> Control: tag -1 moreinfo
> Control: tag -1 unreproducible
> ...
> Anyone else is able to reproduce the problem ?

The package builds nicely in my pbuilder chroot as well.  So I'm
setting severity from serious to important.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#980477: RFA: libzstd1 -- fast lossless compression algorithm

[Peter Pentchev]

On Tue, Jan 19, 2021 at 04:04:16PM +0100, Alex Mestiashvili wrote:
> Package: wnpp
> Severity: normal
> 
> I am looking for a new maintainer/co-maintainer for libzstd.
> Initially it was packaged by the Debian-Med team as a dependency, but now
> this library is also used in many other packages.
> It doesn't fit Debian-Med namespace anymore and it would be better if
> another team would adopt it.

Hi,

I'd be happy to step in as (co-)maintainer, or, if you prefer, we could
move the package to the pkg-rpm team, where the recently packaged
libdrpm and libzchunk depend on it.

Thanks a lot for taking care of libzstd in Debian!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#980782: Info received (Bug#980782: Acknowledgement (os-prober: linux-boot-prober returning "root=/dev/dm-X" line instead of expected "root=UUID=[UUID128]))

[Nicholas D Steeves]

Mirko Vogt  writes:

> Looking at /usr/share/initramfs-tools/scripts/local-top/lvm2 more 
> closely, passing a UUID also wouldn't trigger a `vgchange -ay` here.
> But a path like /dev/mapper/X would.
> So maybe the question is rather: how to make os-prober return a 
> "root=/dev/mapper/X" line instead of one containing a UUID(?)

The first thing that comes to mind is:

For a given UUID
  run blkid, and exclude all lines that do not match the UUID
  count lines and error if there are duplicates
(it probably already does this, and I think the risk of collisions
 most significant for short UUIDs like FAT has)
  as part of that regex, check for ^/dev/mapper, with that anchor
  use /dev/mapper/X for the truly unique UUID


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#980784: pp_dpm_mclk Always at Maximun gpu memory clock frecuency

[Sergio Zamora]

ting subject to 'linux-image-5.10.0-1-amd64: none'
Gathering additional data, this may take a while...
Use sudo to read the kernel log? y
[sudo] password for *:

Include network configuration and status from this computer? n
Saving a backup of the report at
/tmp/reportbug-linux-image-5.10.0-1-amd64-backup-20210121-14638-lsh9jl2v
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: @debian.org>
To: Debian Bug Tracking System 
Subject: linux-image-5.10.0-1-amd64: none

Package: src:linux
Version: 5.10.4-1
Severity: normal
X-Debbugs-Cc: none

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:
** Version:
Linux version 5.10.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10
(Debian 10.2.1-3) 10.2.1 20201224, GNU ld (GNU Binutils for Debian) 2.35.1)
#1 SMP Debian 5.10.4-1 (2020-12-31)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-1-amd64
root=UUID=7af4ef7f-8aaa-4cdf-a8c3-13cf44952a8a ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 81NB
product_version: Lenovo IdeaPad S340-14API
chassis_vendor: LENOVO
chassis_version: Lenovo IdeaPad S340-14API
bios_vendor: LENOVO
bios_version: AMCN28WW(V1.11)
board_vendor: LENOVO
board_name: LNVNB161216
board_version: SDK0J40679 WIN

** Loaded modules:
nft_chain_nat
xt_MASQUERADE
nf_nat
nf_conntrack_netlink
xfrm_user
xfrm_algo
br_netfilter
bridge
stp
llc
ctr
ccm
rfcomm
snd_seq_dummy
snd_hrtimer
snd_seq
snd_seq_device
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
videodev
mc
overlay
cmac
algif_hash
algif_skcipher
af_alg
bnep
cpufreq_userspace
cpufreq_conservative
cpufreq_powersave
btusb
cpufreq_ondemand
btrtl
btbcm
btintel
bluetooth
jitterentropy_rng
edac_mce_amd
joydev
drbg
kvm_amd
snd_hda_codec_realtek
kvm
snd_hda_codec_generic
ledtrig_audio
snd_hda_codec_hdmi
ath10k_pci
ath10k_core
nls_ascii
snd_hda_intel
nls_cp437
ansi_cprng
snd_intel_dspcfg
vfat
soundwire_intel
irqbypass
ecdh_generic
ecc
fat
ath
soundwire_generic_allocation
ghash_clmulni_intel
snd_soc_core
mac80211
snd_compress
nf_log_ipv6
soundwire_cadence
ip6t_REJECT
nf_reject_ipv6
aesni_intel
snd_hda_codec
xt_hl
snd_hda_core
ip6_tables
libaes
snd_hwdep
crypto_simd
soundwire_bus
cryptd
ip6t_rt
glue_helper
snd_pcm
rapl
sg
snd_rn_pci_acp3x
wmi_bmof
snd_timer
hid_multitouch
efi_pstore
snd_pci_acp3x
pcspkr
serio_raw
cfg80211
sp5100_tco
snd
watchdog
k10temp
nf_log_ipv4
soundcore
nf_log_common
ipt_REJECT
ccp
nf_reject_ipv4
xt_LOG
libarc4
ideapad_laptop
sparse_keymap
rfkill
nft_limit
ac
tpm_crb
tpm_tis
tpm_tis_core
tpm
rng_core
evdev
acpi_cpufreq
xt_limit
xt_addrtype
xt_tcpudp
xt_conntrack
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
nft_compat
nft_counter
msr
nf_tables
parport_pc
ppdev
lp
nfnetlink
parport
fuse
configfs
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid1
raid0
multipath
linear
md_mod
sd_mod
hid_generic
amdgpu
gpu_sched
i2c_algo_bit
ttm
drm_kms_helper
ahci
libahci
rtsx_pci_sdmmc
mmc_core
libata
cec
xhci_pci
xhci_hcd
drm
scsi_mod
nvme
usbcore
crc32_pclmul
crc32c_intel
nvme_core
rtsx_pci
t10_pi
crc_t10dif
i2c_piix4
crct10dif_generic
usb_common
crct10dif_pclmul
crct10dif_common
wmi
i2c_hid
battery
hid
video
button

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2
Root Complex [1022:15d0]
Subsystem: Lenovo Raven/Raven2 Root Complex [17aa:380c]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 

00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:01.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2
PCIe GPP Bridge [6:0] [1022:15d3] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:0

Bug#980756: RFS: pynpoint/0.9.0-1 -- Pipeline for processing and analysis of high-contrast imaging data

[Adam Borowski]

On Thu, Jan 21, 2021 at 07:21:54PM +0100, Gürkan Myczko wrote:
>  * Package name: pynpoint
>Version : 0.9.0-1

>  pynpoint (0.9.0-1) unstable; urgency=medium
>  .
>* New upstream version.
>* d/patches: dropped as it was upstreamed.

Alas, autopkgtests fail with something that smells like a problem with
astropy:

autopkgtest [23:28:36]: test autodep8-python3: [---
Testing with python3.9:
/usr/lib/python3/dist-packages/astropy/config/configuration.py:582: 
ConfigurationMissingWarning: Configuration defaults will be used due to 
FileNotFoundError:2 on None
  warn(ConfigurationMissingWarning(msg))
WARNING: CacheMissingWarning: Remote data cache could not be accessed due to 
FileNotFoundError: [Errno 2] No such file or directory: 
'/home/kilobyte/.astropy' [astropy.utils.data]
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pynpoint/__init__.py", line 5, in 

from pynpoint.processing.background import 
SimpleBackgroundSubtractionModule, \
  File "/usr/lib/python3/dist-packages/pynpoint/processing/background.py", line 
17, in 
from pynpoint.util.apply_func import subtract_line
  File "/usr/lib/python3/dist-packages/pynpoint/util/apply_func.py", line 34, 
in 
from pynpoint.util.wavelets import WaveletAnalysisCapsule
  File "/usr/lib/python3/dist-packages/pynpoint/util/wavelets.py", line 19, in 

def _fast_zeros(soft: bool,
  File "/usr/lib/python3/dist-packages/numba/core/decorators.py", line 214, in 
wrapper
disp.enable_caching()
  File "/usr/lib/python3/dist-packages/numba/core/dispatcher.py", line 781, in 
enable_caching
self._cache = FunctionCache(self.py_func)
  File "/usr/lib/python3/dist-packages/numba/core/caching.py", line 616, in 
__init__
self._impl = self._impl_class(py_func)
  File "/usr/lib/python3/dist-packages/numba/core/caching.py", line 351, in 
__init__
raise RuntimeError("cannot cache function %r: no locator available "
RuntimeError: cannot cache function '_fast_zeros': no locator available for 
file '/usr/lib/python3/dist-packages/pynpoint/util/wavelets.py'
autopkgtest [23:28:39]: test autodep8-python3: ---]


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

Bug#980783: RFP: literate-git -- Render hierarchical git repositories into HTML

[Francois Marier]

Package: wnpp
Severity: wishlist

* Package name: literate-git
  Version : 0.3.1
  Upstream Author : Ben North 
* URL : https://github.com/bennorth/literate-git/
* License : GPL-3.0-or-later
  Programming Lang: Python
  Description : Tool to render a hierarchical git history into HTML

Bug#739289: unicon is already ITA

[肖盛文]

The unicon package is already ITA  and team maintained by Debian Chinese 
Team  now.



--
肖盛文 xiao sheng wen Faris Xiao
微信(wechat)：atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x00186602339240CB



OpenPGP_0x00186602339240CB.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#980782: Info received (Bug#980782: Acknowledgement (os-prober: linux-boot-prober returning "root=/dev/dm-X" line instead of expected "root=UUID=[UUID128]))

[Mirko Vogt]

Looking at /usr/share/initramfs-tools/scripts/local-top/lvm2 more 
closely, passing a UUID also wouldn't trigger a `vgchange -ay` here.

But a path like /dev/mapper/X would.
So maybe the question is rather: how to make os-prober return a 
"root=/dev/mapper/X" line instead of one containing a UUID(?)

Bug#980782: Acknowledgement (os-prober: linux-boot-prober returning "root=/dev/dm-X" line instead of expected "root=UUID=[UUID128])

[Mirko Vogt]

Just adding, this isn't only a feature request but results in 
non-bootable systems.
If one of the os-probe'd systems e.g. is also a Debian, it will drop 
into an initramfs due to not finding the root device.
This is due to - within the initramfs - the VGs as part of the the LVM 
system only get activated by certain naming schemes 
("/usr/share/initramfs-tools/scripts/local-top/lvm2").
It tries ti figure out whether the rootfs resides on a LVM and if it 
thinks it doesn't, the respective VG won't be activated, resulting in 
the passed /dev/dm-X block device not being available.

Bug#967537: forward this bug to upstream

[肖盛文]

Forward this bug to the upstream:

https://github.com/iptux-src/iptux/issues/307

--
肖盛文 xiao sheng wen Faris Xiao
微信(wechat)：atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x00186602339240CB



OpenPGP_0x00186602339240CB.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#833928: no more feedback

[肖盛文]

no more feedback  than half  year, so close this bug.


--
肖盛文 xiao sheng wen Faris Xiao
微信(wechat)：atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x00186602339240CB



OpenPGP_0x00186602339240CB.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#980782: os-prober: linux-boot-prober returning "root=/dev/dm-X" line instead of expected "root=UUID=[UUID128]

[Mirko Vogt]

Package: os-prober

Version: 1.77

Severity: important



I noticed when running update-grub on Debian stable and testing, that

the resulting grub.cfg has lines as part of menuentres like:



"linux [..] root=/dev/dm-X"



for found linux installations on other block devices - in my case 
residing on LVs - ,instead of "root=UUID=[XXX]", which I'd have expected 
(and would favour).


This is due to `linux-boot-prober` calling `mapdevfs` defined in

"/usr/share/os-prober/common.sh".

`mapdevfs` does a simple `readlink` on the path given.

The other lines within the menuentry look fine, e.g.:

"set root='lvmid/XX/YY'"

or

"search [..] --set=root [UUID]"



GRUB_DISABLE_LINUX_UUID is undefined.


Is this intentional and if so, why?


-- System Information:

Debian Release: bullseye/sid

  APT prefers testing

  APT policy: (900, 'testing')

Architecture: amd64 (x86_64)



Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)

Kernel taint flags: TAINT_USER, TAINT_WARN

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 os-prober depends on:

ii  grub-common  2.04-12

ii  libc62.31-9



os-prober recommends no packages.



os-prober suggests no packages.



-- no debconf information

Bug#980781: w3c-markup-validator: conflicts with WeBWorK 2.15 install; Apache2 fails

[Justine Leon Uro]

Package: w3c-markup-validator
Version: 1.3+dfsg-4
Severity: important
Tags: a11y

Dear Maintainer,

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

I installed w3c-markup-validator in Debian 10 Skolelinux and this led to
Apache2 failing to start because of some consequent problem with my WeBWorK
2.15 install.

I uninstalled this package together with the other packages (libencode-
jis2k-perl, libhtml-encoding-perl, libhtml-tidy-perl, libset-intspan-perl,
libsgml-parser-opensp-perl, and w3c-sgml-libthat) that were no longer needed
after this package had been uninstalled and Apache2 started properly again.

The output on the terminal related to the install was:
# apt install w3-recs w3c-linkchecker w3c-markup-validator
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libcss-dom-perl libencode-hanextra-perl libencode-jis2k-perl libhtml-
encoding-perl libhtml-tidy-perl libset-intspan-perl libsgml-parser-opensp-perl
  w3c-sgml-lib
Suggested packages:
  libwebservice-validator-html-w3c-perl libtest-html-w3c-perl
The following NEW packages will be installed:
  libcss-dom-perl libencode-hanextra-perl libencode-jis2k-perl libhtml-
encoding-perl libhtml-tidy-perl libset-intspan-perl libsgml-parser-opensp-perl
  w3-recs w3c-linkchecker w3c-markup-validator w3c-sgml-lib
0 upgraded, 11 newly installed, 0 to remove and 0 not upgraded.
Need to get 39.7 MB of archives.
After this operation, 219 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://deb.debian.org/debian buster/main amd64 libcss-dom-perl all 0.17-1
[111 kB]
Get:2 http://deb.debian.org/debian buster/main amd64 libencode-hanextra-perl
amd64 0.23-5+b1 [1,514 kB]
Get:3 http://deb.debian.org/debian buster/main amd64 libencode-jis2k-perl amd64
0.03-1+b5 [315 kB]
Get:4 http://deb.debian.org/debian buster/main amd64 libhtml-encoding-perl all
0.61-2 [19.8 kB]
Get:5 http://deb.debian.org/debian buster/main amd64 libhtml-tidy-perl amd64
1.60-4 [21.2 kB]
Get:6 http://deb.debian.org/debian buster/main amd64 libset-intspan-perl all
1.19-1 [26.7 kB]
Get:7 http://deb.debian.org/debian buster/main amd64 libsgml-parser-opensp-perl
amd64 0.994-3+b6 [48.2 kB]
Get:8 http://deb.debian.org/debian buster/non-free amd64 w3-recs all 20110107-1
[35.1 MB]
Get:9 http://deb.debian.org/debian buster/main amd64 w3c-linkchecker all
4.81-10 [59.8 kB]
Get:10 http://deb.debian.org/debian buster/main amd64 w3c-sgml-lib all 1.3-2
[277 kB]
Get:11 http://deb.debian.org/debian buster/main amd64 w3c-markup-validator all
1.3+dfsg-4 [2,223 kB]
Fetched 39.7 MB in 7s (5,825 kB/s)
Preconfiguring packages ...
Selecting previously unselected package libcss-dom-perl.
(Reading database ... 683013 files and directories currently installed.)
Preparing to unpack .../00-libcss-dom-perl_0.17-1_all.deb ...
Unpacking libcss-dom-perl (0.17-1) ...
Selecting previously unselected package libencode-hanextra-perl.
Preparing to unpack .../01-libencode-hanextra-perl_0.23-5+b1_amd64.deb ...
Unpacking libencode-hanextra-perl (0.23-5+b1) ...
Selecting previously unselected package libencode-jis2k-perl.
Preparing to unpack .../02-libencode-jis2k-perl_0.03-1+b5_amd64.deb ...
Unpacking libencode-jis2k-perl (0.03-1+b5) ...
Selecting previously unselected package libhtml-encoding-perl.
Preparing to unpack .../03-libhtml-encoding-perl_0.61-2_all.deb ...
Unpacking libhtml-encoding-perl (0.61-2) ...
Selecting previously unselected package libhtml-tidy-perl.
Preparing to unpack .../04-libhtml-tidy-perl_1.60-4_amd64.deb ...
Unpacking libhtml-tidy-perl (1.60-4) ...
Selecting previously unselected package libset-intspan-perl.
Preparing to unpack .../05-libset-intspan-perl_1.19-1_all.deb ...
Unpacking libset-intspan-perl (1.19-1) ...
Selecting previously unselected package libsgml-parser-opensp-perl.
Preparing to unpack .../06-libsgml-parser-opensp-perl_0.994-3+b6_amd64.deb ...
Unpacking libsgml-parser-opensp-perl (0.994-3+b6) ...
Selecting previously unselected package w3-recs.
Preparing to unpack .../07-w3-recs_20110107-1_all.deb ...
Unpacking w3-recs (20110107-1) ...
Selecting previously unselected package w3c-linkchecker.
Preparing to unpack .../08-w3c-linkchecker_4.81-10_all.deb ...
Unpacking w3c-linkchecker (4.81-10) ...
Selecting previously unselected package w3c-sgml-lib.
Preparing to unpack .../09-w3c-sgml-lib_1.3-2_all.deb ...
Unpacking w3c-sgml-lib (1.3-2) ...
Selecting previously unselected package w3c-markup-validator.
Preparing to unpack .../10-w3c-markup-validator_1.3+dfsg-4_all.deb ...
Unpacking w3c-markup-validator (1.3+dfsg-4) ...
Setting up libencode-jis2k-perl (0.03-1+b5) ...
Setting up libcss-dom-perl (0.17-1) ...
Setting up w3c-sgml-lib (1.3-2) ...
Setting up libset-intspan-perl (1.19-1) ...
Setting up w3-recs (20110107-1) ...
Setting up libhtml-tidy-perl (1.60-4) ...
Setting up libhtml-encoding-perl (0.61-2) ...
Setting up libsgml-parser-opensp-perl 

Bug#980161: tex-common fails to update to 6.15 - fmtutil failed

[Dario Andres Susman]

Hi Hilmar!
Thank you for answering.

There's plenty of space, but, indeed, there seems to be something wrong 
with my box.

I re-tried to upgrade and it worked.

Disk space:
root@warpcore:~# df -h
Filesystem  Size  Used Avail Use% Mounted on
udev    3.8G 0  3.8G   0% /dev
tmpfs   786M  3.0M  783M   1% /run
/dev/sda1   106G   19G   82G  19% /
tmpfs   5.0M  8.0K  5.0M   1% /run/lock
tmpfs   2.5G  8.0K  2.5G   1% /dev/shm
/dev/sdb1   932G  594G  338G  64% /mnt/WDBLUE1TB
tmpfs   786M 0  786M   0% /run/user/1000
root@warpcore:~#

I've reinstalled the packages now, for good measure, but I think I may 
have to reinstall all packages on this box now :S


root@warpcore:~# dpkg -S  File/Spec
libperl5.32:amd64: /usr/lib/x86_64-linux-gnu/perl/5.32.0/File/Spec/Unix.pm
libperl5.32:amd64: /usr/lib/x86_64-linux-gnu/perl/5.32.0/File/Spec/VMS.pm
libperl5.32:amd64: /usr/lib/x86_64-linux-gnu/perl/5.32.0/File/Spec/OS2.pm
libperl5.32:amd64: /usr/lib/x86_64-linux-gnu/perl/5.32.0/File/Spec/Epoc.pm
libperl5.32:amd64: /usr/lib/x86_64-linux-gnu/perl/5.32.0/File/Spec/Win32.pm
libperl5.32:amd64: /usr/lib/x86_64-linux-gnu/perl/5.32.0/File/Spec/Mac.pm
libperl5.32:amd64: /usr/lib/x86_64-linux-gnu/perl/5.32.0/File/Spec
libperl5.32:amd64: 
/usr/lib/x86_64-linux-gnu/perl/5.32.0/File/Spec/Functions.pm
libperl5.32:amd64: 
/usr/lib/x86_64-linux-gnu/perl/5.32.0/File/Spec/AmigaOS.pm

libperl5.32:amd64: /usr/lib/x86_64-linux-gnu/perl/5.32.0/File/Spec.pm
perl-base: /usr/lib/x86_64-linux-gnu/perl-base/File/Spec/Unix.pm
libperl5.32:amd64: /usr/lib/x86_64-linux-gnu/perl/5.32.0/File/Spec/Cygwin.pm
perl-base: /usr/lib/x86_64-linux-gnu/perl-base/File/Spec.pm
perl-base: /usr/lib/x86_64-linux-gnu/perl-base/File/Spec
root@warpcore:~#

Again, thank you for answering.

Best regards,
Dario Susman

On 21/01/2021 19:43, Hilmar Preuße wrote:

Am 21.01.2021 um 15:34 teilte Dario Susman mit:

Hi,


Processing triggers for tex-common (6.15) ...
Building format(s) --all.
 This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.c2VqiZHg
Please include this file if you report a bug.
 dpkg: error 
processing package tex-common (--configure):
  installed tex-common package post-installation script subprocess 
returned error

Processing triggers for libapache2-mod-php7.4 (7.4.14-1) ...
Errors were encountered while processing:
  tex-common
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)


The error message is:

Can't locate object method "splitpath" via package "File::Spec" at 
/usr/lib/x86_64-linux-gnu/perl-base/File/Temp.pm line 410.


It gives the idea that your perl installation is heavily broken. Could 
you check if there is enough disk space and re-install the perl 
packages perl-base & libperl5.32?

What is the output of "dlocate File/Spec"?

Hilmar





OpenPGP_signature
Description: OpenPGP digital signature

Bug#980780: mpv: Slow performance when startup

[Tee Zhen Cong]

Package: mpv
Version: 0.29.1-1
Severity: important

Dear Maintainer,

Mpv takes around 2 to 3 seconds to startup even only run --help
command without running any video. This only happens in Debian 10. In
Debian 9 and Debian 8, mplayer (predecessor of mpv) runs in less than 1
second.

when check with strace, we found out that each of the library loaded by
mpv, it will do multiple llseek and read at same location. Sometimes it
loads up to 5 or 6 times at same location. Mpv has many libraries and
this causes the slowness of startup of mpv. Example of strace as below:

openat(AT_FDCWD, "/usr/lib/arm-linux-gnueabi/libsndio.so.7.0", 
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\330!\0\0004\0\0\0"..., 
512) = 512
_llseek(3, 49656, [49656], SEEK_SET)= 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1000) = 1000
_llseek(3, 49328, [49328], SEEK_SET)= 0
read(3, "A(\0\0\0aeabi\0\1\36\0\0\0\0055TE\0\6\4\10\1\t\1\22\4\24\1\25"..., 41) 
= 41
_llseek(3, 49656, [49656], SEEK_SET)= 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1000) = 1000
_llseek(3, 49328, [49328], SEEK_SET)= 0
read(3, "A(\0\0\0aeabi\0\1\36\0\0\0\0055TE\0\6\4\10\1\t\1\22\4\24\1\25"..., 41) 
= 41
_llseek(3, 49656, [49656], SEEK_SET)= 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1000) = 1000
_llseek(3, 49328, [49328], SEEK_SET)= 0
read(3, "A(\0\0\0aeabi\0\1\36\0\0\0\0055TE\0\6\4\10\1\t\1\22\4\24\1\25"..., 41) 
= 41
_llseek(3, 49656, [49656], SEEK_SET)= 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1000) = 1000
_llseek(3, 49328, [49328], SEEK_SET)= 0
read(3, "A(\0\0\0aeabi\0\1\36\0\0\0\0055TE\0\6\4\10\1\t\1\22\4\24\1\25"..., 41) 
= 41
_llseek(3, 49656, [49656], SEEK_SET)= 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1000) = 1000
_llseek(3, 49328, [49328], SEEK_SET)= 0
read(3, "A(\0\0\0aeabi\0\1\36\0\0\0\0055TE\0\6\4\10\1\t\1\22\4\24\1\25"..., 41) 
= 41
_llseek(3, 49656, [49656], SEEK_SET)= 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
1000) = 1000
_llseek(3, 49328, [49328], SEEK_SET)= 0
read(3, "A(\0\0\0aeabi\0\1\36\0\0\0\0055TE\0\6\4\10\1\t\1\22\4\24\1\25"..., 41) 
= 41

In fact, we checked and found out that running other applications in Debian10
also has this issue. Debian 9 and Debian 8 does not have the same issue.

Please help. Thank you

-- System Information:
Debian Release: 10.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armel (armv7l)

Kernel: Linux 5.4.24 (SMP w/2 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mpv depends on:
ii  libarchive13  3.3.3-4+deb10u1
ii  libasound21.1.8-1
ii  libass9   1:0.14.0-2
ii  libatomic18.3.0-6
ii  libavcodec58  7:4.1.6-1~deb10u1
ii  libavdevice58 7:4.1.6-1~deb10u1
ii  libavfilter7  7:4.1.6-1~deb10u1
ii  libavformat58 7:4.1.6-1~deb10u1
ii  libavutil56   7:4.1.6-1~deb10u1
ii  libbluray21:1.1.0-1
ii  libc6 2.28-10
ii  libcaca0  0.99.beta19-2.1
ii  libcdio-cdda2 10.2+0.94+2-4
ii  libcdio-paranoia2 10.2+0.94+2-4
ii  libcdio18 2.0.0-2
ii  libdrm2   2.4.97-1
ii  libdvdnav46.0.0-1
ii  libdvdread4   6.0.1-1
ii  libegl1   1.1.0-1
ii  libgbm1   18.3.6-2+deb10u1
ii  libgl11.1.0-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  liblcms2-22.9-3
ii  liblua5.2-0   5.2.4-1.1+b2
ii  libpulse0 12.2-4+deb10u1
ii  librubberband21.8.1-7
ii  libsdl2-2.0-0 2.0.9+dfsg1-1
ii  libsmbclient  2:4.9.5+dfsg-5
ii  libsndio7.0   1.5.0-3
ii  libswresample37:4.1.6-1~deb10u1
ii  libswscale5   7:4.1.6-1~deb10u1
ii  libuchardet0  0.0.6-3
ii  libva-drm22.4.0-1
ii  libva-wayland22.4.0-1
ii  libva-x11-2   2.4.0-1
ii  libva22.4.0-1
ii  libvdpau1 1.1.1-10
ii  libvulkan11.1.97-2
ii  libwayland-client01.16.0-1
ii  libwayland-cursor0

Bug#980247: marked as pending in lintian

[Felix Lechner]

Hi Axel,

On Thu, Jan 21, 2021 at 5:57 PM Axel Beckert  wrote:
>
> Noticed that and despite I'm bit annoyed of all the renamings

As pointed out on d-d today, most renames took place as a result of
two bug reports requesting more consistency. One was about shared
libraries, the other was a request from the Dpkg maintainer, if I
recall correctly.

> Small typo: transposed letters in my given name.

Alex, sorry about that. With some luck you only only have to tell me
once. Please accept my apologies!

> > also for remaining one of our most active bug reporters!

I know you can commit; no slight intended. Maybe I just notice your
reports because they are so well written and show an overarching
concern for the product. I usually fix them quickly. Thank you!

Kind regards
Felix Lechner (plus my son Lee Lechner, who insisted on typing his own name!)

Bug#980779: incompatible with python 3.9 - syntax error

[Yaroslav Halchenko]

Package: python3-uritemplate
Version: 0.6-4
Severity: important

Got following exception with python3.9 (now default for python3) while trying
to run the tests for our code where we react to deprecation warnings etc

...
venvs/dev3/lib/python3.9/site-packages/pyout/__init__.py:10: in 
from pyout.elements import schema
venvs/dev3/lib/python3.9/site-packages/pyout/elements.py:5: in 
import jsonschema
/usr/lib/python3/dist-packages/jsonschema/__init__.py:14: in 
from jsonschema._format import (
/usr/lib/python3/dist-packages/jsonschema/_format.py:411: in 
import uritemplate.exceptions
E File "/usr/lib/python3/dist-packages/uritemplate/__init__.py", 
line 36
E   TEMPLATE = re.compile("{([^\}]+)}")
E ^
E   SyntaxError: invalid escape sequence \}


This package needs to react to two existing already reported where active
new maintainer upstream probably already addressed this issue:

  1) #945530  python-uritemplate: upstream have changed hands
  2) #974040  python3-uritemplate: New upstream version is available (new 
upstream maintainer)

at least looking at 
https://github.com/python-hyper/uritemplate/blob/master/uritemplate/template.py#L22
template_re = re.compile('{([^}]+)}')

it seems tobe kosher

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/12 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 python3-uritemplate depends on:
ii  python3  3.9.0-4

python3-uritemplate recommends no packages.

python3-uritemplate suggests no packages.

-- debconf-show failed

Bug#980442: gst-plugins-bad1.0: Security update DSA-4833-1 seen as downgrade by APT

[Philip Wyett]

On Fri, 2021-01-22 at 01:07 +, Philip Wyett wrote:
> On Thu, 2021-01-21 at 21:02 +, Philip Wyett wrote:
> > The hint here is the version '1.14.4-1deb10u1' when it should be
> > '1.14.4-1~deb10u1', the '~' is important and seems to be missing.
> > This
> > should be rectified with urgency and the update released.
> > 
> > Regards
> > 
> > Phil
> > 
> 
> Or instead of the '~' a '+'. Would have to dig the docs to see which
> would be the appropriate one for this update.
> 
> Regards
> 
> Phil
> 

Going by:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#bug-security-building

We are missing the '+', so the package version should most likely be
'1.14.4-1+deb10u1'.

Regards

Phil

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

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#980247: marked as pending in lintian

[Axel Beckert]

Hi Felix,

Felix Lechner wrote:
> Always print full path to patch files. (Closes: #980247)

Thanks!

> […] We are instead making tag names shorter, […]

Noticed that and despite I'm bit annoyed of all the renamings, I'm
still happy about the shorter tags, because in the end, shorter tag
names also help to make debian/changelog entries and git commit
messages shorter. :-)

> We sincerely hope that this solution is acceptable even though the
> issue was resolved against the filer's stated preference.

It was only a very minor preference, so it's totally fine. Thanks!

> Thank you to Alex Beckert

Small typo: transposed letters in my given name. (But I'm used to it
and I don't expect you to rewrite git history for that. :-)

> also for remaining one of our most active bug reporters!

Oh, I am? (I always have the feeling I should fix more lintian bugs
than report. But then again I often want at least a second opinion on
those I report. Because the obvious things like typos I fix directly
without bug report. :-)

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#973323: Boot failure triggered by USB on rockpro64-rk3399 and pinebook-pro-rk3399

[Jonathan Gray]

U-Boot 2020.07 worked, broken on rockpro64 by

commit 3ae64582fb8ceead4fc464cd2055eb3eaef78ccc (refs/bisect/bad)
Author: Jagan Teki 
Date:   Mon Jul 20 14:53:09 2020 +0530

rockchip: rockpro64: Enable USB3.0 Host

Enable USB3.0 Host support for RockPro64 boards.

Signed-off-by: Jagan Teki 
Reviewed-by: Kever Yang 

according to Kurt Miller who bisected this when the same problem was
encountered booting OpenBSD.  I don't have any rk3399 myself.

https://marc.info/?l=openbsd-ports=161005506031482=2
https://marc.info/?l=openbsd-ports=161012461223737=2

We ended up disabling CONFIG_USE_PREBOOT in rk3399 targets to fix
booting via non-usb as well.

On Thu, Jan 21, 2021 at 11:37:16AM +0800, Kever Yang wrote:
> Hi Vagrant,
> 
>     Do you know which version is the last version that works in this case?
> 
>     The firmware is from eMMC and it's wired for USB to affect the boot
> process.
> 
> Thanks,
> 
> - Kever
> 
> On 2021/1/21 上午8:08, Vagrant Cascadian wrote:
> > It seems rockpro64-rk3399 and pinebook-pro-rk3399 fail to boot when usb
> > is started. It hangs indefinitely at:
> > 
> >## Flattened Device Tree blob at 01f0
> >   Booting using the fdt blob at 0x1f0
> > 
> > I have observed this also using 2020.10 on rockpro64-rk3399, though on
> > pinebook-pro-rk3399 usb does not work and so it basically avoids
> > triggering the issue.
> > 
> > Setting CONFIG_USE_PREBOOT=n in the config works around the problem,
> > though obviously by breaking usb keyboard support or booting from USB
> > devices.
> > 
> > 
> > Related bugs in Debian and manjaro:
> > 
> >https://bugs.debian.org/973323
> >https://bugs.debian.org/980434
> >
> > https://gitlab.manjaro.org/manjaro-arm/packages/core/uboot-rockpro64/-/issues/4
> > 
> > 
> > Boot log:
> > 
> > U-Boot 2021.01+dfsg-1 (Jan 17 2021 - 03:50:13 +)
> > 
> > SoC: Rockchip rk3399
> > Reset cause: POR
> > Model: Pine64 RockPro64 v2.1
> > DRAM:  3.9 GiB
> > PMIC:  RK808
> > MMC:   mmc@fe31: 2, mmc@fe32: 1, sdhci@fe33: 0
> > Loading Environment from SPIFlash... SF: Detected gd25q128 with page size 
> > 256 Bytes, erase size 4 KiB, total 16 MiB
> > *** Warning - bad CRC, using default environment
> > 
> > In:serial
> > Out:   serial
> > Err:   serial
> > Model: Pine64 RockPro64 v2.1
> > Net:   eth0: ethernet@fe30
> > starting USB...
> > Bus usb@fe38: USB EHCI 1.00
> > Bus usb@fe3a: USB OHCI 1.0
> > Bus usb@fe3c: USB EHCI 1.00
> > Bus usb@fe3e: USB OHCI 1.0
> > Bus dwc3: usb maximum-speed not found
> > Register 2000140 NbrPorts 2
> > Starting the controller
> > USB XHCI 1.10
> > scanning bus usb@fe38 for devices... 1 USB Device(s) found
> > scanning bus usb@fe3a for devices... 1 USB Device(s) found
> > scanning bus usb@fe3c for devices... 1 USB Device(s) found
> > scanning bus usb@fe3e for devices... 1 USB Device(s) found
> > scanning bus dwc3 for devices... 1 USB Device(s) found
> > scanning usb for storage devices... 0 Storage Device(s) found
> > Hit any key to stop autoboot:  0
> > => printenv preboot
> > preboot=usb start
> > => usb reset
> > resetting USB...
> > Bus usb@fe38: USB EHCI 1.00
> > Bus usb@fe3a: USB OHCI 1.0
> > Bus usb@fe3c: USB EHCI 1.00
> > Bus usb@fe3e: USB OHCI 1.0
> > Bus dwc3: usb maximum-speed not found
> > Register 2000140 NbrPorts 2
> > Starting the controller
> > USB XHCI 1.10
> > scanning bus usb@fe38 for devices... 1 USB Device(s) found
> > scanning bus usb@fe3a for devices... 1 USB Device(s) found
> > scanning bus usb@fe3c for devices... 1 USB Device(s) found
> > scanning bus usb@fe3e for devices... 1 USB Device(s) found
> > scanning bus dwc3 for devices... 1 USB Device(s) found
> > scanning usb for storage devices... 0 Storage Device(s) found
> > => boot
> > Card did not respond to voltage select! : -110
> > switch to partitions #0, OK
> > mmc1 is current device
> > Scanning mmc 1:1...
> > Found /extlinux/extlinux.conf
> > Retrieving file: /extlinux/extlinux.conf
> > 144 bytes read in 5 ms (27.3 KiB/s)
> > 1:  Debian-Installer
> > Retrieving file: /initrd.gz
> > 28995285 bytes read in 1287 ms (21.5 MiB/s)
> > Retrieving file: /vmlinuz
> > 26922864 bytes read in 1195 ms (21.5 MiB/s)
> > Retrieving file: /dtbs/rockchip/rk3399-rockpro64.dtb
> > 56849 bytes read in 13 ms (4.2 MiB/s)
> > Moving Image from 0x208 to 0x220, end=3c5
> > ## Flattened Device Tree blob at 01f0
> > Booting using the fdt blob at 0x1f0
> > 
> > 
> > 
> > live well,
> >vagrant
> 
> 
> 

Bug#956811: [3dprinter-general] Bug#956811: Bug#956811: Confirmed

[Riccardo Gagliarducci]

Thank you Gregor,
I'm using Appimage (which works fine).
I plan to switch to Bullseye very soon: I will definitely try the package and 
post the results here.

However, I find these reports interesting: at least it is known that there is a 
problem with this package.
I've been using Debian for years, but I don't know what the package management 
policies are, I'd just like to point out
that right now, the package is useless.

If I try to run cura using:
QT_QUICK_CONTROLS_STYLE=material cura

I get a some warnings and the UI is still broken: 
https://www.brixelstudio.it/Cura.png


Thank you,
Riccardo

ps. I accidentally sent my personal data in a previous e-mail: I wrote to 
owner@... is it right? Who can I contact to
delete my phone number? Thanks!



On Thu, 21 Jan 2021 20:39:32 +0100 Gregor Riepl  wrote:
> > The stable debian Buster is shipping a very old version...
> > https://packages.debian.org/buster/cura
> 
> Well... I'm sorry to say, but it's very, very unlikely that buster will
> receive an updated Cura version. New package versions usually land in
> sid and testing, and a new Debian stable release will happen later this
> year anyway.
> 
> If you'd like to run a current version of Cura (that works a little bit
> better than the outdated one in buster), I warmly recommend that you
> update to bullseye now and help with testing. As a matter of fact, I
> think Debian testing is much more suited for desktop use than stable.
> 
> If you just want to "make it work", you can use the AppImage provided by
> UltiMaker, of course.
> 
> That being said, the rendering issue is still present in 4.8. If the
> upstream patch won't help, we'll have to go back and see if anything can
> be done on the Debian side.
> 
> In the meantime, can you try running Cura with the theme override I
> mentioned? Perhaps it will help for now.
>

Bug#980778: RFS: tnftp/20200705-2 -- enhanced ftp client

[肖盛文]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : tnftp
Version : 20200705-2
Upstream Author : Luke Mewburn 
* URL : http://en.wikipedia.org/wiki/Tnftp
* License : Unlicense
* Vcs : https://salsa.debian.org/debian/tnftp
Section : net

It builds those binary packages:

tnftp - enhanced ftp client

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/t/tnftp/tnftp_20200705-2.dsc


Changes since the last upload:

tnftp (20200705-2) unstable; urgency=medium
.
[ xiao sheng wen(肖盛文) ]
* d/control:
- Bump to Standards-Version: 4.5.1
- add Vcs-Browser Vcs-Git fields
* support cross build, Closes: #931163
- d/rules: minimal rules file
- add d/patches/001-for-dh_autoreconf.patch
* d/copyright: update debian/* copyright year to 2021
* add debian/upstream/metadata
* add d/clean

Regards,

--
肖盛文 xiao sheng wen Faris Xiao
微信(wechat)：atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x00186602339240CB



OpenPGP_0x00186602339240CB.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#980442: gst-plugins-bad1.0: Security update DSA-4833-1 seen as downgrade by APT

[Philip Wyett]

On Thu, 2021-01-21 at 21:02 +, Philip Wyett wrote:
> The hint here is the version '1.14.4-1deb10u1' when it should be
> '1.14.4-1~deb10u1', the '~' is important and seems to be missing.
> This
> should be rectified with urgency and the update released.
> 
> Regards
> 
> Phil
> 

Or instead of the '~' a '+'. Would have to dig the docs to see which
would be the appropriate one for this update.

Regards

Phil

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

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#971289: beaker: Switch to python3-pycryptodome

[Fabrice BAUZAC-STEHLY]

I think there are several issues:

The first issue is the mere presence of tests.  The source package has
code to run the upstream tests (via "nose"); that is precisely one of
the reasons for the Build-Depends on python3-crypto.  However, these
tests are not run (anymore) because upstream now strips the "tests/"
subdirectory from their PyPI tarball.  We should instead use the github
tarball, which contains the tests: see merge request [1].

  The alternative would be to give up trying to run tests, in which case
  we could already remove the test dependencies including the one on
  python3-crypto, fixing this bug.  But it is preferable to continue
  running the tests and ensure the quality of the package.

Then, to fix the current bug, we should migrate to python3-pycryptodome
instead of using python3-crypto.  Here is some context and information:

The http://www.pycryptodome.org/ project is a fork of venerable
PyCrypto (which provides "import Crypto").

pycryptodome.org provides two PyPI packages: cryptodome and
cryptodomex.

- cryptodome is a drop-in replacement for PyCrypto: it also provides
"import Crypto".  However, this also means that it cannot be installed
at the same time as PyCrypto.

- cryptodomex is a "clean" alternative to PyCrypto: it provides the
same features but as "import Cryptodome", so it can be installed
side-by-side with PyCrypto.

The beaker upstream uses cryptodome, but there is no Debian package
for that.  There is only Debian package python3-pycryptodome, which
provides cryptodomex.

So there is some work involved to make a patch so that beaker switches
to using "import Cryptodome" instead of "import Crypto".  I propose this
merge request [2].

[1] https://salsa.debian.org/python-team/packages/beaker/-/merge_requests/1
[2] https://salsa.debian.org/python-team/packages/beaker/-/merge_requests/2

Bug#962994: [pcp] Bug#962994: pcp: cron jobs launch pcp in cron's cgroup

[Nathan Scott]

Hi Sam,

On Wed, Jan 6, 2021 at 5:38 AM Sam Morris  wrote:
> [...]
>
> checking if systemd should be used... no
>
> I wish it was possible to see the config.log from this build... but at
> least I can reproduce this with pbuilder.
>
> Adding --with-systemd to the configure command line will promote this to
> a build error. I recommend making that change in debian/rules so that
> this doesn't fall through the cracks:

Agreed - will do.

> [...]
> And it's systemd that ships systemd.pc:
>
> $ dpkg -S /usr/share/pkgconfig/systemd.pc
> systemd: /usr/share/pkgconfig/systemd.pc

Aha!  I get it now - the libsystem-dev dependency is insufficient, we
need a dependency on systemd itself (as you say).  I'll get that fixed
up too.  Thanks!!!

cheers.

--
Nathan

Bug#980777: FIT-PC: Fails to find driver for Ethernet, Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI

[Charles Curley]

Package: installation-reports
Severity: normal
X-Debbugs-Cc: charlescur...@charlescurley.com

Dear Maintainer,

Please see Comments/Problems below.

-- Package-specific info:

Boot method: DVD
Image version: debian-bullseye-DI-alpha3-i386-DVD-1.iso
Date: Jan 20 2021 16:36 MST

Machine: FIT-PC 1 https://en.wikipedia.org/wiki/Fit-PC#fit-PC_1.0
Partitions: 

root@white:~# df -Tl
Filesystem Type  Size  Used Avail Use% Mounted on
udev   devtmpfs  108M 0  108M   0% /dev
tmpfs  tmpfs  23M  560K   22M   3% /run
/dev/sda6  ext2   55G  1.1G   51G   3% /
tmpfs  tmpfs 111M 0  111M   0% /dev/shm
tmpfs  tmpfs 5.0M 0  5.0M   0% /run/lock
tmpfs  tmpfs 4.0M 0  4.0M   0% /sys/fs/cgroup
/dev/sda1  ext2  236M   20M  204M   9% /boot
tmpfs  tmpfs  23M 0   23M   0% /run/user/0
/dev/sdb   vfat  1.4M  209K  1.2M  15% /media/disk
/dev/sdc1  vfat  2.0G  1.2G  748M  62% /mnt
root@white:~# fdisk -l /dev/sda
Disk /dev/sda: 55.89 GiB, 60011642880 bytes, 117210240 sectors
Disk model: Hitachi HTS54166
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0005c92c

Device Boot   Start   End   Sectors  Size Id Type
/dev/sda1  *   2048499711497664  243M 83 Linux
/dev/sda2501758 117209087 116707330 55.7G  5 Extended
/dev/sda5501760   1445887944128  461M 82 Linux swap / Solaris
/dev/sda6   1447936 117209087 115761152 55.2G 83 Linux
root@white:~# 


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

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

Comments/Problems:


I own three FIT-PC 1s, two of which provide network
services. https://en.wikipedia.org/wiki/Fit-PC#fit-PC_1.0 I'd like to
keep them running for a few more years yet. So I tried the alpha 3
installer.

In the process, I hit several problems.

* The NIC finding software failed to detect the two NICs. This has
  worked in the past.

* When I tried to select the driver manually, I was given a list of
  two NICs, neither one of them appropriate. On other hardware, a much
  longer list, including the ones I need (8139.*), appears.

* When I tried to read the drivers from a USB floppy device, the
  software did not find the floppy. This, in spite of the fact that I
  could mount the floppy manually and read the preseed file from
  it. The floppy drive should be /dev/sdb or sdc, depending on what
  else I have on the USB bus.

* When putting file systems on the hard drive, ext4 and ext3 were
  absent from the menu of possible file systems. ext2 was there, and
  that's what I selected and got.

Is something eating my menus?

The first two problems are not new. I got the same with a Buster 10.4
netinst CD. I then fell back to a Debian 8.6 netinst CD. That
correctly found and set up the two NICs.

Just in case I had hardware issues, I have tried this on two machines,
one of which has been in continuous service since I bought them.

-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20201202"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux (none) 5.9.0-4-686 #1 SMP Debian 5.9.11-1 (2020-11-27) i586 
GNU/Linux
lspci -knn: 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
CS5536 [Geode companion] Host Bridge [1022:2080] (rev 33)
lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD] CS5536 [Geode 
companion] Host Bridge [1022:2080]
lspci -knn: 00:01.1 VGA compatible controller [0300]: Advanced Micro Devices, 
Inc. [AMD] Geode LX Video [1022:2081]
lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD] Geode LX Video 
[1022:2081]
lspci -knn: 00:01.2 Entertainment encryption device [1010]: Advanced Micro 
Devices, Inc. [AMD] Geode LX AES Security Block [1022:2082]
lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD] Geode LX AES 
Security Block [1022:2082]
lspci -knn: Kernel modules: geode_rng
lspci -knn: 00:0d.0 Ethernet controller [0200]: 

Bug#980765: eigensoft: absolute path to fixgreen in /usr/bin/ploteig

[Tony Travis]

On 21/01/2021 20:22, Juhani Numminen wrote:

[...]
The bug system works by email, so I am forwarding this for filing there.
I'll also mark the bug fixed in a certain version because it looks like
the ploteig script disappeared at that point.

Even on Ubuntu, the reportbug package is supposed to work, sorry to hear
if does not. The command to use would be "reportbug -B debian eigensoft".


Hi, Juhani.

Thanks for forwarding my BUG report.

The problem with "reportbug" is that it needs an MTA configured on the 
system you are reporting from but most people like me using Ubuntu do 
not use "mutt" and a local MTA. Furthermore, the Ubuntu "apport" system 
is for reporting BUGs in Ubuntu and I realise that the Debian-Med team 
are the people doing the packaging of this software. I've also reported 
a BUG in "metaphlan2" to the Debian-Med list, but I will try my best to 
use "reportbug" again: The last time I tried I gave up in frustration!


Bye,

  Tony.

--
Minke Informatics Limited, Registered in Scotland - Company No. SC419028
Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK)
tel. +44(0)19755 63548http://minke-informatics.co.uk
mob. +44(0)7985 078324mailto:tony.tra...@minke-informatics.co.uk

Bug#980709: dolfin: FTBFS: tests failed

[Drew Parsons]

Lucas Nussbaum wrote:

Source: dolfin
Version: 2019.2.0~git20200629.946dbd3+lfs-4

...

During a rebuild of all packages in sid, your package failed to build
on amd64.


Hi Lucas, there have been various test failures associated with the 
recent openmpi upgrade.  They seem to be resolved now. debci now reports 
dolfin test success.


Your test log gives an odd error message.  Can you run your version of 
the test again to confirm if dolfin is now passing for you with the 
latest openmpi updates (including slepc 3.14.1+dfsg1-1+b1) ?



Drew

Bug#980775: yarnpkg is not compatible with node-uuid 7.0.0+

[anomie]

Package: yarnpkg
Version: 1.22.10+~cs22.25.14-1

>From https://www.npmjs.com/package/uuid/v/7.0.1#default-export-removed:

> Default Export Removed
>
> uuid@3 was exporting the Version 4 UUID method as a default export:
> 
> const uuid = require('uuid'); // <== REMOVED!
> 
> This usage pattern was already discouraged in uuid@3 and has been removed in 
> uuid@7.

But yarnpkg uses that pattern in src/resolvers/exotics/file-resolver.js,
src/cli/commands/install.js, and src/cli/commands/import.js.

This results in failures at runtime, for example

  $ mkdir -p /tmp/test/foo
  $ cd /tmp/test
  $ yes '' | yarn init
  yarn init v1.22.10
  question name (test): 
  question version (1.0.0): 
  question description: 
  question entry point (index.js): 
  question repository url: 
  question author: 
  question license (MIT): 
  question private: 
  success Saved package.json
  Done in 0.14s.
  $ yarn add file:foo
  yarn add v1.22.10
  info No lockfile found.
  [1/4] Resolving packages...
  error An unexpected error occurred: "Cannot read property 'v4' of undefined".
  info If you think this is a bug, please open a bug report with the 
information provided in "/tmp/test/yarn-error.log".
  info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this 
command.

Bug#980161: tex-common fails to update to 6.15 - fmtutil failed

[Hilmar Preuße]

Am 21.01.2021 um 15:34 teilte Dario Susman mit:

Hi,


Processing triggers for tex-common (6.15) ...
Building format(s) --all.
 This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.c2VqiZHg
Please include this file if you report a bug.
 
dpkg: error processing package tex-common (--configure):

  installed tex-common package post-installation script subprocess returned 
error
Processing triggers for libapache2-mod-php7.4 (7.4.14-1) ...
Errors were encountered while processing:
  tex-common
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)


The error message is:

Can't locate object method "splitpath" via package "File::Spec" at 
/usr/lib/x86_64-linux-gnu/perl-base/File/Temp.pm line 410.


It gives the idea that your perl installation is heavily broken. Could 
you check if there is enough disk space and re-install the perl packages 
perl-base & libperl5.32?

What is the output of "dlocate File/Spec"?

Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#980723: autopkgtests aren't being run for rust-sequoia-sqv or rust-sequoia-keyring-linter or rust-sequoia-sop

[Daniel Kahn Gillmor]

Control: reassign 980723 debcargo
Control: retitle 980723 debcargo-built binary crates have no way to run 
upstream tests
Control: affects 980723 + rust-sequoia-sqv rust-sequoia-sop 
rust-sequoia-keyring-linter

On Wed 2021-01-20 20:14:45 -0500, Daniel Kahn Gillmor wrote:
> I think this is because some rust packages needed specifically for
> testing are not available in the archive.

Hm, on further investigation, i think it is actually because the
debcargo-based packaging workflow just doesn't run cargo's tests on
binary-only crates.

The upstream tests associated with "cargo test" aren't run during the
build (dh_auto_test) on any crate, fwict, but they *are* run during the
autopkgtest.

I'm glad that they're run during autopkgtest because that means that
they can be re-run without a package rebuild when new versions of
dependencies are uploaded.

But, binary-only crates don't file any rust source in
/usr/share/cargo/registry/ so running (for example)

 /usr/share/cargo/bin/cargo-auto-test sequoia-sop 0.22.0

from an unpacked rust-sequoia-sop source tree just yields:

 crate directory not found: /usr/share/cargo/registry/sequoia-sop-0.22.0

so they aren't run in autopkgtest for binary-only crates.

I think we might need to rethink how debcargo handles the upstream tests
for binary-only crates.  Perhaps the dh --buildsystem cargo needs to
adjust how that's done?

weirdly, i note that rust-sequoia-sop 0.22 has these two lines in
debian/rules:

override_dh_auto_test:
dh_auto_test -- test --all

but rust-sequoia-sqv 1.0.0 does not.

Both source packages are assembled with debcargo 2.4.3, i think, and
their debcargo.toml files don't differ meaningfully.

 --dkg

Bug#980603: [3dprinter-general] Bug#980603: cura: FTBFS: cura/PrinterOutput/Models/MaterialOutputModel.py:6: error: Module 'PyQt5.QtCore' has no attribute 'pyqtProperty'

[Christoph Berg]

Re: Lucas Nussbaum
> > 14/14 Test  #1: code-style ...***Failed   61.38 sec
> > cura/PrinterOutput/Models/MaterialOutputModel.py:6: error: Module 
> > 'PyQt5.QtCore' has no attribute 'pyqtProperty'

Fwiw cura still works fine here, so I'd claim this is a test-only
problem which we should probably mute unless there's an easy fix.

Christoph

Bug#980554: lutris: Crash on first when opening ~/.local/share/lutris/runtime/dxvk/dxvk_versions.json

[Stephan Lachnit]

Control: tags confirmed fixed-upstream

I can confirm the behavior. It has nothing to do with an internet connection 
like I assumed before.
I'm upload a new version with a fix from upstream [1][2]. Thanks for reporting 
this.

Regards
Stephan Lachnit

[1] 
https://github.com/lutris/lutris/commit/1be0d6e5404068f5eeb8f6849f59b52e879f662a
[2] 
https://github.com/lutris/lutris/commit/9328c3268164f1201f7bdb3f6c28f4b7bd314200

Bug#980323: flatpak: LD_LIBRARY_PATH is not set under flatpak-builder

[Salvatore Bonaccorso]

Hi Simon,

On Thu, Jan 21, 2021 at 06:25:25PM +, Simon McVittie wrote:
> On Thu, 21 Jan 2021 at 17:51:34 +, Simon McVittie wrote:
> > Security team: this is a regression in DSA 4830-1 (CVE-2021-21261), now
> > fixed upstream in 1.10.1 and backported to 1.2.x. In addition to the
> > regression that was reported in #980323, I looked at similar code paths
> > and fixed an equivalent regression elsewhere. It's a 2-line change
> > (I'll follow up with the full debdiff, which is rather larger due to
> > patch headers and changelog). Do you want a DSA 4830-2 to fix this?
> 
> Here's the proposed source debdiff.
> 
> I've assumed that urgency=medium genuinely *is* what I want this time :-)
> 
> smcv

Thanks for the fix! Please do upload to security-master.

Regards,
Salvatore


signature.asc
Description: PGP signature

Bug#980774: bugs.debian.org: fails with d-ports-only binary packages (assigned to unknown-pack...@qa.debian.org)

[Thorsten Glaser]

Package: bugs.debian.org
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

Reporting a bug against a binary package that only exists on d-ports
architectures (such as libgcc2 which is m68k-specific) fails, the
report gets assigned to unknown-pack...@qa.debian.org instead of GCC.

I could understand if this failed for cases where the *source* package
is also only in d-ports (unreleased, usually, then), such as is the
case for some of the bootloaders, but in my case here, the source
package is part of Debian proper and the list of binary packages that
this source package builds is discoverable, so failing here is not
amusing.


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

Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Bug#971515: marked as done (kubernetes: excessive vendoring (private libraries))

[Dmitry Smirnov]

I'm disappointed with TC's decision. IMHO it is lacking depth of judgement.

The original problem I reported is absolutism - "vendor everything".
And TC apparently considered only that without trying to find the balance.

What are the reasons for vendoring stable well maintained library like
Logrus? None. That system library can by used easily with hardly any burden
to maintenance. Same can be said probably about ~100 other libraries.

We could do so much better with recommending at least to un-vendor trivial
cases of 3rd party code...



> The Committee declines to overrule the maintainer and accepts the level
> of vendoring used in the 'kubernetes' source package.  We also decline
> to intervene in bugs requesting that vendored components in the
> 'kubernetes' source package be installed in binary packages in such a
> way that other packages can make use of them.

> Our consensus is that Kubernetes ought to be considered special in the
> same way that Firefox is considered special -- we treat the package
> differently from most other source packages because (i) it is very large
> and complex, and (ii) upstream has significantly more resources to keep
> all those moving parts up-to-date than Debian does.

That is based on misleading Elana's comparison that I've answered
(regretfully too late) in the other email...


> Our most basic reason for this point of view is that given how much
> fewer resources we have than upstream Kubernetes, it is not feasible for
> Kubernetes to make it into a stable release of Debian unless we take an
> approach like this one.

IMHO Kubernetes is not suitable for "stable" either way.


> The same goes for the possibility of providing
> security support.  And given that a strategy for security support is
> available, we do not see any reason why having the Kubernetes bundle in
> a stable release alongside other copies of its vendored dependencies is
> worse than not having Kubernetes in a stable release at all.

It is not suppose to be "all or nothing" approach. We are talking about 3rd
party code, not maintained by Kubernetes. At least some of it is perfectly 
feasible to take from packaged libraries instead of messy upstream bundle.



> It should be noted that we think the greater resources of upstream

Let's not praise greater resources unnecessarily. Upstream don't care
about good versioning practices and even automatically closes bugs for
inactivity without addressing them (e.g. https://github.com/kubernetes/
kubernetes/issues/17077).


> is
> relevant not only to keeping on top of patches and security fixes, but
> also to license compliance.  It is our belief that there is no reason at
> the present time to be concerned that non-DFSG material would find its
> way into the package, because Kubernetes upstream care about ensuring
> that all vendored dependencies are free software, and they have the
> resources to check.

Since when we are delegating DFSG compliance to upstream based on faith??

FYI in case of "cadvisor" - a required Kubernetes component, DFSG compliance 
was difficult to achieve due to pre-minified source-less 3rd party javascript 
files...

It was a hell of an effort to get Kubernetes through NEW process. Apparently
I should not have bothered with all that because upstream is so "good" (it 
wasn't).
Did you ask ftp-masters opinion/position on that?? Are they OK with volume
of needless garbage in vendored bundle? Would they allow that before TC's 
conclusion?


> This could change in the future and it may not be
> true for other upstreams.

I've spent about a year of effort for introducing Kubernetes to Debian - yes, 
I had that much faith in Kubernetes but ultimately the effort lead to
disappointment in the technology and loss of confidence in upstream's
ability to maintain the project. But in the course of the effort many new
libraries were introduced as packages, the Debian Golang ecosystem was 
stabilised and we've gained a valuable experience with maintaining a complex 
Golang software. The hard work was accomplished and it was only the matter or 
maintaining Kubernetes properly...
The TC's decision tells me that the effort was largely wasted because it was 
"too hard" to do things this way... Naturally the sloppy way is so much 
easier...

:(

-- 
Best wishes,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

There are occasions when it pays better to fight and be beaten than not to
fight at all.
-- George Orwell

---

"Increased Risk of Noninfluenza Respiratory Virus Infections Associated
With Receipt of Inactivated Influenza Vaccine".
-- https://pubmed.ncbi.nlm.nih.gov/22423139/


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

Bug#770247: Fwd: ITP: mars -- Asynchronous Block-Level Storage Replication

[Gabriel Francisco]

Forwarding to the ITP because I believe mars is an interesting project 
and to keep people in the loop.



 Forwarded Message 
Subject:Re: ITP: mars -- Asynchronous Block-Level Storage Replication
Date:   Thu, 21 Jan 2021 21:42:51 +
From:   Gabriel Francisco 
To: 	Thomas Schöbel-Theuer , Francesco Paolo 
Lovergine 




Hi, thanks for the updates!


Agree, getting mars into mainline will probably take some time, 
specially because of the required kernel patches. But I found that mars 
module can work fine with the vanilla/debian kernel when compiling it 
via dkms.



I tested manually, setting up a small volume and writing lots of stuff 
in it while checking the mars file in /proc (it really resembles mysql 
replication, yay!). I would like to have some tests running just to give 
me more confidence that I will not face any edge case. I'm trying to 
have the current test suite running, so far I have a work-in-progress at 
https://github.com/fgbreel/mars/tree/wip-dkms-run-test-suite where I'm 
setting up two virtual machines, installing the package and running the 
tests.



I felt that the existing test suite seems a bit rusty, but I don't mind. 
Having *something* to assert that mars dkms works makes me happy :)



I'll check out the link/new test suite you shared and see how it fit the 
whole picture. I just landed on a new job, but I'll try to provide an 
update soon.


Stay safe,

Gabriel Francisco


On 21/01/2021 19:58, Thomas Schöbel-Theuer wrote:

On 21/01/2021 19:08, Francesco Paolo Lovergine wrote:

 Having a single giant patch is not a big issue, of course not nice for
the kernel folks, but fast.


Misunderstanding: my talk about the "jumbo patch" was not about MARS 
or kernels, but about the _new_ test suite, written in _bash_ script.


Background: Gabriel had mentioned "the" test suite at github, although 
there are 2 different test suites in total, thus I was starting to 
explain something about the _new_ test suite.


Probably you don't need any of both test suites for making MARS 
availabe to Debian users.


The "old" test suite is in the mars repo you already know, in 
subdirectory test_suite/ . It is not developed anymore, because Frank 
Liepold left 1&1 in May 2014 (see "git log -- test_suite/" showing his 
last commit at his last working day).


You can find an outdated stage of the _new_ test suite at 
https://github.com/schoebel/test-suite (which is a _separate_ repo / 
project from MARS). My suggestion was to update this repo via a jumbo 
patch (saving a lot of work for me).


Getting MARS into kernel upstream is a completely different topic. 
Theoretically, it is just a new "driver", and changes practically 
_nothing_ at the rest of the kernel. I would be very lucky if it could 
be added to the kernel like a jumbo patch, since it adds only a bunch 
of new files. I already tried some years ago, but it got stuck.


I will retry once it runs on linux-next again (years ago it did, but 
then I had no time for updating it continuously).


Thank you very much,

Thomas

Bug#980671: [Debian-med-packaging] Bug#980671: bmtk: FTBFS: Signal: Aborted (6)

[Étienne Mollier]

Control: tag -1 moreinfo
Control: tag -1 unreproducible

Hi there,

Lucas Nussbaum, on 2021-01-20 21:53:58 +0100:
> Relevant part (hopefully):
> > reading sources... [ 87%] tutorial_NetworkBuilder_Intro
> > A process has executed an operation involving a call
> > to the fork() system call to create a child process.
> > 
> > As a result, the libfabric EFA provider is operating in
> > a condition that could result in memory corruption or
> > other system errors.
> > 
> > For the libfabric EFA provider to work safely when fork()
> > is called, you will need to set the following environment
> > variable:
> >   RDMAV_FORK_SAFE

This might be a matter of exporting this variable from the file
d/rules hopefully.  However I have not been capable of
reproducing the issue.  As far a I can see, my build goes
through painlessly around the tutorial_NetworkBuilder_Intro.

Diffing the build log, what pops up is that my custom kernel is
not RDMA capable, but perhaps it is a matter of machine too:

$ grep RDMA /boot/config-5.9.1
# CONFIG_CGROUP_RDMA is not set
# CONFIG_CARDMAN_4000 is not set
# CONFIG_CARDMAN_4040 is not set

Anyone else is able to reproduce the problem ?

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#980773: python-pysaml2: CVE-2021-21238: Processing of invalid SAML XML documents

[Salvatore Bonaccorso]

Source: python-pysaml2
Version: 6.1.0-3
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 python-pysaml2.

CVE-2021-21238[0]:
| PySAML2 is a pure python implementation of SAML Version 2 Standard.
| PySAML2 before 6.5.0 has an improper verification of cryptographic
| signature vulnerability. All users of pysaml2 that need to validate
| signed SAML documents are impacted. The vulnerability is a variant of
| XML Signature wrapping because it did not validate the SAML document
| against an XML schema. This allowed invalid XML documents to be
| processed and such a document can trick pysaml2 with a wrapped
| signature. This is fixed in PySAML2 6.5.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-2021-21238
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21238
[1] 
https://github.com/IdentityPython/pysaml2/security/advisories/GHSA-f4g9-h89h-jgv9
[2] 
https://github.com/IdentityPython/pysaml2/commit/3b707723dcf1bf60677b424aac398c0c3557641d

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#980772: python-pysaml2: CVE-2021-21239: Unspecified xmlsec1 key-type preference

[Salvatore Bonaccorso]

Source: python-pysaml2
Version: 6.1.0-3
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 python-pysaml2.

CVE-2021-21239[0]:
| PySAML2 is a pure python implementation of SAML Version 2 Standard.
| PySAML2 before 6.5.0 has an improper verification of cryptographic
| signature vulnerability. Users of pysaml2 that use the default
| CryptoBackendXmlSec1 backend and need to verify signed SAML documents
| are impacted. PySAML2 does not ensure that a signed SAML document is
| correctly signed. The default CryptoBackendXmlSec1 backend is using
| the xmlsec1 binary to verify the signature of signed SAML documents,
| but by default xmlsec1 accepts any type of key found within the given
| document. xmlsec1 needs to be configured explicitly to only use only
| _x509 certificates_ for the verification process of the SAML document
| signature. This is fixed in PySAML2 6.5.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-2021-21239
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21239
[1] 
https://github.com/IdentityPython/pysaml2/commit/751dbf50a51131b13d55989395f9b115045f9737
[2] 
https://github.com/IdentityPython/pysaml2/security/advisories/GHSA-5p3x-r448-pc62

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#980326: mutt: diff for NMU version 2.0.2-1.1

[Kevin J. McCarthy]

On Wed, Jan 20, 2021 at 10:36:59PM +0100, Antonio Radici wrote:

yes that will definitely help so we will get additional commits that are not 
yet in 2.0.4.

If you can't make it by the weekend I should be able to find some time 
on Mon/Tue to do the upload!


I've just released 2.0.5.  For this bug, it only contains the actual 
memory leak fix 
.


I was sorely tempted to include the other fix 
, 
but in the end decided to be disciplined with a stable release.


There are actually a couple more fixes I plan on making to group 
parsing, but again in master, where they will have a bit more time to 
bake and uncover potential problems.


Thanks for making an upload.  It will be good to have the bug fixes in 
2.0.3+ in the next Debian release!


-Kevin





signature.asc
Description: PGP signature

Bug#916670: cryptsetup: ERROR: Couldn't resolve device rootfs

[Jacob Post]

In case someone else runs into this:

I have an encrypted LVM partition that contains mount points for root, home, 
swap.
Apparently cryptsetup cannot see through the LVM to find the rootfs, and hence 
the
error.

I added the `initramfs` option in /etc/crypttab and updated initramfs for 
safety,
and everything worked fine on reboot.  I didn't try without the option, so I 
can't
say if it's required or not.

 - Jacob Post

Bug#914390: unable to connect to wpa2-psk secured networks with mwifiex_usb

[txt.f...@txtfile.eu]

fixed -1 4.19.160-2
fixed -1 5.10.4-1
thanks

buster:
I just tested with 
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/10.7.0-live+nonfree/amd64/iso-hybrid/ 
and I was able to connect to two different WPA2 secured access points.


Running Linux was 4.19.0-13-amd64 (4.19.160-2).


bullseye:
I also tried 
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-gnome+nonfree.iso 
as of 2021-01-18 and was able to connect to two different WPA secured 
access points.


Running Linux was 5.10.4-1.

Bug#971515: Status as of last tech-ctte meeting

[Dmitry Smirnov]

On Friday, 20 November 2020 4:35:23 PM AEDT Elana Hashman wrote:
> Kubernetes is a very large and active project. It has about 600
> members,[0] 1000 voters,[1] 100 committers (which I define as members of
> the milestone-maintainers team),[2] and over 50,000 contributors.[3] The
> project has its own security[4] and release teams,[5] and the release
> team includes a software licensing team.
> [...]
> As such, the scale of Kubernetes is similar to that of Debian itself.

I was too slow to reply to this email but I'll leave some comments for the
record.

Comparison of Kubernetes' team size to Debian is misleading and the
comparison is not in favour of Kubernetes.

Debian is compartmentalised into relatively small (mostly) well coordinated
teams. Kubernetes - the monolithic project - suffers from well known
problem with coordinating large teams. Frederick Brooks described the
problem well in his "The Mythical Man-Month" book. 
Regarding number of contributors, what is strength for Debian
is a weakness for Kubernetes.

Kubernetes bug tracker shows the scale of the problem and I don't have
impression that the team is big enough to handle bug reports effectively or
have them under control.

It was my observation that vendoring problems in Kubernetes are worse than
everything I've seen in other projects.
Is that despite the size of the team or because of it?

The particular example that I did not mention enough [1] (and it is not the 
only one) show how little that remarkably large team cares about dependency
hygiene: a trivial library update with a patch was not done in a few years
time and all that was produced by the large team are excuses for not doing
the update, only to finally perform it in the end as advised.
Who can have confidence in the Kubernetes dependency management after that?

[1]: https://github.com/kubernetes/kubernetes/issues/27543

Of course the problem have little to do with Kubernetes. The "use world"
situation with over-dependency on large number of 3rd party libraries is a
challenging one especially with historically poor Golang approach to
dependency management a.k.a. "vendoring". I'm just saying that Kubernetes
is not all that special in regards to vendoring because of the team size.



> Kubernetes as an upstream project is much better resourced than the
> single downstream maintainer in Debian.

Nobody argues with that. But it is only "single maintainer" with monolitic
packaging - a case that I'm arguing against.
Golang team is strong and its capacity is impressive.
Packages that use dependency libraries are always team-maintained.

It is the same situation as with Kubernetes upstream where
much of the 3rd party code is not maintained by Kubernetes team.


> The resourcing and scale of the Kubernetes project gives us better
> assurances that upstream has done due diligence for dependency
> management.

IMHO upstream demonstrated bad and terrible attitude with dependency
management. But apparently nobody here considered that argument... :(

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

---

We often refuse to accept an idea merely because the way in which it has
been expressed is unsympathetic to us.
-- Friedrich Nietzsche

---

COVID-19: The Trouble With PCR Tests
https://swprs.org/the-trouble-with-pcr-tests/


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

Bug#980271: #980271 installation-reports: Toshiba Tecra 8000 Installation report Bullseye

[Holger Wansing]

Control: reassign -1 pcmciautils
Control: tags -1 + patch


Charles Curley  wrote:
> I tried a Xircom CreditCard Ethernet adapter, CE38-100BTX, which uses
> the xirc2ps_cs driver. It runs, if slowly, on an installed system. But
> on installation, the software fails to detect it also.
> 
> I noticed in the log on console F4 a message:
> 
> pcmcia-socket-startup: chdir to /etc/pcmcia failed: no such file or
> directory.
> 
> Possibly this is because the directory actually is /etc/pcmciautils on
> the installer. It is /etc/pcmcia on the installed system.
> 
> I then made a symlink, rmmod yenta_socket, modprobe yenta_socket.
> Messages indicate that yenta_socket picked up the configuration file.
> 
> I then inserted the card. Messages indicate that the card was detected
> and set up. I then went back to the installatio software, had it detect
> the network. It detected it correctly, and auto-configuration worked
> correctly.

I have verified that on a current testing installation system, there is
still /etc/pcmciautils/ existing, and no /etc/pcmcia/.

So re-assigning to pcmciautils package.

Also, I attached a patch, which should hopefully fix this for the udeb.


Thanks
Holger




-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/debian/changelog b/debian/changelog
index 44560d6..0c86fc6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+pcmciautils (018-13) UNRELEASED; urgency=medium
+
+  * Update /etc/pcmciautils/ dir to /etc/pcmcia/ in udeb.
+
+ -- Holger Wansing   Thu, 21 Jan 2021 18:17:41 +0100
+
 pcmciautils (018-12) unstable; urgency=medium
 
   [ Bor Grošelj Simić ]
diff --git a/debian/pcmciautils-udeb.install b/debian/pcmciautils-udeb.install
index 6e4bf21..2010958 100644
--- a/debian/pcmciautils-udeb.install
+++ b/debian/pcmciautils-udeb.install
@@ -1,2 +1,2 @@
 lib/udev lib/
-usr/lib/pcmciautils/config.opts etc/pcmciautils/
+usr/lib/pcmciautils/config.opts etc/pcmcia/

Bug#980771: ITP: luma.led-matrix -- library interfacing LED matrix displays

[Anton Gladky]

Package: wnpp
Severity: wishlist
Owner: Anton Gladky 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: luma.led-matrix
  Version : 1.5.0
  Upstream Author : Richard Hull and contributors
* URL : https://github.com/rm-hull/luma.led_matrix
* License : MIT
  Programming Lang: Python
  Description : library interfacing LED matrix displays

Library interfacing LED matrix displays with the MAX7219 driver
(using SPI), WS2812 (NeoPixels, inc Pimoroni Unicorn pHat/Hat
and Unicorn Hat HD) and APA102 (DotStar) on the Raspberry Pi
and other Linux-based single board computers - it providesxi
a Pillow-compatible drawing canvas, and other functionality to support:
 * multiple cascaded devices
 * LED matrix, seven-segment and NeoPixel variants
 * scrolling/panning capability,
 * terminal-style printing,
 * state management,
 * dithering to monochrome,
 * pygame emulator

Bug#980770: libgcc-s2: file overwrite conflict with libgcc2

[Thorsten Glaser]

Package: libgcc-s2
Version: 10.2.1-6

On upgrading an older (1 year or so) sid installation, I get this:

Preparing to unpack .../libgcc-s2_10.2.1-6_m68k.deb ...
Unpacking libgcc-s2:m68k (10.2.1-6) ...
dpkg: error processing archive 
/var/cache/apt/archives/libgcc-s2_10.2.1-6_m68k.deb (--unpack):
 trying to overwrite '/lib/m68k-linux-gnu/libgcc_s.so.2', which is also in 
package libgcc2:m68k 1:9.2.1-25
Errors were encountered while processing:
 /var/cache/apt/archives/libgcc-s2_10.2.1-6_m68k.deb

Bug#980472: cubicsdr: CubicSDR crashes after lauch! (same effect on 2 clean bullseye OS)

[Christoph Berg]

Re: LH
> Receivers:
> - HackRF One
> - DX Patrol Mk4
> 
> SDR enumerator starting.
> SoapySDR init..
>     API Version: v0.7.1
>     ABI Version: v0.7
>     Install root: /usr
>     Loading modules...
>     Available factories...airspy, audio, bladerf, hackrf, lime, null,
> osmosdr, redpitaya, remote, rtlsdr, uhd
> Hash collision!!! Fatal error!!

That's a message from hamlib:

https://sources.debian.org/src/hamlib/4.0-4/src/register.c/?hl=215#L215

Does startup work if you first disconnect one of the receivers?

Do you have anything configured for hamlib radio control?

> [INFO] [UHD] linux; GNU C++ version 10.2.1 20201207; Boost_107400;
> UHD_3.15.0.0-4+b1
> Detached kernel driver
> Available vertical sync SwapInterval functions:
>     glxSwapIntervalEXT: Yes
>     DRI2SwapInterval: No
>     glxSwapIntervalMESA: Yes
>     glxSwapIntervalSGI: Yes
> Using glxSwapIntervalEXT.
> 
> Loaded font 'Bitstream Vera Sans Mono' from
> '/usr/share/cubicsdr/fonts/vera_sans_mono12_0.png', parsed 255 characters.
> Loaded font 'Bitstream Vera Sans Mono' from
> '/usr/share/cubicsdr/fonts/vera_sans_mono16_0.png', parsed 255 characters.
> Loaded font 'Bitstream Vera Sans Mono' from
> '/usr/share/cubicsdr/fonts/vera_sans_mono18_0.png', parsed 255 characters.
> Found Rafael Micro R820T tuner
> Speicherzugriffsfehler

Hmm. Can exit() lead to segfaults in threaded programs?

Re: LH
> Backtrace:
> After Reading https://wiki.debian.org/HowToGetABacktrace ... sorry, this is
> beyond my knowledge, I'm a user only.
> And I was not able to find a 'cubicsdr-dbgsym' that works on my
> bullseye-system (https://packages.debian.org/sid/cubicsdr-dbgsym) ?
> Or is there an easier way to get the desired 'backtrace'?

The -dbgsym packages are in a separate archive, /debian-debug/:
https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

Also install gdb. Then:

gdb CubicSDR
r
... and once it has crashed:
bt f

Christoph

Bug#980768: gnupg2: reduce Build-Depends

[Helmut Grohne]

Source: gnupg2
Version: 2.2.20-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

gnupg2 participates in a number of dependency cycles relevant to
architecture bootstrap. Instead of looking into such a hard problem, I
looked into easily droppable dependencies and found some. Since gnupg2
is normally reproducible, I verified that performing a nocheck build
with the following dependencies turned into Build-Conflicts results in
precisely the same binary artifacts as a regular full build.

 * ghostscript was used to create doc/gnupg-card-architecture.pdf, but
   this step is not performed during build.
 * imagemagick's convert and transfig's fig2dev are mentioned in
   doc/Makefile.am, but since the relevant artifacts are included in the
   source distribution, they're not run during build.
 * libcurl4-gnutls-dev is unused. While curl is mentioned in source
   comments and checked for in configure, it is never actually used.
 * librsvg2-bin's rsvg-convert is never mentioned anywhere.

Please consider applying the attached patch.

Helmut
diff --minimal -Nru gnupg2-2.2.20/debian/changelog 
gnupg2-2.2.20/debian/changelog
--- gnupg2-2.2.20/debian/changelog  2020-03-23 20:05:13.0 +0100
+++ gnupg2-2.2.20/debian/changelog  2021-01-21 13:53:34.0 +0100
@@ -1,3 +1,19 @@
+gnupg2 (2.2.20-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Drop unused ghostscript. It is used to create
+  doc/gnupg-card-architecture.pdf, but the invocations for doing so are
+  missing from the source.
++ Drop unused imagemagick and transfig. Both convert and fig2dev are used
+  in doc/Makefile.am, but since the relevant output artifacts are
+  included, they're not run.
++ Drop unused libcurl4-gnutls-dev. curl is mentioned in source comments
+  and checked for in configure, but never actually used.
++ Drop unused librsvg2-bin. It is not mentioned anywhere nor used.
+
+ -- Helmut Grohne   Thu, 21 Jan 2021 13:53:34 +0100
+
 gnupg2 (2.2.20-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru gnupg2-2.2.20/debian/control gnupg2-2.2.20/debian/control
--- gnupg2-2.2.20/debian/control2020-03-23 20:04:11.0 +0100
+++ gnupg2-2.2.20/debian/control2021-01-21 13:53:34.0 +0100
@@ -12,12 +12,9 @@
  debhelper-compat (= 12),
  file,
  gettext,
- ghostscript,
  gpgrt-tools,
- imagemagick,
  libassuan-dev (>= 2.5.0),
  libbz2-dev,
- libcurl4-gnutls-dev,
  libgcrypt20-dev (>= 1.7.0),
  libgnutls28-dev (>= 3.0),
  libgpg-error-dev (>= 1.35),
@@ -25,13 +22,11 @@
  libldap2-dev,
  libnpth0-dev (>= 1.2),
  libreadline-dev,
- librsvg2-bin,
  libsqlite3-dev,
  libusb-1.0-0-dev [!hurd-any],
  openssh-client ,
  pkg-config,
  texinfo,
- transfig,
  zlib1g-dev | libz-dev,
 Build-Depends-Indep:
  binutils-multiarch [!amd64 !i386],

Bug#980769: pygobject: reduce Build-Depends

[Helmut Grohne]

Source: pygobject
Version: 3.38.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

pygobject has unsatisfiably cross Build-Depends. Instead of looking into
such hard problem, I looked into easily droppable Build-Depends and
found some. Since pygobject is normally reproducible, I verified that a
nocheck build with the following dependencies turned into
Build-Conflicts results in the same binary artifacts as a regular full
build:
 * at-spi2-core is mentioned in debian/changelog as having been added to
   fix tests. That looks like a good candidate to annotate .
 * dbus (formerly dbus-x11) is also mentioned in debian/changelog as
   being used during tests. Likewise.
 * The documentation was formerly built using docbook, but it now uses
   restructured text. Thus docbook-xsl and xsltproc can be dropped.
 * flake8 is invoked via setup.py quality which is conditional to
   DEB_BUILD_OPTIONS=nocheck. Thus python3-flake8 can also be annotated
   .
 * debian/changelog also hints that locales is needed to make tests
   pass. Annotate .

Please consider applying the attached patch.

Helmut
diff --minimal -Nru pygobject-3.38.0/debian/changelog 
pygobject-3.38.0/debian/changelog
--- pygobject-3.38.0/debian/changelog   2020-09-18 10:30:51.0 +0200
+++ pygobject-3.38.0/debian/changelog   2021-01-21 20:21:05.0 +0100
@@ -1,3 +1,17 @@
+pygobject (3.38.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ at-spi2-core was added to fix failing tests. Annotate .
++ dbus is also used for running tests. Annotate .
++ Drop docbook-xsl and xsltproc. Documentation is now restructured text.
++ Drop python3-cairo-dbg as Python no longer varies the path for debugged
+  extensions.
++ python3-flake8 is used for setup.py quality. Annotate .
++ locales is evidently used in tests. Annotate .
+
+ -- Helmut Grohne   Thu, 21 Jan 2021 20:21:05 +0100
+
 pygobject (3.38.0-1) unstable; urgency=medium
 
   * Team upload
diff --minimal -Nru pygobject-3.38.0/debian/control 
pygobject-3.38.0/debian/control
--- pygobject-3.38.0/debian/control 2020-09-18 10:30:51.0 +0200
+++ pygobject-3.38.0/debian/control 2021-01-21 20:21:05.0 +0100
@@ -7,13 +7,12 @@
 Priority: optional
 Maintainer: Debian GNOME Maintainers 

 Uploaders: Iain Lane , Jeremy Bicha , 
Laurent Bigonville 
-Build-Depends: at-spi2-core,
+Build-Depends: at-spi2-core ,
autoconf-archive,
-   dbus (>= 1.8),
+   dbus (>= 1.8) ,
debhelper-compat (= 12),
dh-exec,
dh-python,
-   docbook-xsl,
dpkg-dev (>= 1.16.1~),
gir1.2-gtk-3.0 ,
gnome-pkg-tools (>= 0.10),
@@ -22,16 +21,14 @@
libffi-dev (>= 3.3),
libgirepository1.0-dev (>= 1.62.0-4~),
libglib2.0-dev (>= 2.48.0),
-   locales,
+   locales ,
python3-all-dbg,
python3-all-dev,
-   python3-cairo-dbg,
python3-cairo-dev (>= 1.11.1),
-   python3-flake8,
+   python3-flake8 ,
python3-pytest ,
python3-setuptools,
xauth ,
-   xsltproc,
xvfb 
 Rules-Requires-Root: no
 Standards-Version: 4.5.0

Bug#980767: kcrash: reduce Build-Depends

[Helmut Grohne]

Source: kcrash
Version: 5.78.0-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

kcrash particiapates in a number of dependency loops relevant to
architecture bootstrap. Rather than working on such a difficult issue, I
looked into easily droppable dependencies. Here we go:
 * graphviz isn't used. I think it was formerly used via doxygen, but no
   longer is.
 * Since bumping debhelper compat to 13, xauth and xvfb can be annotated
as the whole override is now skipped.

Please consider applying the attached patch.

Helmut
diff --minimal -Nru kcrash-5.78.0/debian/changelog 
kcrash-5.78.0/debian/changelog
--- kcrash-5.78.0/debian/changelog  2021-01-18 10:57:48.0 +0100
+++ kcrash-5.78.0/debian/changelog  2021-01-21 22:12:59.0 +0100
@@ -1,3 +1,13 @@
+kcrash (5.78.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends:
++ Annotate xauth and xvfb with  as compat 13 now skips the whole
+  override.
++ Drop unused graphviz dependency as doxygen doesn't call it.
+
+ -- Helmut Grohne   Thu, 21 Jan 2021 22:12:59 +0100
+
 kcrash (5.78.0-3) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru kcrash-5.78.0/debian/control kcrash-5.78.0/debian/control
--- kcrash-5.78.0/debian/control2021-01-18 10:46:08.0 +0100
+++ kcrash-5.78.0/debian/control2021-01-21 22:12:57.0 +0100
@@ -8,7 +8,6 @@
debhelper-compat (= 13),
doxygen,
extra-cmake-modules (>= 5.78.0~),
-   graphviz,
libkf5coreaddons-dev (>= 5.78.0~),
libkf5windowsystem-dev (>= 5.78.0~),
libqt5sql5-sqlite,
@@ -18,8 +17,8 @@
qtbase5-dev (>= 5.14.0~),
qttools5-dev,
qttools5-dev-tools (>= 5.4),
-   xauth,
-   xvfb
+   xauth ,
+   xvfb ,
 Standards-Version: 4.5.1
 Homepage: https://invent.kde.org/frameworks/kcrash
 Vcs-Browser: https://salsa.debian.org/qt-kde-team/kde/kcrash

Bug#980472: cubicsdr: CubicSDR crashes after lauch! (same effect on 2 clean bullseye OS)

[LH]

Hi Christoph

Backtrace:
After Reading https://wiki.debian.org/HowToGetABacktrace ... sorry, this 
is beyond my knowledge, I'm a user only.
And I was not able to find a 'cubicsdr-dbgsym' that works on my 
bullseye-system (https://packages.debian.org/sid/cubicsdr-dbgsym) ?

Or is there an easier way to get the desired 'backtrace'?

Best Regards
Louis Hb





Hi Christoph

Receivers:
- HackRF One
- DX Patrol Mk4

Yes, it crashes before selecting the device. I can see for a very 
short moment the applications GUI. (CubicSDR installed by Synaptic.)


My Debian Systems are new installed. (Bullseye Alpha 3, weekly 
release, 17. January 2021). Desktop environment XFCE. GNU Radio & GQRX 
work perfectly.

I have tested the whole thing on a second pc (also Bullseye), same Error.
As an alternative, I have tested the AppImage Version of CubicSDR. No 
luck, it crashes also.
(By the way, the Problem is only on Bullseye, on Debian Buster the app 
works perfect.)


I will install cubicsdr-dbgsym and let you know, please give me one 
day. Below you may find the CubicSDR Log when I start the application 
in the Terminal.

Best Regards - and thanks for your effort!
Louis HB

---

lhb@pc-168:~$ CubicSDR
Loaded 256 rig models via hamlib.

Audio Device #0 PulseAudio
    Default Output? Yes
    Default Input? Yes
    Input channels: 2
    Output channels: 2
    Duplex channels: 2
    Native formats:
        16-bit signed integer.
        32-bit signed integer.
        32-bit float normalized between plus/minus 1.0.
    Supported sample rates:
        8000hz
        16000hz
        22050hz
        32000hz
        44100hz
        48000hz
        96000hz

SDR enumerator starting.
SoapySDR init..
    API Version: v0.7.1
    ABI Version: v0.7
    Install root: /usr
    Loading modules...
    Available factories...airspy, audio, bladerf, hackrf, lime, null, 
osmosdr, redpitaya, remote, rtlsdr, uhd

Hash collision!!! Fatal error!!
[INFO] [UHD] linux; GNU C++ version 10.2.1 20201207; Boost_107400; 
UHD_3.15.0.0-4+b1

Detached kernel driver
Available vertical sync SwapInterval functions:
    glxSwapIntervalEXT: Yes
    DRI2SwapInterval: No
    glxSwapIntervalMESA: Yes
    glxSwapIntervalSGI: Yes
Using glxSwapIntervalEXT.

Loaded font 'Bitstream Vera Sans Mono' from 
'/usr/share/cubicsdr/fonts/vera_sans_mono12_0.png', parsed 255 
characters.
Loaded font 'Bitstream Vera Sans Mono' from 
'/usr/share/cubicsdr/fonts/vera_sans_mono16_0.png', parsed 255 
characters.
Loaded font 'Bitstream Vera Sans Mono' from 
'/usr/share/cubicsdr/fonts/vera_sans_mono18_0.png', parsed 255 
characters.

Found Rafael Micro R820T tuner
Speicherzugriffsfehler
lhb@pc-168:~$






Am 19.01.21 um 18:24 schrieb Christoph Berg:

Control: tags -1 moreinfo

Re: Louis HB
*** Reporter, please consider answering these questions, where 
appropriate ***

Hi Louis,

what SDR device are you using? Does it crash before selecting the
device?

Please install cubicsdr-dbgsym from the debug archive and provide a
backtrace of the crash.

Christoph DF7CB 

Bug#980472: cubicsdr: CubicSDR crashes after lauch! (same effect on 2 clean bullseye OS)

[LH]

Hi Christoph

Receivers:
- HackRF One
- DX Patrol Mk4

Yes, it crashes before selecting the device. I can see for a very short 
moment the applications GUI. (CubicSDR installed by Synaptic.)


My Debian Systems are new installed. (Bullseye Alpha 3, weekly release, 
17. January 2021). Desktop environment XFCE. GNU Radio & GQRX work 
perfectly.

I have tested the whole thing on a second pc (also Bullseye), same Error.
As an alternative, I have tested the AppImage Version of CubicSDR. No 
luck, it crashes also.
(By the way, the Problem is only on Bullseye, on Debian Buster the app 
works perfect.)


I will install cubicsdr-dbgsym and let you know, please give me one day. 
Below you may find the CubicSDR Log when I start the application in the 
Terminal.

Best Regards - and thanks for your effort!
Louis HB

---

lhb@pc-168:~$ CubicSDR
Loaded 256 rig models via hamlib.

Audio Device #0 PulseAudio
    Default Output? Yes
    Default Input? Yes
    Input channels: 2
    Output channels: 2
    Duplex channels: 2
    Native formats:
        16-bit signed integer.
        32-bit signed integer.
        32-bit float normalized between plus/minus 1.0.
    Supported sample rates:
        8000hz
        16000hz
        22050hz
        32000hz
        44100hz
        48000hz
        96000hz

SDR enumerator starting.
SoapySDR init..
    API Version: v0.7.1
    ABI Version: v0.7
    Install root: /usr
    Loading modules...
    Available factories...airspy, audio, bladerf, hackrf, lime, null, 
osmosdr, redpitaya, remote, rtlsdr, uhd

Hash collision!!! Fatal error!!
[INFO] [UHD] linux; GNU C++ version 10.2.1 20201207; Boost_107400; 
UHD_3.15.0.0-4+b1

Detached kernel driver
Available vertical sync SwapInterval functions:
    glxSwapIntervalEXT: Yes
    DRI2SwapInterval: No
    glxSwapIntervalMESA: Yes
    glxSwapIntervalSGI: Yes
Using glxSwapIntervalEXT.

Loaded font 'Bitstream Vera Sans Mono' from 
'/usr/share/cubicsdr/fonts/vera_sans_mono12_0.png', parsed 255 characters.
Loaded font 'Bitstream Vera Sans Mono' from 
'/usr/share/cubicsdr/fonts/vera_sans_mono16_0.png', parsed 255 characters.
Loaded font 'Bitstream Vera Sans Mono' from 
'/usr/share/cubicsdr/fonts/vera_sans_mono18_0.png', parsed 255 characters.

Found Rafael Micro R820T tuner
Speicherzugriffsfehler
lhb@pc-168:~$






Am 19.01.21 um 18:24 schrieb Christoph Berg:

Control: tags -1 moreinfo

Re: Louis HB

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

Hi Louis,

what SDR device are you using? Does it crash before selecting the
device?

Please install cubicsdr-dbgsym from the debug archive and provide a
backtrace of the crash.

Christoph DF7CB

Bug#980442: gst-plugins-bad1.0: Security update DSA-4833-1 seen as downgrade by APT

[Philip Wyett]

The hint here is the version '1.14.4-1deb10u1' when it should be
'1.14.4-1~deb10u1', the '~' is important and seems to be missing. This
should be rectified with urgency and the update released.

Regards

Phil

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

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#979980: lintian: Please backport 2.104.0 to buster

[Felix Lechner]

Hi Chris,

On Tue, Jan 12, 2021 at 6:45 AM Baptiste Beauplat  wrote:
>
> Could we please have a bpo build for 2.104.0?

Hope all is well! Can you please help?

Kind regards
Fellix Lechner

Bug#980766: fetchmail: Loaded OpenSSL library 0x1010104f newer than headers 0x1010101f, trying to continue.

[Erich Waelde]

Package: fetchmail
Version: 6.4.0~beta4-3
Severity: normal

Dear Maintainer,

thanks for packaging fetchmail.


   * What led up to the situation?

I restarted fetchmail for a configuration change (-d 3600). After that
collecting messages see this error message:

sudo -u fetchmail fetchmail - --nodetach -f /etc/fetchmail/fetchmailrc |& 
tee zz.log
...
fetchmail: Query status=2 (SOCKET)
fetchmail: 6.4.0.beta4 querying sslmailpool.ispgateway.de (protocol IMAP) at 
Thu 21 Jan 2021 09:30:01 PM CET: poll star
ted
Trying to connect to 134.119.228.54/993...connected.
fetchmail: Loaded OpenSSL library 0x1010104f newer than headers 0x1010101f, 
trying to continue.
fetchmail: System error during SSL_connect(): Success
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from 
x...@sslmailpool.ispgateway.de
fetchmail: 6.4.0.beta4 querying sslmailpool.ispgateway.de (protocol IMAP) at 
Thu 21 Jan 2021 09:30:01 PM CET: poll comp
leted
...

Of two different servers, one fails, the other continues. Emails from the 
latter are received.

This looks like bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931568
however the exact version is different:
here:   Loaded OpenSSL library 0x1010104f newer than headers 0x1010101f
931568: Loaded OpenSSL library 0x1010103f newer than headers 0x1010101f
...^^

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

I tried upgrade to fetchmail from testing, no change.
I tried upgrade to libssl from testing, no change either.

   * What was the outcome of this action?
   * What outcome did you expect instead?


Any ideas?
Erich

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

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

Versions of packages fetchmail depends on:
ii  adduser   3.118
ii  debianutils   4.8.6.1
ii  libc6 2.28-10
ii  libcom-err2   1.44.5-1+deb10u3
ii  libgssapi-krb5-2  1.17-3+deb10u1
ii  libk5crypto3  1.17-3+deb10u1
ii  libkrb5-3 1.17-3+deb10u1
ii  libssl1.1 1.1.1d-0+deb10u4
ii  lsb-base  10.2019051400

Versions of packages fetchmail recommends:
ii  ca-certificates  20200601

Versions of packages fetchmail suggests:
pn  fetchmailconf   
ii  postfix [mail-transport-agent]  3.4.14-0+deb10u1
pn  resolvconf  

-- Configuration Files:
/etc/default/fetchmail changed:
export LC_ALL=C
OPTIONS="-d 3600"
START_DAEMON=yes
CONFFILE="/etc/fetchmail/fetchmailrc"


-- no debconf information

Bug#957129: ddrutility: diff for NMU version 2.8-1.1

[Sudip Mukherjee]

Control: tags 957129 + patch
Control: tags 957129 + pending
--

Dear maintainer,

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

--
Regards
Sudip

diff -Nru ddrutility-2.8/debian/changelog ddrutility-2.8/debian/changelog
--- ddrutility-2.8/debian/changelog 2018-01-02 13:23:00.0 +
+++ ddrutility-2.8/debian/changelog 2021-01-21 20:51:18.0 +
@@ -1,3 +1,10 @@
+ddrutility (2.8-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957129)
+
+ -- Sudip Mukherjee   Thu, 21 Jan 2021 20:51:18 
+
+
 ddrutility (2.8-1) unstable; urgency=low
 
   * Initial release (Closes: #730429)
diff -Nru ddrutility-2.8/debian/rules ddrutility-2.8/debian/rules
--- ddrutility-2.8/debian/rules 2018-01-02 13:23:00.0 +
+++ ddrutility-2.8/debian/rules 2021-01-21 20:48:04.0 +
@@ -3,7 +3,7 @@
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed -fPIE -pie
-export DEB_CFLAGS_MAINT_APPEND = -D_FORTIFY_SOURCE=2 -fPIE
+export DEB_CFLAGS_MAINT_APPEND = -D_FORTIFY_SOURCE=2 -fPIE -fcommon
 
 %:
dh $@

Bug#889294: alsa-utils: External mic via combo jack is not detected on Acer Aspire V3-372

[Vladimir K]

model=aspire-headset-mic has similar effect.

Bug#957909: vflib3: diff for NMU version 3.6.14.dfsg-3+nmu5

[Sudip Mukherjee]

Control: tags 957909 + patch
Control: tags 957909 + pending
--

Dear maintainer,

I've prepared an NMU for vflib3 (versioned as 3.6.14.dfsg-3+nmu5) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru vflib3-3.6.14.dfsg/debian/changelog 
vflib3-3.6.14.dfsg/debian/changelog
--- vflib3-3.6.14.dfsg/debian/changelog 2017-11-06 17:23:35.0 +
+++ vflib3-3.6.14.dfsg/debian/changelog 2021-01-21 20:35:42.0 +
@@ -1,3 +1,10 @@
+vflib3 (3.6.14.dfsg-3+nmu5) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957909)
+
+ -- Sudip Mukherjee   Thu, 21 Jan 2021 20:35:42 
+
+
 vflib3 (3.6.14.dfsg-3+nmu4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru vflib3-3.6.14.dfsg/debian/patches/10_fix_ftbfs_gcc-10.patch 
vflib3-3.6.14.dfsg/debian/patches/10_fix_ftbfs_gcc-10.patch
--- vflib3-3.6.14.dfsg/debian/patches/10_fix_ftbfs_gcc-10.patch 1970-01-01 
01:00:00.0 +0100
+++ vflib3-3.6.14.dfsg/debian/patches/10_fix_ftbfs_gcc-10.patch 2021-01-21 
20:34:27.0 +
@@ -0,0 +1,23 @@
+Description: Fix ftbfs with GCC-10
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/957909
+Forwarded: no
+
+---
+
+--- vflib3-3.6.14.dfsg.orig/src/texfonts.h
 vflib3-3.6.14.dfsg/src/texfonts.h
+@@ -81,9 +81,9 @@
+ #endif
+ 
+ 
+-Glocal int   vf_dbg_drv_texfonts;
+-Glocal SEXP_ALISTvf_tex_default_properties;
+-Glocal SEXP_ALISTvf_tex_default_variables;
++Glocal extern int   vf_dbg_drv_texfonts;
++Glocal extern SEXP_ALISTvf_tex_default_properties;
++Glocal extern SEXP_ALISTvf_tex_default_variables;
+ 
+ 
+ 
diff -Nru vflib3-3.6.14.dfsg/debian/patches/series 
vflib3-3.6.14.dfsg/debian/patches/series
--- vflib3-3.6.14.dfsg/debian/patches/series2017-11-06 17:23:35.0 
+
+++ vflib3-3.6.14.dfsg/debian/patches/series2021-01-21 20:28:43.0 
+
@@ -9,3 +9,4 @@
 08_fix_ftbfs_on_kfreebsd.diff
 09_avoid_segfault_at_vflmklib.c.diff
 ppc64el.diff
+10_fix_ftbfs_gcc-10.patch

Bug#956811: [3dprinter-general] Bug#956811: Bug#956811: Confirmed

[Christoph Berg]

Re: Gregor Riepl
> As mentioned earlier, the fix from
> https://github.com/Ultimaker/Cura/pull/7139 will be in the next Cura
> release (not 4.8).

Should we backport that change?

+# WORKAROUND: Cura#5488
+# When using the KDE qqc2-desktop-style, the UI layout is completely broken, 
and
+# even worse, it crashes when switching to the "Preview" pane.
+if Platform.isLinux():
+os.environ["QT_QUICK_CONTROLS_STYLE"] = "default"


Christoph

Bug#955479: apparmor fixes for xline_db and geoip

[duck]

Quack,

On 2021-01-17 02:20, Filippo Giunchedi wrote:

On Wed, Apr 01, 2020 at 07:03 PM, Marc Dequènes wrote:

I added this line to the apparmor policy:
  /usr/share/GeoIP/GeoIP.dat r,

Btw the package could also Suggest geoip-database needed for this 
module.


Thank you for the report, I'm not an apparmor expert but I'm happy to
include support in the package (at
https://salsa.debian.org/debian/inspircd)

Suggesting 'geoip-database' is a good idea, I'll add that!


So that works for Inspircd v2. Not sure that's of much value now since 
the release is close.


v3 now uses the GeoLite2 DB and that's not available without 
registration IIUC. But for people OK to register there is the 
geoipupdate package that can use a token to download it.
I have no idea where it stores the files but it should not be difficult 
to get this information. Then you can simply update the path in the 
apparmor profile.


Another suggestion: to allow admins to add little fixes or adaptations 
to the apparmor policy I saw that several packages include a file in 
/etc/apparmor.d/local/ (chronyd for eg), which is ignored if the file is 
missing, very practical. For Inspircd that would give (at the end of the 
rules but inside the braquets):

#include 

Hope that helps.
\_o<

--
Marc Dequènes

Bug#976928: spass: diff for NMU version 3.9-1.1

[Adrian Bunk]

Control: tags 976928 + pending

Dear maintainer,

I've prepared an NMU for spass (versioned as 3.9-1.1) and uploaded
it to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru spass-3.9/debian/changelog spass-3.9/debian/changelog
--- spass-3.9/debian/changelog	2020-04-29 12:04:25.0 +0300
+++ spass-3.9/debian/changelog	2021-01-21 17:21:50.0 +0200
@@ -1,3 +1,11 @@
+spass (3.9-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Workaround parallel FTBFS by disabling parallel building.
+(Closes: #976928)
+
+ -- Adrian Bunk   Thu, 21 Jan 2021 17:21:50 +0200
+
 spass (3.9-1) unstable; urgency=medium
 
   * New upstream version. This version fixes an FTBFS with glibc 2.26
diff -Nru spass-3.9/debian/rules spass-3.9/debian/rules
--- spass-3.9/debian/rules	2020-04-29 12:04:25.0 +0300
+++ spass-3.9/debian/rules	2021-01-21 17:21:45.0 +0200
@@ -1,4 +1,4 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@
+	dh $@ --no-parallel

Bug#889294: alsa-utils: External mic via combo jack is not detected on Acer Aspire V3-372

[Vladimir K]

Upgraded to pulseaudio 14.2 from unstable.

analog-output-speaker and analog-output-headphones now mutually trading between 
"availability unknown" and "not available" on jack state. At least auto 
switching now works for output.

How does pulseaudio determine "availability" and how to affect it?

Bug#980765: eigensoft: absolute path to fixgreen in /usr/bin/ploteig

[Juhani Numminen]

Package: eigensoft
Version: 6.1.4+dfsg-1
Control: fixed -1 7.2.1+dfsg-1
X-Debbugs-Cc: Tony Travis , Debian Med 
Project List 

Tony Travis kirjoitti 21.1.2021 klo 21.39:
> Hi,
> 
> I still struggle to know the best way to report errors I find running 
> Debian-Med packages under Ubuntu, so I'm just going to report it here.
> 
> There is an absolute path to "fixgreen" in the "ploteig" script in the 
> "eigensoft" package. Sorry I'm not a true Debianista and before I get told 
> off the Debian reporting tools don't work under Ubuntu. I obtained a copy of 
> "fixgreen" from the EIG5.0.2.tgz distribution tarball.
> 
> Thanks again for all your hard work maintaining Debian-Med,
> 
>   Tony.
> 
> root@wildcat:/usr/local/src/bioinformatics/EIGENSOFT/EIG-6.1.4/bin# diff 
> -Naur ploteig /usr/bin/ploteig
> --- ploteig    2016-09-07 16:00:02.0 +0100
> +++ /usr/bin/ploteig    2021-01-21 19:24:39.535788738 +
> @@ -1,4 +1,8 @@
> -#!/usr/local/bin/perl  -w
> +#!/usr/bin/perl  -w
> +#@(#)ploteig  2021-01-21  last modified by A.J.Travis
> +#
> +# Removed absolute path to "fixgreen"
> +#
> 
>  ### ploteig -i eigfile -p pops -c a:b [-t title] [-s stem] [-o outfile] [-x] 
> [-k]  [-y] [-z sep] -r colorstring -m xmul -n ymul
>  use Getopt::Std ;
> @@ -135,7 +139,7 @@
>    $psfile  =~ s/xtxt/ps/ ;
>   }
>  system "gnuplot < $gnfile > $psfile" ;
> -system "/home/np29/bin/fixgreen  $psfile" ;
> +system "fixgreen  $psfile" ;
>  system "ps2pdf  $psfile " ;
>  }
>  unlink (@T) unless $keepflag ;

The bug system works by email, so I am forwarding this for filing there.
I'll also mark the bug fixed in a certain version because it looks like
the ploteig script disappeared at that point.

Even on Ubuntu, the reportbug package is supposed to work, sorry to hear
if does not. The command to use would be "reportbug -B debian eigensoft".

--
Juhani Numminen

Bug#980764: libc6-dev: wrong return value for fputs when STDOUT_FILENO was closed()

[Bérenger]

Package: libc6-dev
Version: 2.28-10
Severity: normal

When running following code:

```C
#include 
#include 
#include 

int main()
{
close( STDIN_FILENO );
close( STDOUT_FILENO );
int fd = dup( STDERR_FILENO );
close( STDERR_FILENO );
if( -1 == fprintf( stdout, "%d\n", fd ) )
{
return -1;
}

char s[] = "should fail\n";
if( -1 == write( STDOUT_FILENO, s, sizeof( s ) ) )
{
return -2;
}
return EXIT_SUCCESS;
}
```

built with glibc, the program returns 254. When built with muslc, it
returns the expected value of 255.

I believe glibc's behavior here is wrong. From what I could get by using
strace, it seems that the 1st printf's write() call is ran _after_ the
2nd one, even when adding a call to fflush( stdout ) right after the
printf.

A way to make the code behaving as one would expect is to add a fprintf
call before closing descriptor. It then behaves as expected with both
libCs.

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

Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages libc6-dev depends on:
ii  libc-dev-bin2.28-10
ii  libc6   2.28-10
ii  linux-libc-dev  4.19.160-2

libc6-dev recommends no packages.

Versions of packages libc6-dev suggests:
pn  glibc-doc 
ii  manpages-dev  4.16-2

-- no debconf information

Bug#962996: libhiredis0.14 renamed funcion

[Vladimir Briatka]

Yep, it is not so bad.
Problem is not present in buster-backports only in buster tree.

On Sun, 26 Jul 2020 15:34:03 +0800 Gang Chen  wrote:
> This bug is caused by libhiredis0.14-0.14.0-3 renaming
> redisReplyReaderGetError to redisReaderGetError.
>
> freeradius-redis may be compiled with another version (<0.14) of
libhiredis.
>
> libhiredis CHANGELOG:
>
https://github.com/redis/hiredis/blob/3af99d5fd5c2352cd73e851686bb18de122897f1/CHANGELOG.md#0140-2018-09-25
>
> --
> If it makes you happy, it can't be that bad.
>
>


--
Táto správa bola skontrolovaná na prítomnosť vírusov programom Avast Antivirus.
https://www.avast.com/antivirus

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

[Sebastian Andrzej Siewior]

On 2021-01-16 19:14:53 [+0100], Kurt Roeckx wrote:
> So I went over the open issues and pull requests, and currently
> don't see a reason not to upload it to unstable with those 2
> patches. I don't know about any other regressions in 1.1.1.

The openssl package migrated to testing.
I would prepare the pu package for Buster. Should I post here the
complete diff or an incremental containing only the new patches?
Once the openssl pu is acked I would open a pu for m2crypto. Or should
it be done now? (just asking).

> Kurt

Sebastian

Bug#980667: node-d3-transition: FTBFS: dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 1

[Xavier]

Le 20/01/2021 à 21:46, Lucas Nussbaum a écrit :
> Source: node-d3-transition
> Version: 1.3.2-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20210120 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
>> make[1]: Entering directory '/<>'
>> rollup -c
>>
>> src/index.js → dist/d3-transition.js...
>> created dist/d3-transition.js in 143ms
>>
>> src/index.js → dist/d3-transition.min.js...
>> created dist/d3-transition.min.js in 681ms
>> make[1]: Leaving directory '/<>'
>>dh_auto_test --buildsystem=nodejs
>>  mkdir -p node_modules
>>  ln -s ../. node_modules/d3-transition
>>  /bin/sh -ex debian/tests/pkg-js/test
>> + tape test/**/*-test.js

it's a timeout problem (very short in this test)

Bug#980763: src:golang-github-nrdcg-goinwx: fails to migrate to testing for too long: triggers autopkgtest regressions in golang-github-xenolf-lego

[Paul Gevers]

Source: golang-github-nrdcg-goinwx
Version: 0.6.1-3
Severity: serious
Control: close -1 0.8.1-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#957752: rcs-blame: diff for NMU version 1.3.1-4.2

[Sudip Mukherjee]

Control: tags 957752 + patch
Control: tags 957752 + pending
--

Dear maintainer,

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

--
Regards
Sudip

diff -Nru rcs-blame-1.3.1/debian/changelog rcs-blame-1.3.1/debian/changelog
--- rcs-blame-1.3.1/debian/changelog2018-10-27 12:43:11.0 +0100
+++ rcs-blame-1.3.1/debian/changelog2021-01-21 19:39:22.0 +
@@ -1,3 +1,10 @@
+rcs-blame (1.3.1-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957752)
+
+ -- Sudip Mukherjee   Thu, 21 Jan 2021 19:39:22 
+
+
 rcs-blame (1.3.1-4.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru rcs-blame-1.3.1/debian/rules rcs-blame-1.3.1/debian/rules
--- rcs-blame-1.3.1/debian/rules2018-10-26 23:17:19.0 +0100
+++ rcs-blame-1.3.1/debian/rules2021-01-21 19:35:03.0 +
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+export DEB_CFLAGS_MAINT_APPEND = -fcommon
+
 # +format causes a build failure, emailed upstream
 export DEB_BUILD_MAINT_OPTIONS=hardening=-format
 

Bug#972754: Bug fixed in 13.5.7-1

[Maximilian Stein]

Dear Maintainer,

In package version 13.5.7-1, this issue is still present. When I try to 
upload a JPG file to an issue, the upload fails unless I manually 
install libimage-exiftool-perl.


Best
Maximilian




OpenPGP_signature
Description: OpenPGP digital signature

Bug#956811: [3dprinter-general] Bug#956811: Bug#956811: Confirmed

[Gregor Riepl]

> The stable debian Buster is shipping a very old version...
> https://packages.debian.org/buster/cura

Well... I'm sorry to say, but it's very, very unlikely that buster will
receive an updated Cura version. New package versions usually land in
sid and testing, and a new Debian stable release will happen later this
year anyway.

If you'd like to run a current version of Cura (that works a little bit
better than the outdated one in buster), I warmly recommend that you
update to bullseye now and help with testing. As a matter of fact, I
think Debian testing is much more suited for desktop use than stable.

If you just want to "make it work", you can use the AppImage provided by
UltiMaker, of course.

That being said, the rendering issue is still present in 4.8. If the
upstream patch won't help, we'll have to go back and see if anything can
be done on the Debian side.

In the meantime, can you try running Cura with the theme override I
mentioned? Perhaps it will help for now.

Bug#845498: [Pkg-pascal-devel] Bug#845498: Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers

[Abou Al Montacir]

Hi Helmut,
On Tue, 2021-01-12 at 22:05 +0100, Helmut Grohne wrote:
> Hi,
> I'm coming late to the party and I only understand a fraction of whatyou
> wrote, but the parts I do understand make a lot of sense.
Better late than never. I'm surprised by the analysis you made, it is quite deep
and correct.
> On Mon, Nov 28, 2016 at 05:25:14PM -0800, Ben Longbons wrote:
> > On Mon, Nov 28, 2016 at 12:19 AM, Abou Al Montacir
> > wrote:
> > > For now you can use multi-arch to install fp-compiler
> > 
> > No, you can't (that was the first thing I thought of):fp-compiler:i386
> > depends on binutils:i386 rather thanbinutils-i586-linux-gnu, and
> > binutils:i386 isn't multiarchinstallable. You'd have to do a full cross
> > chroot, currently.
> 
> I've read the whole discussion and I'm getting the impression that thereare
> two distinct issues that are conflated inside this bug.
Maybe even three as you wrote below.
> One one hand, it would be nice to be able to install a foreignfp-compiler to
> be able to call an emulated (via qemu) compiler. On the
This was the idea. But not only, as the foreign  RTL should be usable by both a
foreign or a native cross compiler.

> other hand it would be nice to be able to install a cross compiler. And
This will require more work on the packaging and I should admit that the current
bandwidth of the team is so low that I fear it will be very difficult. Of course
if someone, with enough free time, volunteers I'll be very happy to help. But I
really have very little time for FPC currently.

> then there is a third issue not otherwise mentioned, which is crossbuilding
> the compiler itself.
For me this is not very useful for users, but only for bootstrapping a new
target. We can ignore it I think.
> All of them are nice and they interact somewhat with one another, but ithelps
> to tell these issues apart.
Maybe a good start is to split this ticket into several ones, each dealing with
a unique feature.
> > But once the dependency part is fixed, /etc/fpc.cfg can
> > `#INCLUDE/etc/fpc/$FPCTARGET.cfg` and put `-e/usr/i586-linux-gnu/bin-
> > Fl/usr/lib/i386-linux-gnu -Fl/lib/i386-linux-gnu -Fl /usr/lib32-Fl/lib32` in
> > there (each of those .cfg files will have to be manuallywritten/installed
> > based on the Debian arch (of the fp-compilerpackage), the Debian triple
> > (subdir of /usr/lib), the legacy libdir(/lib32 - actually not sure if this
> > is necessary or not anymore), theGNU triple (of binutils), and the FPC
> > target (for choice of thefilename)). Incidentally, managing /etc/fpc.cfg
> > throughupdate-alternatives is a waste since it could be implemented as
> > just`#INCLUDE /etc/fpc-$fpcversion.cfg` (though since jessie has 2.6.4,
> > anappropriate upgrade path would need to be written).
> 
> This is the part where I only understand very little. The thing I dounderstand
> is that there is a fpc.cfg that influences how the compilerbehaves and given
> the "right" fpc.cfg it can mostly act as a crosscompiler.
fpc.cfg is a file that gives the path for the RTL (Run Time Library). On Debian
we added a new feature for the compiler to support a #INCLUDE directive. That
one can be used for architecture specific directories. The paths issue is not
only for RTL, but also for the system libraries and the linker configuration. So
a deep analysis is needed. Not sure I have the time to do it for now. But If
done, I can help pointing to the code where we can hack to fix something either
in compiler or in the build system.
> As far as I understand though, there is a major piece missing in theDebian
> package to make this reality. I've run fpc hello.pas under straceand I observe
> that it calls out to ppcx64. If I were to cross compilefor armel, it would
> likely call into ppcarm, but there is no ppcarmbinary in any :amd64 package.
> So regardles how we configure it, we'llneed more binaries to make this happen.
> Please tell if you think this iswrong.
fpc is a pure wrapper that calls an architecture compiler called ppc$TARGET.
ppcx64 is native compiler in x86_64, but allows to compile for all system that
run on this architecture (windows, FreeBSD, ...) as long as related RTL is
available.
If you want to compile for arm, then it will call ppcarm, which is an arm
architecture compiler. It can be a cross compiler, but it can be a shell script
that calls the native foreign ppcarm with quemu. This needs to be further
analyzed for pros and cons. The same ppcarm should also be able to compile for
all arm related OSes like Android ...

However there is still a problem to be solved as we call ppcarm the compiler for
armel and armhf. So there will be a need to hack this in fpc code and send the
patch to upstream.
> > The above is fairly trivial and will get you a multiarch "cross"compiler,
> > with /etc/ ready for real (non-multiarch fp-compiler (I*think* the libc6-*-
> > cross packages are only needed because of ld.soconflicting. but fp-units-*
> > are actually multiarch safe already,they're just not marked 

Bug#980760: please install example latexmkrc files

[Ryan Kavanagh]

Control: tags -1 + patch

Please see the attached patch, which you can apply with

git am 0001-Install-example-latexmkrc-files-Closes-980760.patch

Best,
Ryan

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A
From e8a2f116006be256a80b7558b7e219733950924e Mon Sep 17 00:00:00 2001
From: Ryan Kavanagh 
Date: Thu, 21 Jan 2021 14:23:31 -0500
Subject: [PATCH] Install example latexmkrc files (Closes: #980760)

---
 debian/examples   |  1 +
 debian/patches/fix_file_encoding.diff | 18 ++
 debian/patches/series |  1 +
 3 files changed, 20 insertions(+)
 create mode 100644 debian/examples
 create mode 100644 debian/patches/fix_file_encoding.diff

diff --git a/debian/examples b/debian/examples
new file mode 100644
index 000..b347c16
--- /dev/null
+++ b/debian/examples
@@ -0,0 +1 @@
+example_rcfiles/*
diff --git a/debian/patches/fix_file_encoding.diff b/debian/patches/fix_file_encoding.diff
new file mode 100644
index 000..940ca12
--- /dev/null
+++ b/debian/patches/fix_file_encoding.diff
@@ -0,0 +1,18 @@
+Description: Change file encoding from ISO-8859 to UTF-8
+Author: Ryan Kavanagh 
+Origin: Debian
+Forwarded: no
+Last-Update: 2021-01-21
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: latexmk/example_rcfiles/texinfo-latexmkrc
+===
+--- latexmk.orig/example_rcfiles/texinfo-latexmkrc	2021-01-21 14:24:12.0 -0500
 latexmk/example_rcfiles/texinfo-latexmkrc	2021-01-21 14:24:41.787420897 -0500
+@@ -1,5 +1,5 @@
+ # Modifications 2015 Sep 9-10, John Collins
+-# Copyright 2014 Vincent Belaïche 
++# Copyright 2014 Vincent Belaïche 
+ 
+ # With the settings here, latexmk can be used to process texinfo files
+ # (typical extension .texi) to pdf files, including the making of
diff --git a/debian/patches/series b/debian/patches/series
index f260edd..175162b 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 rc_system_files.patch
 adjust-default-viewer
 fix-perl-shebang
+fix_file_encoding.diff
-- 
2.30.0



signature.asc
Description: PGP signature

Bug#968626: Error 500 during CI artifacts upload from gitlab-runner

[Maximilian Stein]

Hi!

same for me: after upgrading to 13.5.6, the artifacts upload works even after
reverting my local manual workaround (see "etag.patch" above).


I can confirm that the artifact upload works again without "etag.patch" 
in Gitlab 13.5.7-1, so I think that this issue can be closed now.



Best

Maximilian




OpenPGP_signature
Description: OpenPGP digital signature

Bug#980762: buster-pu: package cacti/1.2.2+ds1-2+deb10u4

[Paul Gevers]

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

Hi Adam, all,

[ Reason ]
A CVE was discovered in cacti and fixed upstream. I backported the patch
to the buster package. Related, other security issues were discovered
and fixed.

[ Impact ]
A SQL injection vulnerability in data_debug.php allows remote
authenticated attackers to execute arbitrary SQL commands via the
site_id parameter. This can lead to remote code execution. CVE-2020-35701.

Additionally, there are a few places in the current code where an
attacker, once having gained access to the Cacti database through a SQL
injection, could modify data in tables to possibly expose an stored XSS
bug in Cacti.

[ Tests ]
I have run the autopkgtest included in the source package.

[ Risks ]
The call to the input sanitizer is moved from within the default
alternative to the start of the code. Hence, the change is simple and
the actual code has always been in the default code path, so I think the
risk for the CVE fix is low.

The patch for the other issues didn't apply, so I had to adapt it to the
code base in buster. I've inspected both the final patch and the diff
between upstream's changes and the final patch, both look sane. The
changes are exclusively calling an existing used function to sanitize
input additionally or instead of a text trim command (which upstream
claims is not needed anymore). I think the risk is low.

[ Checklist ]
  [✓] *all* changes are documented in the d/changelog
  [✓] I reviewed all changes and I approve them
  [✓] attach debdiff against the package in stable
  [✓] the issue is verified as fixed in unstable

[ Changes ]
Upstream patches added to the patch set.

[ Other info ]
I've discussed with carnil if this warrants a DSA but we thought this
made sense to fix via a point release.

I have already uploaded the package.

Paul
diff -Nru cacti-1.2.2+ds1/debian/changelog cacti-1.2.2+ds1/debian/changelog
--- cacti-1.2.2+ds1/debian/changelog2020-06-18 22:34:41.0 +0200
+++ cacti-1.2.2+ds1/debian/changelog2021-01-21 20:16:38.0 +0100
@@ -1,3 +1,15 @@
+cacti (1.2.2+ds1-2+deb10u4) buster; urgency=medium
+
+  * Add 0001-Fixing-Issue-4022.patch (Closes: #979998)
+- CVE-2020-35701: SQL injection via data_debug.php
+  * Add 0001-Fixing-Issue-4019.patch
+There are a few places in the current code where an attacker, once
+having gained access to the Cacti database through a SQL injection,
+could modify data in tables to possibly expose an stored XSS bug in
+Cacti.
+
+ -- Paul Gevers   Thu, 21 Jan 2021 20:16:38 +0100
+
 cacti (1.2.2+ds1-2+deb10u3) buster; urgency=medium
 
   * Unix timestamps after Sep 13 2020 are rejected as graph start/end
diff -Nru cacti-1.2.2+ds1/debian/patches/0001-Fixing-Issue-4019.patch 
cacti-1.2.2+ds1/debian/patches/0001-Fixing-Issue-4019.patch
--- cacti-1.2.2+ds1/debian/patches/0001-Fixing-Issue-4019.patch 1970-01-01 
01:00:00.0 +0100
+++ cacti-1.2.2+ds1/debian/patches/0001-Fixing-Issue-4019.patch 2021-01-21 
20:16:38.0 +0100
@@ -0,0 +1,222 @@
+From ef10fe1c340ed932dc18b6a566b21f9dd15933c2 Mon Sep 17 00:00:00 2001
+From: TheWitness 
+Date: Wed, 23 Dec 2020 16:33:27 -0500
+Subject: [PATCH] Fixing Issue #4019
+
+* In a recent audit of core Cacti code, there were a few stored XSS issues 
that can be exposed
+* Also removed a few spurious title_trims, that should no longer be a problem.
+---
+ CHANGELOG  |  1 +
+ automation_devices.php | 10 +-
+ data_debug.php |  6 +++---
+ data_sources.php   |  2 +-
+ lib/api_automation.php | 22 +++---
+ lib/html.php   |  9 +
+ lib/html_graph.php | 10 +-
+ lib/html_tree.php  |  4 ++--
+ managers.php   |  2 +-
+ utilities.php  | 20 ++--
+ 10 files changed, 44 insertions(+), 42 deletions(-)
+
+Index: cacti/automation_devices.php
+===
+--- cacti.orig/automation_devices.php
 cacti/automation_devices.php
+@@ -466,7 +466,7 @@ function draw_filter() {
+$name) {
+-  print "' . $name . "\n";
++  print "' . html_escape($name) . "\n";
+   }
+   }
+   ?>
+@@ -496,7 +496,7 @@ function draw_filter() {
+   ' . $st . "\n";
++  print "' . html_escape($st) . "\n";
+   }
+   }
+   ?>
+@@ -511,7 +511,7 @@ function 

Bug#979088: plasma-applet-redshift-control: redshift

[Ricardo Mones]

Package: plasma-applet-redshift-control
Version: 1.0.18+phabricator~2019080100-1
Followup-For: Bug #979088

Hi,

Just found that redshift is not running twice as original submitter
said, but up to 3 instances (just first session after reboot):

$ pgrep -a redshift
2318 /usr/bin/redshift
2402 /usr/bin/redshift -l 43.5357 -5.6615 -t 6500 4000 -b 1 1 -g 1 1 1
2403 /usr/bin/redshift -l 50 7 -t 6500 4000 -b 1 1 -g 1 1 1 -r

Apliying the suggested workaround just removes the first, but there's
still two of them:

$ systemctl stop redshift.service --user && systemctl disable redshift.service 
--user
$ pgrep -a redshift
2402 /usr/bin/redshift -l 43.5357 -5.6615 -t 6500 4000 -b 1 1 -g 1 1 1
2403 /usr/bin/redshift -l 50 7 -t 6500 4000 -b 1 1 -g 1 1 1 -r

Fortunately these two don't fight for changing the screen gamma and the
flicker is not noticeable.

regards,

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

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 plasma-applet-redshift-control depends on:
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4
ii  redshift1.12-4

plasma-applet-redshift-control recommends no packages.

plasma-applet-redshift-control suggests no packages.

-- no debconf information

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Maximilian Stein]

Someone affected should confirm it, I confirmed issue pages that was broken is 
fixed.


My broken pages are actually fixed with Gitlab 13.5.7-1. So for my side, 
this issue can be closed.


Thanks a lot for debugging & fixing!

Best

Maximilian




OpenPGP_signature
Description: OpenPGP digital signature

Bug#980760: please install example latexmkrc files

[Ryan Kavanagh]

Package: latexmk
Version: 1:4.70b-0.1
Severity: wishlist
X-Debbugs-Cc: r...@debian.org

latexmk sources include a directory of example latexmkrc files. Please
install these.


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

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

Versions of packages latexmk depends on:
ii  perl5.32.0-6
ii  texlive-latex-base  2020.20210113-1

Versions of packages latexmk recommends:
ii  evince [postscript-viewer]3.38.0-3
ii  ghostscript [postscript-viewer]   9.53.3~dfsg-6
ii  gv [postscript-viewer]1:3.7.4-2+b1
ii  mupdf [pdf-viewer]1.17.0+ds1-1.2
ii  xpdf [pdf-viewer] 3.04-14
ii  zathura-pdf-poppler [pdf-viewer]  0.3.0-1

Versions of packages latexmk suggests:
ii  ghostscript  9.53.3~dfsg-6

-- no debconf information

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A

Bug#980754: yadm:bash completions does not work

[Russ Allbery]

YABUKI Yukiharu  writes:

> I use yadm with bash. I use yadm command frequency. Once a day, yadm
> works fine with bash. But nowadays, yadm does not do completions with
> bash. I just switch in zsh. It look yadm completion is fine.

This works for me on one system and not on another, both with the same
version of yadm, so I think something changed in bash.  On the working
system, I have bash 5.1~rc2-1, and on the broken system, I have bash
5.1-2.  Both have the same version of bash-completion.

I haven't yet tracked down what the change was.

-- 
Russ Allbery (r...@debian.org)  

Bug#980751: petsc: breaks multiple autopkgtests: undefined reference to 'MPIU_SUM'

[Graham Inggs]

Might be fixed by binNMU of slepc, see #980749.

Bug#980758: make installation of wireless firmware easier for end users

[lange]

Package: firmware-nonfree

When an end user want to install firmware for the wireless cards, they
need to know which chip is build into their computer, to get the
correct Debian package name.

If Debian would provide a meta package for all wireless/wlan firmware
packages, the end user only need to install this package.

We already have firmware-linux-nonfree and firmware-misc-nonfree
(which do not depend on the wireless firmware packages)
so maybe the new name could be firmware-wireless-nonfree.

I found these package that include firmware for wireless cards.

atmel-firmware
firmware-atheros
firmware-brcm80211
firmware-ipw2x00
firmware-iwlwifi
firmware-libertas
firmware-ralink
firmware-zd1211
firmware-brcm80211
firmware-ti-connectivity

-- 
regards Thomas

Bug#923479: [Pkg-openssl-devel] Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)

[Sebastian Andrzej Siewior]

On 2021-01-20 11:50:05 [+0100], Julien Cristau wrote:
> > Can this be reassigned to openssl in the meantime? I think it's a goal to 
> > have
> > all of Debian built with largefile support, anyways.
> 
> Yes.

meh. Is this stable or sid?

> Cheers,
> Julien

Sebastian

Bug#980640: libdbd-mariadb-perl: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

[gregor herrmann]

Control: tag -1 + confirmed help

On Wed, 20 Jan 2021 21:42:50 +0100, Lucas Nussbaum wrote:

> Source: libdbd-mariadb-perl
> Version: 1.21-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20210120 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Confirmed.

I've imported the Ubuntu patches, but the test setup still fails
with:

# prepare mariadb/mysql server
sh /build/libdbd-mariadb-perl-1.21/debian/tests/pkg-perl/smoke-setup
chown: cannot access 
'/usr/lib/mysql/plugin/auth_pam_tool_dir/auth_pam_tool': Permission denied
Couldn't set an owner to 
'/usr/lib/mysql/plugin/auth_pam_tool_dir/auth_pam_tool'.
It must be root, the PAM authentication plugin doesn't work otherwise..

I.e. it fails in my cowbuilder chroot, with the 'pbuilder' user.
Starting the test manually as root in the chroot then works.

R³: binary doesn't help. Running the setup with fakeroot doesn't
help.


Any ideas?


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Beatles


signature.asc
Description: Digital Signature

Bug#980757: python3-sugar3: trying to overwrite '/usr/bin/sugar-activity-web', which is also in package python-sugar3 0.112-3

[Lisandro Damián Nicanor Pérez Meyer]

Package: python3-sugar3
Version: 0.117-1
Severity: serious
Justification: Tries to overwrite a file of another package
X-Debbugs-Cc: lisan...@debian.org

Hi! While updating a machine from Buster to Bullseye I've got:

dpkg: error processing archive 
/tmp/apt-dpkg-install-RqVcNz/34-python3-sugar3_0.117-1_all.deb (--unpack):
 trying to overwrite '/usr/bin/sugar-activity-web', which is also in package 
python-sugar3 0.112-3

Thanks for your work, Lisandro.


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

Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.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 python3-sugar3 depends on:
pn  gir1.2-atspi-2.0   
ii  gir1.2-gdkpixbuf-2.0   2.42.2+dfsg-1
ii  gir1.2-glib-2.01.66.1-1+b1
ii  gir1.2-gtk-3.0 3.24.24-1
ii  gir1.2-pango-1.0   1.46.2-3
pn  gir1.2-rsvg-2.0
pn  gir1.2-sugarext-1.0
pn  gir1.2-telepathyglib-0.12  
ii  python33.9.1-1
ii  python3-cairo  1.16.2-4+b2
ii  python3-dateutil   2.8.1-5
ii  python3-dbus   1.2.16-4+b1
pn  python3-decorator  
ii  python3-gi 3.38.0-1+b2
pn  python3-gi-cairo   
ii  python3-six1.15.0-2

Versions of packages python3-sugar3 recommends:
ii  alsa-utils   1.2.4-1
pn  gir1.2-webkit2-4.0   
pn  gstreamer1.0-espeak  
ii  gstreamer1.0-plugins-good1.18.3-1
ii  shared-mime-info 2.0-1
pn  telepathy-mission-control-5  
pn  telepathy-salut  
ii  unzip6.0-26

Versions of packages python3-sugar3 suggests:
ii  git 1:2.30.0-1
pn  ipython3
pn  python3-carquinyol  

Bug#980323: flatpak: LD_LIBRARY_PATH is not set under flatpak-builder

[Simon McVittie]

On Thu, 21 Jan 2021 at 17:51:34 +, Simon McVittie wrote:
> Security team: this is a regression in DSA 4830-1 (CVE-2021-21261), now
> fixed upstream in 1.10.1 and backported to 1.2.x. In addition to the
> regression that was reported in #980323, I looked at similar code paths
> and fixed an equivalent regression elsewhere. It's a 2-line change
> (I'll follow up with the full debdiff, which is rather larger due to
> patch headers and changelog). Do you want a DSA 4830-2 to fix this?

Here's the proposed source debdiff.

I've assumed that urgency=medium genuinely *is* what I want this time :-)

smcv
diffstat for flatpak-1.2.5 flatpak-1.2.5

 changelog   |   17 
 patches/build-Convert-environment-into-a-sequence-of-bwrap-argume.patch |   39 ++
 patches/dir-Pass-environment-via-bwrap-setenv-when-running-apply_.patch |   32 
 patches/series  |2 
 4 files changed, 90 insertions(+)

diff -Nru flatpak-1.2.5/debian/changelog flatpak-1.2.5/debian/changelog
--- flatpak-1.2.5/debian/changelog	2021-01-12 16:23:32.0 +
+++ flatpak-1.2.5/debian/changelog	2021-01-21 13:57:39.0 +
@@ -1,6 +1,23 @@
+flatpak (1.2.5-0+deb10u3) buster-security; urgency=medium
+
+  * Fix regressions in DSA 4830-1
+- Add patch from upstream to fix a regression in 'flatpak build'.
+  The patches to resolve CVE-2021-21261 caused a regression in which
+  'flatpak build' wouldn't set the LD_LIBRARY_PATH that it should.
+  (Closes: #980323)
+- Add a patch from upstream to fix possible regressions in extra-data.
+  The extra-data mechanism, used to download large or proprietary
+  components out-of-band, could suffer from a regression similar to
+  #980323 if the app or runtime's apply_extra entry point relies on
+  LD_LIBRARY_PATH.
+  * Add CVE-2021-21261 reference to previous changelog entry
+
+ -- Simon McVittie   Thu, 21 Jan 2021 13:57:39 +
+
 flatpak (1.2.5-0+deb10u2) buster-security; urgency=medium
 
   * Add patches for sandbox escape vulnerability GHSA-4ppf-fxf6-vxg2
+(CVE-2021-21261)
 
  -- Simon McVittie   Tue, 12 Jan 2021 16:23:32 +
 
diff -Nru flatpak-1.2.5/debian/patches/build-Convert-environment-into-a-sequence-of-bwrap-argume.patch flatpak-1.2.5/debian/patches/build-Convert-environment-into-a-sequence-of-bwrap-argume.patch
--- flatpak-1.2.5/debian/patches/build-Convert-environment-into-a-sequence-of-bwrap-argume.patch	1970-01-01 01:00:00.0 +0100
+++ flatpak-1.2.5/debian/patches/build-Convert-environment-into-a-sequence-of-bwrap-argume.patch	2021-01-21 13:57:39.0 +
@@ -0,0 +1,39 @@
+From: Simon McVittie 
+Date: Mon, 18 Jan 2021 17:52:13 +
+Subject: build: Convert environment into a sequence of bwrap arguments
+
+This means we can systematically pass the environment variables
+through bwrap(1), even if it is setuid and thus is filtering out
+security-sensitive environment variables. bwrap itself ends up being
+run with an empty environment instead.
+
+This fixes a regression when CVE-2021-21261 was fixed: before the
+CVE fixes, LD_LIBRARY_PATH would have been passed through like this
+and appeared in the `flatpak build` shell, but during the CVE fixes,
+the special case that protected LD_LIBRARY_PATH was removed in favour
+of the more general flatpak_bwrap_envp_to_args(). That reasoning only
+works if we use flatpak_bwrap_envp_to_args(), consistently, everywhere
+that we run the potentially-setuid bwrap.
+
+Fixes: 6d1773d2 "run: Convert all environment variables into bwrap arguments"
+Bug: https://github.com/flatpak/flatpak/issues/4080
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980323
+Signed-off-by: Simon McVittie 
+Applied-upstream: 1.10.1, commit:9a61d2c44f0a58cebcb9b2787ae88db07ca68bb0
+---
+ app/flatpak-builtins-build.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/app/flatpak-builtins-build.c b/app/flatpak-builtins-build.c
+index 9410791..5ba3ba8 100644
+--- a/app/flatpak-builtins-build.c
 b/app/flatpak-builtins-build.c
+@@ -566,6 +566,8 @@ flatpak_builtin_build (int argc, char **argv, GCancellable *cancellable, GError
+   NULL);
+ }
+ 
++  flatpak_bwrap_envp_to_args (bwrap);
++
+   if (!flatpak_bwrap_bundle_args (bwrap, 1, -1, FALSE, error))
+ return FALSE;
+ 
diff -Nru flatpak-1.2.5/debian/patches/dir-Pass-environment-via-bwrap-setenv-when-running-apply_.patch flatpak-1.2.5/debian/patches/dir-Pass-environment-via-bwrap-setenv-when-running-apply_.patch
--- flatpak-1.2.5/debian/patches/dir-Pass-environment-via-bwrap-setenv-when-running-apply_.patch	1970-01-01 01:00:00.0 +0100
+++ flatpak-1.2.5/debian/patches/dir-Pass-environment-via-bwrap-setenv-when-running-apply_.patch	2021-01-21 13:57:39.0 +
@@ -0,0 +1,32 @@
+From: Simon McVittie 
+Date: Mon, 18 Jan 2021 18:07:38 +
+Subject: dir: Pass environment 

Bug#980756: RFS: pynpoint/0.9.0-1 -- Pipeline for processing and analysis of high-contrast imaging data

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: pynpoint
   Version : 0.9.0-1
   Upstream Author : Tomas Stolker
 * URL : https://github.com/PynPoint/PynPoint
 * License : GPL-3+, GPL-3-only
 * Vcs : https://salsa.debian.org/debian-astro-team/pynpoint
   Section : science

It builds those binary packages:

  python3-pynpoint - Pipeline for processing and analysis of 
high-contrast imaging data


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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/p/pynpoint/pynpoint_0.9.0-1.dsc


Changes since the last upload:

 pynpoint (0.9.0-1) unstable; urgency=medium
 .
   * New upstream version.
   * d/patches: dropped as it was upstreamed.

Regards,
--
  Gürkan Myczko

Bug#980323: flatpak: LD_LIBRARY_PATH is not set under flatpak-builder

[Joonas Sarajärvi]

Hi Simon

Thank you for your prompt handling of this issue

to 21. tammik. 2021 klo 19.51 Simon McVittie (s...@debian.org) kirjoitti:
> Please could you try this test version? (Source code and amd64 binaries
> included; .dsc and .changes signed by my key in the Debian keyring and
> can be checked with dscverify)
>
> https://people.debian.org/~smcv/bug980323/
>

All the symptoms that I reported are absent in the flatpak package
provided here. For example, the problematic Emacs build of the
original report runs just fine.

Thanks,
- Joonas

Bug#980660: libmoox-traits-perl: FTBFS: dh_auto_test: error: make -j4 test TEST_VERBOSE=1 returned exit code 2

[gregor herrmann]

Control: tag -1 + confirmed

On Wed, 20 Jan 2021 21:46:35 +0100, Lucas Nussbaum wrote:

> Source: libmoox-traits-perl
> Version: 0.005-1.1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20210120 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Ack.

Probably the update of librole-tiny-perl.
Forwarded upstream.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Kaputtnicks: Brief an den Bundeskanzler


signature.asc
Description: Digital Signature

Bug#980755: ring-json-clojure: A new source-only upload is needed

[Boyuan Yang]

Source: ring-json-clojure
Version: 0.4.0-1
Severity: important
X-Debbugs-CC: z...@debian.org

Dear Debian ring-json-clojure package maintainers,

According to https://tracker.debian.org/pkg/ring-json-clojure , package
ring-json-clojure was not updated after its initial upload. As a
result, this package did not migrate to Debian Testing due to non-
source-only upload.

The package will miss Debian 11 release if this issue is not solved
recently. Please make another source-only upload following
https://wiki.debian.org/SourceOnlyUpload .

Thanks,
Boyuan Yang




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

Bug#979819: Raise severity, cannot create venv for any older python versions!

[Kostis Anagnostopoulos]

FYI, i managed to complete the workaround attempted above
and install a working python3.8 venv in "sid"
by downloading and unpacking python3-distutils from "buster"[1]
(which is for Python 3.7.3-1: all)
and then moving it over in 3.8 directory:

sudo dpkg  --unpack  ~/Downloads/python3-distutils_3.7.3-1_all.deb
sudo rm -rf /usr/lib/python3.8/distutils
sudo mv  /usr/lib/python3.{7,8}/distutils

[1]: https://packages.debian.org/buster/python3-distutils

Bug#980682: liblist-objects-withutils-perl: FTBFS: dh_auto_test: error: make -j1 test TEST_VERBOSE=1 returned exit code 2

[gregor herrmann]

Control: tag -1 + confirmed

On Wed, 20 Jan 2021 21:46:33 +0100, Lucas Nussbaum wrote:

> Source: liblist-objects-withutils-perl
> Version: 2.028003-1.1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20210120 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Same here.

My hunch is that this broke with the update of librole-tiny-perl from 2.001004-1
to 2.002003-1.

Forwarded upstream.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Anouar Brahem: Leila au pays du carrousel


signature.asc
Description: Digital Signature

Bug#980528: debian-installer: net-install impossible because link is always reset

[Geert Stappers]

Not noticing humor, is no proof for the absence of humor.


On Thu, Jan 21, 2021 at 04:40:14PM +, etkaar wrote:
> Good evening,
> 
> after some testing it seems that I am just a very stupid person.

Mmm,  one of my motivators for working on libre software projects
is collaborating with smart people.
I'm willing to lower the bar to "people who can think for themselfs"
After all is the idea of "I could be stupid" just brilant.

 
> The reason, why the interface is always down is - after I had a look
> into the source code of netcfg - that is simply fails *and*, before
> it fails, netcfg would always reset the link, remove any routes and
> ip addresses. At least that is what I assume.
> 
> But why can I manually configure the network? Because I used the onlink flag:
> 
> # ip link set ens1 up
> # ip addr add 255.255.8.243/29 dev ens1
> # ip route add default via 255.255.8.1 dev ens1 >>>onlink<<<
> 
> "onlink: pretend that the nexthop is directly attached to this link,
> even if it does not match any interface prefix."
> https://linux.die.net/man/8/ip
> 
> The /29 subnet actually does not exist on the host; in reality,
> it is a /24 subnet. While /etc/network/interfaces in the installed
> Debian system itself would be aware of whatever it is aware of - I
> just don't know - and automatically will configure the route using the
> onlink tag, in the debian installer that is not possible. It seems the
> only correct way would have been to configure the network with the /24
> notation and the according 255.255.255.0 netmask, which makes sense,
> because working with a /29 notation using MacVTap and VEPA does not
> make much sense for me if the subnet is configured as /24 on the host.

"netmask" is a layer 3 thingy.  My gutfeeling says the problem is
at layer 2, where "link" happens.
 
> However, I am not well-educated when it comes to networking at all. I
> think my assumptions are right, but if the debian installer should
> be aware of that (like the final Debian installation is), we should
> leave that issue open.

Message for those who encounter simular problem:
  Please express your observations.


My observation:
  An address like _._.8.1 is never in same network as _._.8.243/29


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#980323: flatpak: LD_LIBRARY_PATH is not set under flatpak-builder

[Simon McVittie]

Control: tags -1 + pending

On Mon, 18 Jan 2021 at 17:44:49 +, Simon McVittie wrote:
> On Sun, 17 Jan 2021 at 21:20:38 +0200, Joonas Sarajärvi wrote:
> > With flatpak 1.2.5-0+deb10u2, LD_LIBRARY_PATH is not set when invoked
> > over flatpak-builder.
> 
> Good catch, this is a regression in the security update.

Please could you try this test version? (Source code and amd64 binaries
included; .dsc and .changes signed by my key in the Debian keyring and
can be checked with dscverify)

https://people.debian.org/~smcv/bug980323/

Security team: this is a regression in DSA 4830-1 (CVE-2021-21261), now
fixed upstream in 1.10.1 and backported to 1.2.x. In addition to the
regression that was reported in #980323, I looked at similar code paths
and fixed an equivalent regression elsewhere. It's a 2-line change
(I'll follow up with the full debdiff, which is rather larger due to
patch headers and changelog). Do you want a DSA 4830-2 to fix this?

smcv

Bug#980753: ITP: pampi -- Presentations with Markdown, Pandoc, Impress

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: pampi
  Version : 1.0
  Upstream Author : pascal.pe...@free.fr
* URL : https://gitlab.com/edleh/pampi
* License : GPL-3+
  Programming Lang: Python
  Description : Presentations with Markdown, Pandoc, Impress

 PAMPI is a free software to create presentations easily.
 .
 presentations are written in text files,
   - so they can be modified easily
   - the files syntax (Markdown) is easily learnt
   - many examples of usable Markdown are available at
 https://enacit1.epfl.ch/markdown-pandoc
  They are converted to web pages (HTML files)
   - one can view them with a browser
   - one can publish them online, grab them on a USB stick, etc.
 In PAMPI's interface, the Markdown file is displaied in the left
 side and on can view the result in the right side.
 .
 Every step of a presentation can be located in any position in a 3D
 space
   - one provides its coordinates
   - one can specify its zoom factor
   - one can specify rotations
 Maths can be authored with KaTeX.
 .
 Here are many examples: https://en.wikibooks.org/wiki/LaTeX/Mathematics.

Bug#980754: yadm:bash completions does not work

[YABUKI Yukiharu]

Package: yadm
Version: 2.5.0-2
Severity: normal

Dear Maintainer,

I use yadm with bash. I use yadm command frequency. Once a day, yadm
works fine with bash. But nowadays, yadm does not do completions with
bash. I just switch in zsh. It look yadm completion is fine.

I checked vanilla bash environment with yadm. yadm with bash_completion
does not work.

Who works yadm with bash_completions fine?

Best regards, Yukiharu

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

Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 yadm depends on:
ii  git  1:2.30.0-1

yadm recommends no packages.

yadm suggests no packages.

-- no debconf information

Bug#980750: linux-image-5.10.0-1-amd64: no compatibility with new AMD RX 6800 generation graphics cards

[alain]

Package: src:linux
Version: 5.10.5-1
Followup-For: Bug #980750
X-Debbugs-Cc: compte.perso.de-al...@bbox.fr

thank you very much to the debian dev team and the BTS for the speed with which
they diagnosed and solved the problem.

I hope that this solution will be operational and will bring a positive result
as soon as possible.

for the moment, this kernel is not yet present in the repositories.

I'm looking forward to it.

I am sure that this will solve my problem and that of the people to come for
this generation of graphic cards.

Thank you very much.

I'll get back to you as soon as the new kernel is installed and tested.

Thanks again.





Translated with www.DeepL.com/Translator (free version)



-- Package-specific info:
** Version:
Linux version 5.10.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-5) 10.2.1 20210108, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP 
Debian 5.10.5-1 (2021-01-09)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-1-amd64 
root=UUID=356787df-36be-449a-8129-e219dbf2cab8 ro nomodeset=1 quiet

** Not tainted

** Kernel log:
[2.508749] input: PC Speaker as /devices/platform/pcspkr/input/input6
[2.509677] sd 5:0:0:0: Attached scsi generic sg0 type 0
[2.509713] sd 6:0:0:0: Attached scsi generic sg1 type 0
[2.510090] ccp :0c:00.1: enabling device ( -> 0002)
[2.510206] ccp :0c:00.1: ccp: unable to access the device: you might be 
running a broken BIOS.
[2.510431] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver
[2.510484] sp5100-tco sp5100-tco: Using 0xfeb0 for watchdog MMIO address
[2.510553] sp5100-tco sp5100-tco: initialized. heartbeat=60 sec (nowayout=0)
[2.511185] pstore: Using crash dump compression: deflate
[2.511190] pstore: Registered efi as persistent store backend
[2.515497] asus_wmi: ASUS WMI generic driver loaded
[2.516449] asus_wmi: Initialization: 0x0
[2.516468] asus_wmi: BIOS WMI version: 0.9
[2.516538] asus_wmi: SFUN value: 0x0
[2.516540] eeepc-wmi eeepc-wmi: Detected ASUSWMI, use DCTS
[2.516838] input: Eee PC WMI hotkeys as 
/devices/platform/eeepc-wmi/input/input7
[2.518947] EXT4-fs (nvme0n1p4): mounted filesystem with ordered data mode. 
Opts: (null)
[2.547388] audit: type=1400 audit(1611246971.866:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=1426 comm="apparmor_parser"
[2.547392] audit: type=1400 audit(1611246971.866:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=1434 
comm="apparmor_parser"
[2.547394] audit: type=1400 audit(1611246971.866:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=1425 comm="apparmor_parser"
[2.547585] audit: type=1400 audit(1611246971.866:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=1427 
comm="apparmor_parser"
[2.547588] audit: type=1400 audit(1611246971.866:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=1427 comm="apparmor_parser"
[2.547863] audit: type=1400 audit(1611246971.866:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=1429 
comm="apparmor_parser"
[2.547865] audit: type=1400 audit(1611246971.866:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=1429 
comm="apparmor_parser"
[2.547866] audit: type=1400 audit(1611246971.866:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=1429 
comm="apparmor_parser"
[2.548974] audit: type=1400 audit(1611246971.870:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=1431 comm="apparmor_parser"
[2.554660] snd_hda_intel :0a:00.1: Handle vga_switcheroo audio client
[2.554662] snd_hda_intel :0a:00.1: Force to non-snoop mode
[2.554945] snd_hda_intel :0c:00.4: enabling device ( -> 0002)
[2.606121] input: HDA ATI HDMI HDMI/DP,pcm=3 as 
/devices/pci:00/:00:03.1/:08:00.0/:09:00.0/:0a:00.1/sound/card0/input8
[2.606165] input: HDA ATI HDMI HDMI/DP,pcm=7 as 
/devices/pci:00/:00:03.1/:08:00.0/:09:00.0/:0a:00.1/sound/card0/input9
[2.606199] input: HDA ATI HDMI HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.1/:08:00.0/:09:00.0/:0a:00.1/sound/card0/input10
[2.606228] input: HDA ATI HDMI HDMI/DP,pcm=9 as 
/devices/pci:00/:00:03.1/:08:00.0/:09:00.0/:0a:00.1/sound/card0/input11
[2.606257] input: HDA ATI HDMI HDMI/DP,pcm=10 as 
/devices/pci:00/:00:03.1/:08:00.0/:09:00.0/:0a:00.1/sound/card0/input12
[2.606284] input: HDA ATI HDMI HDMI/DP,pcm=11 as 
/devices/pci:00/:00:03.1/:08:00.0/:09:00.0/:0a:00.1/sound/card0/input13
[2.627195] RAPL PMU: API unit is 2^-32 Joules, 1 fixed 

Bug#961091: gcc-arm-none-eabi: Provide gdc (D compiler) cross-compiler for arm-none-eabi

[Witold Baryluk]

Package: gcc-arm-none-eabi
Version: 15:8-2019-q3-1+b1
Followup-For: Bug #961091
X-Debbugs-Cc: witold.bary...@gmail.com

gdc is now merged in gcc main tree in 9.x and 10.x, so it should be even
easier now than before.

It is present in Arm toolchain bundle from

https://developer.arm.com/-/media/Files/downloads/gnu-rm/9-2020q2/gcc-arm-none-eabi-9-2020-q2-update-src.tar.bz2


To compile it at configure you will need:

--enable-languages=c,c++,d,lto
--disable-libphobos

Other options can remain as they are in current rules file

https://salsa.debian.org/debian/gcc-arm-none-eabi/-/blob/master/debian/rules

I didn't test --enable-tls, but I don't think there should be any issue
with that.

Adding `gdc` to Build-Depends is also required, as it is not included by
default in `build-essential`.


Here is example of compiling gdc for arm-none-eabi for Cortex-M machines
for example.

https://github.com/JinShil/arm-none-eabi-gdc/blob/master/arm-none-eabi-gdc.sh
but it is pretty old, and since then there is no need to apply out of
tree patches for gdc.

--enable-lto \
--enable-gold\
--enable-plugins


would also be useful, for reducing binary sizes in some cases. I am not sure if 
these
are enabled by default, but I assume yes.

Extra references (a bit dated):

http://wiki.dlang.org/GDC/Cross_Compiler/Generic
http://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler

Thanks!

Bug#979859: libvirt0: Starting virtual pc with virtManager cause raise libvirtError setCpusetMemoryMigrate' not supported

[Manuel Espina]

The workaround mentioned in bug #935734 seems to work: configuring
cgroup_controllers = [ ] in /etc/libvirt/qemu.conf and restarting
libvirtd makes the virtual machines boot again.

Bug#980528: debian-installer: net-install impossible because link is always reset

[etkaar]

Good evening,after some testing it seems that I am just a very stupid person.The reason, why the interface is always down is - after I had a look into the source code of netcfg - that is simply fails *and*, before it fails, netcfg would always reset the link, remove any routes and ip addresses. At least that is what I assume.But why can I manually configure the network? Because I used the onlink flag:# ip link set ens1 up# ip addr add 255.255.8.243/29 dev ens1# ip route add default via 255.255.8.1 dev ens1 >>>onlink<<<"onlink: pretend that the nexthop is directly attached to this link, even if it does not match any interface prefix."https://linux.die.net/man/8/ipThe /29 subnet actually does not exist on the host; in reality, it is a /24 subnet. While /etc/network/interfaces in the installed Debian system itself would be aware of whatever it is aware of - I just don't know - and automatically will configure the route using the onlink tag, in the debian installer that is not possible. It seems the only correct way would have been to configure the network with the /24 notation and the according 255.255.255.0 netmask, which makes sense, because working with a /29 notation using MacVTap and VEPA does not make much sense for me if the subnet is configured as /24 on the host.However, I am not well-educated when it comes to networking at all. I think my assumptions are right, but if the debian installer should be aware of that (like the final Debian installation is), we should leave that issue open.--etkaar