Bug#1012658: redis: cjson not usable in current sid release

[Chris Lamb]

> thanks for your support.

No problem. Can you try 7.0.1-2 in experimental? :)  I'm planning on
putting this version in Debian sid/unstable soon anyway.


Regards,

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

Bug#1012785: libgsasl7 depends on outdated gsasl-common version 1.10.0-5

[Felicia P]

Please close this bug.  It is no longer applicable.  Thanks!

Bug#1012820: calibre fails on converting to PDF

[nbi]

It turned out to be an authorization issue which was solved by "xhost +" 
for the non-root user. Calibre is still not doing the PDF conversion, 
but the problem is with the plugin for that conversion not the Debian 
environment. This can be closed.


On Wed, 15 Jun 2022 13:39:24 +0900 yokota  wrote:
> Hello,
>
> > 2. If I run as a non-root user I get:
> >
> > Authorization required, but no authorization protocol specified
> > qt.qpa.xcb: could not connect to display :0.0
> > qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" 
even though it

> > was found.
> > This application failed to start because no Qt platform plugin could be
> > initialized. Reinstalling the application may fix this problem.
> >
> > Available platform plugins are: eglfs, linuxfb, minimal, 
minimalegl, offscreen,
> > vnc, wayland-egl, wayland, wayland-xcomposite-egl, 
wayland-xcomposite-glx, xcb.

>
> > qt.qpa.xcb: could not connect to display :0.0
> This line shows that you are not connected to X11.
>
> PDF render uses Qt library, and Qt requires some GUI environment like 
X11.
> Check X11 environment and works other X11 client programs on your 
machine.

>
> You must setup X11 and connect X server properly even if you don't
> want to use GUI.
> Install X11 environment and related Qt libraries, and run from GUI 
environment.

>
> --
> YOKOTA
>
>

Bug#1007717: Updated draft resolution

[Helmut Grohne]

Hi,

On Tue, Jun 07, 2022 at 10:31:18PM -0700, Sean Whitton wrote:
> Here's an updated ballot in light of our upcoming meeting.  I've left
> space to add a 4b, if, when our current discussion is concluded, someone
> would like that in addition to 4c.


After the meeting, Simon, Sean and myself further discussed aspect 4
without reaching conensus. I'll try to summarize the views expressed
here.

Simon looked at how other distributions approach patches and figured
that basically everyone else uses the patches-unapplied model. Going
patches-unapplied has the benefit of not imposing a particular workflow
onto your git repository. It can be gbp-pq, saving the output of git
format-patch or an email patch, or even writing diff syntax manually. We
also observed that a significant portion of Debian uses the
patches-unapplied model, including but not limited to Gnome, Haskell, Perl,
Python, systemd, much of pkg-games and utopia/freedesktop. It is fair to
say that dgit is an outlier here in choosing patches-applied as a model.

The 3.0 (quilt) format was specifically designed for the
patches-unapplied model (which is also why it is not that a good fit for
dgit). And for that reason, people who prefer patches-unapplied see
little reason to keep using 1.0 source formats. For 1.0-native, we
already figured that 3.0 (native) would be better once lifting the
revision restriction. For 1.0-with-diff, there are two basic models. In
one model, you patch everything directly and most likely manage your
diff in some VCS (e.g. git). In this model, there typically is no
debian/patches or other kind of patch management system in the source
package. The other model restricts itself to only adding files below
debian/ and then using debian/rules to actually apply patches during
build. This latter model is fairly annoying, because there are so many
different ways of doing it (i.e. we lack consistency there).

So what I'd like to ensure is that any resolution we do here is clear
about discontinuing the use of 1.0-with-diff together with a patch
system to be applied during package build. We've explored that model in
depth and settled on 3.0 (quilt) as the superior solution. There is no
need to explore it any further (and as demonstrated by curl, gcc and
glibc, you can even turn 3.0 (quilt) ad absurdum). So in my view, the
only reasonable use of 1.0-with-diff is where you manage your diff
externally rather than during package build.

>   4a. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
> 
>   This is because there is currently no other source format which is
>   such that avoid both (i) uploading the whole source, including
>   upstream, for every upload; and (ii) having to maintain
>   debian/patches/ inside the package tree.
> 
>   4c. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
>   However, we recommend discontinuing use of 1.0-with-diff in other
>   circumstances, to simplify the contents of the archive.
> 
>   This is because ... [second paragraph as in 4a].

For the reasons above, I do think we need another variant of 4. Both of
these leave room for using 1.0-with-diff in combination with a patch
system. Beyond that, we're still giving advice and our advice is a
non-binding recommendation. So going a bit less vague seems warranted to
me. Sean cautioned that we should not deny future developments. I don't
think any future developments should use 1.0-with-diff, so trimming the
possible use cases for 1.0-with-diff to a minimum that explicitly
excludes use with a build-time patch system is what I think we do.

Some people have been asking me why I think consistency is important. I
think the most useful explanation is practical experience here. I
routinely do archive-wide work and I've basically reached a point where
I do no longer send patches for 1.0 source packages, because it simply
takes too much time to figure out their workflows unless fixing that
particular issue is relatively important to me. So yes, 1.0 does present
a practical barrier to contribution.

Helmut

Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language

[Nick Hastings]

Hi Adam,

wow, this is unfortunate - gmail flagged this as spam and I only just saw
it now. So please don't interpret my late reply as being from a lack of
motivation.

* Adam Borowski  [220603 23:34]:
> On Fri, Jun 03, 2022 at 09:38:37AM +0900, Nick Hastings wrote:
> >  * Package name: zig
> >  * URL : https://github.com/ziglang/zig
> >  * License : Expat, Apache-2, Apache-2 with LLVM exception,
> >  CC0, BSD-2-Clause, and LGPL-2+
> >  * Vcs : https://github.com/NickHastings/zig-debian
> 
> > zig - Imperative, general-purpose, statically typed, system programming 
> > language
> 
> Hi!
> Worst news first: the copyright file requires a lot more work.  I see for
> example unlisted Khronos stuff (lib/libc/include/any-windows-any/{GL,KHR}/),
> NTP (lib/libc/include/any-linux-any/linux/timex.h), Zope (mingw), ISC,
> Apache, APSL, ...  And the list of copyright holders is even more
> incomplete.  This is a big honking waste of time but it's
> required... :(

I actually already put quite a bit of effort into the copyright file,
but it has been a very long time since I last worked on it.

Taking a quick look now I wonder if maybe I have overlooked include
directories, perhaps assuming that anything in there would be covered by
src directories. Or maybe I'd just become burned out with it and wanted
to move on!

Anyway I think I'm ready to dive back in.

> The package includes a bunch of tests, and with the likelihood of code not
> handling a particular arch, glibc, etc, I'd say it's a must to run
> them.

Ok, I'll investigate running the tests.

> Not a strict requirement, but a man page would be greatly appreciated.

Will put it on the todo list, but hopefully I can get upstream to do
something on that front.

Thanks for taking interest in this package.

Cheers,

Nick.

Bug#1012835: linux-image-5.10.0-15-amd64: entropy dropped to 256 from ~4k after 5.10.120-1 update

[Vincas Dargis]

Package: src:linux
Version: 5.10.120-1
Severity: normal

Dear Maintainer,

I've noticed in Munin graphs that entropy dropped significantly after
reboot to 5.10.120-1. Please see images attached.

Not sure if this is actually a problem/bug, but that kind of drop "out
of nowhere" seems at least suspicious.

I see same level of entropy on multiple 5.10 machines, though on one
computers I use backported 5.16.12-1~bpo11+1 (due to issues with
i7-11700 graphics) and it's entropy looks rich:

```
$ cat /proc/sys/kernel/random/entropy_avail
3735
```


-- Package-specific info:
** Version:
Linux version 5.10.0-15-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.120-1 (2022-06-09)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-15-amd64 root=/dev/mapper/vg_main-lv_system ro 
quiet security=apparmor elevator=deadline security=apparmor elevator=deadline 
security=apparmor ipv6.disable=1 fsck.repair=yes elevator=deadline

** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

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

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: To be filled by O.E.M.
product_version: To be filled by O.E.M.
chassis_vendor: Gigabyte Technology Co., Ltd.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends Inc.
bios_version: U1f
board_vendor: Gigabyte Technology Co., Ltd.
board_name: Z68X-UD3P-B3
board_version: To be filled by O.E.M.

** Loaded modules:
binfmt_misc
nf_conntrack_netlink
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
tcp_diag
udp_diag
inet_diag
vboxnetadp(OE)
vboxnetflt(OE)
vboxdrv(OE)
xfs
intel_rapl_msr
intel_rapl_common
x86_pkg_temp_thermal
intel_powerclamp
coretemp
kvm_intel
kvm
irqbypass
ghash_clmulni_intel
snd_hda_codec_hdmi
aesni_intel
libaes
crypto_simd
cryptd
glue_helper
snd_hda_intel
snd_intel_dspcfg
soundwire_intel
soundwire_generic_allocation
snd_soc_core
rapl
intel_cstate
nouveau
snd_compress
mei_hdcp
soundwire_cadence
evdev
snd_hda_codec
intel_uncore
snd_hda_core
pl2303
ftdi_sio
ttm
drm_kms_helper
snd_hwdep
usbserial
iTCO_wdt
cec
mxm_wmi
soundwire_bus
pcspkr
intel_pmc_bxt
snd_pcm
at24
i2c_algo_bit
snd_timer
iTCO_vendor_support
mei_me
snd
watchdog
mei
soundcore
sg
button
nf_tables
nfnetlink
it87
drm
hwmon_vid
fuse
configfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
raid10
raid1
raid0
multipath
linear
dm_mod
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
md_mod
sd_mod
t10_pi
crc_t10dif
crct10dif_generic
ahci
libahci
libata
crct10dif_pclmul
crct10dif_common
scsi_mod
crc32_pclmul
crc32c_intel
xhci_pci
i2c_i801
i2c_smbus
xhci_hcd
lpc_ich
ehci_pci
ehci_hcd
e1000e
usbcore
ptp
pps_core
usb_common
fan
video
wmi

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor 
Family DRAM Controller [8086:0100] (rev 09)
Subsystem: Gigabyte Technology Co., Ltd 2nd Generation Core Processor 
Family DRAM Controller [1458:5000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snb_uncore

00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200/2nd Generation Core 
Processor Family PCI Express Root Port [8086:0101] (rev 09) (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:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series 
Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)
Subsystem: Gigabyte Technology Co., Ltd 6 Series/C200 Series Chipset 
Family MEI Controller [1458:1c3a]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset 
Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 05) (prog-if 20 [EHCI])
Subsystem: Gigabyte Technology Co., Ltd 6 Series/C200 Series Chipset 
Family USB Enhanced Host Controller [1458:5006]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series C

Bug#1012820: calibre fails on converting to PDF

[yokota]

Hello,

> 2. If I run as a non-root user I get:
>
> Authorization required, but no authorization protocol specified
> qt.qpa.xcb: could not connect to display :0.0
> qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though 
> it
> was found.
> This application failed to start because no Qt platform plugin could be
> initialized. Reinstalling the application may fix this problem.
>
> Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, 
> offscreen,
> vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, 
> xcb.

> qt.qpa.xcb: could not connect to display :0.0
This line shows that you are not connected to X11.

PDF render uses Qt library, and Qt requires some GUI environment like X11.
Check X11 environment and works other X11 client programs on your machine.

You must setup X11 and connect X server properly even if you don't
want to use GUI.
Install X11 environment and related Qt libraries, and run from GUI environment.

--
YOKOTA

Bug#1012834: ITP: elpa-geiser-chicken -- Chicken's implementation of the geiser protocols

[Diane Trout]

Package: wnpp
Owner: Diane Trout 
Severity: wishlist

* Package name: elpa-geiser-chicken
  Version : 0.17-1
  Upstream Author : Jose Antonio Ortega Ruiz 
* URL or Web page : https://geiser.nongnu.org/
* License : BSD-3-Clause
  Description : Chicken's implementation of the geiser protocols
 Geiser is a generic Emacs/Scheme interaction mode, featuring an
 enhanced REPL and a set of minor modes improving Emacs’ basic scheme
 major mode. This package add support for Chicken in Geiser.


This a language specific module for elpa-geiser and will be maintained
in the debian-emacsen team.

Diane

Bug#1012833: software-properties-common: links to VCS on tracker.debian.org broken

[Ross Boylan]

Package: software-properties-common
Version: 0.96.20.2-2.1
Severity: normal
X-Debbugs-Cc: rossboy...@stanfordalumni.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

**Problem**
https://tracker.debian.org/pkg/software-properties has links to VCS on the
upper left box.  They resolve to https://anonscm.debian.org/git/collab-
maint/software-properties.git, which appears unavailable.  When used remotely
the result is

$ git clone https://anonscm.debian.org/git/collab-maint/software-properties.git
Cloning into 'software-properties'...
fatal: repository 'https://anonscm.debian.org/git/collab-maint/software-
properties.git/' not found

and clicking on the browse link gives a 404 not found error.

**Expected Result**
Using the links would produce a successful clone or web-based browse of the
repository.

**Alternatives**
In the middle on the right of the same page, under "links" is a link labelled
"browse source code".  It points to https://sources.debian.org/src/software-
properties/unstable/, which does have the source code, though it is a snapshot.

I assume apt-get source would also yield the current source code.

**Motivation**
I want to play around with a fix for https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=1012649 and figured it would be good to have the source
in git.  The alternatives do provide the source, and since most of the releases
are on the same version that will probably be OK.


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

Kernel: Linux 5.10.0-15-amd64 (SMP w/8 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 software-properties-common depends on:
ii  ca-certificates  20210119
ii  gir1.2-glib-2.0  1.66.1-1+b1
ii  gir1.2-packagekitglib-1.01.2.2-2
ii  python-apt-common2.2.1
ii  python3  3.9.2-3
ii  python3-dbus 1.2.16-5
ii  python3-gi   3.38.0-2
ii  python3-software-properties  0.96.20.2-2.1

Versions of packages software-properties-common recommends:
ii  packagekit  1.2.2-2

software-properties-common suggests no packages.


-BEGIN PGP SIGNATURE-

iQFSBAEBCgA8FiEEreS674/HIyV9gBfdnAYPmOsbK2AFAmKpWB4eHHJvc3Nib3ls
YW5Ac3RhbmZvcmRhbHVtbmkub3JnAAoJEJwGD5jrGytgUhEH/3CdOt/4SS+Q/0b8
0jc1ylF8wyMXVn/LYuSo8sUik4Rc2MDoGWF+/WGuGzNqkGqC0ANhMgTrvokkekkn
4R6hrMDuPGArzCdkD4dTplWh+f6WfugOpOs0GVhjuoh8bsBcv9SKNXzNnhxMRZxD
CnQ9fqHr3lOEFSQZQ2ucWKGoeOiu4/lAKOkx51FZXqG6m+nX0TfOqpNQ8y/o35+s
SoEogL+SAy10NyNa79ufY7rzuBOtvF8NbBgzDRUQggejWaQWXnMgqz5VXLqfpqcY
WbFO4QnO03Nc/+cXnyTqjieYau6kSQNVM3KaDG5tfktp4g1PHbWLgJ+srd9oXJOE
5IV8SaM=
=ES1Z
-END PGP SIGNATURE-

Bug#1012832: RFP: chezmoi -- Manage dotfiles across multiple diverse machines

[Franklin Yu]

Package: wnpp
Version: N/A
Severity: wishlist

* Package name: chezmoi
  Version:  2.17.1
  Upstream Author:  Tom Payne 
* URL:  https://www.chezmoi.io/
* License:  MIT
  Programming Lang: Golang
  Description:  Manage dotfiles across multiple diverse machines.
  Repository:   https://github.com/twpayne/chezmoi

See https://repology.org/project/chezmoi for packages in other distributions.

Bug#1012831: ITP: python-pypartpicker -- Fetch product and part list information from PCPartPicker

[Ben Westover]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Ben Westover 
X-Debbugs-Cc: kwestover...@gmail.com
Severity: wishlist

* Package name: python-pypartpicker
  Version : 1.9.0
  Upstream Author : QuaKe8782 
* URL : https://github.com/thefakequake/pypartpicker
* License : Expat
  Programming Lang: Python
  Description : Fetch products and part lists from PCPartPicker

PyPartPicker is a package that allows you to obtain information from 
PCPartPicker quickly and easily, with data being returned via objects 
with numerous attributes.

Features:
* Obtain Part objects, estimated wattage, and total cost from 
PCPartPicker lists.
* Obtain name, product URL, price, product type, image, and more from 
Part objects.
* Obtain everything previously mentioned + specs, reviews, and in depth 
pricing information from PCPartPicker product links.

* Async ready: all scraping methods have an asynchronous version

I plan to maintain this inside the Python team.

--
Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012830: libwebservice-validator-css-w3c-perl: The only example script it comes with fails

[Debian Live user]

Package: libwebservice-validator-css-w3c-perl
Version: 0.3-1.1
Severity: important
X-Debbugs-Cc: user9d...@gmail.com

Dear Maintainer,

   * What led up to the situation?
I wanted a super easy CLI CSS validator to check my CSS file's 
uuuhhh...correctness
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
(ineffective:) I tried editing the actual PM file but I realized I just 
couldn't figure out the problem.
(ineffective:) I thought the unstable package would be more successful until I 
realized it's the same thing as stable.
   * What was the outcome of this action?
no output, nothing, no errors either
   * What outcome did you expect instead?
CSS error/syntax-error feedback


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

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

Versions of packages libwebservice-validator-css-w3c-perl depends on:
ii  libclass-accessor-perl  0.51-1
ii  libsoap-lite-perl   1.27-1
ii  liburi-perl 5.08-1
ii  libwww-perl 6.52-1
ii  perl5.32.1-4+deb11u2

libwebservice-validator-css-w3c-perl recommends no packages.

libwebservice-validator-css-w3c-perl suggests no packages.

-- no debconf information

Bug#1012829: linux-image-5.17.0-3-amd64: intel_iommu=igfx_off workaround required for graphics card

[Troy Telford]

Package: src:linux
Version: 5.17.11-1
Severity: normal
Tags: upstream

Dear Maintainer,

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

   * What led up to the situation?

After scouring my logs I've found this started after my first 
boot
of kernel 5.17.6-1 (2022-05-14). I started having issues with 
audio
out via HDMI - especially if the device had its input changed or
was turned off.

Kernel 5.17.0-1-amd64 (Debian 5.17.3-1 (2022-04-18) does not 
have
this issue, which should help reduce the Δ somewhat.

The problem remains with linux-image-5.17.0-3-amd64. I am 
currently
unable (unwilling?) to test linux-image-5.18.0, as my root
filesytem uses ZFS, and there are currently no DKMS packages 
that
build on linux-image-5.18. (I don't have an abundance of time to
try to both get an upstream zfs set of packages built as well as
figure out how to get a rootfs booting using that kernel 
module.)

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

By plugging my error into Google, I was lead to

https://www.mail-archive.com/kernel-packages@lists.launchpad.net/msg478114.html,
which wasn't _quite_ what I was looking for, but it mentioned 
the
intel_iommu driver, and as the device id in my error message 
used
an Intel driver (snd_hda_intel), it seemed a reasonable place to
start looking.

That lead me to
https://www.kernel.org/doc/Documentation/Intel-IOMMU.txt, which
explicitly said:

"If you encounter issues with graphics devices, you can try 
adding
option intel_iommu=igfx_off to turn off the integrated graphics
engine.  If this fixes anything, please ensure you file a bug
reporting the problem."

As the motherboard has an Intel integrated graphics engine, and 
the
rest of the document seemed to describe the error message I was
seeing, it seemed reasonable to try the option 
intel_iommu=igfx_off

   * What was the outcome of this action?

The problems vanished, and the error messages stopped appearing 
in
my kernel log.

I initially thought to add this to the kernel.org bugzilla, but
they had a useful message saying "Please use your distribution's
bug tracking tools" which is reasonable, as I am using a Debian
kernel.

I'm not sure the appropriate way to report the issue upstream 
(if
it is even is an issue upstream). Unfortuantely, I can't test 
the
latest 5.18 kernel yet, as my root filesystem uses ZFS, and 
there
are no working DKMS packages for it yet.

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

-- Package-specific info:
** Version:
Linux version 5.17.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.3.0-3) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38) #1 SMP PREEMPT Debian 
5.17.11-1 (2022-05-26)

** Command line:
BOOT_IMAGE=/ROOT/debian@/boot/vmlinuz-5.17.0-3-amd64 root=ZFS=rpool/ROOT/debian 
ro apparmor=1 security=apparmor nvidia-drm.modeset=1 delayacct 
intel_iommu=igfx_off

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
Jun 14 11:32:14 pilot kernel: [162022.120060] dmar_fault: 82685 callbacks 
suppressed
Jun 14 11:32:14 pilot kernel: [162022.120071] DMAR: [DMA Read NO_PASID] Request 
device [01:00.1] fault addr 0x6ca224000 [fault reason 0x06] PTE Read access is 
not set
Jun 14 11:32:14 pilot kernel: [162022.120250] DMAR: [DMA Read NO_PASID] Request 
device [01:00.1] fault addr 0x6ca224000 [fault reason 0x06] PTE Read access is 
not set
Jun 14 11:32:14 pilot kernel: [162022.120438] DMAR: [DMA Read NO_PASID] Request 
device [01:00.1] fault addr 0x6ca224000 [fault reason 0x06] PTE Read access is 
not set
Jun 14 11:32:19 pilot kernel: [162027.124475] DMAR: [DMA Read NO_PASID] Request 
device [01:00.1] fault addr 0x558cf6000 [fault reason 0x06] PTE Read access is 
not set
Jun 14 11:34:03 pilot kernel: [162130.851574] dmar_fault: 114335 callbacks 
suppressed
Jun 14 11:34:03 pilot kernel: [162130.851579] DMAR: DRHD: handling fault status 
reg 2
Jun 14 11:34:03 pilot kernel: [162130.851586] DMAR: [DMA Read NO_PASID] Request 
device [01:00.1] fault addr 0x50bb59000 [fault reason 0x06] PTE Read access is 
not set
Jun 14 11:34:03 pilot kernel: [162130.851674] DMAR: DRHD: handling fault status 
reg 3
Jun 14 11:34:03 pilot kernel: [162130.851677] DMAR: [DMA Read NO_PASID] Request 
device [00:1b.0] fault addr 0x36174600

Bug#1012828: Please enable busybox sha3sum (SHA3/SHA-3/Keccak)

[Trent W. Buck]

Package: busybox
Version: 1:1.30.1-6+b3
Severity: wishlist
File: /usr/bin/busybox

Is there any reason NOT to enable busybox sha3sums?
(I don't care busybox-udeb or busybox-static.)


https://sources.debian.org/src/busybox/1%3A1.35.0-1/debian/config/pkg/deb/#L280

-# CONFIG_SHA3SUM is not set
+CONFIG_SHA3SUM=y


Per this handy reference table, everyone should be on SHA-3 by now:

https://valerieaurora.org/hash.html


I'd like to switch from b2sum to sha3sum, but

1) Debian only ships coreutils 8.32, and even
   latest coreutils (9.1) lacks "cksum -a sha3"; and

2) Debian's busybox is built without "busybox sha3sum".

3) Debian's python3 understands SHA-3 (hashlib.sha3_512), but
   lacks a turnkey equivalent of
   "sha3sum --check SHA3SUMS" and
   "sha3sum --tag -- *.changes >SHA3SUMS".





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

Kernel: Linux 5.16.0-0.bpo.4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 busybox depends on:
ii  libc6  2.31-13+deb11u3

busybox recommends no packages.

busybox suggests no packages.

-- no debconf information

Bug#1012789: Can you check if Img works at all?

[Vector Hasting]

Package: linuxcnc-uspace

Thank you Jeff for suggesting this is an OpenGL issue.

Indeed, I went looking and I cannot run glxgears on my system, so I think
it would be fair to say that OpenGL is a dependency beyond the 'package
dependencies,' and that without it I can't run the plain vanilla, prettier
interface of LinuxCNC.

It was particularly helpful for you to mention tklinuxcnc, because I had no
idea it was there.

I followed the instructions at
http://linuxcnc.org/docs/2.7/html/gui/tklinuxcnc.html

(one finds the ini files, as of this writing, located at
~/linuxcnc/configs/sim.axis, and modifies/copies one to have a line DISPLAY
= tklinuxcnc  )

Therefore, by using the tklinuxcnc interface, my problem is solve: I have a
working copy of LinuxCNC!

This is as Jeff said an unusual attempt to get a Single Board Computer to
run LinuxCNC, but it may become a more common problem for folks
onceLinuxCNC becomes available in Debian Bookworm.

Therefore, a more fulsome message would probably reduce support work
downstream, but I'm not sure how to implement that myself. I'm happy to be
pointed in the right direction, either on this board or off.

Thanks again for everyone's help.

Bug#1012827: libwine-dev: libwine.so is a dangling symlink

[Adrian Bunk]

Package: libwine-dev
Version: 7.0~repack-1
Severity: serious
Control: affects -1 src:lmms

lrwxrwxrwx 1 root root 12 Jun  5 21:54 
/usr/lib/x86_64-linux-gnu/wine/libwine.so -> libwine.so.1

libwine-dev: /usr/lib/x86_64-linux-gnu/wine/libwine.so
libwine:amd64: /usr/lib/x86_64-linux-gnu/wine/x86_64-unix/libwine.so.1
libwine:amd64: /usr/lib/x86_64-linux-gnu/wine/x86_64-unix/libwine.so.1.0


lrwxrwxrwx 1 root root 12 Jun  5 21:54 /usr/lib/i386-linux-gnu/wine/libwine.so 
-> libwine.so.1

libwine-dev: /usr/lib/i386-linux-gnu/wine/libwine.so
libwine:i386: /usr/lib/i386-linux-gnu/wine/i386-unix/libwine.so.1
libwine:i386: /usr/lib/i386-linux-gnu/wine/i386-unix/libwine.so.1.0

Bug#1012826: broadcom-sta-dkms: Installation fails after upgrade to kernel 5.18-01-amd64

[manel]

Package: broadcom-sta-dkms
Version: 6.30.223.271-19
Followup-For: Bug #1012826
X-Debbugs-Cc: manel@mbp13.xarxa

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

Patch solve issue:


---


diff -u -r a/src/shared/linux_osl.c b/src/shared/linux_osl.c
--- a/src/shared/linux_osl.c    2022-05-24 20:51:15.662604980 +
+++ b/src/shared/linux_osl.c    2022-05-24 21:13:38.264472425 +
@@ -599,6 +599,8 @@
    va = kmalloc(size, GFP_ATOMIC | __GFP_ZERO);
    if (va)
    *pap = (ulong)__virt_to_phys(va);
+#elif LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0)
+   va = dma_alloc_coherent(&((struct pci_dev *)osh->pdev)->dev,
size,
(dma_addr_t*)pap, GFP_ATOMIC);
 #else
    va = pci_alloc_consistent(osh->pdev, size, (dma_addr_t*)pap);
 #endif
@@ -612,6 +614,8 @@

 #ifdef __ARM_ARCH_7A__
    kfree(va);
+#elif LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0)
+   dma_free_coherent(&((struct pci_dev *)osh->pdev)->dev, size,
va,
(dma_addr_t)pa);
 #else
    pci_free_consistent(osh->pdev, size, va, (dma_addr_t)pa);
 #endif
@@ -623,7 +627,11 @@
    int dir;

    ASSERT((osh && (osh->magic == OS_HANDLE_MAGIC)));
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0)
+   dir = (direction == DMA_TX)? DMA_TO_DEVICE: DMA_FROM_DEVICE;
+#else
    dir = (direction == DMA_TX)? PCI_DMA_TODEVICE:
PCI_DMA_FROMDEVICE;
+#endif

 #if defined(__ARM_ARCH_7A__) && defined(BCMDMASGLISTOSL)
    if (dmah != NULL) {
@@ -641,7 +649,11 @@
    ASSERT(totsegs + nsegs <=
MAX_DMA_SEGS);
    sg->page_link = 0;
    sg_set_buf(sg, PKTDATA(osh, skb),
PKTLEN(osh,
skb));
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0)
+   dma_map_single(&((struct pci_dev
*)osh->pdev)->dev, PKTDATA(osh, skb), PKTLEN(osh, skb), dir);
+#else
    pci_map_single(osh->pdev, PKTDATA(osh,
skb),
PKTLEN(osh, skb), dir);
+#endif
    }
    totsegs += nsegs;
    totlen += PKTLEN(osh, skb);
@@ -656,7 +668,11 @@
    }
 #endif

+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0)
+   return (dma_map_single(&((struct pci_dev *)osh->pdev)->dev, va,
size,
dir));
+#else
    return (pci_map_single(osh->pdev, va, size, dir));
+#endif
 }

 void BCMFASTPATH
@@ -665,8 +681,13 @@
    int dir;

    ASSERT((osh && (osh->magic == OS_HANDLE_MAGIC)));
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0)
+   dir = (direction == DMA_TX)? DMA_TO_DEVICE: DMA_FROM_DEVICE;
+   dma_unmap_single(&((struct pci_dev *)osh->pdev)->dev,
(uint32)pa, size,
dir);
+#else
    dir = (direction == DMA_TX)? PCI_DMA_TODEVICE:
PCI_DMA_FROMDEVICE;
    pci_unmap_single(osh->pdev, (uint32)pa, size, dir);
+#endif
 }

 #if defined(BCMDBG_ASSERT)







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

Kernel: Linux 5.18.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN,
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.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 broadcom-sta-dkms depends on:
ii  dkms  3.0.3-2

Versions of packages broadcom-sta-dkms recommends:
ii  wireless-tools  30~pre9-13.1

broadcom-sta-dkms suggests no packages.

-- no debconf information

Bug#1005757: python-jsonschema: Please provide latest upstream release 4.4.0

[Thomas Goirand]

On 6/14/22 22:44, Samuel Henrique wrote:

Hello Thomas,


Since I added so many autopkgtest, what I can do is upload the latest
version to Experimental, and let the Debian CI run its tests against
what's currently in Unstable. Then the pseudo excuse page will show how
it goes.

Maybe you can also deal with the latest version of python-jsonschema in
Experimental for a short time too?


That would certainly be helpful, the diff on ansible-lint is slowly
growing so it would be good to at least have it in experimental.


Note I wrote to the OpenStack list and ask if we can upgrade jsonschema.
Please allow a few days until I get some replies.


Awesome, thank you!

--
Samuel Henrique 


Hi Samuel,

You probably saw I uploaded 4.6.0 to Experimental already. Let me know 
if it works well enough for you. I had to redesign a bit the package as 
upstream switched to Poetry (from setuptools).


As you can see from here:
https://release.debian.org/britney/pseudo-excuses-experimental.html#python-jsonschema

there are many regressions in OpenStack, as I expected. The most 
worrisome is the Nova one (Nova is the core of OpenStack, the one that 
spawns VMs...).


I'd very much prefer to have enough time to fix them before uploading 
jsonschema 4.6.0 to Unstable.


Cheers,

Thomas Goirand (zigo)

Bug#1012789: Can you check if Img works at all?

[Vector Hasting]

Package: linuxcnc-uspace

I started wish from the Terminal.
It brings up a % prompt and launches a small grey window
Typed linuxcnc  (inside the terminal, at the % prompt)
The initial configuration selection window opens, I chose the "axis_mm"
configuration and clicked OK.
It thinks for a while, and then sends the same error message ending in
"undefined symbol: _TIFFsetString, version LIBTIFF_4.0"

Thanks again for your time.

Vector Hasting

Bug#1012789: Can you check if Img works at all?

[Vector Hasting]

I started wish from the Terminal.
It brings up a % prompt and launches a small grey window
Typed linuxcnc  (inside the terminal, at the % prompt)
The initial configuration selection window opens, I chose the "axis_mm"
configuration and clicked OK.
It thinks for a while, and then sends the same error message ending in
"undefined symbol: _TIFFsetString, version LIBTIFF_4.0"

Thanks again for your time.



Vector Hasting

Bug#1012826: broadcom-sta-dkms: Installation fails after upgrade to kernel 5.18-01-amd64

[manel]

Package: broadcom-sta-dkms
Version: 6.30.223.271-19
Severity: important
X-Debbugs-Cc: manel@mbp13.xarxa

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


After upgrade to kernel 5.18-01-amd fails installation or compiling
from source, now happens exactly the same under kernel 5.17-01-amd64
Before it worked perfectly.


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

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.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 broadcom-sta-dkms depends on:
ii  dkms  3.0.3-2

Versions of packages broadcom-sta-dkms recommends:
ii  wireless-tools  30~pre9-13.1

broadcom-sta-dkms suggests no packages.

-- no debconf information

Bug#1012789: [Emc-developers] Bug#1012789: linuxcnc-uspace: Linux CNC will not start

[Vector Hasting]

Thank you for looking at this!

(My purpose reporting here is the understanding that we're trying to debug
to get sid into stable Bookworm with LinuxCNC, and I also want LinuxCNC
working on my little SBC.)

This is potentially helpful, but doesn't immediately clear things up for
me...

Here's what I did after getting this email:

I found the following libtiff packages on my SBC:
libtiff-dev  4.4.0-2
libtiff5 4.4.0-2
libtiffxx5  4.4.0-2

When I search the debian repository, it lists these as unstable (I presume
because we're on sid).
But it also lists them as the most recent releases, not the releases from
Buster (4.2.0-1).

Trying to follow the threads further, I went after the error message you
pointed out and saw it's trying to get:   libtifftcl4.1.0.so

I searched the debian repository and nothing by the name of libtiffcl4
exists:

"You have searched for packages that names contain libtifftcl in all
suites, all sections, and all architectures.
Sorry, your search gave no results"

Interestingly, the Sourceforge branches for tkImg does not have a *branch*
for 1.4 (which appears to be what the line above is looking for)
https://sourceforge.net/p/tkimg/code/HEAD/tree/branches/

But there *is* a version 1.4.13 under tags:
https://sourceforge.net/p/tkimg/code/HEAD/tree/tags/1.4.13/

I downloaded that 1.4.13 source and used MS Code to search the downloaded
source and found a piece of code compat/libtiff/libtiff/libtiff.map that
has the string " LIBTIFF_4.0" in it.

I found 8 files that have _TIFFsetString in it.

But I don't understand the compiling setup well enough to see how those
files get compiled to create an object named libtifftcl4.1.0.so  (??)

(there is no string in the source for libtifftcl4)

I'm happy to try and dig further, but I'm also at a stop point.

Vector Hasting



On Tue, 14 Jun 2022 at 07:31, andy pugh  wrote:

> On Tue, 14 Jun 2022 at 14:49, Vector Hasting 
> wrote:
>
> > _tkinter.TclError: couldn't load file
> "/usr/lib/tcltk/aarch64-linux-gnu/Img1.4.13/libtifftcl4.1.0.so":
> /usr/lib/tcltk/aarch64-linux-gnu/Img1.4.13/libtifftcl4.1.0.so: undefined
> symbol: _TIFFsetString, version LIBTIFF_4.0
>
> This looks to be a dependency (hard coded?) on the version of libtiff
> that shipped with Buster (4.1).
>
> But it also seems to be in a package that LinuxCNC depends on, but
> doesn't control?
> https://sourceforge.net/projects/tkimg/files/tkimg/1.4/tkimg%201.4.13/
> (From the file path being searched)
>
> For me, the trail dries up there. I guess this is due to a Tcl/Tk
> dependency?
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>

Bug#1011339: [Pkg-javascript-devel] Bug#1011339: [Pkg-openssl-devel] Bug#1011339: openssl: missing errors strings on mipsel

[Jérémy Lal]

Le mar. 14 juin 2022 à 23:05, Sebastian Andrzej Siewior <
sebast...@breakpoint.cc> a écrit :

> On 2022-06-08 20:07:48 [+0200], Jérémy Lal wrote:
> > Hi Sebastian,
> Hi,
>
> > Any hint or idea about this ? Even wild ideas that I could try,
> > before I have to remove the files from mips.
>
> I confirmed on eller that nodejs 16.15.0+dfsg-1 builds with openssl
> 3.0.3-7. I was about to give-it-back but then noticed that you uploaded
> a new version with the workaround I mentioned. You may drop the
> workaround in your future upload ;)
>

Yes, I saw that in the latest openssl upload.
Thank you.

Jérémy

Bug#1012824: leiningen: "lein test" requires unavailable hard-coded librepl-clojure version 0.6.0

[Louis-Philippe Véronneau]

Package: leiningen
Severity: important
Version: 2.9.1-5
Tags: patch

Dear maintainer,

With leiningen 2.9.1, "lein test" requires hard-coded librepl-clojure
version 0.6.0. Since I recently uploaded librepl-clojure 0.9.0-1 , all
packages invoking "lein test" currently fail with this error message:

-
lein test
Cannot access central (https://repo1.maven.org/maven2/) in offline mode
and the artifact nrepl:nrepl:jar:0.6.0 has not been downloaded from it
before.
Cannot access clojars (https://repo.clojars.org/) in offline mode and
the artifact nrepl:nrepl:jar:0.6.0 has not been downloaded from it before.
This could be due to a typo in :dependencies, file system permissions,
or network issues.
If you are behind a proxy, try setting the 'http_proxy' environment
variable.
-

I've proposed a patch here:
https://salsa.debian.org/clojure-team/leiningen-clojure/-/merge_requests/3

Cheers,

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄

Bug#1011339: [Pkg-javascript-devel] Bug#1011339: [Pkg-openssl-devel] Bug#1011339: openssl: missing errors strings on mipsel

[Sebastian Andrzej Siewior]

On 2022-06-08 20:07:48 [+0200], Jérémy Lal wrote:
> Hi Sebastian,
Hi,

> Any hint or idea about this ? Even wild ideas that I could try,
> before I have to remove the files from mips.

I confirmed on eller that nodejs 16.15.0+dfsg-1 builds with openssl
3.0.3-7. I was about to give-it-back but then noticed that you uploaded
a new version with the workaround I mentioned. You may drop the
workaround in your future upload ;)

> Jérémy

Sebastian

Bug#1012707: /etc/network/interfaces: only source configuration files using with '*.conf' / use 'source /etc/network/interfaces.d/*.conf' instead of 'source /etc/network/interfaces.d/*'

[Santiago Ruano Rincón]

El 12/06/22 a las 14:13, Patrick Schleizer escribió:
> Package: ifupdown
> Severity: normal
> 
> Dear maintainer,
> 
> in file /etc/network/interfaces ...
> 
> Could you please consider instead of setting the default:
> 
> source /etc/network/interfaces.d/*
> 
> change suggestion:
> 
> source /etc/network/interfaces.d/*.conf
> 
> Reason:
> 
> When
> 
> - text editor (such as kate) create backup files (such as
> /etc/network/interfaces.d/50_user~ with the tilde at the end)
> 
> - local packages by system administrator or Debian derivatives place
> configuration drop-in snippets in /etc/network/interfaces.d/ folder,
> 
> then on upgrades then redundant files might end up in that folder such
> as those with file extensions '.dpkg-old' or '.dpkg-dist'.
> 
> When ifupdown is restarted, an interface is likely to be duplicated
> leading to ifupdown failure, resulting in a broken network connection.
> 
> By parsing only configuration files such as with the `*.conf` file
> extension issues with parsing unexpected files created by editors
> (backup files) or dpkg are avoided.

Thanks for your report. I think it makes sens. But for the moment, I am
pushing it to a separate branch. If I am not wrong, the debian-installer
installs some files in /etc/network/interfaces.d/, so there must be some
coordination to avoid issues in future installs.

Debian Installer Team: it is OK from your side to make the change
described above?

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#992976: uscan: mode=git refs/heads/ instruction scans for tags instead, and fails

[Agathe Porte]

Hi uscan maintainers,

Any potential update?

From the tracked bugs this problem is blocking at least two packages 
from moving forward to close their own bugs.


Best regards,

Agathe.

Bug#1012823: dolphin: kde crashes when dragging folder to places panel

[Will]

Package: dolphin
Version: 4:20.12.2-1
Severity: important
X-Debbugs-Cc: wiiliamchung...@gmail.com

Dear Maintainer,

I'm not exactly sure which package has this issue, and where to find logs, any
help and direction would be appreciated.

Dragging and dropping a folder from the main viewport to the places side panel
causes kde force close, crash, and log the user out.

Steps to reproduce issue:

1. Turn tooltips on inside dolphin
- Settings > Configure Dolphin > General
- Behavior > Miscellaneous > Show tooltips [x]

2. Hover mouse over (any) folder until the tooltip shows up.
3. Drag folder to places panel with the tooltip open.
4. Observe system freeze, close, and log user out.
5. (optional) log into user, and run htop to see a program max out CPU to 100%
- It was initially korganizer, but I uninstalled it. Now it's kdeconnect.

Environment:
Freshly installed bullseye, without other repositories except for backports.


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

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

Versions of packages dolphin depends on:
ii  baloo-kf5 5.78.0-3
ii  kinit 5.78.0-2
ii  kio   5.78.0-5
ii  libc6 2.31-13+deb11u3
ii  libdolphinvcs54:20.12.2-1
ii  libkf5activities5 5.78.0-2
ii  libkf5baloo5  5.78.0-3
ii  libkf5baloowidgets5   4:20.12.0-1
ii  libkf5bookmarks5  5.78.0-2
ii  libkf5codecs5 5.78.0-2
ii  libkf5completion5 5.78.0-3
ii  libkf5configcore5 5.78.0-4
ii  libkf5configgui5  5.78.0-4
ii  libkf5configwidgets5  5.78.0-2
ii  libkf5coreaddons5 5.78.0-4
ii  libkf5crash5  5.78.0-3
ii  libkf5dbusaddons5 5.78.0-2
ii  libkf5filemetadata3   5.78.0-2
ii  libkf5i18n5   5.78.0-2
ii  libkf5iconthemes5 5.78.0-2
ii  libkf5itemviews5  5.78.0-2
ii  libkf5jobwidgets5 5.78.0-2
ii  libkf5kcmutils5   5.78.0-3
ii  libkf5kiocore55.78.0-5
ii  libkf5kiofilewidgets5 5.78.0-5
ii  libkf5kiogui5 5.78.0-5
ii  libkf5kiowidgets5 5.78.0-5
ii  libkf5newstuff5   5.78.0-4
ii  libkf5notifications5  5.78.0-2
ii  libkf5parts5  5.78.0-3
ii  libkf5service-bin 5.78.0-2
ii  libkf5service55.78.0-2
ii  libkf5solid5  5.78.0-2
ii  libkf5textwidgets55.78.0-2
ii  libkf5widgetsaddons5  5.78.0-2
ii  libkf5windowsystem5   5.78.0-2
ii  libkf5xmlgui5 5.78.0-2
ii  libkuserfeedbackcore1 1.0.0-3
ii  libkuserfeedbackwidgets1  1.0.0-3
ii  libpackagekitqt5-11.0.2-1
ii  libphonon4qt5-4   4:4.11.1-4
ii  libqt5core5a  5.15.2+dfsg-9
ii  libqt5dbus5   5.15.2+dfsg-9
ii  libqt5gui55.15.2+dfsg-9
ii  libqt5widgets55.15.2+dfsg-9
ii  libqt5xml55.15.2+dfsg-9
ii  libstdc++610.2.1-6
ii  phonon4qt54:4.11.1-4

Versions of packages dolphin recommends:
ii  kimageformat-plugins  5.78.0-5
ii  kio-extras4:20.12.2-1

Versions of packages dolphin suggests:
pn  dolphin-plugins  

Bug#1005757: python-jsonschema: Please provide latest upstream release 4.4.0

[Samuel Henrique]

Hello Thomas,

> Since I added so many autopkgtest, what I can do is upload the latest
> version to Experimental, and let the Debian CI run its tests against
> what's currently in Unstable. Then the pseudo excuse page will show how
> it goes.
>
> Maybe you can also deal with the latest version of python-jsonschema in
> Experimental for a short time too?

That would certainly be helpful, the diff on ansible-lint is slowly
growing so it would be good to at least have it in experimental.

> Note I wrote to the OpenStack list and ask if we can upgrade jsonschema.
> Please allow a few days until I get some replies.

Awesome, thank you!

--
Samuel Henrique 

Bug#1012822: clang-format-14: git-clang-format-14 still tries to use clang-format instead of clang-format-14

[Marc]

Package: clang-format-14
Version: 1:14.0.5-1
Severity: normal
X-Debbugs-Cc: dkm+deb...@kataplop.net

Dear Maintainer,

When calling:

$ git clang-format-14 HEAD

if you only have 'clang-format-14' installed, this fails with:

 error: cannot find executable "clang-format"

This is because the git-clang-format-14 keeps the default of calling 
'clang-format'.

Calling it using --binary clang-format-14 fixes the error.

Maybe changing the default for the clang-format-* versions would avoid issues. 
I had several versions installed in the past and always thought that calling 
'git clang-format-N' would use the correct version.

I can provide you with a patch if you want.

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

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

Versions of packages clang-format-14 depends on:
ii  libc6   2.33-7
ii  libclang-cpp14  1:14.0.5-1
ii  libgcc-s1   12.1.0-2
ii  libllvm14   1:14.0.5-1
ii  libstdc++6  12.1.0-2
ii  python3 3.10.4-1+b1

clang-format-14 recommends no packages.

clang-format-14 suggests no packages.

-- no debconf information

Bug#1012821: guzzle: CVE-2022-31042 CVE-2022-31043

[Salvatore Bonaccorso]

Source: guzzle
Version: 7.4.1-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for guzzle.

CVE-2022-31042[0]:
| Guzzle is an open source PHP HTTP client. In affected versions the
| `Cookie` headers on requests are sensitive information. On making a
| request using the `https` scheme to a server which responds with a
| redirect to a URI with the `http` scheme, or on making a request to a
| server which responds with a redirect to a a URI to a different host,
| we should not forward the `Cookie` header on. Prior to this fix, only
| cookies that were managed by our cookie middleware would be safely
| removed, and any `Cookie` header manually added to the initial request
| would not be stripped. We now always strip it, and allow the cookie
| middleware to re-add any cookies that it deems should be there.
| Affected Guzzle 7 users should upgrade to Guzzle 7.4.4 as soon as
| possible. Affected users using any earlier series of Guzzle should
| upgrade to Guzzle 6.5.7 or 7.4.4. Users unable to upgrade may consider
| an alternative approach to use your own redirect middleware, rather
| than ours. If you do not require or expect redirects to be followed,
| one should simply disable redirects all together.


CVE-2022-31043[1]:
| Guzzle is an open source PHP HTTP client. In affected versions
| `Authorization` headers on requests are sensitive information. On
| making a request using the `https` scheme to a server which responds
| with a redirect to a URI with the `http` scheme, we should not forward
| the `Authorization` header on. This is much the same as to how we
| don't forward on the header if the host changes. Prior to this fix,
| `https` to `http` downgrades did not result in the `Authorization`
| header being removed, only changes to the host. Affected Guzzle 7
| users should upgrade to Guzzle 7.4.4 as soon as possible. Affected
| users using any earlier series of Guzzle should upgrade to Guzzle
| 6.5.7 or 7.4.4. Users unable to upgrade may consider an alternative
| approach which would be to use their own redirect middleware.
| Alternately users may simply disable redirects all together if
| redirects are not expected or required.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-31042
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31042
https://github.com/guzzle/guzzle/security/advisories/GHSA-f2wf-25xc-69c9
[1] https://security-tracker.debian.org/tracker/CVE-2022-31043
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31043
https://github.com/guzzle/guzzle/security/advisories/GHSA-w248-ffj2-4v5q
[2] 
https://github.com/guzzle/guzzle/commit/e3ff079b22820c2029d4c2a87796b6a0b8716ad8

Regards,
Salvatore

Bug#1012354: Please add support for systemd-binfmt

[Michael Biebl]

Am 14.06.22 um 21:50 schrieb Sean Whitton:

Hello,

On Tue 14 Jun 2022 at 09:39PM +02, Michael Biebl wrote:


Hi Sean

Am 13.06.22 um 03:14 schrieb Sean Whitton:

Thanks for the patch.  I take it you got the sbcl.conf from the
binfmt-conf package?  So systemd-binfmt means that these config files
get stored in packages rather than all stored in binfmt-conf?


I'm confused. What's the "binfmt-conf" package?


Sorry, I meant binfmt-support.


Ok, then that's a no.

I looked at that kind of binfmt configuration the sbcl package ships 
(i.e. debian/binfmt) and created sbcl.conf from that information.



Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012354: Please add support for systemd-binfmt

[Sean Whitton]

Hello,

On Tue 14 Jun 2022 at 09:39PM +02, Michael Biebl wrote:

> Hi Sean
>
> Am 13.06.22 um 03:14 schrieb Sean Whitton:
>> Thanks for the patch.  I take it you got the sbcl.conf from the
>> binfmt-conf package?  So systemd-binfmt means that these config files
>> get stored in packages rather than all stored in binfmt-conf?
>
> I'm confused. What's the "binfmt-conf" package?

Sorry, I meant binfmt-support.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1012820: calibre fails on converting to PDF

[nbi]

I installed all the "pn" packages, but that had no impact.

On Tue, 14 Jun 2022 12:24:23 -0700 nbi  wrote:
> Package: calibre
> Version: 5.43.0+dfsg-1
> Severity: important
>
> This version of calibre fails to convert due to the "Failed to initialize
> plugin: .config/calibre/plugins/DeDRM.zip" error.
> See discussion at
> https://www.mobileread.com/forums/showthread.php?p=4230527#post4230527
>
> I have tried the author's (Kovid Goyal) recommendation of installing his
> official binaries and that does indeed remedy this error, but now 
calibre fails

> to run due to apparent issues with the Debian environment.
>
> As per the above discussion:
>
> 
---

> 1. If I run as root I get:
>
> Creating PDF Output...
> Converting input as a text based book...
> [3252131:3252131:0614/111726.662364:ERROR:zygote_host_impl_linux.cc(89)]
> Running as root without --no-sandbox is not supported. See
> https://crbug.com/638180.
>
> 2. If I run as a non-root user I get:
>
> Authorization required, but no authorization protocol specified
> qt.qpa.xcb: could not connect to display :0.0
> qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even 
though it

> was found.
> This application failed to start because no Qt platform plugin could be
> initialized. Reinstalling the application may fix this problem.
>
> Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, 
offscreen,
> vnc, wayland-egl, wayland, wayland-xcomposite-egl, 
wayland-xcomposite-glx, xcb.
> 
---

>
> I have researched all the discussion threads regarding necessary qt 
and python

> libraries and have verified that they are installed.
> So that leaves me at an impasse as neither the official Debian 
package nor the

> author's binaries will satisfactorily run on Bookworm.
>
>
> -- System Information:
> Debian Release: bookworm/sid
> APT prefers testing
> APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.15.5 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, 
TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE not set

> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages calibre depends on:
> pn calibre-bin 
> ii dpkg 1.21.8
> ii fonts-liberation2 2.1.5-1

Bug#1012354: Please add support for systemd-binfmt

[Michael Biebl]

Hi Sean

Am 13.06.22 um 03:14 schrieb Sean Whitton:

Thanks for the patch.  I take it you got the sbcl.conf from the
binfmt-conf package?  So systemd-binfmt means that these config files
get stored in packages rather than all stored in binfmt-conf?


I'm confused. What's the "binfmt-conf" package?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012819: gnome-software: When installing freecad via gnome-software, the freecad-common package is installed instead of freecad

[Jeremy Bicha]

Control: reassign -1 src:freecad 0.19.4+dfsg1-1
Control: severity -1 important

On Tue, Jun 14, 2022 at 3:21 PM Eugen Wintersberger
 wrote:
>   when I install freecad via gnome-software the freecad-common package instead
> of the freecad package is installed. Therefore, a user cannot run freecad when
> installed with gnome-software.

This is not a bug in gnome-software but a bug in the freecad
packaging. The freecad package needs to install the .desktop and the
AppStream metadata file, not freecad-common. The maintainer will need
to use Breaks/Replaces in debian/control to move files from one
package to another.

https://wiki.debian.org/AppStream/Guidelines#General
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-in-other-packages

Thanks,
Jeremy Bicha

Bug#1012820: calibre fails on converting to PDF

[nbi]

Package: calibre
Version: 5.43.0+dfsg-1
Severity: important

This version of calibre fails to convert due to the "Failed to initialize
plugin: .config/calibre/plugins/DeDRM.zip" error.
See discussion at
https://www.mobileread.com/forums/showthread.php?p=4230527#post4230527

I have tried the author's (Kovid Goyal) recommendation of installing his
official binaries and that does indeed remedy this error, but now calibre fails
to run due to apparent issues with the Debian environment.

As per the above discussion:

---
1. If I run as root I get:

Creating PDF Output...
Converting input as a text based book...
[3252131:3252131:0614/111726.662364:ERROR:zygote_host_impl_linux.cc(89)]
Running as root without --no-sandbox is not supported. See
https://crbug.com/638180.

2. If I run as a non-root user I get:

Authorization required, but no authorization protocol specified
qt.qpa.xcb: could not connect to display :0.0
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it
was found.
This application failed to start because no Qt platform plugin could be
initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen,
vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.
---

I have researched all the discussion threads regarding necessary qt and python
libraries and have verified that they are installed.
So that leaves me at an impasse as neither the official Debian package nor the
author's binaries will satisfactorily run on Bookworm.


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

Kernel: Linux 5.15.5 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages calibre depends on:
pn  calibre-bin
ii  dpkg   1.21.8
ii  fonts-liberation2  2.1.5-1
ii  libjpeg-turbo-progs1:2.1.2-1
ii  libjxr-tools   1.2~git20170615.f752187-5
pn  optipng
ii  poppler-utils  22.02.0-3
ii  python33.10.4-1+b1
pn  python3-apsw   
ii  python3-bs44.11.1-1
ii  python3-chardet4.0.0-2
pn  python3-chm
pn  python3-css-parser 
pn  python3-cssselect  
pn  python3-dateutil   
pn  python3-feedparser 
pn  python3-html2text  
pn  python3-html5-parser   
ii  python3-html5lib   1.1-3
pn  python3-jeepney
ii  python3-lxml   4.8.0-1
ii  python3-markdown   3.3.7-1
pn  python3-mechanize  
ii  python3-msgpack1.0.3-1
pn  python3-netifaces  
ii  python3-pil9.1.1-1
ii  python3-pkg-resources  59.6.0-1.2
pn  python3-py7zr  
ii  python3-pygments   2.11.2+dfsg-2
ii  python3-pyparsing  3.0.7-2
ii  python3-pyqt5  5.15.6+dfsg-1+b2
pn  python3-pyqt5.qtsvg
pn  python3-pyqt5.qtwebengine  
ii  python3-pyqt5.sip  12.10.1-1
pn  python3-regex  
pn  python3-routes 
pn  python3-speechd
pn  python3-zeroconf   
ii  python3.10 3.10.5-1
ii  xdg-utils  1.1.3-4.1

Versions of packages calibre recommends:
ii  python3-dnspython  2.2.1-2
pn  python3-ipython
ii  udisks22.9.4-1

Versions of packages calibre suggests:
ii  python3-openssl   21.0.0-1
pn  python3-unrardll  

Bug#1012819: gnome-software: When installing freecad via gnome-software, the freecad-common package is installed instead of freecad

[Eugen Wintersberger]

Package: gnome-software
Version: 3.38.1-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: eugen.wintersber...@gmail.com

Dear Maintainer,
  when I install freecad via gnome-software the freecad-common package instead
of the freecad package is installed. Therefore, a user cannot run freecad when
installed with gnome-software.

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

Kernel: Linux 5.16.0-0.bpo.4-amd64 (SMP w/8 CPU threads; PREEMPT)
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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-software depends on:
ii  appstream0.14.4-1
ii  apt-config-icons 0.14.4-1
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gnome-software-common3.38.1-1
ii  gsettings-desktop-schemas3.38.0-2
ii  libappstream-glib8   0.7.18-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u3
ii  libcairo21.16.0-5
ii  libfwupd21.5.7-4
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgspell-1-21.8.4-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libgtk3-perl 0.038-1
ii  libgudev-1.0-0   234-1
ii  libjson-glib-1.0-0   1.6.2-1
ii  libmalcontent-0-00.10.0-2
ii  libpackagekit-glib2-18   1.2.2-2
ii  libpolkit-gobject-1-00.105-31+deb11u1
ii  libsoup2.4-1 2.72.0-2
ii  libxmlb1 0.1.15-2
ii  packagekit   1.2.2-2
ii  software-properties-gtk  0.96.20.2-2.1

Versions of packages gnome-software recommends:
ii  fwupd  1.5.7-4

Versions of packages gnome-software suggests:
pn  apt-config-icons-hidpi 
ii  gnome-software-plugin-flatpak  3.38.1-1
pn  gnome-software-plugin-snap 

Bug#1012818: inkscape: Please update for Poppler 22.06

[Nathan Pratta Teodosio]

Package: inkscape
Severity: normal
Tags: patch
X-Debbugs-Cc: nathan.teodo...@canonical.com

Dear Maintainer,

Since Poppler 22.06 is making its way into experimental (currently in NEW[1]),
Inkscape will need the corresponding compatibility changes from upstream to
build. I cherry-picked them in the attached patch and with Sbuilder made sure
it builds against the new Poppler.

[1]: https://ftp-master.debian.org/new.html


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

Kernel: Linux 5.15.0-33-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.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 inkscape depends on:
ii  lib2geom1.1.0  1.1-3
ii  libatkmm-1.6-1v5   2.28.2-1build1
ii  libboost-filesystem1.74.0  1.74.0-14ubuntu4
ii  libc6  2.35-0ubuntu3
ii  libcairo2  1.16.0-5ubuntu2
ii  libcairomm-1.0-1v5 1.12.2-4build3
ii  libcdr-0.1-1   0.1.6-2build3
ii  libdbus-glib-1-2   0.112-2build1
ii  libfontconfig1 2.13.1-4.4ubuntu1
ii  libfreetype6   2.12.1+dfsg-2
ii  libgc1 1:8.0.6-1.1build1
ii  libgcc-s1  12.1.0-2ubuntu1
ii  libgdk-pixbuf-2.0-02.42.8+dfsg-1
ii  libglib2.0-0   2.72.1-1
ii  libglibmm-2.4-1v5  2.66.2-2
ii  libgomp1   12.1.0-2ubuntu1
ii  libgsl27   2.7.1+dfsg-3
ii  libgspell-1-2  1.10.0-1
ii  libgtk-3-0 3.24.33-2ubuntu1
ii  libgtkmm-3.0-1v5   3.24.5-1build1
ii  libharfbuzz0b  2.7.4-1ubuntu4
ii  libjpeg8   8c-2ubuntu10
ii  liblcms2-2 2.12~rc1-2build2
ii  libmagick++-6.q16-88:6.9.11.60+dfsg-1.3build2
ii  libpango-1.0-0 1.50.7+ds-1
ii  libpangocairo-1.0-01.50.7+ds-1
ii  libpangoft2-1.0-0  1.50.7+ds-1
ii  libpangomm-1.4-1v5 2.46.2-1
ii  libpng16-161.6.37-5
ii  libpoppler-glib8   22.06.0-1
pn  libpoppler118  
ii  libpotrace01.16-2
ii  libreadline8   8.1.2-1.2
ii  librevenge-0.0-0   0.0.4-6ubuntu7
ii  librsvg2-common2.52.5+dfsg-3
ii  libsigc++-2.0-0v5  2.10.4-2ubuntu3
ii  libsoup2.4-1   2.74.2-3
ii  libstdc++6 12.1.0-2ubuntu1
ii  libvisio-0.1-1 0.1.7-1build6
ii  libwpg-0.3-3   0.3.3-1build3
ii  libx11-6   2:1.7.5-1
ii  libxml22.9.14+dfsg-1
ii  libxslt1.1 1.1.34-4build2
ii  python33.10.4-0ubuntu2
ii  zlib1g 1:1.2.11.dfsg-2ubuntu9

Versions of packages inkscape recommends:
ii  aspell   0.60.8-4build1
pn  fig2dev  
ii  imagemagick  8:6.9.11.60+dfsg-1.3build2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3build2
pn  libimage-magick-perl 
pn  libwmf-bin   
ii  python3-lxml 4.8.0-1build1
ii  python3-numpy1:1.21.5-1build2
ii  python3-scour0.38.2-2

Versions of packages inkscape suggests:
pn  dia   
pn  inkscape-tutorials
pn  libsvg-perl   
ii  pstoedit  3.78-1
pn  python3-uniconvertor  
ii  ruby  1:3.0~exp1
diff --git a/src/extension/internal/pdfinput/pdf-parser.cpp 
b/src/extension/internal/pdfinput/pdf-parser.cpp
index 
feecefa0434d82f131a203311f08b4ee7165492a..d6e2ede4f358e8761436bf68bdf93be306f03cb9
 100644
--- a/src/extension/internal/pdfinput/pdf-parser.cpp
+++ b/src/extension/internal/pdfinput/pdf-parser.cpp
@@ -30,6 +30,7 @@
 #include "Gfx.h"
 #include "pdf-parser.h"
 #include "util/units.h"
+#include "poppler-transition-api.h"
 
 #include "glib/poppler-features.h"
 #include "goo/gmem.h"
@@ -2158,7 +2159,7 @@ void PdfParser::opSetCharSpacing(Object args[], int 
/*numArgs*/)
 // TODO not good that numArgs is ignored but args[] is used:
 void PdfParser::opSetFont(Object args[], int /*numArgs*/)
 {
-  GfxFont *font = res->lookupFont(args[0].getName());
+  auto font = res->lookupFont(args[0].getName());
 
   if (!font) {
 // unsetting the font (drawing no text) is better than using the
@@ -2179,7 +2180,9 @@ void PdfParser::opSetFont(Object args[], int /*numArgs*/)
 fflush(stdout);
   }
 
+#if !POPPLER_CHECK_VERSION(22, 4, 0)
   font->incRefCnt();
+#endif
   state->setFont(font, args[1].getNum());
   fontChanged = gTrue;
 }
@@ -2373,7 +2376,6 @@ void PdfParser::doShowText(const GooString *s) {
 #else
 void PdfParser::doShowText(GooString *s) {
 #endif
-  GfxFont *font;
   int wMode;
   double riseX, riseY;
   CharCode code;
@@ 

Bug#1012816: reportbug: Failed to insert module 'firewire_sbp2': Key was rejected by service

[Diederik de Haas]

Control: reassign reassign -1 src:linux-signed-i386
Control: severity -1 serious
Control: merge -1 1012741

On Tuesday, 14 June 2022 19:26:06 CEST Albrecht Dreß wrote:
> Package: src:linux
> Version: 5.10.120-1
> Severity: normal
> X-Debbugs-Cc: albrecht.dr...@netcologne.de
> 
> Since the latest update, during startup systemd fails (i.e. prints "red"
> messages) whilst inserting modules.  /var/log/syslog contains
> 
> --8<-
> systemd-modules-load[1767]: Failed to insert module 'firewire_sbp2': Key was
> rejected by service

Module name may be different, but the issue and cause is the same, see 
https://bugs.debian.org/1012741#16 for details.

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

Bug#1012817: evolution-common: Checking local mail causes High CPU Usage

[Tim McConnell]

Package: evolution-common
Version: 3.44.2-1
Severity: important
X-Debbugs-Cc: tmcconnell...@gmail.com

Dear Maintainer,

What led up to the situation? Not sure, it took a while to narrow down the CPU
usage.

What exactly did you do (or not do) that was effective (or ineffective)?
Ineffective attempts to fix have been updating kernel, reducing log reports
being sent and killing evolution by evolution --force shutdown.

What was the outcome of this action? No Change WebkitWebProcess still consumes
50% or higher of my CPU and will go to 100% occasionally, I have opened bug
Bug#1012227: webkitgtk: CPU usage and haven't really found anything.

What outcome did you expect instead? For my CPU use to be the usualy 3 - 20%


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

Kernel: Linux 5.18.0-1-rt-amd64 (SMP w/2 CPU threads; PREEMPT)
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 evolution-common depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3

Versions of packages evolution-common recommends:
ii  evolution  3.44.2-1

evolution-common suggests no packages.

-- no debconf information

Bug#835439: gdb --write segfaults on quit in _bfd_elf_strtab_finalize

[Ben Harris]

Control: fixed 835439 10.1-2

Looking through my old Debian bug reports, I found this one that I'm still 
in a position to test, and I can confirm that the problem is fixed (and 
probably has been for several years):


wraith:/tmp/hello$ cat > hello.c
#include 

int main(int argc, char **argv)
{

printf("hello, world\n");
return 0;
}
wraith:/tmp/hello$ gcc -o hello hello.c
wraith:/tmp/hello$ gdb --quiet --write hello
Reading symbols from hello...
(No debugging symbols found in hello)
(gdb) quit
wraith:/tmp/hello$

--
Ben Harris, University of Cambridge Information Services.

Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain

[Hakan Ardo]

There is no progress I'm afraid. The package is up for adoption. We need to
find someone who's willing to put in the time needed...

On Tue, Jun 14, 2022 at 7:27 PM Marco  wrote:

> What's the current status? This bug is almost 3 years old and Debian
> is still shipping 5.4.0, even in Sid. nightwalker-87 mentions that
> Arch Linux may have found a working solution:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932989#20
>


-- 
Håkan Ardö

Bug#1012362: transition: luajit

[Jeroen Ploemen]

On Sun, 12 Jun 2022 20:20:50 -0700
"M. Zhou"  wrote:

> After browsing the corresponding github issues I think there is
> virtually nobody working on the ppc64el port. And I don't have any
> idea on how to fix it. So let's inform the reverse dependencies to
> remove ppc64el support, or switch back to lua.

Looking at the buildlogs for sysbench, running the upstream testsuite
triggers (apparently) identical segfaults for both ppc64el and ppc64,
so in all likelihood the latter is also affected by the underlying
issue.

> The only outcome for this luajit2 transition is that s390x seems
> working.

That's a new arch for sysbench too. You gain some, you lose some.


pgpoosJS0wW_p.pgp
Description: OpenPGP digital signature

Bug#1012816: reportbug: Failed to insert module 'firewire_sbp2': Key was rejected by service

[Albrecht Dreß]

Package: src:linux
Version: 5.10.120-1
Severity: normal
X-Debbugs-Cc: albrecht.dr...@netcologne.de

Since the latest update, during startup systemd fails (i.e. prints "red" 
messages) whilst inserting modules.  /var/log/syslog contains

--8<-
systemd-modules-load[1767]: Failed to insert module 'firewire_sbp2': Key was 
rejected by service
systemd[1]: systemd-modules-load.service: Main process exited, code=exited, 
status=1/FAILURE
systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Load Kernel Modules.
--8<-

Running modprobe from the command line produces the same error:

--8<-
root@schottland:~# modprobe firewire-sbp2
modprobe: ERROR: could not insert 'firewire_sbp2': Key was rejected by service
--8<-

The box is a /very/ old Apple MacBookPro5,5 (13-inch, Mid 2009).  I don't use 
Firewire (so this issue is actually not a blocker), but the "red" messages 
during startup are always a litte disturbing.

-- Package-specific info:
** Version:
Linux version 5.10.0-15-686-pae (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 
SMP Debian 5.10.120-1 (2022-06-09)

** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-15-686-pae root=/dev/mapper/schottland--vg-root ro 
quiet intel_iommu=off no_console_suspend nouveau.debug=warn init_on_alloc=0

** Not tainted

** Kernel log:
[ 1932.244859] wlan0: authenticate with dc:39:6f:b2:24:d7
[ 1932.596959] wlan0: send auth to dc:39:6f:b2:24:d7 (try 1/3)
[ 1932.602395] wlan0: authenticated
[ 1932.608543] wlan0: associate with dc:39:6f:b2:24:d7 (try 1/3)
[ 1932.616120] wlan0: RX ReassocResp from dc:39:6f:b2:24:d7 (capab=0x1431 
status=0 aid=1)
[ 1932.616496] wlan0: associated
[ 1932.642531] wlan0: Limiting TX power to 20 (20 - 0) dBm as advertised by 
dc:39:6f:b2:24:d7
[ 1952.676137] perf: interrupt took too long (3151 > 3141), lowering 
kernel.perf_event_max_sample_rate to 63250
[ 2012.603525] wlan0: deauthenticating from dc:39:6f:b2:24:d7 by local choice 
(Reason: 3=DEAUTH_LEAVING)
[ 2012.952630] b43-phy0: Loading firmware version 784.2 (2012-08-15 21:35:19)
[ 2013.609015] b43-phy0: Loading firmware version 784.2 (2012-08-15 21:35:19)
[ 2013.837739] PM: suspend entry (deep)
[ 2013.920420] Filesystems sync: 0.082 seconds
[ 2014.551896] (NULL device *): firmware: direct-loading firmware 
regulatory.db.p7s
[ 2014.551901] (NULL device *): firmware: direct-loading firmware regulatory.db
[ 2014.551969] Freezing user space processes ... (elapsed 0.003 seconds) done.
[ 2014.06] OOM killer disabled.
[ 2014.10] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
done.
[ 2014.558126] queueing ieee80211 work while going to suspend
[ 2014.576587] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 2014.576768] sd 0:0:0:0: [sda] Stopping disk
[ 2019.133627] ACPI: EC: interrupt blocked
[ 2019.152949] ACPI: Preparing to enter system sleep state S3
[ 2019.154238] ACPI: EC: event blocked
[ 2019.154240] ACPI: EC: EC stopped
[ 2019.154241] PM: Saving platform NVS memory
[ 2019.156670] Disabling non-boot CPUs ...
[ 2019.157995] smpboot: CPU 1 is now offline
[ 2019.158606] ACPI: Low-level resume complete
[ 2019.158606] ACPI: EC: EC started
[ 2019.158606] PM: Restoring platform NVS memory
[ 2019.158606] Enabling non-boot CPUs ...
[ 2019.158606] x86: Booting SMP configuration:
[ 2019.158606] smpboot: Booting Node 0 Processor 1 APIC 0x1
[ 2019.166234] CPU1 is up
[ 2019.168678] ACPI: Waking up from system sleep state S3
[ 2019.173784] ACPI: EC: interrupt unblocked
[ 2019.193490] ACPI: EC: event unblocked
[ 2019.194643] sd 0:0:0:0: [sda] Starting disk
[ 2019.424628] b43-phy0: Loading firmware version 784.2 (2012-08-15 21:35:19)
[ 2019.508208] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 2019.508224] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 2019.508420] ata1.00: configured for UDMA/133
[ 2019.512069] ata2.00: configured for UDMA/66
[ 2019.781424] OOM killer enabled.
[ 2019.781426] Restarting tasks ... done.
[ 2019.908456] PM: suspend exit
[ 2019.990366] forcedeth :00:0a.0 enp0s10: MSI enabled
[ 2019.990592] forcedeth :00:0a.0 enp0s10: no link during initialization
[ 2020.280648] b43-phy0: Loading firmware version 784.2 (2012-08-15 21:35:19)
[ 2031.292765] b43-phy0: Loading firmware version 784.2 (2012-08-15 21:35:19)
[ 2042.180733] wlan0: authenticate with dc:39:6f:b2:24:d6
[ 2042.528780] wlan0: send auth to dc:39:6f:b2:24:d6 (try 1/3)
[ 2042.534183] wlan0: authenticated
[ 2042.540467] wlan0: associate with dc:39:6f:b2:24:d6 (try 1/3)
[ 2042.546059] wlan0: RX AssocResp from dc:39:6f:b2:24:d6 (capab=0x1511 
status=0 aid=4)
[ 2042.546307] wlan0: associated
[ 2042.572107] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 2042.629346] wlan0: Limiting TX power to 20 (23 - 3) dBm as advertised by 
dc:39:6f:b2:24:d6
[ 2061.057267] EXT4-fs (dm-1): re-mounted. Opts: errors=remount-ro,commit=600
[ 2061.080116] EXT4-fs (sda2): re-m

Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain

[Marco]

What's the current status? This bug is almost 3 years old and Debian
is still shipping 5.4.0, even in Sid. nightwalker-87 mentions that
Arch Linux may have found a working solution:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932989#20

Bug#1012033: bullseye-pu: package gnutls28/3.7.1-5+deb11u1

[Andreas Metzler]

On 2022-05-29 Andreas Metzler  wrote:
[...]
> as requested in #1011246 I would like fix miscalculation of SHA384 in
> the SSA accelarated implementation.

> It is a one-line change and was part of the 3.7.3 release.
[...]

Actually this seems like a good opportunity to fix a minor CVE, which
was also fixed in 3.7.3.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
diff -Nru gnutls28-3.7.1/debian/changelog gnutls28-3.7.1/debian/changelog
--- gnutls28-3.7.1/debian/changelog 2021-05-29 12:14:30.0 +0200
+++ gnutls28-3.7.1/debian/changelog 2022-06-14 18:55:44.0 +0200
@@ -1,3 +1,12 @@
+gnutls28 (3.7.1-5+deb11u1) bullseye; urgency=medium
+
+  * 56_40-fix-SSSE3-SHA384-to-work-more-than-once.patch: Backport SSSE3 SHA384
+miscalculation fix from 3.7.3.  Closes: #1011246
+  * 56_45-wrap_nettle_hash_fast-avoid-calling-_update-with-zer.patch from
+3.7.3: Fix null-pointer dereference flaw. CVE-2021-4209
+
+ -- Andreas Metzler   Tue, 14 Jun 2022 18:55:44 +0200
+
 gnutls28 (3.7.1-5) unstable; urgency=medium
 
   * Another fix from 3.7.2:
diff -Nru 
gnutls28-3.7.1/debian/patches/56_40-fix-SSSE3-SHA384-to-work-more-than-once.patch
 
gnutls28-3.7.1/debian/patches/56_40-fix-SSSE3-SHA384-to-work-more-than-once.patch
--- 
gnutls28-3.7.1/debian/patches/56_40-fix-SSSE3-SHA384-to-work-more-than-once.patch
   1970-01-01 01:00:00.0 +0100
+++ 
gnutls28-3.7.1/debian/patches/56_40-fix-SSSE3-SHA384-to-work-more-than-once.patch
   2022-06-14 10:55:13.0 +0200
@@ -0,0 +1,34 @@
+From acdfeb4b3f0c64ad20f28513618e9903bfb81426 Mon Sep 17 00:00:00 2001
+From: Miroslav Lichvar 
+Date: Wed, 1 Sep 2021 15:48:27 +0200
+Subject: [PATCH] fix SSSE3 SHA384 to work more than once
+
+The output function called sha512_digest() instead of sha384_digest(),
+which caused the hash context to be reinitialized for SHA512 instead of
+SHA384 and all following digests using the hash handle were wrong.
+
+Signed-off-by: Miroslav Lichvar 
+---
+ lib/accelerated/x86/sha-x86-ssse3.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/accelerated/x86/sha-x86-ssse3.c 
b/lib/accelerated/x86/sha-x86-ssse3.c
+index 8ea4e54aee..1d442e97e7 100644
+--- a/lib/accelerated/x86/sha-x86-ssse3.c
 b/lib/accelerated/x86/sha-x86-ssse3.c
+@@ -258,11 +258,11 @@ static int _ctx_init(gnutls_digest_algorithm_t algo,
+   ctx->length = SHA256_DIGEST_SIZE;
+   break;
+   case GNUTLS_DIG_SHA384:
+   sha384_init(&ctx->ctx.sha384);
+   ctx->update = (update_func) x86_sha512_update;
+-  ctx->digest = (digest_func) sha512_digest;
++  ctx->digest = (digest_func) sha384_digest;
+   ctx->init = (init_func) sha384_init;
+   ctx->ctx_ptr = &ctx->ctx.sha384;
+   ctx->length = SHA384_DIGEST_SIZE;
+   break;
+   case GNUTLS_DIG_SHA512:
+-- 
+2.35.1
+
diff -Nru 
gnutls28-3.7.1/debian/patches/56_45-wrap_nettle_hash_fast-avoid-calling-_update-with-zer.patch
 
gnutls28-3.7.1/debian/patches/56_45-wrap_nettle_hash_fast-avoid-calling-_update-with-zer.patch
--- 
gnutls28-3.7.1/debian/patches/56_45-wrap_nettle_hash_fast-avoid-calling-_update-with-zer.patch
  1970-01-01 01:00:00.0 +0100
+++ 
gnutls28-3.7.1/debian/patches/56_45-wrap_nettle_hash_fast-avoid-calling-_update-with-zer.patch
  2022-06-14 10:58:46.0 +0200
@@ -0,0 +1,32 @@
+From 3db352734472d851318944db13be73da61300568 Mon Sep 17 00:00:00 2001
+From: Daiki Ueno 
+Date: Wed, 22 Dec 2021 09:12:25 +0100
+Subject: [PATCH] wrap_nettle_hash_fast: avoid calling _update with zero-length
+ input
+
+As Nettle's hash update functions internally call memcpy, providing
+zero-length input may cause undefined behavior.
+
+Signed-off-by: Daiki Ueno 
+---
+ lib/nettle/mac.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/lib/nettle/mac.c b/lib/nettle/mac.c
+index f9d4d7a8df..35e070fab0 100644
+--- a/lib/nettle/mac.c
 b/lib/nettle/mac.c
+@@ -788,7 +788,9 @@ static int wrap_nettle_hash_fast(gnutls_digest_algorithm_t 
algo,
+   if (ret < 0)
+   return gnutls_assert_val(ret);
+ 
+-  ctx.update(&ctx, text_size, text);
++  if (text_size > 0) {
++  ctx.update(&ctx, text_size, text);
++  }
+   ctx.digest(&ctx, ctx.length, digest);
+ 
+   return 0;
+-- 
+2.35.1
+
diff -Nru gnutls28-3.7.1/debian/patches/series 
gnutls28-3.7.1/debian/patches/series
--- gnutls28-3.7.1/debian/patches/series2021-05-29 11:37:38.0 
+0200
+++ gnutls28-3.7.1/debian/patches/series2022-06-14 10:59:12.0 
+0200
@@ -18,3 +18,5 @@
 56_28-handshake-fix-timing-of-sending-early-data.patch
 56_30-x509-verify-treat-SHA-1-signed-CA-in-the-trusted-set.patch
 56_33-serv-stop-setting-AI_ADDRCONFIG-on-getaddrinfo.patch
+56_40-fix-SSSE3-SHA384-to-work-more-than-once.patch
+56_45-wrap_nettle_ha

Bug#765936: qemu-system-common: please preserve setuid bit on /usr/lib/qemu/qemu-bridge-helper

[Corey Hickey]

On 2022-06-13 22:45, Michael Tokarev wrote:

Is it sufficient to use

dpkg-statoverride --add root root 04755 /usr/lib/qemu/qemu-bridge-helper

to fix this on a particular system?


I tested this and found:
1. This does persist across a reinstallation of qemu-system-common.
2. This does not apply immediately.

I suggest instead:

sudo dpkg-statoverride --update --add root root 04755 
/usr/lib/qemu/qemu-bridge-helper

That will immediately change the mode of the existing file.


I also tested granting CAP_NET_ADMIN via:
sudo setcap cap_net_admin=ep /usr/lib/qemu/qemu-bridge-helper

This works as well, but I don't see any way to make it persist
across package reinstallation. Some research indicates this must
be done by post-install script.

https://superuser.com/questions/1606800/how-can-capabilities-be-set-for-a-file-across-upgrades-in-dpkg-like-for-permissi
https://serverfault.com/questions/784426/preserve-linux-capabilities-in-debian-package

Thanks,
Corey

Bug#1010355: Fwd: Bug#1010355: CVE-2022-0530: null pointer dereference on invalid UTF-8 input

[Santiago Vila]

Hello.

I received this from the Debian bug system.

There are actually two problems here. One of them is CVE-2022-0530
which is what the reported bug is about. For that I have the proposed 
patch by Enrico Zini which seems to fix the issue.


But the github repository containing the test cases, namely this:

https://github.com/ByteHackr/unzip_poc

contains a test case for yet another problem called CVE-2022-0529
which I would like to fix as well.

This is what I've done to reproduce the bug:

export LC_ALL=C
cd CVE-2022-0529
unzip testcase

and I get this:

Archive:  testcase
warning [testcase]:  303 extra bytes at beginning or within zipfile
  (attempting to process anyway)
error [testcase]:  reported length of central directory is
  -303 bytes too long (Atari STZip zipfile?  J.H.Holm ZIPSPLIT 1.1
  zipfile?).  Compensating...
double free or corruption (out)

Any help will be appreciated.

Thanks.

 Forwarded Message 
Subject: Bug#1010355: CVE-2022-0530: null pointer dereference on invalid 
UTF-8 input

Date: Fri, 29 Apr 2022 13:27:33 +0200
From: Enrico Zini 
Reply-To: Enrico Zini , 1010...@bugs.debian.org
To: Debian Bug Tracking System 

Package: unzip
Version: 6.0-21+deb9u2
Severity: serious
Tags: security upstream patch
X-Debbugs-Cc: Debian Security Team 

Fixed: 6.0-26

Hello,

details are at https://security-tracker.debian.org/tracker/CVE-2022-0530

stretch and buster segfault:

  $ unzip testcase-0530   Archive:  testcase-0530
  warning [testcase-0530]:  16 extra bytes at beginning or within zipfile
(attempting to process anyway)
  error [testcase-0530]:  reported length of central directory is
-16 bytes too long (Atari STZip zipfile?  J.H.Holm ZIPSPLIT 1.1
zipfile?).  Compensating...
  error:  zipfile probably corrupt (segmentation violation)

bullseye errors out without valgrind issues reported:

  $ unzip testcase-0530
  Archive:  testcase-0530
  warning [testcase-0530]:  16 extra bytes at beginning or within zipfile
(attempting to process anyway)
  error [testcase-0530]:  reported length of central directory is
-16 bytes too long (Atari STZip zipfile?  J.H.Holm ZIPSPLIT 1.1
zipfile?).  Compensating...
  mp/zip-unzip-0/7/source/workdir 
/��6a9f01ad36a4ac3b68815bf6f83b3ff_inpu㉴�瑥:  mismatching 
"local" filename 
(mp/zip-unzip-0/7/source/workdir/��6a9f01ad36a4ac3b6881PK^G^HQ�V�^Q),

   continuing with "central" filename version
 skipping: mp/zip-unzip-0/7/source/workdir 
/��6a9f01ad36a4ac3b68815bf6f83b3ff_inpu㉴�瑥  unable to get password


The main issue here seems to be at utf8_to_local_string, defined in
process.c:2606, which doesn't check the result of utf8_to_wide_string
for a NULL value.

I'm attaching a proposed patch that adds the missing error handling.


Enrico


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

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

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

Versions of packages unzip depends on:
ii  libbz2-1.0  1.0.8-4
ii  libc6   2.31-13+deb11u3

unzip recommends no packages.

Versions of packages unzip suggests:
ii  zip  3.0-12

-- no debconf informationdiff --git a/fileio.c b/fileio.c
index 6290824..77e4b5f 100644
--- a/fileio.c
+++ b/fileio.c
@@ -2361,6 +2361,9 @@ int do_string(__G__ length, option)   /* return PK-type 
error code */
   /* convert UTF-8 to local character set */
   fn = utf8_to_local_string(G.unipath_filename,
 G.unicode_escape_all);
+  if (fn == NULL)
+return PK_ERR;
+
   /* make sure filename is short enough */
   if (strlen(fn) >= FILNAMSIZ) {
 fn[FILNAMSIZ - 1] = '\0';
diff --git a/process.c b/process.c
index d2a846e..715bc0f 100644
--- a/process.c
+++ b/process.c
@@ -2605,6 +2605,8 @@ char *utf8_to_local_string(utf8_string, escape_all)
   int escape_all;
 {
   zwchar *wide = utf8_to_wide_string(utf8_string);
+  if (wide == NULL)
+return NULL;
   char *loc = wide_to_local_string(wide, escape_all);
   free(wide);
   return loc;

Bug#1012810: (no subject)

[Henrik Christian Grove]

submitter deb...@3001.dk

Bug#1012524: marked as pending in libass

[Oneric]

Thanks for looking into this so quickly!
It appears though, that the commit marking the bug as fixed,
only deals with the assembly part. I don't see any additional commits
in salsa either.

This means when the next upstream release comes and it is (as announced
to be possible with the last release) signed with one of the other keys,
uscan will fail to verify the signature. The additional keys are listed in
MAINTAINERS inside the last (signed) tarball. Additionally the git commit
adding the keys to the list was also signed with the same key as used for
the last few release tags and the last release archive.

I only listed instructions (to the best of my knowledge, I may be wrong),
since I assumed you might be more comfortable adding the keys yourself
instead of having to check `gpg --list-packets`  from a patched  keyring
file to ensure no additional malicious keys were added.
If it’s preferred I can also send a patch.


Cheers

Oneric


signature.asc
Description: PGP signature

Bug#1012812: spacenavd: Please package new upstream relesae (1.0)

[Boyuan Yang]

Source: spacenavd
Version: 0.7.1-1
Severity: normal
Tags: sid  bookworm
X-Debbugs-CC: rodol...@damsy.net

Dear Debian spacenavd maintainer,

As requested in
https://lists.debian.org/debian-science/2022/06/msg8.html , A new
upstream release (1.0) of the package is available. Please consider
packaging it. If you need any help in packaging (such as packaging
sponsorship), please let me know. Besides, it would be great if the package
could be team-maintained in Debian Science Team. Please let me know if you
agree with team maintenance.

Thanks,
Boyuan Yang


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

Bug#1012813: libspnav: Please package new upstream relesae (1.0)

[Boyuan Yang]

Source: libspnav
Version: 0.2.3-1
Severity: normal
Tags: sid  bookworm
X-Debbugs-CC: rodol...@damsy.net

Dear Debian libspnav maintainer,

As requested
in https://lists.debian.org/debian-science/2022/06/msg8.html , A new
upstream release (1.0) of the package is available. Please consider
packaging it. If you need any help in packaging (such as packaging
sponsorship), please let me know. Besides, it would be great if the package
could be team-maintained in Debian Science Team. Please let me know if you
agree with team maintenance.

Thanks,
Boyuan Yang


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

Bug#1010355: Wrong upstream

[Santiago Vila]

notforwarded 1010355
thanks

Wrong upstream, this is unzip, not procmail.

Bug#1012795: libengine-gost-openssl1.1: Shared library file in /

[Wartan Hachaturow]

This seems to be caused by last NMU :(
libengine-gost-openssl 3.0.1-1, which fixes that (and other) problem, and
also deprecates libengine-gost-openssl1.1, is in the NEW queue.
I will leave the bug open, though, until it installs in the archive, as a
reminder.

Thanks for the report!

On Tue, Jun 14, 2022, 11:39 Cédric Hannotier 
wrote:

> Package: libengine-gost-openssl1.1
> Version: 1.1.0.3-1.1
> Severity: important
>
> Dear Maintainer,
>
> The package is ill-configured and end up
> putting gost.so in the root of the filesystem (/gost.so),
> as shown in [1].
> The source of the issue is [2], which is empty...
>
> [1]
> https://packages.debian.org/sid/amd64/libengine-gost-openssl1.1/filelist
> [2]
> https://sources.debian.org/src/libengine-gost-openssl1.1/1.1.0.3-1.1/debian/rules/#L22
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
> 'testing-debug'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.17.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
> Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 libengine-gost-openssl1.1 depends on:
> ii  libc62.33-7
> ii  libssl3  3.0.3-7
>
> libengine-gost-openssl1.1 recommends no packages.
>
> libengine-gost-openssl1.1 suggests no packages.
>
> --
>
> Cédric Hannotier
>

Bug#1012811: Installation of bookworm successfully at AMD Desktop PC

[Bernhard]

Package: installation-reports

Boot method: Network PXE Boot
Image version: PXE Boot with daily:

> https://d-i.debian.org/daily-images/amd64/daily/netboot/debian-installer/amd64/initrd.gz
> https://d-i.debian.org/daily-images/amd64/daily/netboot/debian-installer/amd64/linux

Date: 2022-06-14

Machine: Self-made Desktop PC
Processor: AMD A10-5700 APU with Radeon(tm) HD Graphics
Memory: 4GB
Partitions:

> DateisystemTyp  1K-Blöcke  Benutzt Verfügbar Verw% Eingehängt auf
> udev   devtmpfs   18960360   18960360% /dev
> tmpfs  tmpfs   383776  9003828761% /run
> /dev/sda1  ext4 113809604 10271888  97710340   10% /
> tmpfs  tmpfs  191888010320   19085601% /dev/shm
> tmpfs  tmpfs 51204  51161% /run/lock
> tmpfs  tmpfs   383776  1163836601% /run/user/1000

Output of lspci -knn:

> 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
> (Models 10h-1fh) Processor Root Complex [1022:1410]
>   Subsystem: ASUSTeK Computer Inc. Family 15h (Models 10h-1fh) Processor 
> Root Complex [1043:8526]
> 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
> [AMD/ATI] Trinity [Radeon HD 7660D] [1002:9901]
>   Subsystem: ASUSTeK Computer Inc. Trinity [Radeon HD 7660D] [1043:8526]
>   Kernel driver in use: radeon
>   Kernel modules: radeon, amdgpu
> 00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Trinity 
> HDMI Audio Controller [1002:9902]
>   Subsystem: ASUSTeK Computer Inc. Trinity HDMI Audio Controller 
> [1043:8526]
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
> 00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> XHCI Controller [1022:7812] (rev 03)
>   Subsystem: ASUSTeK Computer Inc. FCH USB XHCI Controller [1043:8527]
>   Kernel driver in use: xhci_hcd
>   Kernel modules: xhci_pci
> 00:10.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> XHCI Controller [1022:7812] (rev 03)
>   Subsystem: ASUSTeK Computer Inc. FCH USB XHCI Controller [1043:8527]
>   Kernel driver in use: xhci_hcd
>   Kernel modules: xhci_pci
> 00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA 
> Controller [AHCI mode] [1022:7801] (rev 40)
>   Subsystem: ASUSTeK Computer Inc. FCH SATA Controller [AHCI mode] 
> [1043:8527]
>   Kernel driver in use: ahci
>   Kernel modules: ahci
> 00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> OHCI Controller [1022:7807] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB OHCI Controller [1043:8527]
>   Kernel driver in use: ohci-pci
>   Kernel modules: ohci_pci
> 00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> EHCI Controller [1022:7808] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB EHCI Controller [1043:8527]
>   Kernel driver in use: ehci-pci
>   Kernel modules: ehci_pci
> 00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> OHCI Controller [1022:7807] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB OHCI Controller [1043:8527]
>   Kernel driver in use: ohci-pci
>   Kernel modules: ohci_pci
> 00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> EHCI Controller [1022:7808] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB EHCI Controller [1043:8527]
>   Kernel driver in use: ehci-pci
>   Kernel modules: ehci_pci
> 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
> [1022:780b] (rev 14)
>   Subsystem: ASUSTeK Computer Inc. FCH SMBus Controller [1043:8527]
>   Kernel driver in use: piix4_smbus
>   Kernel modules: i2c_piix4, sp5100_tco
> 00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] FCH Azalia 
> Controller [1022:780d] (rev 01)
>   Subsystem: ASUSTeK Computer Inc. F2A85-M Series [1043:8444]
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
> 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge 
> [1022:780e] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH LPC Bridge [1043:8527]
> 00:14.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] FCH PCI Bridge 
> [1022:780f] (rev 40)
> 00:15.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Hudson PCI to 
> PCI bridge (PCIE port 0) [1022:43a0]
>   Kernel driver in use: pcieport
> 00:15.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Hudson PCI to 
> PCI bridge (PCIE port 1) [1022:43a1]
>   Kernel driver in use: pcieport
> 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
> (Models 10h-1fh) Processor Function 0 [1022:1400]
> 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
> (Models 10h-1fh) Processor Function 1 [1022:1401]
> 00:18.2 Host bridge [0600]: Advanced M

Bug#1012810: cadaver: Doesn't recognise SSL cert (perhaps because it has many names)

[Henrik Christian Grove]

Package: cadaver
Version: 0.23.3-2.1+b1
Severity: normal

I'm trying to use cadaver on stable/amd64, the version I've got here
differs from the newest packages both by having a binary non-maintainer
upload for amd64 (giving the "+b1" on my version, i.e. I have that) and
a non-maintainer upload that only fixes building issues (as far as I 
can see - giving the change for "-2.1" to "-2.2" - I don't have that).
In total I don't believe those differences matter for this issue.

When I try to use cadaver, I get this:
dav:!> open https://files.one.com
WARNING: Untrusted server certificate presented for `confluence.one.com':
Issued to: internal-it.one.com
Issued by: Let's Encrypt, US
Certificate is valid from Wed, 27 Apr 2022 15:35:02 GMT to Tue, 26 Jul 2022 
15:35:01 GMT
Do you wish to accept the certificate? (y/n)


When I visit that site in a browser, it doesn't say anything about that
certificate, if I view it I can see it has 11 alternate names, of which
files.one.com is the second. We're witin the validity period that cadaver 
sees and it actually shows the first alternate name in the "Untrusted
server certificate presented"-message, perhaps cadaver (or some library
it uses) doesn't properly support that many alternate names?

This might be the same issue as reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741366
but that bug report doesn't contain any info about the certificate
offered, so it's hard to tell.

.Henrik

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

Kernel: Linux 5.10.0-13-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.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 cadaver depends on:
ii  libc6 2.31-13+deb11u3
ii  libgcrypt20   1.8.7-6
ii  libgnutls30   3.7.1-5
ii  libncurses6   6.2+20201114-2
ii  libneon27-gnutls  0.31.2-1
ii  libreadline8  8.1-1
ii  libtinfo6 6.2+20201114-2
ii  libxml2   2.9.10+dfsg-6.7+deb11u2

cadaver recommends no packages.

cadaver suggests no packages.

-- no debconf information

Bug#139861: Is this the same bug?

[sergio]

Is this the same bug, or a separate one should be opened?

% echo '¡Hola!' | tr -d '¿'
�Hola!

--
sergio.

Bug#1012786: libcamera: Fails to build from source

[Christopher Obbard]

On 14/06/2022 15:35, Lisandro Damián Nicanor Pérez Meyer wrote:

Hi!

On Tue, 14 Jun 2022 at 05:26, Christopher Obbard
 wrote:



Hi!

I propose a patch to potentially fix this:
https://salsa.debian.org/multimedia-team/libcamera/-/merge_requests/6

The use of the depreciated function could even be fixed in upstream, it
could be worth updating the package from upstream?


No, upstream is doing the right thing. Their builds ought to fail in
this case. We are the ones that should disable this flag, as done.

What you really need to do is take this issue to upstream so they use
the newer interfaces if possible (ie, avoid the deprecation warning).



Right, what I originally meant was: "perhaps upstream have fixed this by 
using the correct gstreamer function instead of a depreciated one, maybe 
we should check if upstream have done that".


For the record, it turns out that upstream have: 
https://git.libcamera.org/libcamera/libcamera.git/commit/test/gstreamer/gstreamer_multi_stream_test.cpp?id=4085372c517e1527114dc4098194c3ae3b973ba0


So, if we update to the latest version of libcamera, everything is fine 
again for future :-). I don't mind doing an update to libcamera HEAD, if 
Andrew would like some help.


Cheers!

Chris

Bug#1004109: xdg-utils-cxx FTBFS on !amd64/arm64: symbol differences

[Benjamin Drung]

Hi,

Instead of disabling the symbols that are not present when building with
LTO, mark them as optional instead. Attached is a patch applied to
Ubuntu.

-- 
Benjamin Drung
Debian & Ubuntu Developer
diff -Nru xdg-utils-cxx-1.0.1/debian/changelog xdg-utils-cxx-1.0.1/debian/changelog
--- xdg-utils-cxx-1.0.1/debian/changelog	2021-03-11 20:24:59.0 +0100
+++ xdg-utils-cxx-1.0.1/debian/changelog	2022-06-14 16:49:46.0 +0200
@@ -1,3 +1,10 @@
+xdg-utils-cxx (1.0.1-4) UNRELEASED; urgency=medium
+
+  * Mark symbols as optional not seen when building with lto.
+(Closes: #1004109)
+
+ -- Benjamin Drung   Tue, 14 Jun 2022 16:49:46 +0200
+
 xdg-utils-cxx (1.0.1-3) unstable; urgency=medium
 
   * Add patches provided by Assassin to fix issues with targets and
diff -Nru xdg-utils-cxx-1.0.1/debian/libxdgutilsdesktopentry1.0.1.symbols xdg-utils-cxx-1.0.1/debian/libxdgutilsdesktopentry1.0.1.symbols
--- xdg-utils-cxx-1.0.1/debian/libxdgutilsdesktopentry1.0.1.symbols	2021-03-11 20:24:59.0 +0100
+++ xdg-utils-cxx-1.0.1/debian/libxdgutilsdesktopentry1.0.1.symbols	2022-06-14 16:49:39.0 +0200
@@ -1,14 +1,14 @@
 # SymbolsHelper-Confirmed: 1.0.1 amd64
 libXdgUtilsDesktopEntry.so.1.0.1 libxdgutilsdesktopentry1.0.1 #MINVER#
 * Build-Depends-Package: xdg-utils-cxx-dev
- _ZN8XdgUtils12DesktopEntry10ParseErrorD0Ev@Base 1.0.1
- _ZN8XdgUtils12DesktopEntry10ParseErrorD1Ev@Base 1.0.1
- _ZN8XdgUtils12DesktopEntry10ParseErrorD2Ev@Base 1.0.1
+ (optional=lto)_ZN8XdgUtils12DesktopEntry10ParseErrorD0Ev@Base 1.0.1
+ (optional=lto)_ZN8XdgUtils12DesktopEntry10ParseErrorD1Ev@Base 1.0.1
+ (optional=lto)_ZN8XdgUtils12DesktopEntry10ParseErrorD2Ev@Base 1.0.1
  _ZN8XdgUtils12DesktopEntry12DesktopEntry3setERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_@Base 1.0.1
- _ZN8XdgUtils12DesktopEntry12DesktopEntry4Priv11createEntryERKNS0_19DesktopEntryKeyPathERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0.1
- _ZN8XdgUtils12DesktopEntry12DesktopEntry4Priv11createGroupERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0.1
- _ZN8XdgUtils12DesktopEntry12DesktopEntry4Priv11removeEntryERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0.1
- _ZN8XdgUtils12DesktopEntry12DesktopEntry4Priv11updatePathsEv@Base 1.0.1
+ (optional=lto)_ZN8XdgUtils12DesktopEntry12DesktopEntry4Priv11createEntryERKNS0_19DesktopEntryKeyPathERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0.1
+ (optional=lto)_ZN8XdgUtils12DesktopEntry12DesktopEntry4Priv11createGroupERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0.1
+ (optional=lto)_ZN8XdgUtils12DesktopEntry12DesktopEntry4Priv11removeEntryERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0.1
+ (optional=lto)_ZN8XdgUtils12DesktopEntry12DesktopEntry4Priv11updatePathsEv@Base 1.0.1
  _ZN8XdgUtils12DesktopEntry12DesktopEntry6removeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0.1
  _ZN8XdgUtils12DesktopEntry12DesktopEntryC1EOS1_@Base 1.0.1
  _ZN8XdgUtils12DesktopEntry12DesktopEntryC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0.1
@@ -27,13 +27,13 @@
  _ZN8XdgUtils12DesktopEntry12DesktopEntryaSERKS1_@Base 1.0.1
  _ZN8XdgUtils12DesktopEntry12DesktopEntryixERKNS0_19DesktopEntryKeyPathE@Base 1.0.1
  _ZN8XdgUtils12DesktopEntry12DesktopEntryixERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0.1
- _ZN8XdgUtils12DesktopEntry17DesktopEntryErrorD0Ev@Base 1.0.1
- _ZN8XdgUtils12DesktopEntry17DesktopEntryErrorD1Ev@Base 1.0.1
- _ZN8XdgUtils12DesktopEntry17DesktopEntryErrorD2Ev@Base 1.0.1
- _ZN8XdgUtils12DesktopEntry18MalformedPathErrorD0Ev@Base 1.0.1
- _ZN8XdgUtils12DesktopEntry18MalformedPathErrorD1Ev@Base 1.0.1
- _ZN8XdgUtils12DesktopEntry18MalformedPathErrorD2Ev@Base 1.0.1
- _ZN8XdgUtils12DesktopEntry19DesktopEntryKeyPath4Priv5parseERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0.1
+ (optional=lto)_ZN8XdgUtils12DesktopEntry17DesktopEntryErrorD0Ev@Base 1.0.1
+ (optional=lto)_ZN8XdgUtils12DesktopEntry17DesktopEntryErrorD1Ev@Base 1.0.1
+ (optional=lto)_ZN8XdgUtils12DesktopEntry17DesktopEntryErrorD2Ev@Base 1.0.1
+ (optional=lto)_ZN8XdgUtils12DesktopEntry18MalformedPathErrorD0Ev@Base 1.0.1
+ (optional=lto)_ZN8XdgUtils12DesktopEntry18MalformedPathErrorD1Ev@Base 1.0.1
+ (optional=lto)_ZN8XdgUtils12DesktopEntry18MalformedPathErrorD2Ev@Base 1.0.1
+ (optional=lto)_ZN8XdgUtils12DesktopEntry19DesktopEntryKeyPath4Priv5parseERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0.1
  _ZN8XdgUtils12DesktopEntry19DesktopEntryKeyPath6setKeyERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0.1
  _ZN8XdgUtils12DesktopEntry19DesktopEntryKeyPath8setGroupERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0.1
  _ZN8XdgUtils12DesktopEntry19DesktopEntryKeyPath9setLocaleERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.0.1
@@ -65,8 +65,8 @@
  _ZN8XdgUtils12DesktopEntry20DesktopEntryKeyValuecvbEv@Base 1.0.1
  _ZN8XdgUtils12DesktopEntry20DesktopEntryKeyValue

Bug#1012809: openboard: Update for Poppler 22.06

[Nathan Pratta Teodosio]

Package: openboard
Version: 1.6.1+dfsg2-1
Severity: normal
Tags: patch
X-Debbugs-Cc: nathan.teodo...@canonical.com

Dear Maintainer,

Since Poppler 22.06 is making its way into experimental (currently in NEW[1]),
Openboard will need the compatibility changes from upstream to build. I
collected them in the attached patch.

[1]: https://ftp-master.debian.org/new.html


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

Kernel: Linux 5.15.0-33-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.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 openboard depends on:
ii  libavcodec58  7:4.4.2-1ubuntu3
ii  libavformat58 7:4.4.2-1ubuntu3
ii  libavutil56   7:4.4.2-1ubuntu3
ii  libc6 2.35-0ubuntu3
ii  libgcc-s1 12.1.0-2ubuntu1
ii  libgomp1  12.1.0-2ubuntu1
pn  libpoppler118 
ii  libqt5core5a  5.15.4+dfsg-2
ii  libqt5gui55.15.4+dfsg-2
ii  libqt5multimedia5 5.15.4-1
ii  libqt5multimediawidgets5  5.15.4-1
ii  libqt5network55.15.4+dfsg-2
ii  libqt5svg55.15.4-1
ii  libqt5webkit5 5.212.0~alpha4-18
ii  libqt5widgets55.15.4+dfsg-2
ii  libqt5xml55.15.4+dfsg-2
ii  libquazip5-1  0.9.1-2
ii  libssl3   3.0.3-5ubuntu3
ii  libstdc++612.1.0-2ubuntu1
ii  libswresample37:4.4.2-1ubuntu3
ii  libswscale5   7:4.4.2-1ubuntu3
ii  libx11-6  2:1.7.5-1
pn  openboard-common  
ii  zlib1g1:1.2.11.dfsg-2ubuntu9

openboard recommends no packages.

Versions of packages openboard suggests:
pn  openboard-contrib  
Description: Backport for Poppler 22.06 compatibility
Author: Nathan Pratta Teodosio 
--- a/src/pdf/XPDFRenderer.cpp  2022-06-14 11:15:55.508584513 -0300
+++ b/src/pdf/XPDFRenderer.cpp  2022-06-14 11:16:00.312570630 -0300
@@ -95,6 +95,8 @@
 }
 #ifdef USE_XPDF
 mDocument = new PDFDoc(new GString(filename.toLocal8Bit()), 0, 0, 0); // 
the filename GString is deleted on PDFDoc desctruction
+#elif POPPLER_VERSION_MAJOR > 22 || (POPPLER_VERSION_MAJOR == 22 && 
POPPLER_VERSION_MINOR >= 3)
+mDocument = new 
PDFDoc(std::make_unique(filename.toLocal8Bit()));
 #else
 mDocument = new PDFDoc(new GooString(filename.toLocal8Bit()), 0, 0, 0); // 
the filename GString is deleted on PDFDoc desctruction
 #endif

Bug#1012808: git-review 2.2 is not compatible with OpenSSH 9.X (scp breaking change)

[Baptiste Jonglez]

Package: git-review
Version: 2.2.0-1
Severity: important

Dear Maintainer,

While using git-review on Bookworm, I couldn't perform the initial setup:

$ git review -s -v
Running: scp -P29418 usern...@review.opendev.org:hooks/commit-msg 
.git/hooks/commit-msg
Problems encountered installing commit-msg hook
The following command failed with exit code 255
"scp -P29418 usern...@review.opendev.org:hooks/commit-msg 
.git/hooks/commit-msg"
---
subsystem request failed on channel 0
scp: Connection closed
---

Running the scp command manually yields the same error.

This is likely caused by a breaking change in scp behaviour introduced in 
OpenSSH 9.X

The upstream project already has a fix for this issue:

  
https://opendev.org/opendev/git-review/commit/5bfaa4a6f355a6820fe16c1aea77a01ba7b97eaa

Updating the git-review package to version 2.3 should be enough to fix this 
issue.

Thanks,
Baptiste

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

Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
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 git-review depends on:
ii  git   1:2.35.1-1
ii  python3   3.10.4-1+b1
ii  python3-requests  2.27.1+dfsg-1
ii  python3-six   1.16.0-3

git-review recommends no packages.

git-review suggests no packages.

-- no debconf information

Bug#1012807: curl: "unexpected eof" from Patroni API endpoint after client upgrade to OpenSSL 3

[Ben Harris]

Package: curl
Version: 7.83.1-1+b1
Severity: normal
Control: fixed -1 7.83.0-1

Dear Maintainer,

Patroni (Debian package "patroni") is a piece of cluster management 
software for PostgreSQL that provides an HTTPS endpoint for managing it.  
When connecting to a Patroni instance from curl 7.83.0-1 (a version 
using libssl1.1), everything works happily:

wraith:~# curl --fail --insecure https://infra-db.srv.uis.cam.ac.uk:8008/ -o 
/dev/null
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100   6510   6510 0  62928  0 --:--:-- --:--:-- --:--:-- 65100

However, when I upgrade to curl 7.83.1-1+b1, I get an error from the 
same request:

wraith:~# curl --fail --insecure https://infra-db.srv.uis.cam.ac.uk:8008/ -o 
/dev/null
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100   6510   6510 0  22106  0 --:--:-- --:--:-- --:--:-- 22448
curl: (56) OpenSSL SSL_read: error:0A000126:SSL routines::unexpected eof while 
reading, errno 0

I would expect the two versions to behave the same.

Patroni uses Python's "http.server" to implement its API endpoint, so it 
may be possible to construct a simple test-case out of that.  I haven't 
yet tried.

I'm not certain that this bug is in cURL rather than in OpenSSL, Python, 
or Patroni, but cURL is the part I'm interacting with so it seems like a 
good place to start.

Here are the versions of libcurl4's dependencies, since they might be 
relevant:

ii  libbrotli1:i3861.0.9-2+b3
ii  libgssapi-krb5-2:i386  1.19.2-2+b2
ii  libidn2-0:i386 2.3.2-2
ii  libldap-2.5-0:i386 2.5.12+dfsg-2
ii  libnghttp2-14:i386 1.47.0-1+b1
ii  libpsl5:i386   0.21.0-1.2
ii  librtmp1:i386  2.4+20151223.gitfa8646d.1-2+b2
ii  libssh2-1:i386 1.10.0-3+b1
ii  libssl3:i386   3.0.3-7
ii  libzstd1:i386  1.5.2+dfsg-1

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

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

Versions of packages curl depends on:
ii  libc6 2.33-7
ii  libcurl4  7.83.1-1+b1
ii  zlib1g1:1.2.11.dfsg-4

curl recommends no packages.

curl suggests no packages.

-- no debconf information

Bug#1012806: xpdf: Please update for Poppler 22.06

[Nathan Pratta Teodosio]

Package: xpdf
Version: 3.04+git20220201-1
Severity: normal
X-Debbugs-Cc: nathan.teodo...@canonical.com

Dear Maintainer,

Please consider releasing a new snapshot for Xpdf, since Poppler 22.06 is
making its way into experimental (currently in NEW[1]) and it will need the
compatibility changes from upstream to build.

[1]: https://ftp-master.debian.org/new.html


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

Kernel: Linux 5.15.0-33-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.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 xpdf depends on:
ii  libc6  2.35-0ubuntu3
ii  libgcc-s1  12.1.0-2ubuntu1
ii  libpaper1  1.1.28build2
ii  libpoppler118  22.02.0-3
ii  libstdc++6 12.1.0-2ubuntu1
ii  libx11-6   2:1.7.5-1
ii  libxm4 2.3.8-3
ii  libxt6 1:1.2.1-1

Versions of packages xpdf recommends:
ii  cups-bsd2.4.2-1ubuntu1
pn  gsfonts-x11 
ii  poppler-data0.4.11-1
ii  poppler-utils   22.06.0-1
ii  sensible-utils  0.0.17

xpdf suggests no packages.

Bug#1012786: libcamera: Fails to build from source

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Tue, 14 Jun 2022 at 05:26, Christopher Obbard
 wrote:
>
>
> Hi!
>
> I propose a patch to potentially fix this:
> https://salsa.debian.org/multimedia-team/libcamera/-/merge_requests/6
>
> The use of the depreciated function could even be fixed in upstream, it
> could be worth updating the package from upstream?

No, upstream is doing the right thing. Their builds ought to fail in
this case. We are the ones that should disable this flag, as done.

What you really need to do is take this issue to upstream so they use
the newer interfaces if possible (ie, avoid the deprecation warning).

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1012789: [Emc-developers] Bug#1012789: linuxcnc-uspace: Linux CNC will not start

[andy pugh]

On Tue, 14 Jun 2022 at 14:49, Vector Hasting  wrote:

> _tkinter.TclError: couldn't load file 
> "/usr/lib/tcltk/aarch64-linux-gnu/Img1.4.13/libtifftcl4.1.0.so": 
> /usr/lib/tcltk/aarch64-linux-gnu/Img1.4.13/libtifftcl4.1.0.so: undefined 
> symbol: _TIFFsetString, version LIBTIFF_4.0

This looks to be a dependency (hard coded?) on the version of libtiff
that shipped with Buster (4.1).

But it also seems to be in a package that LinuxCNC depends on, but
doesn't control?
https://sourceforge.net/projects/tkimg/files/tkimg/1.4/tkimg%201.4.13/
(From the file path being searched)

For me, the trail dries up there. I guess this is due to a Tcl/Tk dependency?

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

Bug#1012768: Bug#1012785: libgsasl7 depends on outdated gsasl-common version 1.10.0-5

[Sebastian Ramacher]

On 2022-06-14 12:59:37, Simon Josefsson wrote:
> tis 2022-06-14 klockan 01:36 + skrev Felicia P:
> > Package: libgsasl7
> > Version: 1.10.0-5+b1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > libgsasl7 depends on gsasl-common 1.10.0-5 however the current
> > version of gsasl-common is now 1.11.3-2
> 
> Thanks -- this is related to the transition to libgsasl18, so cc'ing
> 1012768 too.  Any help to resolve this would be appreciated!  I must
> admit that my brain cannot really understand all the complexities
> around library transitions.  
> 
> The situation appears to be:
> 
> 1) Testing contains libgsasl7 1.10.0-5 that has a hard versioned
> dependency on gsasl-common 1.10.0-5 for translation files.
> 
> 2) Unstable now has libgsasl18 1.11.3-2 that depends on gsasl-common
> 1.11.3-2.
> 
> 3) Libgsasl7 is no longer built by the gsasl source package, and the
> idea is that it should go away.
> 
> 4) The old libgsasl7 is not installable since it depends on a gsasl-
> common package that is no longer in unstable.
> 
> What should be done here?  
> 
> I guess the idea is that all packages that are built against libgsasl7
> is going to be NMU'd through the transition, so that they are built
> against libgsasl18 instead.  Then this shouldn't be a problem.

While this won't be a problem in testing and unstable once the
transition is done, it could be a problem for bullseye -> bookworm
upgrades. In the worst case, this may make it harder for apt to find an
upgrade path and might have unintended side-effects on reverse
dependencies. For example, for upgrades to bullseye we faced issues with
a library that had postgresql extension modules as reverse dependencies
which also transitioned between postgresql versions where it would have
been desirable to keep the old binary packages installed for the
database migration.

Whether this is a problem for libgsasl, we'll see once upgrade tests for
bullseye -> bookworm are started.

> However, maybe something more should be done anyway.  Some ideas:
> 
> A) We declare that gsasl-common >= 1.11.3-2 conflicts with libgsasl7. 
> Doesn't really solve anything, but maybe it will lead to libgsasl7
> being uninstalled automatically?

That won't help. libgsasl7's strict dependency on gsasl-common
will already force its removal when gsasl-common is upgraded.

> B) Somehow drop the gsasl-common dependency?  It only contains
> translations, which works for both libgsasl7 and libgsasl18.

If gsasl-common only contains translations, would a Recommends:
gsasl-common (>= ${source:Version}) (or Depends) be enough? The solution
with Depends would not improve the situation for this transition, but
only for the next one.

> C) Change the versioning dependency, so that new gsasl-common satisfy
> the old libgsasl7 dependency -- but I'm not sure that's possible,
> libgsasl7 depends on the same version of gsasl-common.

That won't be possible … unless SRMs accept such a change in stable.

> I guess this means that libgsasl7 and libgsasl18 cannot be installed on
> the same system ever, due to the gsasl-common versioned dependencies. 
> That is unfortunate, since there is no real problem with having both
> versions installed.
> 
> Maybe B) is the right solution?!  We could move the translations into
> libgsasl18 and drop gsasl-common.  Then old libgsasl7 could depend on
> gsasl-common and things will work, and you could have libgsasl18
> installed too -- however, they would conflict in files since both ship
> the same translation files... unless we modify the filenames so they
> live in separate directories or basenames.  I'm not sure that is worth
> it.

Note that this requires the translation files contained in libgsasl18
to be versioned exactly in the same way as the shared library. See Policy
8.2.

Cheers

> It may also be that we can't fix this problem, and just live with the
> consequences.  What is the real problem here?  All dependencies on
> libgsasl7 should be rebuilt and then link to libgsasl18.  Libgsasl7
> will disappear from testing shortly.
> 
> I wonder if it was a mistake to put translations in gsasl-common?!  I
> recall a lot of thought went into that but it was many years ago and
> maybe the best practice around this has changed.
> 
> /Simon
-- 
Sebastian Ramacher

Bug#1012805: zfsutils-linux: vdev_id not working

[Gero]

Package: zfsutils-linux

Version: 2.1.4-1~bpo11+1

Severity: normal

Dear Maintainer,

I installed zfs as it's described here: 
https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/, i.e. 
installed the packages zfs-dkms zfsutils-linux from bullseye-backports


Then I tried to create disk device name mappings for a zfs pool and it 
seems that the vdev_id tool is not working or not properly configured to 
create symlinks in a new directory /dev/disk/by-vdev as promised in the 
openzfs documentation 
https://openzfs.github.io/openzfs-docs/Project%20and%20Community/FAQ.html#setting-up-the-etc-zfs-vdev-id-conf-file


At first vdev_id is not in the search path but in /lib/udev/vdev_id. 
Next, it doesn't find the config file /etc/zfs/vdev_id.conf when started 
without options. It does find it however when this very path is given 
explicitly like so:

# /lib/udev/vdev_id -c /etc/zfs/vdev_id.conf
(I don't know if that's ok or part of the problem.)

The instructions in the FAQ section of the openzfs docs state that the 
command

# udevadm trigger
should create the /dev/disk/by-vdev directory and some symlinks in it. 
This doesn't seem to work. I can't see any effect of this command, 
except for a couple of messages in /var/log/syslog:

systemd-udevd[2523]: Using default interface naming scheme 'v247'.
In particular no folder by-vdev is created.

I tried essentially with two versions of a /etc/zfs/vdev_id.conf - file:
---snip---
multipath no
topology  sas_direct
channel 85:00.0  1 A
---snap---
and secondly:
---snip---
alias Front00   /dev/disk/by-path/pci-:af:00.0-sas-0x5000c500a18fb521
alias Front01   /dev/disk/by-path/pci-:af:00.0-sas-0x5000c500a18f2cd5
---snap---

Thanks a lot for your effort!

Regards,
Gero.


-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-14-amd64 (SMP w/32 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=en_US:en

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

Versions of packages zfsutils-linux depends on:
ii  init-system-helpers  1.60
ii  libblkid1    2.36.1-8+deb11u1
ii  libc6    2.31-13+deb11u3
ii  libnvpair3linux  2.1.4-1~bpo11+1
ii  libuuid1 2.36.1-8+deb11u1
ii  libuutil3linux   2.1.4-1~bpo11+1
ii  libzfs4linux 2.1.4-1~bpo11+1
ii  libzpool5linux   2.1.4-1~bpo11+1
ii  python3  3.9.2-3

Versions of packages zfsutils-linux recommends:
ii  lsb-base    11.1.0
ii  zfs-dkms [zfs-modules]  2.1.4-1~bpo11+1
ii  zfs-zed 2.1.4-1~bpo11+1

Versions of packages zfsutils-linux suggests:
pn  nfs-kernel-server   
pn  samba-common-bin    
pn  zfs-initramfs | zfs-dracut  

-- Configuration Files:
/etc/sudoers.d/zfs [Errno 13] Permission denied: '/etc/sudoers.d/zfs'

-- no debconf information

Bug#1012789: Can you check if Img works at all?

[Jeff Epler]

Thanks for tryting LinuxCNC on aarch64. I don't know of anyone presently
using such a configuration.

As far as the "undefined symbol" message:

Please check whether in "wish", it works to "package require Img" or
whether the same error occurs. If it's the same error then may point to a
general problem between libtk-img and libtiff.

As far as the "LIBGL: Error while gathering supported extension
(eglInitialize: EGL_BAD_DISPLAY), default to none" message:

Most UIs for LinuxCNC require working OpenGL. You can try a different UI
such as tklinuxcnc, it doesn't use OpenGL and probably also doesn't use
Img. However, it's much less friendly (IMO)

Jeff

Bug#1012746: libwebkit2gtk-4.0-37: 2.36.3-1~deb11u1 fails messily over glx

[Alberto Garcia]

On Mon, Jun 13, 2022 at 10:32:59AM +0200, Markus Demleitner wrote:

> After the update to 2.36.3-1~deb11u1, webkit-using clients like
> luakit or midori do not work any more through ssh-forwarded X
> connections (as in ssh -X  luakit).

I gave this a quick try using a VM and I can open luakit and midori
just fine, with both WebKit versions... I'll try to see if I can
reproduce this on a different computer.

Berto

Bug#1012804: rocksdb: Please build against liblz4-dev

[Benjamin Drung]

Package: rocksdb
Version: 7.2.2-3
Severity: serious
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
X-Debbugs-Cc: bdr...@ubuntu.com

Dear Maintainer,

The autopkgtest for balboa fails against rocksdb 7.2.2-3 with:

rocksdb_open() failed: `Invalid argument: Compression type LZ4 is not
linked with the binary.`

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

  * Enable LZ4 support (Closes: #1012629)


Thanks for considering the patch.

-- 
Benjamin Drung
Debian & Ubuntu Developer
diff -Nru rocksdb-7.2.2/debian/control rocksdb-7.2.2/debian/control
--- rocksdb-7.2.2/debian/control2022-05-19 23:16:32.0 +0200
+++ rocksdb-7.2.2/debian/control2022-06-14 15:22:00.0 +0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Laszlo Boszormenyi (GCS) 
 Build-Depends: debhelper-compat (= 13), cmake, libgflags-dev, libsnappy-dev,
- libbz2-dev, zlib1g-dev, libzstd-dev
+ libbz2-dev, zlib1g-dev, libzstd-dev, liblz4-dev
 Standards-Version: 4.6.0
 Homepage: https://rocksdb.org/
 
diff -Nru rocksdb-7.2.2/debian/rules rocksdb-7.2.2/debian/rules
--- rocksdb-7.2.2/debian/rules  2022-05-21 19:47:37.0 +0200
+++ rocksdb-7.2.2/debian/rules  2022-06-14 14:31:59.0 +0200
@@ -26,6 +26,7 @@
dh_auto_configure -O--buildsystem=cmake \
 -- \
 -DWITH_BZ2=ON \
+-DWITH_LZ4=ON \
 -DWITH_ZLIB=ON \
 -DWITH_ZSTD=ON \
 -DWITH_SNAPPY=ON \

Bug#1012803: libmariadb-java: Missing AwsIamCredentialPlugin error (libmariadb-java stable(2.7.2-1) and testing(2.7.4-1))

[anonymous]

Package: libmariadb-java
Version: 2.7.4-1
Severity: important
X-Debbugs-Cc: anonymouse743...@gmail.com

Java 17 refuses to use the jdbc driver for mariadb because of a missing
plugin

This error persists on both version 2.7.2-1 and 2.7.4-1, but is
fixed upstream in the jar file downloaded from mariadb.com for versions
3.0.5 and 2.7.5.

Specific error reproduced in java and jshell binaries:

java --module-path 
/usr/share/maven-repo/org/mariadb/jdbc/mariadb-java-client/2.7.4/ --add-modules 
org.mariadb.jdbc -ea TestJDBC 
Error occurred during initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for 
/usr/share/maven-repo/org/mariadb/jdbc/mariadb-java-client/2.7.4/mariadb-java-client-2.7.4.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class 
org.mariadb.jdbc.credential.aws.AwsIamCredentialPlugin not in module

jshell --module-path 
/usr/share/maven-repo/org/mariadb/jdbc/mariadb-java-client/2.7.4/ --add-modules 
org.mariadb.jdbc -ea TestJDBC 
Launching JShell execution engine threw: FailOverExecutionControlProvider: 
FAILED: 0:jdi:hostname(127.0.0.1) --
  Exception: java.lang.IllegalArgumentException: Error occurred during 
initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for 
/usr/share/maven-repo/org/mariadb/jdbc/mariadb-java-client/2.7.4/mariadb-java-client-2.7.4.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class 
org.mariadb.jdbc.credential.aws.AwsIamCredentialPlugin not in module

  
jdk.jshell/jdk.jshell.execution.JdiInitiator.listenTarget(JdiInitiator.java:201)
  
jdk.jshell/jdk.jshell.execution.JdiInitiator.(JdiInitiator.java:111)
  
jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
  
jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
  
jdk.jshell/jdk.jshell.spi.ExecutionControl.generate(ExecutionControl.java:179)
FailOverExecutionControlProvider: FAILED: 1:jdi:launch(true) --
  Exception: java.lang.InternalError: Failed remote launch: 
java.util.concurrent.ExecutionException: com.sun.jdi.connect.VMStartException: 
VM initialization failed for: /usr/lib/jvm/java-17-openjdk-amd64/bin/java 
--add-modules org.mariadb.jdbc --module-path 
/usr/share/maven-repo/org/mariadb/jdbc/mariadb-java-client/2.7.4 -Xdebug 
-Xrunjdwp:transport=dt_socket,address=localhost:50629,suspend=y 
jdk.jshell.execution.RemoteExecutionControl 35629 @ 
com.sun.jdi.CommandLineLaunch (defaults: 
home=/usr/lib/jvm/java-17-openjdk-amd64, options=, main=, suspend=true, 
quote=", vmexec=java) -- {home=home=/usr/lib/jvm/java-17-openjdk-amd64, 
options=options=--add-modules org.mariadb.jdbc --module-path 
/usr/share/maven-repo/org/mariadb/jdbc/mariadb-java-client/2.7.4, 
main=main=jdk.jshell.execution.RemoteExecutionControl 35629, 
suspend=suspend=true, quote=quote=", vmexec=vmexec=java}
  
jdk.jshell/jdk.jshell.execution.JdiInitiator.reportLaunchFail(JdiInitiator.java:300)
  
jdk.jshell/jdk.jshell.execution.JdiInitiator.launchTarget(JdiInitiator.java:141)
  
jdk.jshell/jdk.jshell.execution.JdiInitiator.(JdiInitiator.java:110)
  
jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
  
jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiExecutionControlProvider.java:152)
  cause: java.util.concurrent.ExecutionException: 
com.sun.jdi.connect.VMStartException: VM initialization failed for: 
/usr/lib/jvm/java-17-openjdk-amd64/bin/java --add-modules org.mariadb.jdbc 
--module-path /usr/share/maven-repo/org/mariadb/jdbc/mariadb-java-client/2.7.4 
-Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:50629,suspend=y 
jdk.jshell.execution.RemoteExecutionControl 35629
FailOverExecutionControlProvider: FAILED: 2:jdi --
  Exception: java.lang.IllegalArgumentException: Error occurred during 
initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for 
/usr/share/maven-repo/org/mariadb/jdbc/mariadb-java-client/2.7.4/mariadb-java-client-2.7.4.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class 
org.mariadb.jdbc.credential.aws.AwsIamCredentialPlugin not in module

  
jdk.jshell/jdk.jshell.execution.JdiInitiator.listenTarget(JdiInitiator.java:201)
  
jdk.jshell/jdk.jshell.execution.JdiInitiator.(JdiInitiator.java:111)
  
jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.create(JdiDefaultExecutionControl.java:103)
  
jdk.jshell/jdk.jshell.execution.JdiExecutionControlProvider.generate(JdiE

Bug#1012801: pdf2djvu: Backport for compatibility with Poppler 22.06

[Nathan Pratta Teodosio]

Package: pdf2djvu
Version: 0.9.18.2-1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: nathan.teodo...@canonical.com

Dear Maintainer,

With Poppler 22.06, pdf2djvu no longer builds.

The attached patch is comprised of upstream changes to fix this.


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

Kernel: Linux 5.15.0-33-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.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 pdf2djvu depends on:
ii  djvulibre-bin   3.5.28-2build2
ii  libc6   2.35-0ubuntu3
ii  libdjvulibre21  3.5.28-2build2
ii  libexiv2-27 0.27.5-3ubuntu1
ii  libgcc-s1   12.1.0-2ubuntu1
ii  libgomp112.1.0-2ubuntu1
ii  libgraphicsmagick++-q16-12  1.4+really1.3.38-1
ii  libgraphicsmagick-q16-3 1.4+really1.3.38-1
ii  libpoppler118   22.02.0-3
ii  libstdc++6  12.1.0-2ubuntu1
ii  libuuid12.38-4ubuntu1

pdf2djvu recommends no packages.

Versions of packages pdf2djvu suggests:
ii  poppler-data  0.4.11-1

-- no debconf information
diff -Nru pdf2djvu-0.9.18.2/debian/changelog pdf2djvu-0.9.18.2/debian/changelog
--- pdf2djvu-0.9.18.2/debian/changelog  2022-02-17 14:16:25.0 -0300
+++ pdf2djvu-0.9.18.2/debian/changelog  2022-06-14 09:00:10.0 -0300
@@ -1,3 +1,11 @@
+pdf2djvu (0.9.18.2-2) UNRELEASED; urgency=medium
+
+  * debian/patches/compat-with-poppler-22.06.patch
+- Backport upstream changes need for compatibility with new Poppler
+version.
+
+ -- Nathan Pratta Teodosio   Tue, 14 Jun 2022 
09:00:10 -0300
+
 pdf2djvu (0.9.18.2-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru pdf2djvu-0.9.18.2/debian/patches/compat-with-poppler-22.06.patch 
pdf2djvu-0.9.18.2/debian/patches/compat-with-poppler-22.06.patch
--- pdf2djvu-0.9.18.2/debian/patches/compat-with-poppler-22.06.patch
1969-12-31 21:00:00.0 -0300
+++ pdf2djvu-0.9.18.2/debian/patches/compat-with-poppler-22.06.patch
2022-06-14 09:00:10.0 -0300
@@ -0,0 +1,29 @@
+Description: Backport for Poppler 22.06 compatibility
+Author: Nathan Pratta Teodosio 
+
+--- pdf2djvu-0.9.18.2.orig/pdf-backend.cc
 pdf2djvu-0.9.18.2/pdf-backend.cc
+@@ -130,7 +130,11 @@ void pdf::Environment::set_antialias(boo
+  */
+ 
+ pdf::Document::Document(const std::string &file_name)
+-: ::PDFDoc(new pdf::String(file_name.c_str()), nullptr, nullptr)
++#if POPPLER_VERSION >= 220300
++: ::PDFDoc(std::make_unique(file_name.c_str()))
++#else
++: ::PDFDoc(new pdf::String(file_name.c_str()))
++#endif
+ {
+   if (!this->isOk())
+ throw LoadError();
+--- pdf2djvu-0.9.18.2.orig/pdf2djvu.cc
 pdf2djvu-0.9.18.2/pdf2djvu.cc
+@@ -89,7 +89,7 @@ static int get_page_for_goto_link(pdf::l
+ #endif
+   }
+   else
+-dest.reset(orig_dest->copy());
++dest.reset(new pdf::link::Destination(*orig_dest));
+   if (dest.get() != nullptr)
+   {
+ int page;
diff -Nru pdf2djvu-0.9.18.2/debian/patches/series 
pdf2djvu-0.9.18.2/debian/patches/series
--- pdf2djvu-0.9.18.2/debian/patches/series 1969-12-31 21:00:00.0 
-0300
+++ pdf2djvu-0.9.18.2/debian/patches/series 2022-06-14 08:59:39.0 
-0300
@@ -0,0 +1 @@
+compat-with-poppler-22.06.patch

Bug#1012802: python3-ipykernel: breaks jupyter notebook

[Jörg-Volker Peetz]

Package: python3-ipykernel
Version: 6.13.1-1
Severity: serious

Dear Debian Python Modules Team,

trying to load a jupyter notebook fails with the message

/usr/bin/python3: No module named ipykernel_launcher

Indeed, in the package there is no file
`/usr/lib/python3/dist-packages/ipykernel_launcher.py`
any more. Not any file in `/usr/lib/`.

Regards,
Jörg.


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

Kernel: Linux 5.18.3 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages python3-ipykernel depends on:
ii  python33.9.8-1
ii  python3-ipython7.31.1-1
ii  python3-jupyter-client 7.3.4-1
ii  python3-matplotlib-inline  0.1.3-1
ii  python3-nest-asyncio   1.5.4-1
ii  python3-packaging  21.3-1
ii  python3-psutil 5.9.0-1
ii  python3-tornado6.1.0-3
ii  python3-traitlets  5.2.2-1

python3-ipykernel recommends no packages.

python3-ipykernel suggests no packages.

-- no debconf information

Bug#1012768: Bug#1012785: libgsasl7 depends on outdated gsasl-common version 1.10.0-5

[Felicia P]

On 6/14/22 03:59, Simon Josefsson wrote:


1) Testing contains libgsasl7 1.10.0-5 that has a hard versioned
dependency on gsasl-common 1.10.0-5 for translation files.

2) Unstable now has libgsasl18 1.11.3-2 that depends on gsasl-common
1.11.3-2.



But unstable also still has libgsasl7 1.10.0-5.

Isn't it possible to update libgsasl7 in unstable to 1.11.3-2 to match 
gsasl-common's version or else just update the gsasl-common dependency 
in libgsasl7 to 1.11.3-2 ?

Bug#1012800: ncurses-term: Terminfo entry jfbterm should not be linked to kon

[Steven Shiau]

Package: ncurses-term
Version: 6.3+20220423-2
Severity: normal

Dear Maintainer,

Terminfo entry jfbterm should not be linked to kon. It causes CJK
(Chinese, Japanes, Korean) environment showing weird characters.
The original terminfo entry jfbterm from it's orignal tarball 0.4.7,
could be found here:
https://launchpad.net/ubuntu/+source/jfbterm/0.4.7-9
and it should be created by something like:
TERMINFO=/usr/share/terminfo tic terminfo.jfbterm
If /usr/share/terminfo/j/jfbterm is linked to /usr/share/terminfo/k/kon,
once jfbterm is run with CJK environment,
the window pane separators are all qq and xx, as shown in this
photo:
https://groups.google.com/group/ocs-clonezilla/attach/66972702fe2c/PXL_20220530_160635485.jpg?part=0.2&view=1

The correct one should be like this:
https://clonezilla.org/clonezilla-live/doc/01_Save_disk_image/images/ocs-11-2-save-progress-2.png

Hence it's recommended to extract the file "terminfo.jfbterm" from
jfbterm_0.4.7.orig.tar.gz, and use tic to compile it.
Or please do not link it to kon so that in the CJK environment, the
window pane can be shown correctly.
If user want to use jfbterm, just package it by himself/herself, and the
correct terminfo.jfbterm can be used.
My 2 cents.

Thank you very much.


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

Kernel: Linux 5.18.0-1-amd64 (SMP w/6 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ncurses-term depends on:
ii  ncurses-base  6.3+20220423-2

ncurses-term recommends no packages.

ncurses-term suggests no packages.

-- no debconf information

-- 
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

Bug#1007222: transition: onetbb

[Andrius Merkys]

Hi,

On 2022-06-14 13:05, Graham Inggs wrote:
> I've noticed some binNMUs failed on armel; mathicgb [1] (subsequently
> fixed by maintainer upload) and r-cran-rcppparallel [2].  Both seem to
> fail in a similar way:
> 
> /usr/bin/ld: 
> /usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi/libtbb.so:
> undefined reference to `__atomic_fetch_sub_8'
> /usr/bin/ld: 
> /usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi/libtbb.so:
> undefined reference to `__atomic_load_8'
> 
>   call: dyn.load(path, local = FALSE, now = TRUE)
>   error: unable to load shared object '/usr/lib/arm-linux-gnueabi/libtbb.so':
>   /usr/lib/arm-linux-gnueabi/libtbb.so: undefined symbol: __atomic_fetch_sub_8
> 
> I also noticed the following in the armel build of onetbb [3]:
> 
> dpkg-shlibdeps: warning: symbol __atomic_fetch_sub_8 used by
> debian/libtbb12/usr/lib/arm-linux-gnueabi/libtbb.so.12.5 found in none
> of the libraries
> dpkg-shlibdeps: warning: symbol __atomic_load_8 used by
> debian/libtbb12/usr/lib/arm-linux-gnueabi/libtbb.so.12.5 found in none
> of the libraries
> dpkg-shlibdeps: warning: symbol __atomic_fetch_add_8 used by
> debian/libtbb12/usr/lib/arm-linux-gnueabi/libtbb.so.12.5 found in none
> of the libraries
> 
> Is this something that can/should be fixed in onetbb, or should this
> be fixed in the reverse-dependencies?

My guess is that libtbb12 lacks some shlib dependency, but I have little
idea where __atomic_* symbols come from.

> Additionally, r-cran-rcppparallel failed on mipsel [4] and mips64el
> [5] with the following:
> 
> /usr/bin/ld: cannot find -ltbbmalloc: No such file or directory
> collect2: error: ld returned 1 exit status
> 
> This seems related to #102 [6].  What needs to happen here?

libtbbmalloc2 is not provided for mips* architectures. I guess
bin:r-cran-rcppparallel should be RMed from mips* then.

Best,
Andrius
> [1] https://buildd.debian.org/status/logs.php?pkg=mathicgb&arch=armel
> [2] 
> https://buildd.debian.org/status/logs.php?pkg=r-cran-rcppparallel&arch=armel
> [3] 
> https://buildd.debian.org/status/fetch.php?pkg=onetbb&arch=armel&ver=2021.5.0-10&stamp=1655112619&raw=0
> [4] 
> https://buildd.debian.org/status/logs.php?pkg=r-cran-rcppparallel&arch=mipsel
> [5] 
> https://buildd.debian.org/status/logs.php?pkg=r-cran-rcppparallel&arch=mips64el
> [6] https://bugs.debian.org/102

Bug#711592: Current x86 linux kernel is misconfigured.

[Diederik de Haas]

Control: tag -1 moreinfo

> > On 8 Jun 2013 09:32:48 +0100 Robert de Bath  wrote:
> > > Package: linux-image-686-pae
> > > 
> > > On current Debian kernels the the WCHAN column for procps is NOT
> > > working.
> > > Run this command:
> > > # cat /proc/*/wchan
> > > 
> > > For current Debian kernels you get all zeros
> > 
> > # cat /proc/*/wchan
> > do_epoll_waitdo_selectdo_sys_polldo_sys_polldo_epoll_waitdo_epoll_waitdo_s
> > elect
> > 
> > [IOW: working for me on an amd64 5.18.2-1 kernel]
> 
> I was able to narrow this down a bit with snapshots of each release:
> 
> - broken in squeeze, wheezy, and jessie
> - partly fixed in stretch and buster (wchan shows function names for
>   most sleeping threads, subject to privilege check)
> - broken again in bullseye
> - fully fixed in 5.16.14-1 (wchan shows function names for all sleeping
>   threads, subject to privilege check)
> 
> Given that, I think this can be closed with version 5.16.14-1.

Robert: can you confirm that the issue is fixed for you with a 5.16.14-1 kernel 
or later?
Currently, Stable Backports has version 5.16.12-1~bpo11+1, which should still 
have the issue, but IIUC a new Stable Backports kernel is in the works.


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

Bug#1012723: bullseye-pu: package runc/runc_1.0.0~rc93+ds1-5+deb11u1

[Reinhard Tartler]

On Tue, Jun 14, 2022 at 5:54 AM Emilio Pozuelo Monfort 
wrote:

> On 13/06/2022 19:12, Adam D. Barratt wrote:
> > On Mon, 2022-06-13 at 10:55 +0800, Shengjing Zhu wrote:
> >> X-Debbugs-CC: siret...@debian.org, t...@security.debian.org
> >>
> >> Hi,
> >>
> >> On Sun, Jun 12, 2022 at 05:33:48PM -0400, Reinhard Tartler wrote:
> >>> diff -Nru runc-1.0.0~rc93+ds1/debian/changelog runc-
> >>> 1.0.0~rc93+ds1/debian/changelog
> >>> --- runc-1.0.0~rc93+ds1/debian/changelog2022-06-12
> >>> 14:49:36.0 -0400
> >>> +++ runc-1.0.0~rc93+ds1/debian/changelog2021-05-19
> >>> 14:46:14.0 -0400
> >>> @@ -1,10 +1,3 @@
> >>> -runc (1.0.0~rc93+ds1-5+deb11u1) bullseye; urgency=medium
> >>> -
> >>> -  * Team upload.
> >>> -  * backport upstream patch: Honor seccomp defaultErrnoRet,
> >>> Closes: #1012030
> >>> -
> >>> - -- Reinhard Tartler   Sun, 12 Jun 2022
> >>> 14:49:36 -0400
> >>> -
> >>
> >> Could you include the patch for CVE-2022-29162?
> >>
> >> https://security-tracker.debian.org/tracker/CVE-2022-29162
> >>
> >> If you don't have time, I can work on this later in this week.
> >
> > The Security Tracker says it's not fixed in unstable - is that correct?
> > If so, that needs addressing first before it can be considered for p-u.
>
> The tracker is corrected now, the issue was fixed in 1.1.2.
>
>
Thanks, I've tested the new runc and concluded it works fine. The effective
(additional) security patch reads:

--- a/exec.go
+++ b/exec.go
@@ -193,7 +193,6 @@
  if caps := context.StringSlice("cap"); len(caps) > 0 {
  for _, c := range caps {
  p.Capabilities.Bounding = append(p.Capabilities.Bounding, c)
- p.Capabilities.Inheritable = append(p.Capabilities.Inheritable, c)
  p.Capabilities.Effective = append(p.Capabilities.Effective, c)
  p.Capabilities.Permitted = append(p.Capabilities.Permitted, c)
  p.Capabilities.Ambient = append(p.Capabilities.Ambient, c)
--- a/libcontainer/README.md
+++ b/libcontainer/README.md
@@ -92,22 +92,6 @@
  "CAP_KILL",
  "CAP_AUDIT_WRITE",
  },
- Inheritable: []string{
- "CAP_CHOWN",
- "CAP_DAC_OVERRIDE",
- "CAP_FSETID",
- "CAP_FOWNER",
- "CAP_MKNOD",
- "CAP_NET_RAW",
- "CAP_SETGID",
- "CAP_SETUID",
- "CAP_SETFCAP",
- "CAP_SETPCAP",
- "CAP_NET_BIND_SERVICE",
- "CAP_SYS_CHROOT",
- "CAP_KILL",
- "CAP_AUDIT_WRITE",
- },
  Permitted: []string{
  "CAP_CHOWN",
  "CAP_DAC_OVERRIDE",
--- a/libcontainer/integration/exec_test.go
+++ b/libcontainer/integration/exec_test.go
@@ -412,7 +412,6 @@
  pconfig.Capabilities.Bounding = append(config.Capabilities.Bounding,
"CAP_NET_ADMIN")
  pconfig.Capabilities.Permitted = append(config.Capabilities.Permitted,
"CAP_NET_ADMIN")
  pconfig.Capabilities.Effective = append(config.Capabilities.Effective,
"CAP_NET_ADMIN")
- pconfig.Capabilities.Inheritable =
append(config.Capabilities.Inheritable, "CAP_NET_ADMIN")
  err = container.Run(&pconfig)
  ok(t, err)

@@ -1593,7 +1592,6 @@
  pconfig2.Capabilities.Bounding = append(config.Capabilities.Bounding,
"CAP_SYS_ADMIN")
  pconfig2.Capabilities.Permitted = append(config.Capabilities.Permitted,
"CAP_SYS_ADMIN")
  pconfig2.Capabilities.Effective = append(config.Capabilities.Effective,
"CAP_SYS_ADMIN")
- pconfig2.Capabilities.Inheritable =
append(config.Capabilities.Inheritable, "CAP_SYS_ADMIN")

  err = container.Run(pconfig2)
  stdinR2.Close()
--- a/libcontainer/integration/template_test.go
+++ b/libcontainer/integration/template_test.go
@@ -69,22 +69,6 @@
  "CAP_KILL",
  "CAP_AUDIT_WRITE",
  },
- Inheritable: []string{
- "CAP_CHOWN",
- "CAP_DAC_OVERRIDE",
- "CAP_FSETID",
- "CAP_FOWNER",
- "CAP_MKNOD",
- "CAP_NET_RAW",
- "CAP_SETGID",
- "CAP_SETUID",
- "CAP_SETFCAP",
- "CAP_SETPCAP",
- "CAP_NET_BIND_SERVICE",
- "CAP_SYS_CHROOT",
- "CAP_KILL",
- "CAP_AUDIT_WRITE",
- },
  Ambient: []string{
  "CAP_CHOWN",
  "CAP_DAC_OVERRIDE",
--- a/libcontainer/specconv/example.go
+++ b/libcontainer/specconv/example.go
@@ -41,11 +41,6 @@
  "CAP_KILL",
  "CAP_NET_BIND_SERVICE",
  },
- Inheritable: []string{
- "CAP_AUDIT_WRITE",
- "CAP_KILL",
- "CAP_NET_BIND_SERVICE",
- },
  Ambient: []string{
  "CAP_AUDIT_WRITE",
  "CAP_KILL",


Full updated debdiff attached to this email


-- 
regards,
Reinhard


runc_1.0.0~rc93+ds1-5+deb11u2.debdiff
Description: Binary data

Bug#1012666: ITS: wget2

[Noël Köthe]

Hello Boyuan,

Am Samstag, dem 11.06.2022 um 09:10 -0400 schrieb Boyuan Yang:

> After looking into the package you maintain (wget2, 
> https://tracker.debian.org/pkg/wget2), I found that this package
> received no maintainer updates in the past 4 years and missed several
> upstream
> releases. The request of making new uploads
> at https://bugs.debian.org/951354
> was not solved as well. As a result, I am filing an ITS (Intent to
> Salvage)
> request against your package according to section 5.12 in Debian's
> Developers'
> Reference [1].
> 
> My current plan is to package the latest upstream release (2.0.1) and
> clean up existing bugs.
> 
> Please let me know whether you are still willing to maintain this
> package. According to the criteria listed at [2], I will upload a
> Non-maintainer Upload (NMU) of this package onto DELAYED/7 after 21
> days (July 02, 2022) to continue with the package salvaging. If you
> find it necessary to pause the ITS process, please let me know
> immediately by replying this bug report.

Thank you for your email.
I will be able to work on the package in July (Debconf22) but you are
welcome to do a NMU before.:) A DELAYED/2 will be fine for me.

Thank you for your help and work.

-- 
Noël Köthe 
Debian GNU/Linux, www.debian.org


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

Bug#1012548: libwebkit2gtk-4.1-0: Offline renderer SIGSEGV on i386

[Alberto Garcia]

reopen 1012548
tags 1012548 - unreproducible wontfix
thanks

On Mon, Jun 13, 2022 at 11:00:03AM +0200, karogyoker wrote:

> I think the solution is not to use the code where the ORing happens
> with 0x8040 (in case of i386 releases because this combination is
> not supported by hardware). For 32 bit CPUs the manual flushing must
> be used (the "FIXME: worst case" part in the code).

But is this for all i386 CPUs or only for older models? How come this
never crashed before?

Berto

Bug#1012565: Bug#1012798: Acknowledgement (libecap: diff for NMU version 1.0.1-3.3 fix FTBFS on riscv arch)

[肖盛文]

Control:  forcemerge 1012565 1012798


O, I make a mistake when use nmudiff to report bug.

#1012798 should not open as a new bug, it should follow #1012565.

sorry!

在 2022/6/14 17:45, Debian Bug Tracking System 写道:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1012798: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012798.






OpenPGP_signature
Description: OpenPGP digital signature

Bug#1007222: transition: onetbb

[Graham Inggs]

Hi

I've noticed some binNMUs failed on armel; mathicgb [1] (subsequently
fixed by maintainer upload) and r-cran-rcppparallel [2].  Both seem to
fail in a similar way:

/usr/bin/ld: 
/usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi/libtbb.so:
undefined reference to `__atomic_fetch_sub_8'
/usr/bin/ld: 
/usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi/libtbb.so:
undefined reference to `__atomic_load_8'

  call: dyn.load(path, local = FALSE, now = TRUE)
  error: unable to load shared object '/usr/lib/arm-linux-gnueabi/libtbb.so':
  /usr/lib/arm-linux-gnueabi/libtbb.so: undefined symbol: __atomic_fetch_sub_8

I also noticed the following in the armel build of onetbb [3]:

dpkg-shlibdeps: warning: symbol __atomic_fetch_sub_8 used by
debian/libtbb12/usr/lib/arm-linux-gnueabi/libtbb.so.12.5 found in none
of the libraries
dpkg-shlibdeps: warning: symbol __atomic_load_8 used by
debian/libtbb12/usr/lib/arm-linux-gnueabi/libtbb.so.12.5 found in none
of the libraries
dpkg-shlibdeps: warning: symbol __atomic_fetch_add_8 used by
debian/libtbb12/usr/lib/arm-linux-gnueabi/libtbb.so.12.5 found in none
of the libraries

Is this something that can/should be fixed in onetbb, or should this
be fixed in the reverse-dependencies?

Additionally, r-cran-rcppparallel failed on mipsel [4] and mips64el
[5] with the following:

/usr/bin/ld: cannot find -ltbbmalloc: No such file or directory
collect2: error: ld returned 1 exit status

This seems related to #102 [6].  What needs to happen here?

Regards
Graham


[1] https://buildd.debian.org/status/logs.php?pkg=mathicgb&arch=armel
[2] https://buildd.debian.org/status/logs.php?pkg=r-cran-rcppparallel&arch=armel
[3] 
https://buildd.debian.org/status/fetch.php?pkg=onetbb&arch=armel&ver=2021.5.0-10&stamp=1655112619&raw=0
[4] 
https://buildd.debian.org/status/logs.php?pkg=r-cran-rcppparallel&arch=mipsel
[5] 
https://buildd.debian.org/status/logs.php?pkg=r-cran-rcppparallel&arch=mips64el
[6] https://bugs.debian.org/102

Bug#1012723: bullseye-pu: package runc/runc_1.0.0~rc93+ds1-5+deb11u1

[Emilio Pozuelo Monfort]

On 13/06/2022 19:12, Adam D. Barratt wrote:

On Mon, 2022-06-13 at 10:55 +0800, Shengjing Zhu wrote:

X-Debbugs-CC: siret...@debian.org, t...@security.debian.org

Hi,

On Sun, Jun 12, 2022 at 05:33:48PM -0400, Reinhard Tartler wrote:

diff -Nru runc-1.0.0~rc93+ds1/debian/changelog runc-
1.0.0~rc93+ds1/debian/changelog
--- runc-1.0.0~rc93+ds1/debian/changelog2022-06-12
14:49:36.0 -0400
+++ runc-1.0.0~rc93+ds1/debian/changelog2021-05-19
14:46:14.0 -0400
@@ -1,10 +1,3 @@
-runc (1.0.0~rc93+ds1-5+deb11u1) bullseye; urgency=medium
-
-  * Team upload.
-  * backport upstream patch: Honor seccomp defaultErrnoRet,
Closes: #1012030
-
- -- Reinhard Tartler   Sun, 12 Jun 2022
14:49:36 -0400
-


Could you include the patch for CVE-2022-29162?

https://security-tracker.debian.org/tracker/CVE-2022-29162

If you don't have time, I can work on this later in this week.


The Security Tracker says it's not fixed in unstable - is that correct?
If so, that needs addressing first before it can be considered for p-u.


The tracker is corrected now, the issue was fixed in 1.1.2.

Cheers,
Emilio

Bug#1007222: transition: onetbb

[Andrius Merkys]

Hi Mo,

On 2022-06-13 18:54, M. Zhou wrote:
> Thank you so much for the help! I was still looking for time slot
> to login into a build server to deal with this hard-to-build package.

Thank you for updating the onetbb package! Building and uploading it was
not that much of a work. Admittedly, ratt-rebuilding all reverse
dependencies took quite some time and effort. I became aware of Lucas's
collab-qa-tools [1] only since, this could have saved some time.

> Nowadays I sort of started to dislike packages that my laptop cannot
> easily build within a few minutes :-)

I do not mind running unstable VM on my desktop to do builds in the
background. But yes, life is so much easier with smaller packages :)

[1] https://salsa.debian.org/lucas/collab-qa-tools

Best wishes,
Andrius

Bug#1012793: libpyside2-py3-5.15 uninstallable on unstable: unsatisfiable Depends

[Julian Gilbey]

On Tue, Jun 14, 2022 at 10:43:34AM +0300, Dmitry Shachnev wrote:
> Hi Julian!
> 
> On Tue, Jun 14, 2022 at 08:37:38AM +0100, Julian Gilbey wrote:
> > Package: libpyside2-py3-5.15
> > Version: 5.15.2-2.1
> > Severity: serious
> > 
> > This package depends on qtbase-abi-5-15-2 and
> > qtdeclarative-abi-5-15-2, but libqt5core5a now Provides:
> > qtbase-abi-5-15-4 and libqt5qml5 now Provides:
> > qtdeclarative-abi-5-15-4.  The dependencies of this package need
> > updating to bring them into sync.
> 
> We are now in a middle of Qt 5.15.4 transition [1][2]. Wait a couple of days,
> pyside2 will be rebuilt by the Release team.
> 
> [1]: https://release.debian.org/transitions/html/qtbase-abi-5-15-4.html
> [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007170

Hi Dmitry,

Amazing, thanks!

   Julian

Bug#1012798: libecap: diff for NMU version 1.0.1-3.3 fix FTBFS on riscv arch

[肖盛文]

Package: libecap
Control: tags 1012565 + pending

Dear maintainer,

I've prepared an NMU for libecap (versioned as 1.0.1-3.3) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

I'd upload to mentors.d.n.

Welcome to review and upload.

-
Your upload of the package 'libecap' to mentors.debian.net was
successful. Others can now see it. The URL of your package is:

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

The respective dsc file can be found at:


https://mentors.debian.net/debian/pool/main/libe/libecap/libecap_1.0.1-3.3.dsc

Regards.
xiao sheng wen

diff -Nru libecap-1.0.1/debian/changelog libecap-1.0.1/debian/changelog
--- libecap-1.0.1/debian/changelog  2016-10-04 05:22:11.0 +0800
+++ libecap-1.0.1/debian/changelog  2022-06-14 15:09:04.0 +0800
@@ -1,3 +1,12 @@
+libecap (1.0.1-3.3) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "ftbfs on riscv64 (error: some symbols or patterns disappeared
+in the symbols file)", update d/libecap3.symbols (Closes: #1012565)
+  * d/control: B-D add pkg-kde-tools
+
+ -- xiao sheng wen   Tue, 14 Jun 2022 15:09:04 +0800
+
 libecap (1.0.1-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libecap-1.0.1/debian/control libecap-1.0.1/debian/control
--- libecap-1.0.1/debian/control2016-09-27 06:24:40.0 +0800
+++ libecap-1.0.1/debian/control2022-06-14 15:09:04.0 +0800
@@ -1,7 +1,8 @@
 Source: libecap
 Priority: extra
 Maintainer: Luigi Gangitano 
-Build-Depends: debhelper (>= 9), autotools-dev, cdbs, dh-autoreconf
+Build-Depends: debhelper (>= 9), autotools-dev, cdbs, dh-autoreconf,
+ pkg-kde-tools,
 Standards-Version: 3.9.8
 Section: libs
 Homepage: http://www.e-cap.org/Downloads
diff -Nru libecap-1.0.1/debian/libecap3.symbols 
libecap-1.0.1/debian/libecap3.symbols
--- libecap-1.0.1/debian/libecap3.symbols   2016-10-04 05:22:11.0 
+0800
+++ libecap-1.0.1/debian/libecap3.symbols   2022-06-12 09:58:02.0 
+0800
@@ -1,4 +1,4 @@
-# SymbolsHelper-Confirmed: 1.0.1 amd64 armhf i386 powerpc
+# SymbolsHelper-Confirmed: 1.0.1 amd64 arm64 armel armhf i386 mips64el mipsel 
powerpc ppc64el riscv64 s390x
 libecap.so.3 libecap3 #MINVER#
  _ZN7libecap10methodHeadE@Base 1.0.1
  _ZN7libecap10methodPostE@Base 1.0.1
@@ -80,20 +80,34 @@
  _ZNK7libecap8BodySize7badSizeEv@Base 1.0.1
  (optional=templinst)_ZNSt3tr110shared_ptrIN7libecap4host4HostEED1Ev@Base 1.0.1
  (optional=templinst)_ZNSt3tr110shared_ptrIN7libecap4host4HostEED2Ev@Base 1.0.1
- 
(optional=templinst)_ZNSt3tr116_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base
 1.0.1
- 
(optional=templinst)_ZNSt3tr116_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE10_M_releaseEv@Base
 1.0.1
- 
(optional=templinst)_ZNSt3tr121_Sp_counted_base_implIPN7libecap20StdStringAreaDetailsENS_11_Sp_deleterIS2_EELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv@Base
 1.0.1
- 
(optional=templinst)_ZNSt3tr121_Sp_counted_base_implIPN7libecap20StdStringAreaDetailsENS_11_Sp_deleterIS2_EELN9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_info@Base
 1.0.1
- 
(optional=templinst)_ZNSt3tr121_Sp_counted_base_implIPN7libecap20StdStringAreaDetailsENS_11_Sp_deleterIS2_EELN9__gnu_cxx12_Lock_policyE2EED0Ev@Base
 1.0.1
- 
(optional=templinst)_ZNSt3tr121_Sp_counted_base_implIPN7libecap20StdStringAreaDetailsENS_11_Sp_deleterIS2_EELN9__gnu_cxx12_Lock_policyE2EED1Ev@Base
 1.0.1
- 
(optional=templinst)_ZNSt3tr121_Sp_counted_base_implIPN7libecap20StdStringAreaDetailsENS_11_Sp_deleterIS2_EELN9__gnu_cxx12_Lock_policyE2EED2Ev@Base
 1.0.1
- 
(optional=templinst)_ZNSt3tr121_Sp_counted_base_implIPN7libecap7adapter7ServiceENS_11_Sp_deleterIS3_EELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv@Base
 1.0.1
- 
(optional=templinst)_ZNSt3tr121_Sp_counted_base_implIPN7libecap7adapter7ServiceENS_11_Sp_deleterIS3_EELN9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_info@Base
 1.0.1
- 
(optional=templinst)_ZNSt3tr121_Sp_counted_base_implIPN7libecap7adapter7ServiceENS_11_Sp_deleterIS3_EELN9__gnu_cxx12_Lock_policyE2EED0Ev@Base
 1.0.1
- 
(optional=templinst)_ZNSt3tr121_Sp_counted_base_implIPN7libecap7adapter7ServiceENS_11_Sp_deleterIS3_EELN9__gnu_cxx12_Lock_policyE2EED1Ev@Base
 1.0.1
- 
(optional=templinst)_ZNSt3tr121_Sp_counted_base_implIPN7libecap7adapter7ServiceENS_11_Sp_deleterIS3_EELN9__gnu_cxx12_Lock_policyE2EED2Ev@Base
 1.0.1
+ (optional=templinst|arch=armel 
riscv64)_ZNSt3tr116_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_destroyEv@Base
 1.0.1
+ (optional=templinst|arch=armel 
riscv64)_ZNSt3tr116_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_releaseEv@Base
 1.0.1
+ (optional=templinst|arch=!armel 
!riscv64)_ZNSt3tr116_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base
 1.0.1
+ (optional=templinst|arch=!armel 
!riscv64)_ZNSt3tr116_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE10_M_releaseEv@Base
 1.0.1
+ (optional=templinst|arch=armel 
riscv64)_ZNSt3tr121_Sp_c

Bug#1012797: iptables-1.8.2-4: Segmentation fault caused by iptables with no matching rules.

[root]

Package: iptables-1.8.2-4
Version: iptables 1.8.2-4
Severity: normal

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


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

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

Segmentation fault caused by iptables with no matching rules.


# iptables -D INPUT -s 10.0.0.1 -j DENY

Segmentation fault (core dumped) 

Jun 14 09:58:45 dux kernel: [6724455.363431] iptables[12347]: segfault at 2 ip 
7f9137f467be sp 7ffed4f99f58 error 4 in
libc-2.28.so[7f9137ed8000+147000]

Bug#1012796: ITP: golang-github-cli-go-gh -- Go module for interacting with gh and the GitHub API from the command line

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-cli-go-gh
  Version : 0.0.3-1
  Upstream Author : GitHub Inc.
* URL : https://github.com/cli/go-gh
* License : Expat
  Programming Lang: Go
  Description : Go module for interacting with gh and the GitHub API from 
the command line

 go-gh is a Go module for CLI Go applications and gh extensions
 that want a convenient way to interact with gh, and the GitHub API
 using gh environment configuration.
 .
 go-gh supports multiple ways of getting access to gh functionality:
 .
  * Helpers that automatically read a gh config to authenticate
themselves
  * gh.Exec shells out to a gh install on your machine
 .
 If you'd like to use go-gh on systems without gh installed and
 configured, you can provide custom authentication details to the go-gh
 API helpers.


Reason for packaging: Needed by gh v2.12.1 and up

Bug#1012565: libecap3: ftbfs on riscv64 (error: some symbols or patterns disappeared in the symbols file)

[肖盛文]

control: severity -1 important



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011838: xonsh: FTBFS: ModuleNotFoundError: No module named 'attr'

[Anthony Fok]

Control: reassign -1 python3-myst-parser
Control: affects -1 + xonsh
Control: found -1 python3-myst-parser/0.16.1-1
Control: found -1 python3-myst-parser/0.16.1-2
Control: found -1 python3-myst-parser/0.16.1-3
Control: found -1 python3-myst-parser/0.16.1-4
Control: fixed -1 python3-myst-parser/0.17.2-1

On Thu, May 26, 2022 at 1:26 PM Lucas Nussbaum  wrote:
>
> Source: xonsh
> Version: 0.12.4+dfsg-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220525 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > make[2]: Entering directory '/<>/docs'
> > sphinx-build -b html -d _build/doctrees   . _build/html
> > Running Sphinx v4.5.0
> >
> > Exception occurred:
> >   File "/usr/lib/python3/dist-packages/myst_parser/main.py", line 3, in 
> > 
> > import attr
> > ModuleNotFoundError: No module named 'attr'
> > The full traceback has been saved in /tmp/sphinx-err-f46ojpq1.log, if you 
> > want to report the issue to the developers.
> > Please also report this if it was a user error, so that a better error 
> > message can be provided next time.
> > A bug report can be filed in the tracker at 
> > . Thanks!
> > make[2]: *** [Makefile:39: html] Error 2
>
>
> The full build log is available from:
> http://qa-logs.debian.net/2022/05/25/xonsh_0.12.4+dfsg-1_unstable.log
>
> All bugs filed during this archive rebuild are listed at:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20220525;users=lu...@debian.org
> or:
> https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20220525&fusertaguser=lu...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> If you reassign this bug to another package, please marking it as 
> 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
>
> If you fail to reproduce this, please provide a build log and diff it with 
> mine
> so that we can identify if something relevant changed in the meantime.

As it turns out, this is not a bug in xonsh, but rather in
python3-myst-parser 0.16.1 where
the line "from attr import Attribute" was added, but without
dependency on the python3-attr.
xonsh became a "victim" of that missing dependency.

The good news is that the xonsh FTBFS problem is fixed with the upload
of python3-myst-parser 0.17.2-1 where upstream did this:

- ♻️ REFACTOR: Replace `attrs` by `dataclasses` for configuration (#557)

The 'attr' module is no longer needed, hence no more FTBFS for xonsh!

Special thanks to Emmanuel Arias and Bastian Germann for the upload of
myst-parser 0.17.2-1 which resolves this bug.

I am hereby reassigning this bug to python3-myst-parser, and will
close the bug shortly after.

Cheers,

Anthony Fok

Bug#1012786: libcamera: Fails to build from source

[Christopher Obbard]

Hi!

I propose a patch to potentially fix this: 
https://salsa.debian.org/multimedia-team/libcamera/-/merge_requests/6


The use of the depreciated function could even be fixed in upstream, it 
could be worth updating the package from upstream?


@Andrew: can you review the patch above? Also, I can help with updating 
from upstream if you would like.


Chris

On 14/06/2022 03:02, Lisandro Damián Nicanor Pérez Meyer wrote:

Source: libcamera
Version: 0~git20200629+e7aa92a-8
Severity: serious
Justification: Fails to build form source
X-Debbugs-Cc: lisan...@debian.org

Trying to fix a bug in libcamera I found it's currently failing to build
from source. Seems it's taking deprecation warnings as errors.

Log follows. Kinds regards, Lisandro.

../test/gstreamer/gstreamer_multi_stream_test.cpp: In member function ‘virtual 
int GstreamerMultiStreamTest::run()’:
../test/gstreamer/gstreamer_multi_stream_test.cpp:90:76: error: ‘GstPad* 
gst_element_get_request_pad(GstElement*, const gchar*)’ is deprecated: Use 
'gst_element_request_pad_simple' instead [-Werror=deprecated-declarations]
90 | g_autoptr(GstPad) request_pad = 
gst_element_get_request_pad(libcameraSrc_, "src_%u");
   | 
~~~^
In file included from /usr/include/gstreamer-1.0/gst/gstbin.h:27,
  from /usr/include/gstreamer-1.0/gst/gst.h:35,
  from ../test/gstreamer/gstreamer_multi_stream_test.cpp:13:
/usr/include/gstreamer-1.0/gst/gstelement.h:1042:25: note: declared here
  1042 | GstPad* gst_element_get_request_pad (GstElement 
*element, const gchar *name);
   | ^~~
cc1plus: all warnings being treated as errors
[246/390] /usr/bin/meson --internal symbolextractor 
'/<>/obj-x86_64-linux-gnu' 
src/libcamera/base/libcamera-base.so.0.0.0 src/libcamera/base/libcamera-base.so.0.0.0 
src/libcamera/base/libcamera-base.so.0.0.0.p/libcamera-base.so.0.0.0.symbols
[247/390] ccache c++ -Itest/stream/stream_formats.p -Itest/stream -I../test/stream 
-Itest/libtest -I../test/libtest -Iinclude -I../include -Iinclude/libcamera 
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor 
-Wextra -Werror -std=c++17 -O0 -Wshadow -include config.h -g -O2 
'-ffile-prefix-map=/<>=.' -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ 
test/stream/stream_formats.p/stream_formats.cpp.o -MF 
test/stream/stream_formats.p/stream_formats.cpp.o.d -o 
test/stream/stream_formats.p/stream_formats.cpp.o -c ../test/stream/stream_formats.cpp
[248/390] ccache c++ -Itest/serialization/control_serialization.p -Itest/serialization 
-I../test/serialization -Itest/libtest -I../test/libtest -Iinclude -I../include 
-Iinclude/libcamera/ipa -Iinclude/libcamera -fdiagnostics-color=always 
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Werror -std=c++17 
-O0 -Wshadow -include config.h -g -O2 '-ffile-prefix-map=/<>=.' 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
-DLIBCAMERA_BASE_PRIVATE -MD -MQ 
test/serialization/control_serialization.p/serialization_test.cpp.o -MF 
test/serialization/control_serialization.p/serialization_test.cpp.o.d -o 
test/serialization/control_serialization.p/serialization_test.cpp.o -c 
../test/serialization/serialization_test.cpp
[249/390] ccache c++ -Itest/serialization/ipa_data_serializer_test.p -Itest/serialization 
-I../test/serialization -Itest/libtest -I../test/libtest -Iinclude -I../include 
-Iinclude/libcamera/ipa -Iinclude/libcamera -fdiagnostics-color=always 
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Werror -std=c++17 
-O0 -Wshadow -include config.h -g -O2 '-ffile-prefix-map=/<>=.' 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
-DLIBCAMERA_BASE_PRIVATE -MD -MQ 
test/serialization/ipa_data_serializer_test.p/serialization_test.cpp.o -MF 
test/serialization/ipa_data_serializer_test.p/serialization_test.cpp.o.d -o 
test/serialization/ipa_data_serializer_test.p/serialization_test.cpp.o -c 
../test/serialization/serialization_test.cpp
[250/390] ccache c++ -Itest/serialization/control_serialization.p -Itest/serialization 
-I../test/serialization -Itest/libtest -I../test/libtest -Iinclude -I../include 
-Iinclude/libcamera/ipa -Iinclude/libcamera -fdiagnostics-color=always 
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Werror -std=c++17 
-O0 -Wshadow -include config.h -g -O2 '-ffile-prefix-map=/<>=.' 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
-DLIBCAMERA_BASE_PRIVATE -MD -MQ 
test/serialization/control_serialization.p/control_serialization.cpp.o -MF 
test/serialization/control_serialization.p/control_serialization.cpp.o.d -o 
test/serialization/control_serialization.p/co

Bug#1012658: redis: cjson not usable in current sid release

[Chris Lamb]

Chris Lamb wrote:

> I'm almost certain that this is related to the fix for #1005787 which
> is not present in that "old" version.

Ah, my mistake: I think it's due to the Debian packaging reverting to
using the bundled version of Lua over the Debian-provided one. (This
is needed due to it having additional security features needed to
address CVE-2022-24735 and CVE-2022-24736.)

This means it is not finding the Debian version of
liblua5.1-cjson.so.0 or liblua5.1-bitop.so.0 under /lib. It works with
the Lua modules that we don't try and use the Debian version of, for
example:

  $ redis-cli EVAL "cmsgpack.pack({})" 0
  (nil)

I suspect there is some kind of require/import path that needs to be
adjusted for the bundled Lua (which is preconfigured to point under
/lib for Debian's shipped Lua). Or, we might have to revert entirely to
using the bundled cjson and bitop modules. :(


Regards,

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

Bug#1012794: linux-image-5.18.0-1-amd64: Please enable CONFIG_SND_HDA_SCODEC_CS35L41_I2C

[Göran Weinholt]

Package: src:linux
Version: 5.18.2-1
Severity: wishlist
X-Debbugs-Cc: weinh...@debian.org

Dear Maintainer,

Please enable the CONFIG_SND_HDA_SCODEC_CS35L41_I2C option in the
kernel. It is needed for the speakers to work on this laptop,
according to the discussion at
.


-- Package-specific info:
** Version:
Linux version 5.18.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.3.0-3) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38) #1 SMP PREEMPT_DYNAMIC 
Debian 5.18.2-1 (2022-06-06)

** Command line:
BOOT_IMAGE=/vmlinuz-5.18.0-1-amd64 root=/dev/mapper/hardtack-root ro quiet

** Tainted: DW (640)
 * kernel died recently, i.e. there was an OOPS or BUG
 * kernel issued warning

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

Completely unrelated to this wishlist bug, here's an oops that
happened just now. I blame resuming after hibernate for this, but who
knows.

[49437.499381] BUG: unable to handle page fault for address: 0020
[49437.499386] #PF: supervisor read access in kernel mode
[49437.499387] #PF: error_code(0x) - not-present page
[49437.499388] PGD 30014067 P4D 30014067 PUD 0 
[49437.499390] Oops:  [#2] PREEMPT SMP NOPTI
[49437.499392] CPU: 10 PID: 138670 Comm: bluetoothd Tainted: G  D W 
5.18.0-1-amd64 #1  Debian 5.18.2-1
[49437.499394] Hardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN50WW 11/24/2021
[49437.499395] RIP: 0010:__crypto_alg_lookup+0x3a/0x100
[49437.499399] Code: 83 ec 08 4c 8b 3d c6 7c 56 01 49 81 ff 30 b7 fc 92 0f 84 
cd 00 00 00 c7 44 24 04 fe ff ff ff 49 89 fd 41 89 f4 89 d5 45 31 f6 <41> 8b 4f 
20 44 89 e0 31 c8 89 ce 21 e8 83 e6 60 09 f0 0f 85 80 00
[49437.499400] RSP: 0018:af4143ea7d60 EFLAGS: 00010283
[49437.499402] RAX: 000b RBX:  RCX: 040e
[49437.499403] RDX: 0063 RSI:  RDI: 9e5a02988c80
[49437.499404] RBP: 240f R08:  R09: 7fff6739dbc0
[49437.499404] R10: 000e R11:  R12: 0405
[49437.499405] R13: af4143ea7ea0 R14:  R15: 
[49437.499406] FS:  7f7bd0f757c0() GS:9e5d1de8() 
knlGS:
[49437.499407] CS:  0010 DS:  ES:  CR0: 80050033
[49437.499408] CR2: 0020 CR3: 0002a986a000 CR4: 00750ee0
[49437.499409] PKRU: 5554
[49437.499410] Call Trace:
[49437.499412]  
[49437.499414]  crypto_alg_lookup+0x57/0x110
[49437.499416]  crypto_alg_mod_lookup+0x41/0x220
[49437.499417]  crypto_alloc_tfm_node+0x4c/0xd0
[49437.499419]  ? try_module_get.part.0+0x4e/0xc0
[49437.499423]  alg_bind+0x84/0x140 [af_alg]
[49437.499426]  __sys_bind+0xd3/0xf0
[49437.499429]  __x64_sys_bind+0x14/0x20
[49437.499430]  do_syscall_64+0x3b/0xc0
[49437.499433]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[49437.499436] RIP: 0033:0x7f7bd15d9987
[49437.499438] Code: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 15 e1 24 0d 00 f7 
d8 64 89 02 b8 ff ff ff ff eb bc 0f 1f 44 00 00 b8 31 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d b9 24 0d 00 f7 d8 64 89 01 48
[49437.499439] RSP: 002b:7fff6739dbb8 EFLAGS: 0202 ORIG_RAX: 
0031
[49437.499440] RAX: ffda RBX: 555fe985eac0 RCX: 7f7bd15d9987
[49437.499440] RDX: 0058 RSI: 7fff6739dbc0 RDI: 000e
[49437.499441] RBP: 000e R08: 0026 R09: 555fe9856350
[49437.499442] R10: 0014 R11: 0202 R12: 555fe985a970
[49437.499442] R13:  R14: 555fe84b6300 R15: 555fe985e370
[49437.499444]  
[49437.499444] Modules linked in: authenc echainiv esp4 tun uinput ipheth 
apple_mfi_fastcharge rfcomm hid_logitech_hidpp cp210x hid_microsoft 
hid_logitech_dj ff_memless usbserial snd_usb_audio snd_usbmidi_lib snd_rawmidi 
snd_seq_device cdc_ether usbnet r8152 mii rtl2832_sdr r820t rtl2832 i2c_mux 
dvb_usb_rtl28xxu dvb_usb_v2 dvb_core xfrm_user xfrm_algo l2tp_ppp l2tp_netlink 
l2tp_core ip6_udp_tunnel udp_tunnel pppox ppp_generic slhc ctr ccm qrtr cmac 
algif_hash algif_skcipher af_alg bnep binfmt_misc nls_ascii nls_cp437 vfat fat 
intel_rapl_msr intel_rapl_common btusb btrtl btbcm btintel btmtk edac_mce_amd 
iwlmvm bluetooth mac80211 snd_hda_codec_realtek jitterentropy_rng kvm_amd 
snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi libarc4 nouveau uvcvideo 
sha512_ssse3 snd_hda_intel kvm videobuf2_vmalloc videobuf2_memops 
snd_intel_dspcfg iwlwifi mxm_wmi snd_intel_sdw_acpi videobuf2_v4l2 
sha512_generic drm_dp_helper snd_hda_codec videobuf2_common irqbypass cec 
videodev drbg rapl joydev
[49437.499481]  snd_hda_core rc_core cfg80211 snd_hwdep ansi_cprng 
drm_ttm_helper mc snd_pcm wdat_wdt ttm pcspkr serio_raw efi_pstore ecdh_generic 
snd_timer ecc drm_kms_helper wmi_bmof snd hid_multitouch ccp sp5100_tco 
i2c_algo_bit ucsi_acpi soundcore watchdog k10temp typec_ucsi rng_core roles 
ide

Bug#1012793: libpyside2-py3-5.15 uninstallable on unstable: unsatisfiable Depends

[Dmitry Shachnev]

Hi Julian!

On Tue, Jun 14, 2022 at 08:37:38AM +0100, Julian Gilbey wrote:
> Package: libpyside2-py3-5.15
> Version: 5.15.2-2.1
> Severity: serious
> 
> This package depends on qtbase-abi-5-15-2 and
> qtdeclarative-abi-5-15-2, but libqt5core5a now Provides:
> qtbase-abi-5-15-4 and libqt5qml5 now Provides:
> qtdeclarative-abi-5-15-4.  The dependencies of this package need
> updating to bring them into sync.

We are now in a middle of Qt 5.15.4 transition [1][2]. Wait a couple of days,
pyside2 will be rebuilt by the Release team.

[1]: https://release.debian.org/transitions/html/qtbase-abi-5-15-4.html
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007170

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1012793: libpyside2-py3-5.15 uninstallable on unstable: unsatisfiable Depends

[Julian Gilbey]

Package: libpyside2-py3-5.15
Version: 5.15.2-2.1
Severity: serious

This package depends on qtbase-abi-5-15-2 and
qtdeclarative-abi-5-15-2, but libqt5core5a now Provides:
qtbase-abi-5-15-4 and libqt5qml5 now Provides:
qtdeclarative-abi-5-15-4.  The dependencies of this package need
updating to bring them into sync.

Best wishes,

   Julian