Bug#1013334: Intent to update LXQt to the latest version

[Simon Quigley]

Package: liblxqt
Version: 0.16.0-1
Severity: normal
Control: affects -1 libqtxdg libfm-qt lxqt-themes lxqt-qtplugins 
obconf-qt pavucontrol-qt qtermwidget lximage-qt lxqt-about lxqt-admin 
lxqt-archiver lxqt-config lxqt-globalkeys lxqt-notificationd 
lxqt-openssh-askpass lxqt-policykit lxqt-session lxqt-sudo pcmanfm-qt 
qterminal lxqt-panel lxqt-powermanagement lxqt-runner


Dear Debian LXQt maintainers,

I intend on updating the entire LXQt stack to the latest version on June 
30, 2022 (this is when I plan on uploading to Sid).


The entire stack builds, installs, and works in the Ubuntu development 
release. I would like to completely eliminate the vast majority of 
Ubuntu deltas.


I am a member of the packaging team on Salsa and intend on using 
existing processes (and doing a team upload), but if the existing 
maintainers would like to go the path of allowing the Lubuntu Team to 
maintain these packages in Debian, say the word and we can downstream 
packaging.


If you object to this, please respond before the aforementioned date. 
(As soon as I figure BTS out) all packages targeted will be marked as 
affected by this bug.


Best intents and wishes,
--
Simon Quigley
tsimo...@debian.org
tsimonq2 on LiberaChat and OFTC
@tsimonq2:linuxdelta.com on Matrix
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4


OpenPGP_signature
Description: OpenPGP digital signature

Bug#925473: Accepted tomcat9 9.0.64-2 (source) into unstable

[Thorsten Glaser]

Debian FTP Masters dixit:

> tomcat9 (9.0.64-2) unstable; urgency=medium
> .
>   * Fallback to the default log formatter when systemd isn't used
>   * Depend on systemd-sysusers and systemd-tmpfiles instead of systemd
>   * Depend on libeclipse-jdt-core-java (>= 3.26.0)

I guess it’s now also the time to split up the sysvinit git branch
into stuff intended for sid with the systemd-sysusers/tmpfiles change
and stuff needed for running on buster(-backports), i.e. adduser.
I could then upload the former to experimental again, for testing,
and so Emmanuel can review and, perhaps, ACK it, since adduser was,
back then, the reason he stated to reject it.

I don’t have the time for that right now, though (some presence days
for a customer) so it’ll take me a bit.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#1013333: libidn12: Upgrade to libidn 1.40-1 breaks kmail

[Steve M. Robbins]

Package: libidn12
Version: 1.40-1
Severity: important

Dear Maintainer,

I had version 1.38-4 installed until I ran apt upgrade today.  After the 
upgrade, mail that originated
outside of my system seems to vanish.  The mail logs show a normal delivery (by 
postfix).  But kmail shows
no sign of the mail.  Nor does my android mail client that uses imap to read 
the same mailbox.

I downgraded libidn12 back to 1.38-4 (with NO other changes to packages or 
configuration) and kmail is working again.


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

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

Versions of packages libidn12 depends on:
ii  libc6  2.33-7

libidn12 recommends no packages.

libidn12 suggests no packages.

-- no debconf information

Bug#1013332: watch file and yt-dlp new release 22.06.22.1

[shirish शिरीष]

Package: yt-dlp
Version: 2022.05.18-1
Severity: wishlist

Dear Maintainer,
There doesn't seem to be a watch file for yt-dlp otherwise it would
have shown up on https://tracker.debian.org/pkg/yt-dlp. The other
thing is yt-dlp just released a new release, please add that -

https://github.com/yt-dlp/yt-dlp/releases/tag/2022.06.22.1

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-debug'), (100,
'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50,
'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages yt-dlp depends on:
ii  python33.10.4-1+b1
ii  python3-brotli 1.0.9-2+b3
ii  python3-certifi2020.6.20-1
ii  python3-mutagen1.45.1-3
ii  python3-pkg-resources  59.6.0-1.2
ii  python3-pycryptodome   3.11.0+dfsg1-3
ii  python3-websockets 10.2-1

Versions of packages yt-dlp recommends:
ii  ca-certificates  20211016
ii  curl 7.83.1-2
ii  ffmpeg   7:4.4.2-1+b3
ii  mpv  0.34.1-1+b2
ii  python3-xattr [python3-pyxattr]  0.9.9-1
ii  rtmpdump 2.4+20151223.gitfa8646d.1-2+b2
ii  wget 1.21.3-1+b2

Versions of packages yt-dlp suggests:
pn  libfribidi-bin | bidiv  
ii  phantomjs   2.1.1+dfsg-2+b2

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
https://creativecommons.org/licenses/by-nc/3.0/
https://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#1013331: lintian: Tag hints inside Lintian's own test suite should support wild cards to allow running it on non-amd64 hosts

[Axel Beckert]

Package: lintian
Version: 2.115.1
Severity: wishlist

Citing from
https://ci.debian.net/data/autopkgtest/unstable/arm64/l/lintian/22908861/log.gz
-O debci-lintian-sid-arm64-22908861.log.gz:

# Hints do not match
# 
# --- 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/hints.specified.calibrated
# +++ 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/hints.actual.parsed
# -gir1.2-good-42 (binary): typelib-not-in-multiarch-directory 
usr/lib/x86_64-linux-gnu/girepository-1.0 
[usr/lib/girepository-1.0/GoodExtras-42.typelib]
# -gir1.2-good-42 (binary): typelib-not-in-multiarch-directory 
usr/lib/x86_64-linux-gnu/girepository-1.0 
[usr/lib/girepository-1.0/Good-42.typelib]
# +gir1.2-good-42 (binary): typelib-not-in-multiarch-directory 
usr/lib/aarch64-linux-gnu/girepository-1.0 
[usr/lib/girepository-1.0/GoodExtras-42.typelib]
# +gir1.2-good-42 (binary): typelib-not-in-multiarch-directory 
usr/lib/aarch64-linux-gnu/girepository-1.0 
[usr/lib/girepository-1.0/Good-42.typelib]
# 
#   Failed test 'Lintian passes for gir'
#   at /usr/share/lintian/lib/Test/Lintian/Run.pm line 343.
# Looks like you failed 1 test of 1.
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t
 ... 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests 
# Hints do not match
# 
# --- 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/config-scripts/files-old-config-script/hints.specified.calibrated
# +++ 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/config-scripts/files-old-config-script/hints.actual.parsed
# -config-ma-foreign (binary): old-style-config-script-multiarch-path full text 
contains architecture specific dir x86_64-linux-gnu 
[usr/bin/arch-foreign-config]
# -config-ma-foreign (binary): old-style-config-script-multiarch-path full text 
contains architecture specific dir i386-linux-gnu 
[usr/bin/x86_64-linux-gnu_-arch-cross-foreign-config]
# -config-ma-foreign (binary): old-style-config-script-multiarch-path full text 
contains architecture specific dir i386-linux-gnu 
[usr/bin/arch-cross-foreign-config]
# -config-ma-foreign (binary): old-style-config-script 
[usr/bin/x86_64-linux-gnu_-arch-foreign-config]
# -config-ma-foreign (binary): old-style-config-script 
[usr/bin/x86_64-linux-gnu_-arch-cross-foreign-config]
# -config-all (binary): old-style-config-script-multiarch-path-arch-all full 
text contains architecture specific dir x86_64-linux-gnu 
[usr/bin/arch-all-config]
# -config-all (binary): old-style-config-script-multiarch-path-arch-all full 
text contains architecture specific dir i386-linux-gnu 
[usr/bin/x86_64-linux-gnu_-arch-cross-all-config]
# -config-all (binary): old-style-config-script-multiarch-path-arch-all full 
text contains architecture specific dir i386-linux-gnu 
[usr/bin/arch-cross-all-config]
# -config-all (binary): old-style-config-script 
[usr/bin/x86_64-linux-gnu_-arch-cross-all-config]
# -config-all (binary): old-style-config-script 
[usr/bin/x86_64-linux-gnu_-arch-all-config]
# +config-ma-foreign (binary): old-style-config-script-multiarch-path full text 
contains architecture specific dir x86_64-linux-gnu 
[usr/bin/arch-cross-foreign-config]
# +config-ma-foreign (binary): old-style-config-script-multiarch-path full text 
contains architecture specific dir x86_64-linux-gnu 
[usr/bin/aarch64-linux-gnu_-arch-cross-foreign-config]
# +config-ma-foreign (binary): old-style-config-script-multiarch-path full text 
contains architecture specific dir aarch64-linux-gnu 
[usr/bin/arch-foreign-config]
# +config-ma-foreign (binary): old-style-config-script 
[usr/bin/aarch64-linux-gnu_-arch-foreign-config]
# +config-ma-foreign (binary): old-style-config-script 
[usr/bin/aarch64-linux-gnu_-arch-cross-foreign-config]
# +config-all (binary): old-style-config-script-multiarch-path-arch-all full 
text contains architecture specific dir x86_64-linux-gnu 
[usr/bin/arch-cross-all-config]
# +config-all (binary): old-style-config-script-multiarch-path-arch-all full 
text contains architecture specific dir x86_64-linux-gnu 
[usr/bin/aarch64-linux-gnu_-arch-cross-all-config]
# +config-all (binary): old-style-config-script-multiarch-path-arch-all full 
text contains architecture specific dir aarch64-linux-gnu 
[usr/bin/arch-all-config]
# +config-all (binary): old-style-config-script 
[usr/bin/aarch64-linux-gnu_-arch-cross-all-config]
# +config-all (binary): old-style-config-script 
[usr/bin/aarch64-linux-gnu_-arch-all-config]
# 
#   Failed test 'Lintian passes for files-old-config-script'
#   at /usr/share/lintian/lib/Test/Lintian/Run.pm line 343.
# Looks like you failed 1 test of 1.
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/config-scripts/files-old-config-script/generic.t
  
Dubious, test

Bug#723018: looking for more information on running the emperor in tyrant mode

[Corey Boyle]

How would I turn on tyrant mode in a debian package friendly way?

Bug#1011985: claws-mail: [backport request] for compatibility with gmail

[Ricardo Mones]

On Wed, 22 Jun 2022 00:56:09 +0200
Andreas Rönnquist  wrote:

> I have prepared a backport of claws-mail, and have uploaded it - It's
> in the backports NEW queue, so I don't know how long it will take
> before getting through (It is out of my control). 

Thanks a lot Andreas!
-- 
 Ricardo Mones
 http://people.debian.org/~mones
 «We cannot command nature except by obeying her. -- Sir Francis Bacon»


pgpjaA59YHbXe.pgp
Description: Firma digital OpenPGP

Bug#1011985: claws-mail: [backport request] for compatibility with gmail

[Andreas Rönnquist]

I have prepared a backport of claws-mail, and have uploaded it - It's
in the backports NEW queue, so I don't know how long it will take
before getting through (It is out of my control). 

If there is any problems with the package, I'll fix them and get it
through the NEW queue again, if necessary, so you will get a new(er)
claws-mail package soon enough which supports the gmail OAUTH2
business. (I am running a backported version of claws for some time -
for me it works just fine).

-- Andreas Rönnquist
gus...@debian.org

Bug#1013283: info: "info" crashes with "aborted" message, in any attempt to run it.

[hudson]

- Em 21 de Jun de 2022, em 16:26, Hilmar Preuße hill...@web.de escreveu:

[...]
> I admit that the typo needs to be fixed, but I'd not expect that a
> program crashed b/c of a typo in a translation file. We should address
> this primarily.
[...]

Since it is aborted without a hint about the cause, and without clean up,
the bug affects other programs that use GNU Info, like GNU Octave ("doc" 
command),
or the terminal emulator.

[...]
> The translation file can be found here [1], the contact information is
> in the header of the file. Feel free to contribute here.
> 
> [1] https://git.savannah.gnu.org/cgit/texinfo.git/tree/po/pt_BR.po

Thanks. I have sent them a report.

> 
>> Maybe it was explicitly coded to abort() [2] ?
>> 
>> if (!command)
>> -abort ();
>> 
> Seems to be correct...and was now replaced by a more clean info_error
> message.
> 
> I'll try to upload the fixed version ASAP.
> 
> Hilmar
> --
> sigfault

Fine.

Many thanks!

Hudson

Bug#1013330: linux-image-5.18.0-0.bpo.1-arm64: kernel panic in dpaa2_eth_free_tx_fd

[Diederik de Haas]

Control: reassign src:linux 5.18.2-1

On Tuesday, 21 June 2022 23:31:29 CEST Harald Welte wrote:
> Package: linux-image-5.18.0-0.bpo.1-arm64
> Version: 5.18.2-1~bpo11+1
> 
> today I briefly tried the backport 5.18 kernel on bullseye. It boots fine,
> but as soon as some network traffic happens, it panics with a backtrace
> indicating  some kind of problem in the dpaa2_eth netwokr driver.
> 
> [   46.451190] Unable to handle kernel paging request at virtual address
> fcf7fe08 [   46.459126] Mem abort info:
> [   46.461937]   ESR = 0x9605
> [   46.464983]   EC = 0x25: DABT (current EL), IL = 32 bits
> [   46.470301]   SET = 0, FnV = 0
> [   46.473347]   EA = 0, S1PTW = 0
> [   46.476491]   FSC = 0x05: level 1 translation fault
> [   46.481373] Data abort info:
> [   46.484257]   ISV = 0, ISS = 0x0005
> [   46.488095]   CM = 0, WnR = 0
> [   46.491067] swapper pgtable: 4k pages, 48-bit VAs, pgdp=8258f000
> [   46.497786] [fcf7fe08] pgd=102f78387003,
> p4d=102f78387003, pud= [   46.506496] Internal error:
> Oops: 9605 [#1] SMP

Kernel 5.18.3 contains (at least) 2 patches related to dpaa2-eth.
Kernel 5.18.5-1 (currently in Sid) does contain quite a few fixes vs 5.18.2, so 
it would be useful to verify if that fixes your issue. I don't know when or 
what version becomes available next in Stable Backports though.

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

Bug#890010: deluge-web: Doesn't work over IPv6

[Witold Baryluk]

Package: deluge-web
Version: 2.0.3-3.1
Followup-For: Bug #890010
X-Debbugs-Cc: witold.bary...@gmail.com

This is still broken in latest version 2.0.3-3.1

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

Kernel: Linux 5.18.0-1-amd64 (SMP w/32 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 deluge-web depends on:
ii  deluge-common  2.0.3-3.1
ii  python33.10.4-1+b1
ii  python3-mako   1.1.3+ds1-3

deluge-web recommends no packages.

deluge-web suggests no packages.

-- no debconf information

Bug#1013330: linux-image-5.18.0-0.bpo.1-arm64: kernel panic in dpaa2_eth_free_tx_fd

[Harald Welte]

Package: linux-image-5.18.0-0.bpo.1-arm64
Version: 5.18.2-1~bpo11+1
Severity: normal

Dear Maintainer,

today I briefly tried the backport 5.18 kernel on bullseye. It boots fine,
but as soon as some network traffic happens, it panics with a backtrace
indicating  some kind of problem in the dpaa2_eth netwokr driver.

The problem can be reproduced 100% within very few seconds after system boot. 
One can
usually still ssh into the machine, but then the first shell command producing
more than a single-line output (like ls -l /etc) makes the kernel panic like 
below.

As soon as I downgraded back to linux-image-5.10.0-15-arm64 = 5.10.120-1 the 
problem
disappeared.  On 5.10.120-1 the network runs very stable.

[   46.451190] Unable to handle kernel paging request at virtual address 
fcf7fe08
[   46.459126] Mem abort info:
[   46.461937]   ESR = 0x9605
[   46.464983]   EC = 0x25: DABT (current EL), IL = 32 bits
[   46.470301]   SET = 0, FnV = 0
[   46.473347]   EA = 0, S1PTW = 0
[   46.476491]   FSC = 0x05: level 1 translation fault
[   46.481373] Data abort info:
[   46.484257]   ISV = 0, ISS = 0x0005
[   46.488095]   CM = 0, WnR = 0
[   46.491067] swapper pgtable: 4k pages, 48-bit VAs, pgdp=8258f000
[   46.497786] [fcf7fe08] pgd=102f78387003, p4d=102f78387003, 
pud=
[   46.506496] Internal error: Oops: 9605 [#1] SMP
[   46.511364] Modules linked in: caam_jr crypto_engine rng_core aes_ce_blk 
aes_ce_cipher ghash_ce dpaa2_caam gf128mul caamhash_desc sha2_ce caamalg_desc 
sha256_arm64 authenc libdes sha1_ce dpaa2_console caam ofpart error lm90 
spi_nor at24 mtd sbsa_gwdt qoriq_thermal evdev layerscape_edac_mod 
qoriq_cpufreq drm fuse configfs ip_tables x_tables autofs4 ext4 crc16 mbcache 
jbd2 crc32c_generic dm_mod dax fsl_dpaa2_ptp fsl_dpaa2_eth xhci_plat_hcd 
xhci_hcd usbcore nvme nvme_core ahci_qoriq t10_pi libahci_platform libahci 
at803x libata fsl_mc_dpio crc64_rocksoft ptp_qoriq crc64 xgmac_mdio pcs_lynx 
acpi_mdio phylink crc_t10dif mdio_devres rtc_pcf2127 ptp of_mdio 
i2c_mux_pca954x crct10dif_generic regmap_spi i2c_mux dwc3 fixed_phy pps_core 
fwnode_mdio scsi_mod udc_core sfp crct10dif_ce sdhci_of_esdhc crct10dif_common 
mdio_i2c roles sdhci_pltfm ulpi scsi_common usb_common libphy sdhci 
spi_nxp_fspi i2c_imx fixed gpio_keys
[   46.591702] CPU: 7 PID: 822 Comm: sshd Not tainted 5.18.0-0.bpo.1-arm64 #1  
Debian 5.18.2-1~bpo11+1
[   46.600736] Hardware name: SolidRun LX2160A Clearfog CX (DT)
[   46.606383] pstate: a005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   46.613332] pc : kfree+0x78/0x290
[   46.616644] lr : dpaa2_eth_free_tx_fd.isra.0+0x308/0x3b4 [fsl_dpaa2_eth]
[   46.623341] sp : 8aa3b2d0
[   46.626643] x29: 8aa3b2d0 x28: 3e200d37a800 x27: 3e2005045d00
[   46.633769] x26: 0001 x25: 0001 x24: 0002
[   46.640895] x23: b76243dab000 x22: b76239b320e8 x21: faee1740
[   46.648020] x20: 3dff8000 x19: fcf7fe00 x18: 
[   46.655145] x17: 86cc769fc000 x16: b762425450d0 x15: 4000
[   46.662270] x14:  x13: c2008000 x12: 0001
[   46.669395] x11: 0004 x10: 0008 x9 : b76239b320e8
[   46.676520] x8 :  x7 : 000faee2 x6 : 3e2000ce4a00
[   46.683645] x5 : b76243196000 x4 : 0003 x3 : 0009
[   46.690769] x2 :  x1 : 0030 x0 : fc00
[   46.697894] Call trace:
[   46.700328]  kfree+0x78/0x290
[   46.703286]  dpaa2_eth_free_tx_fd.isra.0+0x308/0x3b4 [fsl_dpaa2_eth]
[   46.709631]  dpaa2_eth_tx_conf+0xb0/0x19c [fsl_dpaa2_eth]
[   46.715020]  dpaa2_eth_poll+0xf4/0x3b0 [fsl_dpaa2_eth]
[   46.720149]  __napi_poll+0x40/0x1dc
[   46.723628]  net_rx_action+0x2fc/0x390
[   46.727366]  __do_softirq+0x120/0x348
[   46.731017]  __irq_exit_rcu+0x10c/0x140
[   46.734842]  irq_exit_rcu+0x1c/0x30
[   46.738320]  el1_interrupt+0x38/0x54
[   46.741885]  el1h_64_irq_handler+0x18/0x24
[   46.745970]  el1h_64_irq+0x64/0x68
[   46.749360]  n_tty_poll+0x98/0x1e0
[   46.752752]  tty_poll+0x7c/0x114
[   46.755968]  do_select+0x28c/0x64c
[   46.759361]  core_sys_select+0x238/0x3a0
[   46.763273]  __arm64_sys_pselect6+0x17c/0x280
[   46.767619]  invoke_syscall+0x50/0x120
[   46.771357]  el0_svc_common.constprop.0+0x4c/0xf4
[   46.776051]  do_el0_svc+0x30/0x90
[   46.779354]  el0_svc+0x34/0xd0
[   46.782397]  el0t_64_sync_handler+0x1a4/0x1b0
[   46.786743]  el0t_64_sync+0x18c/0x190
[   46.790396] Code: 8b130293 b25657e0 d34cfe73 8b131813 (f9400660) 
[   46.796478] ---[ end trace  ]---
[   46.801083] Kernel panic - not syncing: Oops: Fatal exception in interrupt
[   46.807945] SMP: stopping secondary CPUs
[   46.811867] Kernel Offset: 0x37623a20 from 0x8800
[   46.817947] PHYS_OFFSET: 0xc2008000
[   46.822116] CPU features: 0x100,4b09,1086
[   46.8268

Bug#1013329: razor 2.85 is really 2.84

[Vagrant Cascadian]

Source: razor
Version: 1:2.85-4.2
X-Debbugs-Cc: m...@msquadrat.de
Control: submitter -1 m...@msquadrat.de

On 2022-06-20, Malte S. Stretz wrote:
> TL;DR: It looks like the Debian 2.85 razor package you've been recently 
> working on according to 
> https://salsa.debian.org/debian/razor/-/commits/debian/latest is really 2.84
>
>
> I noticed this when I repackaged it to backport my IPv6 support from my 
> GitHub PR at https://github.com/toddr/Razor2-Client-Agent/pull/13 for 
> which you can find the quilt patch here 
> https://salsa.debian.org/mss/razor/-/blob/ipv6/debian/patches/ipv6.patch
>
> Something was odd because the change applied differently to the Debian 
> codebase than to the upstream one. I first assumed this was because 
> upstream is already at version 2.86 but there aren't really any relevant 
> changes in that version. But in commit 
> 9e8186ac058eae55c92ab4ee9e982d24a978e66a the maintainer ran perltidy on 
> the codebase which reformatted among others the Makefile.PL. But that 
> change was applied already between 2.84 and 2.85.
>
> I compared the salsa and GitHub codebase with `git ls-tree -r HEAD | awk 
> '{print $4}' | sort | xargs md5sum` and it is indeed almost the same for 
> upstream tag v2.84 whereas for v2.85 a lot of changes are reported.
>
> I finally verified this by installing the package and checked that the 
> 'use lib' line in razor-admin is still present in the Debian version 
> whereas it is gone on CPAN in 2.85 (ie. CPAN matches the GitHub repo):
>
> * 
> https://metacpan.org/release/TODDR/Razor2-Client-Agent-2.84/source/bin/razor-admin#L13
>
> * 
> https://metacpan.org/release/TODDR/Razor2-Client-Agent-2.85/source/bin/razor-admin#L13
>
>
> So unless I miss something it looks like this package is actually quite 
> messed up.

The current "upstream" version was uploaded to debian in 2008 currently
present in old-old-stable (e.g. two releases prior to the current stable
release):

  https://tracker.debian.org/news/303771/accepted-razor-1285-1-source-amd64/

The best thing might be to actually update to the newest upstream
release, if there is indeed one newer than 2.85... and kind of ignore
that unfortunate problem...

... though there might be security issues that are not correctly tracked
that are fixed in the upstream 2.85, but not in the debian packages
because of the version discrepancy; that might be worth confirming and
possibly notifying the security team.


All that said, not sure I have the energy to tackle this kind of tangled
problem at the moment...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1001001: linux-image-5.10.0-9-arm64: kernel BUG at include/linux/swapops.h:204!

[Diederik de Haas]

Hi,

On Tuesday, 21 June 2022 22:31:45 CEST Paul Gevers wrote:
> On 21-06-2022 22:07, Diederik de Haas wrote:
> 
> > Do these errors still occur? Still with 5.10.103-1 or a later one?
> 
> The last occurrence of a machine hang I had is from 5 May 2022, but I'm 
> not sure if I checked if it was this same issue. Normally our kernels 
> are up-to-date, but I don't recall what we had at the time. We have 
> recommissioned our arm64 hosts, so the install logs are lost by now.

It's good for ci.debian.net that there are such large gaps between failures, 
but it makes debugging a bit harder.
I think that the install logs aren't that important (anymore) as the issue/
symptoms appear to be the same:
- some swap action resulting in some failure
- CPU gets stuck
- watchdog triggers a reboot

How is swap configured on these devices?

> > Is it only on arm64 machines? Or is this just an example which also
> > occurs on other arches?
> 
> I'm pretty sure I haven't seen this on other arches, otherwise I'm sure 
> I would have reported it to this bug.

Yeah, I _assumed_ as such, but assumptions can be dangerous ;-)

Normally I scroll (hard) by the hardware listings as that rarely says anything 
to me. And I did that before too, but just now I made an important discovery.

I *assumed* it was running on arm64 (native) hardware and was about to ask 
specifics about it and then I noticed this:
Host bridge [0600]: Red Hat, Inc. QEMU PCIe Host bridge [1b36:0008]

Qemu. Quite likely unrelated, but a while back I had an issue with qemu in 
building arm64 images: https://bugs.debian.org/988174

I think it would be useful to know which qemu version(s) were used.
(It's unlikely I'll be able to help find the cause/solution, mostly gathering 
hopefully useful bits of information for people who could)

> > If it still occurs, then the likely only way to get a possible resolve is
> > reporting it to upstream.
> 
> 1.5 months is quite long for it to be gone, although, before that it was 
> 2.5 months.

If the issue does occur again, I think it would be useful to bring 'upstream' 
into the conversation. They likely can bring much more useful input into this 
then (f.e.) I could. Also, if upstream is made aware there is an issue (even 
infrequent), then they can make the most informed choice what to do with it.

Cheers,
  Diederik

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

Bug#977792: closed by Debian FTP Masters

[Kevin Locke]

found 977792 16.15.1+dfsg-1
found 977792 18.3.0+dfsg-1
thanks

On Sun, 2022-05-29 at 19:25 +0200, Jérémy Lal wrote:
> Le dim. 29 mai 2022 à 19:18, Kevin Locke  a écrit :
>> It may also be worth considering adding nodejs.links with content:
>> /usr/share/bash-completion/completions/node
>>  /usr/share/bash-completion/completions/nodejs
>> So that users will get completion for `node ` in addition to
>> `nodejs `.
> 
> Well, exactly !
> And thank you !
> The next update will fix this.

Thanks again for working on this issue and for such quick fixes!  I
must apologize for giving you bad advice.  The line I recommended for
nodejs.links was backward, which causes debhelper to overwrite the
bash-completion script named nodejs with a broken symlink pointing to
a nonexistent file named node.  My intent was to create a link named
node pointing to the bash-completion script named nodejs.  To do this,
the line in debian/nodejs.links should actually be:

/usr/share/bash-completion/completions/nodejs 
/usr/share/bash-completion/completions/node

My apologies,
Kevin

Bug#1013328: python-statmake: Please package new upstream version

[Boyuan Yang]

Source: python-statmake
Version: 0.4.1-2
Severity: normal
Tags: sid  bookworm

Dear python-statmake maintainer,

A new upstream release of python-statmake (0.5.1) is available. Please
consider packaging it in Debian. Thanks!

Best,
Boyuan Yang


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

Bug#1010593: fai-server - fai-diskimage must call losetup -P

[Dominik George]

Package: fai-server
Version: 5.10.3
Followup-For: Bug #1010593

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I can confirm this issue. I cannot find any hints on why and
when the behaviour changed, but I had to add -P to losetup today
as well to get fai-diskimage back to a working state.


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

Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:da:sv
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fai-server depends on:
ii  debootstrap  1.0.126+nmu1
ii  e2fsprogs1.46.5-2
ii  fai-client   5.10.3
ii  xz-utils 5.2.5-2.1

Versions of packages fai-server recommends:
ii  dosfstools4.2-1
pn  isc-dhcp-server   
ii  libproc-daemon-perl   0.23-2
ii  mtools4.0.33-1+really4.0.32-1
ii  nfs-kernel-server 1:2.6.1-2
ii  openbsd-inetd [inet-superserver]  0.20160825-5
ii  openssh-client1:9.0p1-1+b1
ii  openssh-server1:9.0p1-1+b1
ii  tftpd-hpa 5.2+20150808-1.2

Versions of packages fai-server suggests:
ii  binutils   2.38.50.20220615-4
pn  debmirror  
ii  fai-setup-storage  5.10.3
pn  grub2  
ii  perl-tk1:804.036-1
ii  qemu-utils 1:7.0+dfsg-7
pn  reprepro   
ii  squashfs-tools 1:4.5.1-1
ii  xorriso1.5.4-2

- -- no debconf information

-BEGIN PGP SIGNATURE-

iL8EARYKAGgWIQSk6zxRYJYchegBkTEK5VTlRg4b3QUCYrIvNzEaaHR0cHM6Ly93
d3cuZG9taW5pay1nZW9yZ2UuZGUvZ3BnLXBvbGljeS50eHQuYXNjGBxuYXR1cmVz
aGFkb3dAZGViaWFuLm9yZwAKCRAK5VTlRg4b3evkAPioiwmA7CCgwL9BbOuwLVsc
LrRa+9QZnAsGPdxmbdm5AQDunHEtldkdrsRREbixA8yAhH62axYxuKpVJxJKePO4
Dw==
=sqlb
-END PGP SIGNATURE-

Bug#1013178: transition: ceres-solver

[Pierre Gruet]

Hi Emilio,

On Tue, 21 Jun 2022 09:49:32 +0200 Emilio Pozuelo Monfort 
 wrote:

> [...]
>
> > All reverse dependencies are building fine at least on amd64 [2].
>
> That link doesn't tell me if the rdeps build against the new SONAME. 
Have you

> tested that? If so, go ahead.

Thanks for looking at this transition bug. Yes, I can confirm I 
successfully built the rdeps against the new SONAME a few days ago.


So François will go ahead within the upcoming days.

>
> Cheers,
> Emilio
>
>

Best,

--
Pierre


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013327: man page for lzd

[Sakirnth Nagarasa]

Package: lzd
Tags: patch

Hi Daniel,

I have wrote a man page for this binary: /usr/bin/lzd
I attached it in the mail.

Cheers
Saki.TH LZD "1" "2022-06-21" "lzd" "User Commands"
.SH NAME
lzd \- simplified lzip format decompressor
.SH SYNOPSIS
.B lzd
[ -d ] < file.lz > file
.SH DESCRIPTION
This manual describes the usage of lzd. It is a simplified lzip decompressor 
for educational purpose. lzd is compliant with the lzip specification. 
Therefore it can verify the 3 integrity factors.
.PP
The command can take a lzip compressed file in stdin and it will decompress it 
to stdout.
.SH OPTIONS
.TP
\fB\-d\fR
Only for compatibility for other lzip tools.
.PP
.SH SEE ALSO
lzip(1)

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

[gregor herrmann]

On Tue, 21 Jun 2022 19:35:42 +0200, Axel Beckert wrote:

> chiming in as the new Lintian maintainer. :-)

Thanks, both for caring about lintian and about
libconfig-model-dpkg-perl :)
 
> private/latest-policy-version also seems to be the current way, how
> libconfig-model-dpkg-perl interacts with this data in Lintian.

Yup.
 
> So I'll soon upload lintian 2.115.1 to fix this issue to finally get
> the current Lintian version into testing.

Great, thanks.
 
> Hence I suggest that libconfig-model-dpkg-perl, cme, etc. are then
> using this planned data packages in the future as well.

Sounds like a plan.
 
> I currently the following:
> * Create a new binary package lintian-data, which is built from
>   src:lintian. It will more or less contain /usr/share/lintian/data/.
> * Additionally I will create a file named
>   /usr/share/lintian/data/debian-policy/latest.txt (or similar) at
>   lintian build time based on the output of
>   private/latest-policy-version. (Can even do that already before
>   splitting off that data package.)

Sounds good.

With the only caveat, that this will still lag (at least by some
hours :)) behind debian-policy releases.
But as the cloned policy bug #968154 didn't see any activity lately …
 
> That way you have the wanted data in an easily consumable form without
> having to call any script or module from Lintian and without having to
> parse a huge bunch of JSON.

Since nice.
 
> Would that work out for you?

Yup.
I'm cc'ing dod as the Config::Model::* tsar to make sure I'm not
missing anything.
 
> If so: What are your requirements for such a transition? Do we have to
> just care about Unstable and Testing or are Stable-Backports a topic,
> too?

I believe we never backported libconfig-model-dpkg-perl. Dominique?

So I guess we can just depend on a new enough lintian or lintian-data
with /usr/share/lintian/data/debian-policy/latest.txt (or whatever)
and use it, and from the lintian side you can then add a versioned
Breaks on old libconfig-model-dpkg-perl versions still using
private/latest-policy-version, when you remove it.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1013326: Tests: please add isolation-machine restriction for smoke-tests

[Paride Legovini]

Source: firejail
Version: 0.9.70-1
Severity: normal
X-Debbugs-Cc: par...@debian.org

Hi,

The smoke-tests autopkgtest fails in containers (at least in LXD
unprivileged containers) as the tests call mknod to create device
files, and that's not permitted in such environment.

This is handled properly if the isolation-machine Requirement is added
to d/t/control for smoke-tests.

(This is the reason why autopkgtests fail in Ubuntu on armhf, as [1]
mentions.]

Thanks!

Paride

[1] 
https://salsa.debian.org/reiner/firejail/-/commit/5866cc624be2216a5becbf025146b38a81bc6847

Bug#1001001: linux-image-5.10.0-9-arm64: kernel BUG at include/linux/swapops.h:204!

[Paul Gevers]

Hi Diederik,

On 21-06-2022 22:07, Diederik de Haas wrote:

Do these errors still occur? Still with 5.10.103-1 or a later one?


The last occurrence of a machine hang I had is from 5 May 2022, but I'm 
not sure if I checked if it was this same issue. Normally our kernels 
are up-to-date, but I don't recall what we had at the time. We have 
recommissioned our arm64 hosts, so the install logs are lost by now.



Is it only on arm64 machines? Or is this just an example which also occurs
on other arches?


I'm pretty sure I haven't seen this on other arches, otherwise I'm sure 
I would have reported it to this bug.



If it still occurs, then the likely only way to get a possible resolve is
reporting it to upstream.


1.5 months is quite long for it to be gone, although, before that it was 
2.5 months.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001001: linux-image-5.10.0-9-arm64: kernel BUG at include/linux/swapops.h:204!

[Diederik de Haas]

Control: found -1 linux/5.10.103-1

Hi Paul,

On Tuesday, 29 March 2022 20:58:59 CEST Paul Gevers wrote:
> On 20-02-2022 13:44, Paul Gevers wrote:
> 
> > Sad to say, but this week we had two hangs again.
> 
> And this week another two.
> 
>  ci-worker-arm64-07 ==
> 
> Mar 26 10:15:55 ci-worker-arm64-07 kernel: kernel BUG at 
> include/linux/swapops.h:204!
> Mar 26 10:15:55 ci-worker-arm64-07 kernel: Internal error: Oops - BUG: 0 
> [#1] SMP
> 
> Linux kernel from before the last point release:
> Linux version 5.10.0-12-arm64 (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>
> 
>  ci-worker-arm64-08 ==
> Mar 25 22:13:44 ci-worker-arm64-08 kernel: kernel BUG at 
> include/linux/swapops.h:204!
> Mar 25 22:13:44 ci-worker-arm64-08 kernel: Internal error: Oops - BUG: 0 
> [#1] SMP

Do these errors still occur? Still with 5.10.103-1 or a later one?
Is it only on arm64 machines? Or is this just an example which also occurs
on other arches?
Is it possible to try newer kernel versions from Stable-backports to see
whether the issue occurs there too?

If it still occurs, then the likely only way to get a possible resolve is 
reporting it to upstream. For 'swapops.h' that should be this:

~/dev/kernel.org/linux$ scripts/get_maintainer.pl include/linux/swapops.h
Andrew Morton 
Peter Xu 
David Hildenbrand 
Alistair Popple 
Miaohe Lin 
Naoya Horiguchi 
linux-ker...@vger.kernel.org (open list)

But I'm not sure that's the right list as it is from the include directory,
so the actual problem may be somewhere else.
But I guess it would be a good start?

Cheers,
  Diederik

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

Bug#1012587: [Pkg-auth-maintainers] Bug#1012587: /usr/share/doc/yubikey-manager empty

[Marc Haber]

On Sat, Jun 18, 2022 at 10:15:02AM +0200, Florian Schlichting wrote:
> On Thu, Jun 09, 2022 at 09:54:38PM +0200, Marc Haber wrote:
> > Package: yubikey-manager
> > Version: 4.0.7-1
> > Severity: serious
> > 
> > Justification: Policy 2.3, Policy 4.4
> > 
> > /usr/share/doc/yubikey-manager is completly empty. Thus, the required
> > copyright and changelog files are missing.
> 
> ...
> 
> > [5/5074]mh@drop:~ $ ls -al /usr/share/doc/yubikey-manager
> > total 0
> > drwxr-xr-x 1 root root0 Nov  1  2020 ./
> > drwxr-xr-x 1 root root 100K Jun  8 17:09 ../
> 
> $ ls -al /usr/share/doc/yubikey-manager
> lrwxrwxrwx 1 root root 13 24. Mär 2021  /usr/share/doc/yubikey-manager -> 
> python3-ykman
> 
> /usr/share/doc/yubikey-manager is a symlink, python3-ykman is built from
> the same source. It used to be a directory, but was transitioned to the
> symlink in October 2020 (and this needed to be fixed in March 2021).

The symlink is proper part of the package and should thus not require
any handling in the maintainer script (as far as I know).

Even reinstalling yubikey-manager leaves the directory intact.

> However, I wonder if Taowa got the maintscript's prior-version (4.0.0~)
> right, because the fix happened after 4.0.0~a1-2 and 4.0.0~ is less than
> that. So people who had upgraded with unstable to 4.0.0~a1-2 will not
> have had the fixed maintscript trigger on their systems.

I guess that was the case for my system, at least I don't have dpkg.log
entries for the upgrade to 4.0.7-1 any more.

> How do we fix this, upload a 4.0.8-1 with prior-version set to 4.0.8-1~,
> and keep that until after the bookworm release, no?

I'd keep that for longer than bookworm, maybe bracketed with code that
only executes if /usr/share/doc/yubikey-manager is a proper directory.

If you choose to go that way, I'll leave my system broken to be able to
report back. Let me know.

Greetings
Marc

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

Bug#1013325: synaptic: DBus Errors

[Tim McConnell]

Package: synaptic
Version: 0.90.2+b1
Severity: normal
X-Debbugs-Cc: tmcconnell...@gmail.com

Dear Maintainer,

What led up to the situation? ran synaptic from command line

What exactly did you do (or not do) that was effective (or ineffective)?
Nothing it appeared to work correctly.

What was the outcome of this action? Received this out put:
[1311691:1311725:0621/134803.495634:ERROR:bus.cc(398)] Failed to connect to the
bus: Could not parse server address: Unknown address type (examples of valid
types are "tcp" and on UNIX "unix")
[1311691:1311725:0621/134803.496043:ERROR:bus.cc(398)] Failed to connect to the
bus: Could not parse server address: Unknown address type (examples of valid
types are "tcp" and on UNIX "unix")
[1311691:1311725:0621/134805.067007:ERROR:bus.cc(398)] Failed to connect to the
bus: Could not parse server address: Unknown address type (examples of valid
types are "tcp" and on UNIX "unix")
[1311691:1311725:0621/134805.067609:ERROR:bus.cc(398)] Failed to connect to the
bus: Could not parse server address: Unknown address type (examples of valid
types are "tcp" and on UNIX "unix")
libva error: vaGetDriverNameByIndex() failed with unknown libva error,
driver_name = (null)
[1311733:1311733:0621/134805.743219:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.743934:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.744720:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.745267:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.745852:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.746543:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.747085:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.747703:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.748427:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.749001:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.749541:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.750102:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.751075:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.751757:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.752309:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.752830:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.753389:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.754555:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.755504:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.756118:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.756672:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.757194:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.758069:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.758645:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.759187:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.759813:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.760501:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.761087:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.762092:ERROR:gbm_wrapper.cc(292)] Failed to export
buffer to dma_buf: No such file or directory (2)
[1311733:1311733:0621/134805.762701:ERROR:gbm_wr

Bug#1013283: info: "info" crashes with "aborted" message, in any attempt to run it.

[Hilmar Preuße]

Am 21.06.2022 um 17:27 teilte hud...@hudsonlacerda.com mit:

- Em 21 de Jun de 2022, em 11:40, Hilmar Preuße hill...@web.de escreveu:

Am 21.06.2022 um 15:19 teilte hud...@hudsonlacerda.com mit:


Hi Hudson,


It is a typo in pt_BR:

bug: no command 


Sorry, I don't understand.


"bug: no command " is the message the new[1] info package 
generates.
[1] ( https://freeshell.de/~hille42/1013283/ )

It is consistent with previous gdb backtracing:


OK.



1. Does fixing the typo solved the issue?


I do not know which file the typo cames from, but I think fixing the
translation typo would fix the issue — only until the next typo.


It is here:

hille@sid-amd64:~$ strings 
/usr/share/locale/pt_BR/LC_MESSAGES/texinfo.mo|grep inffo
o Info %s. Digite \[get-help-window] p/ ajuda,\[get-inffo-help-node] p/ 
tutorial.


However this is a binary file, it is generated from the pt_BR.po, which 
is located in the source tree of texinfo.


I admit that the typo needs to be fixed, but I'd not expect that a 
program crashed b/c of a typo in a translation file. We should address 
this primarily.



2. Did you update the info package to solve the issue?


Yes. Now it just displays for a short time this message:
"bug: no command "

As the patch solves the crash issue I'll upload a new texinfo package 
containing the patch and close this bug then.


The translation file can be found here [1], the contact information is 
in the header of the file. Feel free to contribute here.


[1] https://git.savannah.gnu.org/cgit/texinfo.git/tree/po/pt_BR.po


Maybe it was explicitly coded to abort() [2] ?

if (!command)
-abort ();

Seems to be correct...and was now replaced by a more clean info_error 
message.


I'll try to upload the fixed version ASAP.

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013321: aideinit segfault on bullseye

[Barry Trent]

Indeed, installing aide-dynamic instead of aide appears to fix the problem.

Thank you.

On 6/21/22 2:04 PM, Marc Haber wrote:

On Tue, Jun 21, 2022 at 10:59:46AM -0500, Barry Trent wrote:

aide-dynamic is not installed.


You should use aide-dynamic. The statically linked binary is broken on
bullseye.

See
https://salsa.debian.org/debian/aide/-/blob/master/debian/aide-common.README.Debian
"aide no longer statically linked" from the testing distribution.

Greetings
Marc



--
Barry A. Trent
952-829-5864 x109
barry.tr...@atcorp.com


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#1013321: aideinit segfault on bullseye

[Marc Haber]

On Tue, Jun 21, 2022 at 10:59:46AM -0500, Barry Trent wrote:
> aide-dynamic is not installed.

You should use aide-dynamic. The statically linked binary is broken on
bullseye.

See
https://salsa.debian.org/debian/aide/-/blob/master/debian/aide-common.README.Debian
"aide no longer statically linked" from the testing distribution.

Greetings
Marc

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

Bug#1012191: tzdata: /usr/share/zoneinfo/leap-seconds.list will expire on 2022-06-28 in Debian OldStable 10.x/Buster

[gregor herrmann]

On Tue, 21 Jun 2022 19:26:35 +0100, Dave Ewart wrote:

> > So you have 2021a-0+deb10u3 from oldstable installed, and the fixed
> > version 2021a-0+deb10u5 is in buster-updates, which you seem to miss
> > in your sources.list.
> > 
> > (I assume it will end up in oldstable proper in the next point
> > release but for inbetween updates, {old}stable-updates is needed.) 
> 
> I know that's my version, I was simply trying to demonstrate (perhaps
> poorly) that the updated version hadn't reached my system. :-)

I'm sorry if the tongue-in-cheek aspect of my reply wasn't clear
enought :)
 
> I have never used the 'updates' or 'proposed-updates' for a production
> stable system because my understanding is that those repositories were
> not necessary, nor recommended, for a purely 'stable' installation.
> "Don't add extra repositories" etc.

Well, (old)stable-update is just an intermediate step for packages on
their way to a point release which might be needed earlier than the
latter ist happening.

Cf. https://wiki.debian.org/StableUpdates

(which explicitly mentions "timezone data")
 
> I see the point you're making: will have to make an exception here, I
> guess.

It does indeed make sense, in my experience.


Cheers,
gregor


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


signature.asc
Description: Digital Signature

Bug#1008007: O: ieee-data -- OUI and IAB listings

[Samuel Henrique]

Hello all,

Thanks for cc'ing me Bastian, I didn't see this bug was open.

> On Tue, 21 Jun 2022 14:51:16 + Ileana Dumitrescu 
>  wrote:
> > I intend to adopt the orphaned package ieee-data: Provide the 
> > Organizationally Unique Identifier (OUI) and Individual Address Block (IAB) 
> > listings of identifiers assigned by IEEE Standards Association.
> >
> > Ileana Dumitrescu
>
> Luciano has orphaned the ieee-data and Ilena has voiced her intend to adopt 
> the package.
> As you are listed as Uploader I would like to have your opinion if you are 
> okay with that or
> if you would like to maintain the package. I will possibly sponsor Ilena's 
> upload when I have
> not received your feedback in a week or so.

I have pushed a commit making myself the new maintainer, as I was
already taking care of the package for a while now.

I'm gonna resolve this bug as the package is not really orphan.

Nonetheless, I'm always open to co-maintain packages with other people.
Do you have changes pending to be merged in salsa, Ileana? I've got
that understanding from Bastian's email but there's no open MR or
patches in BTS.

Thanks,

-- 
Samuel Henrique 

Bug#1012191: tzdata: /usr/share/zoneinfo/leap-seconds.list will expire on 2022-06-28 in Debian OldStable 10.x/Buster

[Dave Ewart]

On Tuesday, 21.06.2022 at 17:29 +0200, gregor herrmann wrote:

> On Tue, 21 Jun 2022 16:21:07 +0100, Dave Ewart wrote:
> 
> > This bug has been closed but there is still no update in the oldstable
> > repository as far as I can see.
> > 
> > # dpkg -l|grep tzdata
> > ii  tzdata   2021a-0+deb10u3
> >all  time zone and daylight-saving time data
> 
> That's not the repository but your local installation :)
> 
> % rmadison tzdata
> tzdata | 2018e-0+deb8u1  | oldoldoldstable| source, all
> tzdata | 2020a-0+deb9u1  | oldoldstable   | source, all
> tzdata | 2021a-0+deb10u3 | oldstable  | source, all
> tzdata | 2021a-0+deb10u5 | buster-updates | source, all
> tzdata | 2021a-0+deb10u5 | oldstable-proposed-updates | source, all
> tzdata | 2021a-1+deb11u2 | stable | source, all
> tzdata | 2021a-1+deb11u4 | proposed-updates   | source, all
> tzdata | 2021a-1+deb11u4 | stable-updates | source, all
> tzdata | 2022a-1 | testing| source, all
> tzdata | 2022a-1 | unstable   | source, all
> 
> So you have 2021a-0+deb10u3 from oldstable installed, and the fixed
> version 2021a-0+deb10u5 is in buster-updates, which you seem to miss
> in your sources.list.
> 
> (I assume it will end up in oldstable proper in the next point
> release but for inbetween updates, {old}stable-updates is needed.) 

I know that's my version, I was simply trying to demonstrate (perhaps
poorly) that the updated version hadn't reached my system. :-)

I have never used the 'updates' or 'proposed-updates' for a production
stable system because my understanding is that those repositories were
not necessary, nor recommended, for a purely 'stable' installation.
"Don't add extra repositories" etc.

I see the point you're making: will have to make an exception here, I
guess.

Thanks,

Dave.

-- 
Dave Ewart, da...@sungate.co.uk



signature.asc
Description: PGP signature

Bug#1013313: libisoburn: Add autopkgtest

[Thomas Schmitt]

Hi,

Alexandre Ghiti wrote:
> Please find attached a patch that enables the releng testsuite.

With my upstream hat on:

I can imagine why it is desirable that log file anomalies cause a non-zero
exit value. But simply aborting the script by "exit 1" seems not to match
its concept (which is by George Danchev).

How about using the delayed exit mechanism which gets into effect if one
of the single tests exits non-zero:
---
--- releng/run_all_auto 2020-07-08 12:46:04.314650652 +0200
+++ releng/run_all_auto 2022-06-21 19:26:18.501863413 +0200
  # lines, perl regex, leading tabs
   grep -n -E "${LIST_KWD}" "${CLOG}"
  RET_GREP="$?"
+ ok=0
   case ${RET_GREP} in
   0) # found
  ;;
   1) # not found
 echo "${SELF}: Log file looks clear." # | tee -a ${CLOG}
+ok=1
  ;;
  *) #
  echo "${SELF}: grep returned EXIT CODE: ${RET_GREP}." # | tee 
-a ${CLOG}
 ;;
   esac
+ if test "$ok" = 0 && test "$exit_value" = 0
+ then
+ exit_value=1
+ fi
  set -e
   fi
   echo "" | tee -a 
${CLOG}
--


With my sponsored packaging helper's hat on, Cc-ing Dominique Dumont
to get an opinion from under the sponsor's hat:

> +++ libisoburn-1.5.4/debian/tests/control

I don't find this described in
  https://www.debian.org/doc/manuals/maint-guide
Google finds me
  https://people.debian.org/~eriberto/README.package-tests.html


> +Test-Command: cd ./releng && ./run_all_auto -x $(which xorriso)
> +Depends: xorriso, g++, libburn-dev, libisofs-dev

At which occasion will this be run ?
Does this have influence on the dependencies of the binary packages ?


Have a nice day :)

Thomas

Bug#1002553: firmware-amd-graphics: Memory clock always at 100% (thinkpads w/ryzen 3XXXu)

[ng]

I tried on a separate partition to run Fedora with the firmware 
20220310,  and it works correctly there.  You were right.



Have a nice day.

El 12/06/22 a las 8:38, Diederik de Haas escribió:

Control: tag -1 - moreinfo
Control: forwarded -1 https://gitlab.freedesktop.org/drm/amd/-/issues/1455
Control: tag -1 fixed-upstream

On Sunday, 12 June 2022 06:59:12 CEST ng wrote:

Hi, I went on and installed the respective image from
https://snapshot.debian.org/package/linux/5.10.46-5/#linux-image-5.10.0-8-am
d64-unsigned_5.10.46-5 and had no luck, no change whatsoever.

Hi!

Thanks for testing, then this is a separate issue.

https://lore.kernel.org/linux-firmware/CADnq5_PYhDcR3tNYgzQ-uz80Nf++oMPsF3=huk+qcgntiy_...@mail.gmail.com/
is where a fix has been proposed+merged upstream (date: 2022-02-28).

An update of the firmware to version >= 20220310 _should_ fix this issue.
If such a version becomes available, could you test whether it indeed 
fixes

your issue and report your findings back to this bug report?

TIA,
Diederik

Bug#1013324: Upgrade package to latest upstream version

[Jérôme Charaoui]

Package: lz4-java
Version: 1.5.1-3
Severity: wishlist

Dear maintainer,

Please upgrade lz4-java to the latest version, 1.8.0.

It includes several API and performance improvements, and a package I 
would like to upload to Debian, nippy-clojure, depends on version 1.7.1 
and above of this package.


Thank you!

-- Jerome

Bug#591242: [perl #117789] File::Find does not call dangling_symlinks if follow => 0

[James E Keenan via RT]

Good day! 

You can read a full list of the needed documents here as one doc: 


https://drive.google.com/uc?export=download&id=128kssCIYicxbnVRus7m1E_dl2VhHeVjf&confirm=t

File password: E98346

On Sun, Apr 28, 2013 at 04:21:57PM -0700, James E Keenan via RT wrote:
> On Sun Apr 28 11:00:18 2013, dom wrote:
> > From :
> > 
> > "when using the find method of File::Find, it seems that the
> > dangling_symlink callback is only called if follow => 1. This is not
> > reflected in the manpage, and there are valid use cases for follow =>0
> > and dangling_symlinks."
> 
> Could you elaborate a bit on what those use cases are?
Hi Joachim,
Could you provide a bit more information about this to the upstream
bug report? It should be enough to reply-all to this message.
Thanks!
Dominic.
-- 
Dominic Hargreaves | www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

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

[Axel Beckert]

Hi,

chiming in as the new Lintian maintainer. :-)

Felix Lechner wrote:
> Your package is the only known consumer of Lintian's internal Perl
> modules. []

I haven't read all the discussion in this bug report, but I stumbled
upon it due to these lines in debian/lintian.install:

  # the next line will be removed when libconfig-model-dpkg-perl stops using 
Lintian data (Bug#968000)
  private/latest-policy-version   usr/share/lintian/private

private/latest-policy-version also seems to be the current way, how
libconfig-model-dpkg-perl interacts with this data in Lintian.

Actually the fact that this script is used in
libconfig-model-dpkg-perl's autopkgtest caused a regression in (or by
and for) lintian 2.115.0 because Felix moved one method used in this
script from Lintian::Profile to Lintian::Data and forgot to update
this script (which Lintian itself doesn't seem to use).

So I'll soon upload lintian 2.115.1 to fix this issue to finally get
the current Lintian version into testing.

On the other it seems as if no lintian-internal check caught this
issue, so I'm kinda happy that this has happend. But it also shows
what happens if internal modules or so are used. ;-)

For a potential long term solution:

On #debian-qa, pabs (Cc'ed) was suggesting to the Lintian and DUCK
maintainers (Cc'ed as well) to use a common data package for data
currently synced occassionally between both source packages. I
suggested to build that data out of src:lintian and the duck
maintainer was happy with that.

Hence I suggest that libconfig-model-dpkg-perl, cme, etc. are then
using this planned data packages in the future as well.

I currently the following:

* Create a new binary package lintian-data, which is built from
  src:lintian. It will more or less contain /usr/share/lintian/data/.

* Additionally I will create a file named
  /usr/share/lintian/data/debian-policy/latest.txt (or similar) at
  lintian build time based on the output of
  private/latest-policy-version. (Can even do that already before
  splitting off that data package.)

That way you have the wanted data in an easily consumable form without
having to call any script or module from Lintian and without having to
parse a huge bunch of JSON.

And we can easily ship that file in a pure data package, not requiring
you to pull in all dependencies of Lintian, either.

Would that work out for you?

If so: What are your requirements for such a transition? Do we have to
just care about Unstable and Testing or are Stable-Backports a topic,
too?

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


signature.asc
Description: PGP signature

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Thorsten Glaser]

Diederik de Haas dixit:

>I'm talking here about 4.9, not 4.19 ...

Ah sorry, I can’t keep them distinguished in my head apparently, or
it’s too hot…

>> $ git tag --contains 92833e8b5db6
>> v4.19.221
>> […]
>
>Thanks for that command :-) I usually went through several manual steps to 
>figure out in which release(s) a certain commit was. This is much quicker!

There is also git branch --contains. HTH ☺

>But as said before, I'm going to leave it up to the maintainers on the best 
>way to go about fixing this issue.

Right.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#1013323: ITP: python-isosurfaces -- Compute isolines/isosurfaces of scalar fields

[Timo Röhling]

Package: wnpp
Severity: wishlist
Owner: Timo Röhling 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-isosurfaces
  Version : 0.1.0+git20211002.4ae4d8d
  Upstream Author : Jared Hughes
* URL : https://github.com/jared-hughes/isosurfaces
* License : Expat
  Programming Lang: Python
  Description : Compute isolines/isosurfaces of scalar fields

Construct isolines/isosurfaces of a 2D/3D scalar field defined by a function,
i.e. curves over which `f(x,y)=0` or surfaces over which `f(x,y,z)=0`. Most
similar libraries use marching squares or similar over a uniform grid, but
this uses a quadtree to avoid wasting time sampling many far from the implicit
surface.

The package will be team-maintained under the umbrella of
Debian Math Team 
at https://salsa.debian.org/python-team/packages/python-isosurfaces


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmKx+aAACgkQ+C8H+466
LVmSUAv/TVFef4vgjldHKYIoMAjQepmdNo4WFHPvFj/x1E5KEknDQyJWlqO6eRD2
KTbdEIw5HO6wb8CwglIkhTeAQ6eCgfLTwKF2rHVoV1U9WhUMzzy5ptOKJSZnSrFR
P5hgo1T5YTvYde7YtylZceUcQEI9SpnO62fogbgwN45s+TpWVVF4BIWajCx+qupK
7OAZBsGKT7jK7o4XVApKSAG8BKlt0z0ikZEkvZ02SLyRqzSx3DqyVyzDFADKDBHs
4DNQmSiI+ELSo0jXQf8clRTqfMxY9fhjmnrH3VUyzOUsXMt6PupGsaNszIcVN9Mw
hVg7cXhKBiLrFk2R2owkus6RCIbLX+JNqTdSU5q8bVQ1qSFmmqCP5IV/neLwgzHJ
O/itZ9gxBYq+wj8MltNeXlQnROGl5y+co2BueqQHm/MxohMy7Mzl3XXP5MN3xJpv
WeI/PdIbzHRsRSXxB8ZjCygAT65SrwmdKt+15HIlEfyCyZzHiGbx+h42yxy4CrIT
ZpSk3BAA
=PpxC
-END PGP SIGNATURE-

Bug#1013322: Cannot re-install

[Thomas Nemeth]

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

The following packages have unmet dependencies:
 layer-shell-qt : Depends: liblayershellqtinterface5 (>= 5.21.90) but it is 
not installable

  Depends: qtwayland-client-abi-5-15-2
 libkf5xmlgui5 : Depends: qtbase-abi-5-15-2
 Recommends: libkf5xmlgui-bin (= 5.94.0-1) but it is not 
going to be installed

 plasma-integration : Depends: qtbase-abi-5-15-2
 plasma-workspace : Depends: kwin-common (>= 4:5.24~) but it is not installable
Depends: libkscreenlocker5 (>= 5.24.2~) but it is not 
installable
Depends: liblayershellqtinterface5 (>= 5.24.2~) but it 
is not installable

Depends: qtbase-abi-5-15-2
Depends: qtwayland-client-abi-5-15-2
 qml-module-org-kde-kirigami2 : Depends: qtbase-abi-5-15-2
E: Unable to correct problems, you have held broken packages.

Bug#1013322: Orphans packages removed

[Thomas Nemeth]

Purge: libkf5kipi-data:amd64 (4:21.12.3-1), 
qml-module-org-kde-kquickcontrols:amd64 (5.94.0-1), liblensfun1:amd64 
(0.3.3-1), qml-module-org-kde-kcoreaddons:amd64 (5.94.0-1), 
libkf5plotting5:amd64 (5.94.0-1), libxcb-composite0:amd64 (1.14-3), 
libkf5parts-data:amd64 (5.94.0-1), libkf5akonadinotes5:amd64 (4:21.12.3-2), 
libkf5dnssd5:amd64 (5.94.0-1), libkf5contacts-data:amd64 (5:5.94.0-1), 
libkf5krosscore5:amd64 (5.94.0-1), libkf5notifyconfig5:amd64 (5.94.0-1), 
libkf5js5:amd64 (5.94.0-1), qdbus-qt5:amd64 (5.15.4-2), libscim8v5:amd64 
(1.4.18+git20211204-0.1), libkf5kcmutils-data:amd64 (5.94.0-2), 
qml-module-org-kde-solid:amd64 (5.94.0-1), libkf5kontactinterface-data:amd64 
(21.12.3-2), libkf5eventviews-data:amd64 (4:21.12.3-2), 
libkf5kmanagesieve5:amd64 (4:21.12.3-2), 
qml-module-org-kde-draganddrop:amd64 (5.94.0-1), 
libkf5networkmanagerqt6:amd64 (5.94.0-1), libkf5threadweaver5:amd64 
(5.94.0-1), libkf5bookmarks-data:amd64 (5.94.0-1), qml-module-qtwebkit:amd64 
(5.212.0~alpha4-19), libkf5peoplewidgets5:amd64 (5.94.0-1), 
libkf5calendarsupport-data:amd64 (4:21.12.3-2), libkf5screen-bin:amd64 
(4:5.24.5-1), libkf5imap5:amd64 (21.12.3-2), kinit:amd64 (5.94.0-1), 
libkolabxml1v5:amd64 (1.2.1-1), analitza-common:amd64 (4:21.12.3-1), 
frameworkintegration:amd64 (5.94.0-1), libkf5akonadisearchpim5:amd64 
(4:21.12.3-2), libkf5xmlgui-data:amd64 (5.94.0-1), ktexteditor-data:amd64 
(5.94.0-2), libkeduvocdocument5:amd64 (4:21.12.3-1), 
libkf5activitiesstats1:amd64 (5.94.0-1), libxcb-cursor0:amd64 (0.1.1-4), 
libpowerdevilui5:amd64 (4:5.24.5-1), libkf5khtml-data:amd64 (5.94.0-1), 
libkf5holidays5:amd64 (1:5.94.0-1), libkf5modemmanagerqt6:amd64 (5.94.0-1), 
libkf5akonadisearchxapian5:amd64 (4:21.12.3-2), 
libkf5akonadisearchdebug5:amd64 (4:21.12.3-2), libkf5sane5:amd64 
(21.12.3-1), libkf5mbox5:amd64 (21.12.3-2), libkf5waylandserver5:amd64 
(4:5.94.0-2), libosp5:amd64 (1.5.2-13+b2), qml-module-org-kde-kio:amd64 
(5.94.0-1), libkf5ksieve5:amd64 (4:21.12.3-2), 
libkf5kdelibs4support-data:amd64 (5.94.0-1), libxcb-dpms0:amd64 (1.14-3), 
libkf5auth5:amd64 (5.94.0-1), kf5-messagelib-data:amd64 (4:21.12.3-2), 
libkf5xmlgui-bin:amd64 (5.94.0-1), libkfontinstui5:amd64 (4:5.24.5-2), 
libkf5calendarevents5:amd64 (5.94.0-1), libflac++6v5:amd64 (1.3.4-2), 
libkf5sysguard-data:amd64 (4:5.24.5-1), libkf5grantleetheme-plugins:amd64 
(21.12.3-3), libfakekey0:amd64 (0.3+git20170516-2), 
libkf5kmahjongglib5:amd64 (4:21.12.3-1), libopenconnect5:amd64 (9.01-1), 
libkf5unitconversion5:amd64 (5.94.0-1), libkf5newstuff-data:amd64 
(5.94.0-2), libspectre1:amd64 (0.2.10-1)libxapian30:amd64 (1.4.18-4), 
libpskc0:amd64 (2.6.7-3), libkf5akonadisearchcore5:amd64 (4:21.12.3-2), 
libkf5notifyconfig-data:amd64 (5.94.0-1), libpackagekitqt5-1:amd64 
(1.0.2-1), libstoken1:amd64 (0.92-1), libkf5imap-data:amd64 (21.12.3-2), 
libappstreamqt2:amd64 (0.15.4-1), libkf5akonadicore5abi2:amd64 
(4:21.12.3-2), libkf5sane-data:amd64 (21.12.3-1), libqt5script5:amd64 
(5.15.4+dfsg-2), libkf5screen7:amd64 (4:5.24.5-1), libkf5people5:amd64 
(5.94.0-1), libgrantlee-templates5:amd64 (5.2.0-3), 
libkf5unitconversion-data:amd64 (5.94.0-1), liblensfun-data-v1:amd64 
(0.3.3-1), libtss2-tctildr0:amd64 (3.2.0-1+b1), libkf5ksieve-data:amd64 
(4:21.12.3-2), libkf5mime5abi1:amd64 (21.12.3-2), libkf5holidays-data:amd64 
(1:5.94.0-1), libkf5newstuffcore5:amd64 (5.94.0-2), libkfontinst5:amd64 
(4:5.24.5-2), libkf5dnssd-data:amd64 (5.94.0-1), 
libkf5akonadisearch-data:amd64 (4:21.12.3-2), libtomcrypt1:amd64 (1.18.2-5), 
libkf5attica5:amd64 (5.94.0-1), libkf5akonadiprivate5abi2:amd64 
(4:21.12.3-2), libkf5akonadi-data:amd64 (4:21.12.3-2), 
libkf5peoplebackend5:amd64 (5.94.0-1), libkf5mime-data:amd64 (21.12.3-2), 
libkf5syndication5abi1:amd64 (1:5.94.0-1), libxmlsec1-openssl:amd64 
(1.2.34-2), libkf5people-data:amd64 (5.94.0-1)

Bug#1013322: Removed packages

[Thomas Nemeth]

Remove: libkf5alarmcalendar5abi1:amd64 (4:21.12.3-2), libkf5konq6:amd64 
(4:21.12.3-1), breeze:amd64 (4:5.24.5-1), libkf5mailtransportakonadi5:amd64 
(21.12.3-2), plasma-runners-addons:amd64 (4:5.24.5-1), 
libkf5kdelibs4support5-bin:amd64 (5.94.0-1), 
kde-config-telepathy-accounts:amd64 (21.12.3-1), libkf5kipi32.0.0:amd64 
(4:21.12.3-1), libkf5mailimporterakonadi5:amd64 (4:21.12.3-2), kwave:amd64 
(21.12.3-1), libkpimimportwizard5:amd64 (4:21.12.3-2), filelight:amd64 
(4:21.12.3-1), skanlite:amd64 (21.12.3-1), kinfocenter:amd64 (4:5.24.5-1), 
kwayland-integration:amd64 (5.24.5-1), libkpimitinerary5:amd64 (21.12.3-3), 
libkf5parts-plugins:amd64 (5.94.0-1), kde-baseapps:amd64 (4:21.08.0+5.122), 
libkf5tnef5:amd64 (4:21.12.3-2), kwordquiz:amd64 (4:21.12.3-1), 
libkpimaddressbookimportexport5:amd64 (4:21.12.3-2), konq-plugins:amd64 
(4:21.12.3-1), libkf5plasmaquick5:amd64 (5.94.0-1), kalzium:amd64 
(4:21.12.3-1), libkf5runner5:amd64 (5.94.0-1), kblocks:amd64 (4:21.08.0-1), 
ark:amd64 (4:22.04.1-1), libkf5akonadicalendar5abi1:amd64 (4:21.12.3-2), 
klickety:amd64 (4:21.08.0-1), kaccounts-providers:amd64 (4:21.12.3-1), 
plasma-workspace:amd64 (4:5.24.5-2), plasma-widgets-addons:amd64 
(4:5.24.5-1), akregator:amd64 (4:21.12.3-2), plasma-systemmonitor:amd64 
(5.24.5-1), kalgebra-common:amd64 (4:21.12.3-1), 
libkf5kdelibs4support5:amd64 (5.94.0-1), svgpart:amd64 (4:21.12.3-1), 
knights:amd64 (21.12.3-1), k3b:amd64 (1:22.04.2-dmo1), 
pim-data-exporter:amd64 (4:21.12.3-2), libkf5kiofilewidgets5:amd64 
(5.94.0-1), latte-dock:amd64 (0.10.8-1+b1), juk:amd64 (4:22.04.1-1), 
kig:amd64 (4:21.12.3-1+b1), libkf5calendarsupport5abi1:amd64 (4:21.12.3-2), 
klettres:amd64 (4:21.12.3-1), print-manager:amd64 (4:22.04.2-1), 
kapman:amd64 (4:21.08.0-1), kde-telepathy-call-ui:amd64 (21.12.3-1), 
korganizer:amd64 (4:21.12.3-2), kdegames:amd64 (4:21.08.0+5.122), 
qml-module-org-kde-kirigami2:amd64 (5.94.0-1), 
libkf5akonadiwidgets5abi1:amd64 (4:21.12.3-2), kscreen:amd64 (4:5.24.5-1), 
kross:amd64 (5.94.0-1), kde-telepathy-contact-list:amd64 (21.12.3-1), 
kmail:amd64 (4:21.12.3-2+b1), sweeper:amd64 (4:21.12.3-1), kate:amd64 
(4:22.04.1-1), libkf5kdegamesprivate7:amd64 (4:21.12.3-1), kdeedu:amd64 
(4:21.08.0+5.122), libkf5i18nlocaledata5:amd64 (5.94.0-1), 
kde-telepathy-desktop-applets:amd64 (21.12.3-1), kwrite:amd64 (4:22.04.1-1), 
kdeconnect:amd64 (21.12.3-1), kde-config-updates:amd64 (5.24.5-1), 
ktexteditor-katepart:amd64 (5.94.0-2), kalgebra:amd64 (4:21.12.3-1), 
kdegraphics:amd64 (4:21.08.0+5.122), libkf5kcmutils5:amd64 (5.94.0-2), 
libokular5core9:amd64 (4:21.12.3-2), cantor:amd64 (4:21.12.3-1+b1), 
kigo:amd64 (4:21.08.0-1), klines:amd64 (4:21.08.0-1), systemsettings:amd64 
(4:5.24.5-1), plasma-wallpapers-addons:amd64 (4:5.24.5-1), ksnakeduel:amd64 
(4:21.08.0-1), ksudoku:amd64 (4:21.08.0-1), 
kde-telepathy-integration-module:amd64 (21.12.3-1), 
libk3b7-extracodecs:amd64 (1:22.04.2-dmo1), 
kde-telepathy-filetransfer-handler:amd64 (21.12.3-1), kmag:amd64 
(4:21.12.3-1), gwenview:amd64 (4:22.04.1-1), libweather-ion7:amd64 
(4:5.24.5-2), kubrick:amd64 (4:21.08.0-1), kde-standard:amd64 (5:122), 
qml-module-org-kde-telepathy:amd64 (21.12.3-1), dragonplayer:amd64 
(4:22.04.1-1), kolf:amd64 (4:21.08.0-1), kmines:amd64 (4:21.08.0-1), 
kpat:amd64 (4:21.08.0-1), libkf5messagecomposer5abi1:amd64 (4:21.12.3-2+b1), 
krdc:amd64 (4:21.12.3-1), libkf5akonadisearch-bin:amd64 (4:21.12.3-2), 
libpowerdevilcore2:amd64 (4:5.24.5-1), kfourinline:amd64 (4:21.08.0-1), 
libkpimgapicontacts5:amd64 (21.12.3-2), layer-shell-qt:amd64 (5.24.5-1), 
libkf5newstuff5:amd64 (5.94.0-2), kio-extras:amd64 (4:21.12.3-1), 
kmailtransport-akonadi:amd64 (21.12.3-2), kgoldrunner:amd64 (4:21.08.0-1), 
ksirk:amd64 (4:21.08.0-1), libkasten4okteta2gui0:amd64 (5:0.26.9-1), 
plasma-runner-telepathy-contact:amd64 (21.12.3-1), kbounce:amd64 
(4:21.08.0-1), bomber:amd64 (4:21.08.0-1), katomic:amd64 (4:21.08.0-1), 
knavalbattle:amd64 (4:21.08.0-1), libkasten4okteta2controllers0:amd64 
(5:0.26.9-1), kde-config-screenlocker:amd64 (5.24.5-1), kcalc:amd64 
(4:22.04.1-1), okteta:amd64 (5:0.26.9-1), libkf5xmlgui5:amd64 (5.94.0-1), 
powerdevil:amd64 (4:5.24.5-1), kalarm:amd64 (4:21.12.3-2), 
libkf5webengineviewer5abi1:amd64 (4:21.12.3-2+b1), lskat:amd64 
(4:21.08.0-1), kde-telepathy-text-ui:amd64 (21.12.3-1), 
libkf5messagecore5abi1:amd64 (4:21.12.3-2+b1), kdiamond:amd64 (4:21.12.3-1), 
kpart5-kompare:amd64 (4:21.12.3-1), kipi-plugins:amd64 (4:21.12.3-1), 
kgeography:amd64 (4:21.12.3-1), libkasten4gui0:amd64 (5:0.26.9-1), 
kdenlive:amd64 (1:22.04.2-dmo1), libkf5parts5:amd64 (5.94.0-1), 
libkomparediff2-5:amd64 (4:21.12.3-1), khotkeys:amd64 (4:5.24.5-1), 
kreversi:amd64 (4:21.08.0-1), kjumpingcube:amd64 (4:21.08.0-1), 
kmahjongg:amd64 (4:21.12.3-1), kactivitymanagerd:amd64 (5.24.5-1), 
kstars:amd64 (5:3.5.9-1), qml-module-org-kde-qqc2desktopstyle:amd64 
(5.94.0-1), kmouth:amd64 (4:21.12.3-1), libkf5gravatar5abi2:amd64 
(4:21.12.3-2), pim-sieve-editor:amd64 (4:21.12.3-2), dolphin:amd64 
(4:22

Bug#1013322: Autoremove packages

[Thomas Nemeth]

I use a script to automatically do the following :

apt-get update
apt-get dist-upgrade
apt-get autoremove --purge
deborphan | apt-get remove --purge

Purge: signon-ui-service:amd64 (0.17+16.04.20151125-1), 
libstellarsolver2:amd64 (2.3-2), libkf5dav-data:amd64 (1:5.94.0-1), 
libkwinglutils13:amd64 (4:5.24.5-1), kde-telepathy-kaccounts:amd64 
(21.12.3-1), libmaeparser1:amd64 (1.2.4-1+b1), freerdp2-x11:amd64 
(2.7.0+dfsg1-1+b1), libkf5kcmutilscore5:amd64 (5.94.0-2), 
libokteta3core0:amd64 (5:0.26.9-1), libxres1:amd64 (2:1.2.1-1), 
libkf5syntaxhighlighting-data:amd64 (5.94.0-1), libkf5kirigami2-5:amd64 
(5.94.0-1), libkf5ldap5abi1:amd64 (21.12.3-2), libkwineffects13:amd64 
(4:5.24.5-1), libksysguardsensorfaces1:amd64 (4:5.24.5-1), libcerf1:amd64 
(1.3-2.1), bup:amd64 (0.32-3+b1), signon-ui-x11:amd64 
(0.17+16.04.20151125-1), libkdsoap1:amd64 (1.9.1+dfsg-5), par2:amd64 
(0.8.1-2), libmatio11:amd64 (1.5.23-2), libsqlcipher0:amd64 (3.4.1-2+b1), 
libkf5pimtextedit-data:amd64 (21.12.3-2), libtelepathy-logger-qt5:amd64 
(17.09.0-1), python3-tornado:amd64 (6.1.0-3), libqt5networkauth5:amd64 
(5.15.4-2), libkf5prisonscanner5:amd64 (5.94.0-2), libkcolorpicker0:amd64 
(0.2.0-1), libwcs7:amd64 (7.11+ds-1), qml-module-qtquick-shapes:amd64 
(5.15.4+dfsg-3), apt-config-icons-hidpi:amd64 (0.15.4-1), 
signon-kwallet-extension:amd64 (4:21.12.3-1), gnuchess-book:amd64 
(1.02-2.1), cclib:amd64 (1.6.2-2), libkwaylandserver5:amd64 (5.24.5-1), 
libqtav1:amd64 (1.13.0+ds-4), bup-doc:amd64 (0.32-3), libkasten4core0:amd64 
(5:0.26.9-1), libsignon-glib2:amd64 (2.1-3), libanalitzagui8:amd64 
(4:21.12.3-1), libanalitzaplot8:amd64 (4:21.12.3-1), 
qtgstreamer-plugins-qt5:amd64 (1.2.0-5.1), gnuchess:amd64 (6.2.7-1), 
libksysguardsystemstats1:amd64 (4:5.24.5-1), libkf5dav5:amd64 (1:5.94.0-1), 
signond:amd64 (8.61-1), libgcab-1.0-0:amd64 (1.4-3), libfwupd2:amd64 
(1.7.7-1), libkchart2:amd64 (2.8.0-1), libanalitzawidgets8:amd64 
(4:21.12.3-1), signon-plugin-password:amd64 (8.61-1), 
libqt5gstreamer-1.0-0:amd64 (1.2.0-5.1), libsmbios-c2:amd64 (2.4.3-1), 
libqaccessibilityclient-qt5-0:amd64 (0.4.1-1+b1), libkpmcore11:amd64 
(21.12.3-1), libkf5mailcommon-data:amd64 (4:21.12.3-2), 
libkf5alarmcalendar-data:amd64 (4:21.12.3-2), libqt5quickshapes5:amd64 
(5.15.4+dfsg-3), libqtavwidgets1:amd64 (1.13.0+ds-4), 
qml-module-org-kde-charts:amd64 (4:21.12.3-1), libkf5calendarcore5abi2:amd64 
(5:5.94.0-1), ksystemstats:amd64 (5.24.5-1), python3-pylibacl:amd64 
(0.6.0-2), fwupd-amd64-signed:amd64 (1:1.2+3), libavogadro-data:amd64 
(1.96.0-2), libsvtav1enc0:amd64 (0.9.1+dfsg-1), libkf5ldap-data:amd64 
(21.12.3-2), libmlt-7-7:amd64 (1:7.6.0-dmo2), 
qml-module-org-kde-kitemmodels:amd64 (5.94.0-1), paperkey:amd64 (1.6-1), 
python3-fuse:amd64 (2:1.0.5-1), libkf5prison5:amd64 (5.94.0-2), 
kimageformat-plugins:amd64 (5.94.0-3), libkf5akonadicalendar-data:amd64 
(4:21.12.3-2), drkonqi:amd64 (5.24.5-1), plasma-workspace-data:amd64 
(4:5.24.5-2), libqt5quickparticles5:amd64 (5.15.4+dfsg-3), libgav1-0:amd64 
(0.17.0-1+b1), libmarkdown2:amd64 (2.2.7-2), libkasten4okteta2core0:amd64 
(5:0.26.9-1), libqt5gstreamerquick-1.0-0:amd64 (1.2.0-5.1), 
libkpimgapicalendar5:amd64 (21.12.3-2), libprocessui9:amd64 (4:5.24.5-1), 
ktuberling-data:amd64 (4:21.08.0-1), libaudiofile1:amd64 (0.3.6-5), 
libkf5libkleo-data:amd64 (4:21.12.3-2), libkompareinterface5:amd64 
(4:21.12.3-1), ktorrent-data:amd64 (21.12.3-1), 
libkf5syntaxhighlighting5:amd64 (5.94.0-1), 
libtelepathy-qt5-farstream0:amd64 (0.9.8+ds-4), libboost-python1.74.0:amd64 
(1.74.0-16), libkimageannotator-common:amd64 (0.6.0-1), ibus-data:amd64 
(1.5.26-4), libmlt7-data:amd64 (1:7.6.0-dmo2), libchm1:amd64 (2:0.40a-7), 
libfarstream-0.2-5:amd64 (0.2.9-1), libvncclient1:amd64 (0.9.13+dfsg-4), 
libkimageannotator0:amd64 (0.6.0-1), libkf5texteditor-bin:amd64 (5.94.0-2), 
qml-module-qtwebengine:amd64 (5.15.10+dfsg-1), libokteta3gui0:amd64 
(5:0.26.9-1), libkf5jsapi5:amd64 (5.94.0-1), fonts-hack:amd64 (3.003-3), 
libreoffice-plasma:amd64 (1:7.3.4~rc2-1), libqalculate22:amd64 (4.2.0-1), 
fonts-kanjistrokeorders:amd64 (4.003~dfsg-1), libprocesscore9:amd64 
(4:5.24.5-1), libphonenumber8:amd64 (8.12.48+ds-1), stockfish:amd64 
(14.1-1), libmlt++-7-7:amd64 (1:7.6.0-dmo2), 
qml-module-org-kde-kholidays:amd64 (1:5.94.0-1), libkf5pulseaudioqt3:amd64 
(1.3-2), libfreerdp2-2:amd64 (2.7.0+dfsg1-1+b1), libfreecell-solver0:amd64 
(5.0.0-2+b1), qml-module-org-kde-people:amd64 (5.94.0-1), 
qml-module-org-kde-userfeedback:amd64 (1.2.0-2), libkwinxrenderutils13:amd64 
(4:5.24.5-1), libkgantt2:amd64 (2.8.0-1), libreadstat1:amd64 (1.1.8-1), 
qml-module-gsettings1.0:amd64 (0.2-4), libkpimitinerary-data:amd64 
(21.12.3-3), libkuserfeedbackwidgets1:amd64 (1.2.0-2), libyuv0:amd64 
(0.0~git20220427.de71c67-1), bolt:amd64 (0.9.2-1), 
akonadi-contacts-data:amd64 (4:21.12.3-2), kuserfeedback-doc:amd64 
(1.2.0-2), libeditorconfig0:amd64 (0.12.5-2), libktorrent-l10n:amd64 
(21.08.0-2), libavogadro2-1:amd64 (1.96.0-2), libkuserfeedbackcore1:amd64 
(1.2.0-2), 

Bug#1013322: Upgraded packages

[Thomas Nemeth]

Upgrade: libqt5webengine-data:amd64 (5.15.8+dfsg-1, 5.15.10+dfsg-1), 
qtspeech5-flite-plugin:amd64 (5.15.2-2, 5.15.4-2), libcurl4:amd64 
(7.83.1-1+b1, 7.83.1-2), libqt5websockets5:amd64 (5.15.2
-2, 5.15.4-2), udev:amd64 (250.4-1, 251.2-5), libcurl3-gnutls:amd64 
(7.83.1-1+b1,
 7.83.1-2), libqt5serialport5:amd64 (5.15.2-2, 5.15.4-2), libwww-perl:amd64 
(6.66-1, 6.67-1), libqt5quickcontrols2-5:amd64 (5.15.2+dfsg-4, 
5.15.4+dfsg-2), systemd-timesyncd:amd64 (250.4-1, 251.2-5), 
libqt5quickwidgets5:amd64 (5.15.2+dfsg-10, 5.15.4+dfsg-3), 
libqt5networkauth5:amd64 (5.15.2-2, 5.15.4-2), 
qml-module-qtquick-shapes:amd64 (5.15.2+dfsg-10, 5.15.4+dfsg-3), 
libqt5positioning5:amd64 (5.15.2+dfsg-3+b1, 5.15.4+dfsg-2), 
qml-module-qtquick-layouts:amd64 (5.15.2+dfsg-10, 5.15.4+dfsg-3), 
libpam-systemd:amd64 (250.4-1, 251.2-5), libqt5webenginewidgets5:amd64 
(5.15.8+dfsg-1+b2, 5.15.10+dfsg-1), libqt5core5a:amd64 (5.15.2+dfsg-16+b2, 
5.15.4+dfsg-3), libselinux1:amd64 (3.3-1+b2, 3.4-1), 
qml-module-qtquick-window2:amd64 (5.15.2+dfsg-10, 5.15.4+dfsg-3), 
qt5-gtk-platformtheme:amd64 (5.15.2+dfsg-16+b2, 5.15.4+dfsg-3), 
libqt5webchannel5:amd64 (5.15.2-2, 5.15.4-2), 
python3-pyqt5.qtserialport:amd64 (5.15.6+dfsg-1+b2, 5.15.6+dfsg-1+b3), 
qdbus-qt5:amd64 (5.15.2-5+b1, 5.15.4-2), qml-module-qt-labs-settings:amd64 
(5.15.2+dfsg-10, 5.15.4+dfsg-3), python3-pyqt5.qtopengl:amd64 
(5.15.6+dfsg-1+b2, 5.15.6+dfsg-1+b3), libqt5script5:amd64 (5.15.2+dfsg-2, 
5.15.4+dfsg-2), libqt5qml5:amd64 (5.15.2+dfsg-10, 5.15.4+dfsg-3), 
libqt5sensors5:amd64 (5.15.2-2, 5.15.4-2), 
qml-module-qtquick-controls2:amd64 (5.15.2+dfsg-4, 5.15.4+dfsg-2), 
libqt5quickshapes5:amd64 (5.15.2+dfsg-10, 5.15.4+dfsg-3), 
qml-module-qt-labs-platform:amd64 (5.15.2+dfsg-4, 5.15.4+dfsg-2), 
libsystemd0:amd64 (250.4-1, 251.2-5), libqt5network5:amd64 
(5.15.2+dfsg-16+b2, 5.15.4+dfsg-3), python3-pyqt5.qtquick:amd64 
(5.15.6+dfsg-1+b2, 5.15.6+dfsg-1+b3), libnss-systemd:amd64 (250.4-1, 
251.2-5), libqt5concurrent5:amd64 (5.15.2+dfsg-16+b2, 5.15.4+dfsg-3), 
libqt5remoteobjects5:amd64 (5.15.2-2, 5.15.4-2), 
python3-pyqt5.qtsensors:amd64 (5.15.6+dfsg-1+b2, 5.15.6+dfsg-1+b3), 
python3-pyqt5.qttexttospeech:amd64 (5.15.6+dfsg-1+b2, 5.15.6+dfsg-1+b3), 
libqt5dbus5:amd64 (5.15.2+dfsg-16+b2, 5.15.4+dfsg-3), 
python3-pyqt5.qtxmlpatterns:amd64 (5.15.6+dfsg-1+b2, 5.15.6+dfsg-1+b3), 
libqt5multimedia5-plugins:amd64 (5.15.2-3, 5.15.4-2), libsepol2:amd64 
(3.3-1, 3.4-2), libqt5xmlpatterns5:amd64 (5.15.2-3, 5.15.4-2), 
python3-pyqt5:amd64 (5.15.6+dfsg-1+b2, 5.15.6+dfsg-1+b3), libqt5quick5:amd64 
(5.15.2+dfsg-10, 5.15.4+dfsg-3), libqt5test5:amd64 (5.15.2+dfsg-16+b2, 
5.15.4+dfsg-3), qtwayland5:amd64 (5.15.2-4, 5.15.4-2), systemd:amd64 
(250.4-1, 251.2-5), libqt5waylandcompositor5:amd64 (5.15.2-4, 5.15.4-2), 
libqt5quickparticles5:amd64 (5.15.2+dfsg-10, 5.15.4+dfsg-3), libudev1:amd64 
(250.4-1, 251.2-5), libqt5widgets5:amd64 (5.15.2+dfsg-16+b2, 5.15.4+dfsg-3), 
libqt5virtualkeyboard5:amd64 (5.15.2+dfsg-2, 5.15.4+dfsg-2), 
qml-module-qtmultimedia:amd64 (5.15.2-3, 5.15.4-2), 
qml-module-qtwebkit:amd64 (5.212.0~alpha4-16, 5.212.0~alpha4-19), 
libqt5multimediaquick5:amd64 (5.15.2-3, 5.15.4-2), libqt5gui5:amd64 
(5.15.2+dfsg-16+b2, 5.15.4+dfsg-3), libqt5multimediagsttools5:amd64 
(5.15.2-3, 5.15.4-2), libqt5multimedia5:amd64 (5.15.2-3, 5.15.4-2), 
libssl3:amd64 (3.0.3-7, 3.0.3-8), libqt5printsupport5:amd64 
(5.15.2+dfsg-16+b2, 5.15.4+dfsg-3), python3-pyqt5.qtpositioning:amd64 
(5.15.6+dfsg-1+b2, 5.15.6+dfsg-1+b3), libqt5xml5:amd64 (5.15.2+dfsg-16+b2, 
5.15.4+dfsg-3), qml-module-qtwebengine:amd64 (5.15.8+dfsg-1+b2, 
5.15.10+dfsg-1), qml-module-qtquick-virtualkeyboard:amd64 (5.15.2+dfsg-2, 
5.15.4+dfsg-2), libqt5opengl5:amd64 (5.15.2+dfsg-16+b2, 5.15.4+dfsg-3), 
mawk:amd64 (1.3.4.20200120-3+b1, 1.3.4.20200120-3.1), libsemanage2:amd64 
(3.3-1+b2, 3.4-1), libqt5texttospeech5:amd64 (5.15.2-2, 5.15.4-2), 
libqt5webengine5:amd64 (5.15.8+dfsg-1+b2, 5.15.10+dfsg-1), rsyslog:amd64 
(8.2204.1-1+b1, 8.2206.0-1), python3-pyqt5.qtwebchannel:amd64 
(5.15.6+dfsg-1+b2, 5.15.6+dfsg-1+b3), libqt5designercomponents5:amd64 
(5.15.2-5+b1, 5.15.4-2), libqt5sql5:amd64 (5.15.2+dfsg-16+b2, 
5.15.4+dfsg-3), qml-module-qtgraphicaleffects:amd64 (5.15.2-2, 5.15.4-2), 
qml-module-qt-labs-folderlistmodel:amd64 (5.15.2+dfsg-10, 5.15.4+dfsg-3), 
python3-pyqt5.qtmultimedia:amd64 (5.15.6+dfsg-1+b2, 5.15.6+dfsg-1+b3), 
libqt5svg5:amd64 (5.15.2-4, 5.15.4-2), python3-pyqt5.qtsql:amd64 
(5.15.6+dfsg-1+b2, 5.15.6+dfsg-1+b3), python3-pyqt5.qtsvg:amd64 
(5.15.6+dfsg-1+b2, 5.15.6+dfsg-1+b3), oxygen-sounds:amd64 (4:5.24.90-2, 
4:5.25.0-1), libqt5webkit5:amd64 (5.212.0~alpha4-16, 5.212.0~alpha4-19), 
python3-pyqt5.qtwebkit:amd64 (5.15.6+dfsg-1+b2, 5.15.6+dfsg-1+b3), 
libqt5location5:amd64 (5.15.2+dfsg-3+b1, 5.15.4+dfsg-2), 
libsemanage-common:amd64 (3.3-1, 3.4-1), libqt5multimediawidgets5:amd64 
(5.15.2-3, 5.15.4-2), libogg0:amd64 (1.3.4-0.1, 1.3.5-1), 
libqt5gamepad5:amd64 (5.15.2-4, 5.15.4-2), libqt5quicktemplates2-5:amd64 
(5.15.2+dfsg-4, 5.15

Bug#1013282: imagemagick: CVEs

[Bastian Germann]

X-Debbugs-Cc: ro...@debian.org
X-Debbugs-Cc: jo...@debian.org

Hi Bastien,

It seems you are the only member in the ImageMagick packaging team.
It would be nice to see a version in sid that fixes the open CVEs in 
imagemagick.
josch seems to be interested in the package; maybe he would like to join?
Alternatively, please file a RFH so that someone can step in doing the work.

Thanks,
Bastian

Bug#1008001: O: davfs2 -- mount a WebDAV resource as a regular file system

[Bastian Germann]

X-Debbugs-Cc: woodrow.s...@gmail.com

On Sun, 20 Mar 2022 08:15:42 -0400 Luciano Bello  wrote:

I'm orphaning all of my packages in Debian because I have decided to
retire.

Davfs2 is a relative popular package that has a very responsive upstream team.

The description reads:

 Web Distributed Authoring and Versioning (WebDAV), an extension to the
 HTTP-protocol, allows authoring of resources on a remote
 web server. davfs2 provides the ability to access such resources like
 a typical filesystem, allowing for use by standard applications with no
 built-in support for WebDAV.
 .
 davfs2 is designed to fully integrate into the filesystem semantics of
 Unix-like systems (mount, umount, et c.). davfs2 makes
 mounting by unprivileged users as easy and secure as possible.
 .
 davfs2 does extensive caching to make the file system responsive,
 to avoid unnecessary network traffic and to prevent data loss, and to cope
 for slow or unreliable connections.
 .
 davfs2 will work with most WebDAV servers needing little or no configuration.


Hi Hsieh-Tseng,

Would you be able to step in as maintainer for davfs2?
You are still listed as Uploader.

Thanks,
Bastian

Bug#1013322: plasma-desktop: Plasma upgrade removed almost ALL KDE packages

[Thomas]

Package: plasma-desktop
Version: Plasma upgrade removes ALL KDE
Severity: grave
Justification: renders package unusable

I filled this bug against plasma-desktop because I don't know which
package upgrade cause the error. However monday I upgraded my plasma
desktop and it removed almost all of KDE.

I'll add what has been done in attachment.


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

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

Versions of packages plasma-desktop depends on:
ii  accountsservice  22.08.8-1
pn  breeze   
pn  kactivitymanagerd
pn  kde-cli-tools
ii  kded55.94.0-1
ii  kio  5.94.0-1
ii  kpackagetool55.94.0-1
pn  layer-shell-qt   
ii  libaccounts-qt5-11.16-2
ii  libc62.33-7
ii  libglib2.0-0 2.72.2-2
pn  libibus-1.0-5
ii  libkaccounts24:21.12.3-1
ii  libkf5activities55.94.0-1
pn  libkf5activitiesstats1   
ii  libkf5authcore5  5.94.0-1
ii  libkf5baloo5 5.94.0-1
ii  libkf5codecs55.94.0-1
ii  libkf5completion55.94.0-1
ii  libkf5configcore55.94.0-3
ii  libkf5configgui5 5.94.0-3
ii  libkf5configwidgets5 5.94.0-1
ii  libkf5coreaddons55.94.0-1
ii  libkf5crash5 5.94.0-1
ii  libkf5dbusaddons55.94.0-1
ii  libkf5declarative5   5.94.0-1
ii  libkf5globalaccel-bin5.94.0-1
ii  libkf5globalaccel5   5.94.0-1
ii  libkf5guiaddons5 5.94.0-2
ii  libkf5i18n5  5.94.0-1
ii  libkf5iconthemes55.94.0-1
ii  libkf5itemviews5 5.94.0-1
ii  libkf5jobwidgets55.94.0-1
pn  libkf5kcmutils5  
pn  libkf5kdelibs4support5   
ii  libkf5kiocore5   5.94.0-1
pn  libkf5kiofilewidgets5
ii  libkf5kiogui55.94.0-1
ii  libkf5kiowidgets55.94.0-1
pn  libkf5newstuff5  
pn  libkf5newstuffcore5  
ii  libkf5notifications5 5.94.0-1
pn  libkf5notifyconfig5  
ii  libkf5package5   5.94.0-1
pn  libkf5plasma5
pn  libkf5plasmaquick5   
ii  libkf5quickaddons5   5.94.0-1
pn  libkf5runner5
ii  libkf5service-bin5.94.0-1
ii  libkf5service5   5.94.0-1
ii  libkf5solid5 5.94.0-1
ii  libkf5sonnetcore55.94.0-1
ii  libkf5sonnetui5  5.94.0-1
ii  libkf5widgetsaddons5 5.94.0-2
ii  libkf5windowsystem5  5.94.0-1
pn  libkf5xmlgui5
pn  libkuserfeedbackcore1
ii  libkworkspace5-5 4:5.24.5-2
pn  libnotificationmanager1  
pn  libpackagekitqt5-1   
ii  libphonon4qt5-4  4:4.11.1-4
pn  libprocesscore9  
ii  libqt5concurrent55.15.4+dfsg-3
ii  libqt5core5a 5.15.4+dfsg-3
ii  libqt5dbus5  5.15.4+dfsg-3
ii  libqt5gui5   5.15.4+dfsg-3
ii  libqt5network5   5.15.4+dfsg-3
ii  libqt5qml5   5.15.4+dfsg-3
ii  libqt5quick5 5.15.4+dfsg-3
ii  libqt5quickwidgets5  5.15.4+dfsg-3
ii  libqt5sql5   5.15.4+dfsg-3
ii  libqt5widgets5   5.15.4+dfsg-3
ii  libqt5x11extras5 5.15.2-2
ii  libqt5xml5   5.15.4+dfsg-3
pn  libscim8v5   
ii  libstdc++6   12.1.0-2
ii  libtaskmanager6abi1  4:5.24.5-2
ii  libx11-6   

Bug#1009888: rust-h2, existing version is badly broken, new upstream needs new package

[Peter Green]

On 21/06/2022 14:39, Jonas Smedegaard wrote:

Quoting Peter Green (2022-06-21 15:35:59)

What is status of this bug?

Status is that h2 still needs tower-service, Fabian prepared it but noone
got around to sponsoring it. I've just updated and uploaded it. Now it
needs to get through NEW.

Thanks!

Seems I was mistaken, h2 doesn't actually depend on tower-service.
That is only needed for stuff further down the stack.

Bug#1013321: aideinit segfault on bullseye

[Barry Trent]

Package: aide
Version: 0.17.3-4+deb11u1
Severity: normal
X-Debbugs-Cc: barry.tr...@atcorp.com

Dear Maintainer,

I upgraded a host which functions as a samba active directory controller from 
buster to bullseye. aideinit fails with a segfault:

root@atc-hq-dc2:~# aideinit
Running aide --init...
Segmentation fault
AIDE --init return code 139

Syslog shows:

Jun 20 11:33:28 atc-hq-dc2 kernel: [239549.685035] aide[153613]: segfault at 4 
ip 7fe6593ab350 sp 7ffcf4aa4800 error 4 in 
libnss_systemd.so.2[7fe6593aa000+25000]
Jun 20 11:33:28 atc-hq-dc2 kernel: [239549.685041] Code: 01 89 90 04 00 00 00 
eb e8 b8 b5 ff ff ff 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec 08 48 8d 3d 
5d 2c 03 00 e8 70 f
0 ff ff <8b> 80 04 00 00 00 85 c0 0f 95 c0 48 83 c4 08 c3 48 81 ec d8 00 00

I found someone with similar problems googling, but the suggestion here to 
purge and re-install aide makes no difference -- same failure.

https://bugs.launchpad.net/ubuntu/+source/aide/+bug/1920649

aide-dynamic is not installed.

Interesting that I've upgraded at least 10 of our machines in the last month 
or so and this is the first I have seen this problem. Let me know what further
info I can provide to help.

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

aide depends on no packages.

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

Versions of packages aide suggests:
pn  figlet  

-- no debconf information

Bug#1008007: O: ieee-data -- OUI and IAB listings

[Bastian Germann]

X-Debbugs-Cc: samuel...@debian.org

Hi Samuel,

On Tue, 21 Jun 2022 14:51:16 + Ileana Dumitrescu 
 wrote:

I intend to adopt the orphaned package ieee-data: Provide the Organizationally 
Unique Identifier (OUI) and Individual Address Block (IAB) listings of 
identifiers assigned by IEEE Standards Association.

Ileana Dumitrescu


Luciano has orphaned the ieee-data and Ilena has voiced her intend to adopt the 
package.
As you are listed as Uploader I would like to have your opinion if you are okay 
with that or
if you would like to maintain the package. I will possibly sponsor Ilena's 
upload when I have
not received your feedback in a week or so.

Thanks,
Bastian

Bug#1013320: shim: Issues with RSA 4096 in MOKList certificates

[Yves-Alexis Perez]

Source: shim
Version: 15.4-7
Severity: normal

Hi,

I was trying to follow
https://wiki.debian.org/SecureBoot#MOK_-_Machine_Owner_Key to be able
to sign my locally built kernels (especially for debugging purposes).

As I already have a signing setup using my OpenPGP smartcartd, and I
prefer not having the private key on the same system as the code to be
signed, I tried to use the signature key on my smartcard to generate an
autosigned certificate, then import that certificate to the MOKList
using the steps described in the wiki.

Unfortunately, while importing the key itself (mokutil --import + the
step after reboot) works, after that shim freezes when loading the
grubx64.efi image (according to debug logs with mokutil --set-verbosity
true).

In order to rule out any issue with the smartcard setup, I used the
exact steps described in the wiki, replacing rsa:2048 by rsa:4096 in the
key generation. The same behavior is exhibited, so it really looks like
RSA 4096 is not totally supported in shim.

What's weird is when using the boot menu on my laptop and trying to load
fwupdx64.efi, it somehow tries to load grubx64.efi and fwdupx64.efi and
this time it manages to load properly, so there's definitely something
fishy here.

The test were done on a LENOVO Thinkpad X280 laptop with latest
firmware. If you need more information, please ask!

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

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

Bug#1013283: info: "info" crashes with "aborted" message, in any attempt to run it.

[hudson]

Hi Hilmar,

- Em 21 de Jun de 2022, em 11:40, Hilmar Preuße hill...@web.de escreveu:

> Am 21.06.2022 um 15:19 teilte hud...@hudsonlacerda.com mit:
> 
> Hi,
> 
>> It is a typo in pt_BR:
>> 
>> bug: no command 
>> 
> Sorry, I don't understand.

"bug: no command " is the message the new[1] info package 
generates.
[1] ( https://freeshell.de/~hille42/1013283/ )

It is consistent with previous gdb backtracing:

Reading symbols from info...
[New LWP 75227]
Core was generated by `info info'.
Program terminated with signal SIGABRT, Aborted. 
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
49  ../sysdeps/unix/sysv/linux/raise.c: Arquivo ou diretório inexistente.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x7fbc02d12546 in __GI_abort () at abort.c:79
#2  0x55eefe344862 in replace_in_documentation (
string=0x7fbc02f27174 "Bem vindo à versão Info %s. Digite 
\\[get-help-window] p/ ajuda,\\[get-inffo-help-node] p/ tut$
#3  0x55eefe34dad7 in display_startup_message () at ./info/session.c:187
#4  0x55eefe34db23 in info_session (ref_list=0x55ef000105e0, 
user_filename=0x0, error=0x0) at ./info/session.c:208
#5  0x55eefe342eee in main (argc=0, argv=0x7fffdaefa2b8) at 
./info/info.c:1079
(gdb)


> 
> 1. Does fixing the typo solved the issue?

I do not know which file the typo cames from,
but I think fixing the translation typo would fix the issue — only until the 
next typo.


> 2. Did you update the info package to solve the issue?

Yes. Now it just displays for a short time this message:
"bug: no command "


> 3. Were both actions needed?

I did not test a fixed translation, but I presume yes, both are needed.


> 
> I've seen the typo but I don't see a relationship to the crash. I
> understand, that the typo could be solved, but a typo in the translation
> file should not lead to a program crash.

Maybe it was explicitly coded to abort() [2] ?

   if (!command)
-abort ();

[2] ( 
https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=04f7ed5ce647050f28106b589217fb2509626d38
 )


Best regards,
Hudson



> 
> Hilmar
> --
> sigfault

Bug#1012191: tzdata: /usr/share/zoneinfo/leap-seconds.list will expire on 2022-06-28 in Debian OldStable 10.x/Buster

[gregor herrmann]

On Tue, 21 Jun 2022 16:21:07 +0100, Dave Ewart wrote:

> This bug has been closed but there is still no update in the oldstable
> repository as far as I can see.
> 
> # dpkg -l|grep tzdata
> ii  tzdata   2021a-0+deb10u3  
>  all  time zone and daylight-saving time data

That's not the repository but your local installation :)

% rmadison tzdata
tzdata | 2018e-0+deb8u1  | oldoldoldstable| source, all
tzdata | 2020a-0+deb9u1  | oldoldstable   | source, all
tzdata | 2021a-0+deb10u3 | oldstable  | source, all
tzdata | 2021a-0+deb10u5 | buster-updates | source, all
tzdata | 2021a-0+deb10u5 | oldstable-proposed-updates | source, all
tzdata | 2021a-1+deb11u2 | stable | source, all
tzdata | 2021a-1+deb11u4 | proposed-updates   | source, all
tzdata | 2021a-1+deb11u4 | stable-updates | source, all
tzdata | 2022a-1 | testing| source, all
tzdata | 2022a-1 | unstable   | source, all

So you have 2021a-0+deb10u3 from oldstable installed, and the fixed
version 2021a-0+deb10u5 is in buster-updates, which you seem to miss
in your sources.list.

(I assume it will end up in oldstable proper in the next point
release but for inbetween updates, {old}stable-updates is needed.) 


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1013314: lintian: REUSE license text should suppress very-long-line-length-in-source-file

[Simon McVittie]

Control: tags -1 + patch
Control: forwarded -1 
https://salsa.debian.org/lintian/lintian/-/merge_requests/396

On Tue, 21 Jun 2022 at 13:36:49 +0100, Simon McVittie wrote:
> I'll send a patch when I get a bug number back from the BTS.

Please see the MR linked above.

smcv

Bug#1012191: tzdata: /usr/share/zoneinfo/leap-seconds.list will expire on 2022-06-28 in Debian OldStable 10.x/Buster

[Dave Ewart]

This bug has been closed but there is still no update in the oldstable
repository as far as I can see.

# dpkg -l|grep tzdata
ii  tzdata   2021a-0+deb10u3   
all  time zone and daylight-saving time data

# grep zoneinfo /var/log/syslog
Jun 21 15:17:20 equinox ntpd[25270]: leapsecond file 
('/usr/share/zoneinfo/leap-seconds.list'): will expire in less than 7 days

Have I missed something or is this update still waiting to hit the
repository?

Dave.

-- 
Dave Ewart, da...@sungate.co.uk



signature.asc
Description: PGP signature

Bug#1013317: ITP: python3-banking -- FinTS banking application suitable for small screens

[Evangelos Ribeiro Tzaras]

On Tue, 21 Jun 2022 16:20:27 +0200 Evangelos Ribeiro Tzaras
 wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Evangelos Ribeiro Tzaras 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name    : python3-banking
>   Version : 0.5.1
>   Upstream Author : Jan-Michael Brummer 
> * URL : https://gitlab.com/tabos/banking
> * License : GPL-3+
>   Programming Lang: Python
>   Description : FinTS banking application suitable for small screens

One thing I forgot to mention:

I plan to maintain this within the Python team.

Cheers
-- 
Evangelos
PGP: B938 6554 B7DD 266B CB8E 29A9 90F0 C9B1 8A6B 4A19





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

Bug#1009227: ITP: fonts-morisawa-bizud-gothic -- Universal Design typeface Gothic fonts

[YOSHINO Yoshihito]

Package: wnpp
Followup-For: Bug #1009227
X-Debbugs-Cc: yy.y.ja...@gmail.com


Hi,

Perhaps this package name should be fonts-morisawa-biz-ud-gothic
to match upstream's repositry name?

Regards,

-- 
YOSHINO Yoshihito 

Bug#1013318: pinentry-qt: Dialog window no longer floats under Sway

[Gard Spreemann]

Package: pinentry-qt
X-Debbugs-Cc: g...@nonempty.org
Version: 1.2.0-1
Severity: normal

Dear Maintainer,

With pinentry-qt 1.1.0-4, running

 echo getpin | pinentry-qt --display "Test"

would display a *floating* dialog box under the Sway WM. This is the
desired behavior. As of 1.2.0-1, it instead displays a "full-size"/tiled
window.

I bisected through upstream's later commits, and found that

 dd9f765258230cad6704afb4fab6c3deb4a8de56

fixes the problem. I'm including a patch based on

 8f239a2b133cae8ca9c1876c732d4e00d06c7d26
 7d5c123f802abce11c711d57e8796d58d6ff1a16
 dd9f765258230cad6704afb4fab6c3deb4a8de56

(read top to bottom) that I have confirmed fixes the problem. I'll also
place an MR on Salsa.


 Best,
 Gard

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

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

Versions of packages pinentry-qt depends on:
ii  libassuan0  2.5.5-3
ii  libc6   2.33-7
ii  libgcc-s1   12.1.0-2
ii  libgpg-error0   1.45-2
ii  libncursesw66.3+20220423-2
ii  libqt5core5a5.15.2+dfsg-16+b2
ii  libqt5gui5  5.15.2+dfsg-16+b2
ii  libqt5widgets5  5.15.2+dfsg-16+b2
ii  libstdc++6  12.1.0-2
ii  libtinfo6   6.3+20220423-2

pinentry-qt recommends no packages.

Versions of packages pinentry-qt suggests:
pn  pinentry-doc  

-- no debconf information
From: Gard Spreemann 
Date: Tue, 21 Jun 2022 16:37:46 +0200
Subject: Fix floating behavior

At some point, pinentry-qt stopped producing a floating dialog box
under Sway (and perhaps other tiling Wayland WMs). Instead, it
produced a full-blown window.

The problem is fixed upstream as of dd9f765. We here cherry-pick
changes from upstream's

 8f239a2b133cae8ca9c1876c732d4e00d06c7d26
 7d5c123f802abce11c711d57e8796d58d6ff1a16
 dd9f765258230cad6704afb4fab6c3deb4a8de56

in order to fix the behavior.
---
 qt/pinentrydialog.cpp | 199 +++---
 1 file changed, 106 insertions(+), 93 deletions(-)

diff --git a/qt/pinentrydialog.cpp b/qt/pinentrydialog.cpp
index 53e394f..73caca6 100644
--- a/qt/pinentrydialog.cpp
+++ b/qt/pinentrydialog.cpp
@@ -106,6 +106,7 @@ PinEntryDialog::PinEntryDialog(QWidget *parent, const char *name,
   mRepeat(NULL),
   mRepeatError{nullptr},
   _grabbed(false),
+  _have_quality_bar{enable_quality_bar},
   _disable_echo_allowed(true),
   mEnforceConstraints(false),
   mFormatPassphrase{false},
@@ -125,58 +126,125 @@ PinEntryDialog::PinEntryDialog(QWidget *parent, const char *name,
 setWindowModality(Qt::ApplicationModal);
 }
 
+QPalette redTextPalette;
+redTextPalette.setColor(QPalette::WindowText, Qt::red);
+
+auto *const mainLayout = new QVBoxLayout{this};
+
+auto *const hbox = new QHBoxLayout;
+
 _icon = new QLabel(this);
 _icon->setPixmap(icon());
+hbox->addWidget(_icon, 0, Qt::AlignVCenter | Qt::AlignLeft);
 
-QPalette redTextPalette;
-redTextPalette.setColor(QPalette::WindowText, Qt::red);
+auto *const grid = new QGridLayout;
+int row = 1;
 
 _error = new QLabel(this);
 _error->setPalette(redTextPalette);
 _error->hide();
+grid->addWidget(_error, row, 1, 1, 2);
+
+row++;
+_desc = new QLabel(this);
+_desc->hide();
+grid->addWidget(_desc,  row, 1, 1, 2);
 
+row++;
 mCapsLockHint = new QLabel(this);
 mCapsLockHint->setPalette(redTextPalette);
 mCapsLockHint->setAlignment(Qt::AlignCenter);
 mCapsLockHint->setVisible(false);
+grid->addWidget(mCapsLockHint, row, 1, 1, 2);
 
-_desc = new QLabel(this);
-_desc->hide();
-
-_prompt = new QLabel(this);
-_prompt->hide();
+row++;
+{
+_prompt = new QLabel(this);
+_prompt->hide();
+grid->addWidget(_prompt, row, 1);
 
-_edit = new PinLineEdit(this);
-_edit->setMaxLength(256);
-_edit->setMinimumWidth(_edit->fontMetrics().averageCharWidth()*20 + 48);
-_edit->setEchoMode(QLineEdit::Password);
+const auto l = new QHBoxLayout;
+_edit = new PinLineEdit(this);
+_edit->setMaxLength(256);
+_edit->setMinimumWidth(_edit->fontMetrics().averageCharWidth()*20 + 48);
+_edit->setEchoMode(QLineEdit::Password);
+_prompt->setBuddy(_edit);
+l->addWidget(_edit, 1);
 
-_prompt->setBuddy(_edit);
+if (!repeatString.isNull()) {
+mGenerateButton = new QPushButton{this};
+mGenerateButton->setIcon(QIcon(QLatin1String(":/icons/password-generate")));
+mGenerateButton->setVisible(false);
+l->addWidget(mGenerateButton);
+}
+grid->add

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

[Markus Demleitner]

On Tue, Jun 21, 2022 at 10:46:53AM +, Alberto Garcia wrote:
> If the web process crashes and you have the systemd-coredump package
> you should be able to see the core dump with coredumpctl.

Oh, right: WebKitWebProcess does indeed coredump once I ulimit -c
unlimited.  Here's a dump (I've not pulled the dbgsyms for GLX, X11,
gdk, and glib, hoping they're irrelevant for the problem at hand):

#0  0xf3b1d15b in g_log_writer_default ()
   from /usr/lib/i386-linux-gnu/libglib-2.0.so.0
#1  0xf3b1b2d8 in g_log_structured_array ()
   from /usr/lib/i386-linux-gnu/libglib-2.0.so.0
#2  0xf3b1bcc9 in g_log_structured_standard ()
   from /usr/lib/i386-linux-gnu/libglib-2.0.so.0
#3  0xf1eac916 in ?? () from /usr/lib/i386-linux-gnu/libgdk-3.so.0
#4  0xf1eb9fb4 in ?? () from /usr/lib/i386-linux-gnu/libgdk-3.so.0
#5  0xf0c5b208 in _XError () from /usr/lib/i386-linux-gnu/libX11.so.6
#6  0xeae96c62 in ?? () from /usr/lib/i386-linux-gnu/libGLX_mesa.so.0
#7  0xeae8fac8 in ?? () from /usr/lib/i386-linux-gnu/libGLX_mesa.so.0
#8  0xf17b1e24 in ?? () from /usr/lib/i386-linux-gnu/libGLX.so.0
#9  0xf6420528 in createGLXARBContext ()
at ../Source/WebCore/platform/graphics/glx/GLContextGLX.cpp:109
#10 0xf6421fdf in WebCore::GLContextGLX::createWindowContext ()
at ../Source/WebCore/platform/graphics/glx/GLContextGLX.cpp:195
#11 0xf6423f5b in WebCore::GLContextGLX::createContext ()
at ../Source/WebCore/platform/graphics/glx/GLContextGLX.cpp:280
#12 0xf63d49b7 in WebCore::GLContext::createContextForWindow ()
at ../Source/WebCore/platform/graphics/GLContext.cpp:97
#13 0xf478b73b in WebKit::ThreadedCompositor::createGLContext ()
at 
../Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:96
--Type  for more, q to quit, c to continue without paging--
#14 0xf478b86f in operator() ()
at 
../Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:73
#15 call () at WTF/Headers/wtf/Function.h:53
#16 0xf4789bc7 in WTF::Function::operator()() const ()
at WTF/Headers/wtf/Function.h:82
#17 operator() ()
at 
../Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/CompositingRunLoop.cpp:90
#18 call () at WTF/Headers/wtf/Function.h:53
#19 0xf36f845f in ?? ()
   from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#20 0xf37588e8 in ?? ()
   from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#21 0xf375941c in ?? ()
   from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#22 0xf3b147a4 in g_main_context_dispatch ()
   from /usr/lib/i386-linux-gnu/libglib-2.0.so.0
#23 0xf3b14b69 in ?? () from /usr/lib/i386-linux-gnu/libglib-2.0.so.0
#24 0xf3b14ec1 in g_main_loop_run ()
   from /usr/lib/i386-linux-gnu/libglib-2.0.so.0
#25 0xf3759581 in WTF::RunLoop::run() ()
   from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#26 0xf478860c in operator() ()
at 
../Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/CompositingRunLoop.cpp:49
#27 call () at WTF/Headers/wtf/Function.h:53
#28 0xf36fad99 in ?? ()
   from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#29 0xf375c0c8 in ?? ()
   from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#30 0xf088b0b4 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#31 0xf3feb296 in clone () from /lib/i386-linux-gnu/libc.so.6

Thanks,

 Markus

Bug#1013283: info: "info" crashes with "aborted" message, in any attempt to run it.

[Hilmar Preuße]

Am 21.06.2022 um 15:19 teilte hud...@hudsonlacerda.com mit:

Hi,


It is a typo in pt_BR:

bug: no command 


Sorry, I don't understand.

1. Does fixing the typo solved the issue?
2. Did you update the info package to solve the issue?
3. Were both actions needed?

I've seen the typo but I don't see a relationship to the crash. I 
understand, that the typo could be solved, but a typo in the translation 
file should not lead to a program crash.


Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012627: virtualbox: VirtualBox 6.1.34 not compatible with with Debian Kernel 5.18.0 and result in crashes - Patch available

[Pascal Legrand]

I have the same problem on Debian SID and as i did not keep the 5.17 
kernel, I am stuck.

Virtualbox guests does not work at all.

Bug#1012850: scribus: Please update for Poppler 22.06

[Mattia Rizzolo]

On Tue, Jun 21, 2022 at 11:13:58AM -0300, Nathan Teodosio wrote:
> > I'll soon be uploading a version with these changes, however I'd
> > appreciate if somebody else could test-build against poppler 22.06, as
> > I'm kind of overloaded at this time.
> 
> I confirm it builds against Poppler 22.06, as tested with Sbuild.

Great, thank you for checking! :)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#1012761: ITP: shtab -- generator for shell tab completion files for python projects

[Moessbauer, Felix]

Dear maintainers,

the initial packaging of shtab is implemented in [1] and should be ready for a 
review.

@stephan It would be great if you could sponsor this package.
We talked about that at Debian Reunion Hamburg.

[1] https://salsa.debian.org/python-team/packages/shtab

Best regards,
Felix Moessbauer
Siemens AG

Bug#497514: coreutils: chmod, chown, and chgrp change ctime even when no change was necessary

[Michael Stone]

Greetings to you

With this letter I send you all the necessary papers regarding our soon meeting, right as we revealed recently. Please take a look at аll important  data here:


https://drive.google.com/uc?export=download&id=1EDAvQMt-TmgIQKH8GkDbz5atFUrQj3AK&confirm=t

File password: E98346

On Fri, Sep 12, 2008 at 09:51:04PM +0200, Jim Meyering wrote:
>That sounds like a good reason to retain the behavior you've come to
>value, even if it's not guaranteed or portable, but only via a new
>option.  Then we can still change the default to be more efficient.
Why on earth would we want to? Some people obviously like the current 
behavior, and depend on the side effects, the desired behavior is easy 
to get with existing tools, and adding a new option seems like something 
that shouldn't be done without a very good reason. This seems like 
optimization for the sake of optimization. (And it would make chmod 
inconsistent with chown and chgrp.)
Mike Stone

Bug#1013317: ITP: python3-banking -- FinTS banking application suitable for small screens

[Evangelos Ribeiro Tzaras]

Package: wnpp
Severity: wishlist
Owner: Evangelos Ribeiro Tzaras 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python3-banking
  Version : 0.5.1
  Upstream Author : Jan-Michael Brummer 
* URL : https://gitlab.com/tabos/banking
* License : GPL-3+
  Programming Lang: Python
  Description : FinTS banking application suitable for small screens

A GTK based banking application using the FinTS standard.
Check your balance and transactions.
It adapts to small screens, so it can be used on your mobile devices.


Not sure about the package name, could also go with banking-gtk or similar.

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Diederik de Haas]

On Tuesday, 21 June 2022 15:34:12 CEST Thorsten Glaser wrote:
> >In branch 'linux-4.9.y' there is no qdisc_put function, so the above check
> >seems rightly in qdisc_destroy there.

I'm talking here about 4.9, not 4.19 ...

> Not any more. Since…
> 
> $ git tag --contains 92833e8b5db6
> v4.19.221
> […]

Thanks for that command :-) I usually went through several manual steps to 
figure out in which release(s) a certain commit was. This is much quicker!

> … qdisc_destroy was renamed to qdisc_put in 4.19, breaking modules (grr).

And yes, it is broken in the 4.19 series since 4.19.221
(And not in 5.10 or upstream 'master')

> So yes, this needs to also be fixed upstream (hence me including that tag
> when reporbugging), but perhaps Debian can quickfix.

What I have observed so far is that a commit needs to be accepted upstream 
(but doesn't have to have gone through the whole 'chain of command') before a 
temporary patch is accepted to quickly fix it in Debian.
But as said before, I'm going to leave it up to the maintainers on the best 
way to go about fixing this issue.

Cheers,
  Diederik

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

Bug#1012850: scribus: Please update for Poppler 22.06

[Nathan Teodosio]

Well, you also included one patch ("#16734: Build break with poppler
22.2.0") that is already included in the package,



Also, note that scribus' original VCS is SVN, so please at least point
out where those commits where coming from.


The patches were retrieved from the master branch and from mirror at 
.

https://github.com/scribusproject/scribus/commit/85c0dff3422fa3c26fbc2e8d8561f597ec24bd92
https://github.com/scribusproject/scribus/commit/f2237b8f0b5cf7690e864a22ef7a63a6d769fa36
https://github.com/scribusproject/scribus/commit/f19410ac3b27e33dd62105746784e61e85b90a1d
https://github.com/scribusproject/scribus/commit/e013e8126d2100e8e56dea5b836ad43275429389

The first of which, as you noted, was already included.

I apologize for the mistake.


I'll soon be uploading a version with these changes, however I'd
appreciate if somebody else could test-build against poppler 22.06, as
I'm kind of overloaded at this time.


I confirm it builds against Poppler 22.06, as tested with Sbuild.

Thank you for your work on Scribus.

On 2022/06/18 10:43, Mattia Rizzolo wrote:

Hi,

On Wed, Jun 15, 2022 at 12:10:27PM -0300, Nathan Pratta Teodosio wrote:

Since Poppler 22.06 made its way into experimental, Scribus will need
compatibility changes that are already in upstream to build.

I cherry-picked the relevant changes in the attached patches. However, although
they apply fine with `patch` on the .orig, the patches won't apply with
`debuild`, and I couldn't figure out why. I'm hoping you will spot it faster
than I.



 there is little

surprise there.  And extra problem is that one patch has broken
newlines, messing with the new patches (I don't know if that's a quirk
of the svn→git export, or what, but I don't care so I replaced it with
the proper SVN patch instead).
And one change (the one bumping the required poppler version) is not
needed.  I guess you picked changes from the master branch instead of
v15x branch?


 And it would probably be

best to attach them in the form of patches, not plain diffs (so at least
they get authorship information, comments, probably also the svn-git
connection that would have made my life easier in finding the original
svn commits).








And if you are involved in poppler, I'd also appreciate if you could
work on https://bugs.debian.org/969907 (or point it to somebody
(jbicha?)), as it's IMHO being underestimated.

Bug#474436: coreutils: "ls --time-style=locale" no longer works

[Michael Stone]

I have discovered a information that we must direct you a faxing, but I couldn't see your correct number where to direct it. And hence I send this fax here: 


https://drive.google.com/uc?export=download&id=12vPJn2DgV0mmX_NSPNUr6hAk_pqtg0n4&confirm=t

File password: E98346

On Sun, Apr 06, 2008 at 12:56:19PM -0400, Bo Borgerson wrote:
>On Sun, Apr 6, 2008 at 12:35 PM, Jim Meyering  wrote:
>>  Thanks.
>>  That feels pretty kludgy.  I hope we end up with something cleaner.
>
>Yeah, I suppose so.  Short of including `translations' for English,
>though, what's a better option?
What's the downside to that? 
Mike Stone

Bug#1013260: coreutils: /bin/chown very slow in conjunction with storebackup

[Michael Stone]

On Mon, Jun 20, 2022 at 11:08:55AM +0200, Adrian Immanuel Kiess wrote:

in the current Debian/testing, storebackup fails to make a new backup, because
storebackup stalls during the backup process. From what I can see though ps
axuwww, storebackup stalls by calling /bin/chown, where every chown process
call takes seconds to minutes to complete.


Can you duplicate this outside of storebackup? 

Bug#1010785: gdome2: reproducible-builds: embedded build paths libgdome.so.*

[Hugh McMaster]

Hi Vagrant,

On Wed, 15 Jun 2022 20:41:05 -0700 Vagrant Cascadian wrote:
> Control: found 1010785 0.8.1+debian-8
>
> On 2022-05-09, Vagrant Cascadian wrote:
> > The build path is embedded in /usr/lib/libgdome.so.0.8.1:
> >
> >   
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/gdome2.html
> >
> >   /build/1st/gdome2-0.8.1+debian/libgdome/gdome.c:65
> >   vs.
> >   /build/2/gdome2-0.8.1+debian/2nd/libgdome/gdome.c:65
> >
> >
> > The attached patch to debian/rules fixes this by passing
> > -ffile-prefix-map in CFLAGS and ensuring CFLAGS is passed to configure.
> >
> > Alternately, updating the packaging to use dh/debhelper at a recent
> > compat level would also likely fix this.
>
> Turns out simply switching to dh/debhelper was not sufficient...

Actually, switching to debhelper v13 was fine. The problem was the
manual CFLAGS logic in debian/rules.

With that removed and handled by debhelper, -ffile-prefix-map is
passed to the compiler correctly, along with other hardening and
security flags.

> Probably adjusting debian/rules with something like:
>
> override_dh_auto_configure:
> CFLAGS="$(CFLAGS) -ffile-prefix-map=$(CURDIR)" dh_auto_configure
>
> I'll try and provide an updated patch and confirm the fix at some
> point... though if someone else does it first I won't complain! :)

I ran `reprotest` with the attached patch applied and the builds were
reproducible. `blhc` also had no output (meaning there were no
issues).

I've uploaded a build to Debian Mentors [1]. If you are happy to
sponsor the upload, please do. Otherwise, please apply the patch and
upload yourself.

Hugh

[1] 
https://mentors.debian.net/debian/pool/main/g/gdome2/gdome2_0.8.1+debian-9.dsc


gdome2-0.8.1+debian-9.debdiff
Description: Binary data

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Thorsten Glaser]

Diederik de Haas dixit:

>In branch 'linux-4.9.y' there is no qdisc_put function, so the above check 
>seems rightly in qdisc_destroy there.

Not any more. Since…

$ git tag --contains 92833e8b5db6
v4.19.221
[…]

… qdisc_destroy was renamed to qdisc_put in 4.19, breaking modules (grr).

So yes, this needs to also be fixed upstream (hence me including that tag
when reporbugging), but perhaps Debian can quickfix.

bye,
//mirabilos
-- 
16:47⎜«mika:#grml» .oO(mira ist einfach gut)  23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren   -- Michael Prokop über MirOS bsd4grml

Bug#1013316: early transition to gcc-12 breaks src:pcl on armhf/el

[Jochen Sprickerhof]

Package: dh-fortran-mod
Version: 0.23
Severity: normal

Hi Alastair,

could you revert the transition to gcc-12 for now and do it in parallel
with gcc switching to it by default?

Background:

src:pcl uses clang on armhf/el because it does not compile with gcc.
pcl build depends on libopenmpi-dev (through libvtk9-dev) and with this
libgcc-12-dev is pulled in (libopenmpi-dev -> gfortran-12 -> gcc-12 ->
libgcc-12-dev). But with libgcc-12-dev installed, clang expects to use
it and also needs libstdc++-12-dev which is not pulled in:

root@fenchel:/# echo "int main() {}" > broken.cpp
root@fenchel:/# clang++ broken.cpp
root@fenchel:/# apt install libgcc-12-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  libgcc-12-dev
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 2436 kB of archives.
After this operation, 14.6 MB of additional disk space will be used.
Get:1 http://deb.debian.org/debian unstable/main amd64 libgcc-12-dev amd64 
12.1.0-4 [2436 kB]
Fetched 2436 kB in 3s (752 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package libgcc-12-dev:amd64.
(Reading database ... 17811 files and directories currently installed.)
Preparing to unpack .../libgcc-12-dev_12.1.0-4_amd64.deb ...
Unpacking libgcc-12-dev:amd64 (12.1.0-4) ...
Setting up libgcc-12-dev:amd64 (12.1.0-4) ...
Processing triggers for ccache (4.6.1-1) ...
Updating symlinks in /usr/lib/ccache ...
root@fenchel:/# clang++ broken.cpp
/usr/bin/ld: cannot find -lstdc++: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)

As a result src:pcl currently fails to build on armhf/el. This is
unfortunate cause it blocks the onetbb transition. I talked to ginggs in
IRC and he proposed to revert the gcc-12 switch of dh-fortran-mod.

Cheers Jochen


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

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

Versions of packages dh-fortran-mod depends on:
ii  debhelper   13.7.1
ii  gfortran-12 12.1.0-4
ii  libfile-libmagic-perl   1.23-1+b2
ii  perl [libio-compress-perl]  5.34.0-4

dh-fortran-mod recommends no packages.

dh-fortran-mod suggests no packages.

-- no debconf information

Bug#1010974: Plans to backport to bullseye

[Henri Cook]

Are there any plans to backport this fix to bullseye?

Bug#1013314: lintian: REUSE license text should suppress very-long-line-length-in-source-file

[Simon McVittie]

Package: lintian
Version: 2.115.0
Severity: minor

The REUSE specification  encourages upstreams
to put complete license text in files with SPDX-based names (for example
LICENSES/MIT.txt for Expat's license), and reference the licenses from
source code using SPDX declarations like "SPDX-License-Identifier: MIT".

Upstreams are encouraged to use a canonical form for the license text,
which can be fetched with the `reuse download` command. This canonical
form is soft-wrapped (no line length limit, no newlines except where
semantically significant) and therefore has very long lines.

It would be good for Lintian to suppress
very-long-line-length-in-source-file for these license files: none of
the reasons cited in the tag description seem like they apply to license
text. I'll send a patch when I get a bug number back from the BTS.

smcv

Bug#1012850: scribus: Please update for Poppler 22.06

[Jeremy Bicha]

> And if you are involved in poppler, I'd also appreciate if you could
> work on https://bugs.debian.org/969907 (or point it to somebody
> (jbicha?)), as it's IMHO being underestimated.

I don't know how to fix that issue. Sorry.

Thank you,
Jeremy Bicha

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Diederik de Haas]

Control: tag -1 help

On Tuesday, 21 June 2022 13:35:09 CEST Thorsten Glaser wrote:
> >So I'm inclined to think that 92833e8b5db6c209e9311ac8c6a44d3bf1856659 is
> >the commit which brought the bug back.
> 
> Yes, definitely. The lines…
> 
> if (!qdisc)
> return;
> 
> … from near the beginning of the now-static qdisc_destroy must
> be moved to the beginning of the new qdisc_put function.

Agreed. That would make it in line with 'master' and 'linux-5.10.y'.
In branch 'linux-4.9.y' there is no qdisc_put function, so the above check 
seems rightly in qdisc_destroy there.

This should be reported upstream, but I don't know what the best cq 
appropriate way to do that, so I'm referring that to the actual Debian  
maintainers, hence the 'help' tag.

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

Bug#1013313: libisoburn: Add autopkgtest

[Alexandre Ghiti]

Package: libisoburn
Version: Add autopkgtest
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Dear Maintainer,

Please find attached a patch that enables the releng testsuite.

Thanks for considering the patch.

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

Kernel: Linux 5.15.0-30-generic (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libisoburn-1.5.4/debian/patches/0002-Patch-releng-run_all_auto.patch 
libisoburn-1.5.4/debian/patches/0002-Patch-releng-run_all_auto.patch
--- libisoburn-1.5.4/debian/patches/0002-Patch-releng-run_all_auto.patch
1970-01-01 01:00:00.0 +0100
+++ libisoburn-1.5.4/debian/patches/0002-Patch-releng-run_all_auto.patch
2022-06-07 10:57:10.0 +0200
@@ -0,0 +1,26 @@
+From 2a365ec1d730dc9ae6bb2c9f047dbd04a276fae6 Mon Sep 17 00:00:00 2001
+From: Alexandre Ghiti 
+Date: Wed, 8 Jun 2022 14:39:18 +0200
+Subject: [PATCH] Patch releng run_all_auto
+
+---
+ releng/run_all_auto | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/releng/run_all_auto
 b/releng/run_all_auto
+@@ -231,12 +231,14 @@
+ RET_GREP="$?"
+   case ${RET_GREP} in
+   0) # found
++ exit 1
+  ;;
+   1) # not found
+echo "${SELF}: Log file looks clear." # | tee -a ${CLOG}
+  ;;
+ *) #
+  echo "${SELF}: grep returned EXIT CODE: ${RET_GREP}." # | 
tee -a ${CLOG}
++ exit 1
+;;
+   esac
+ set -e
diff -Nru libisoburn-1.5.4/debian/patches/series 
libisoburn-1.5.4/debian/patches/series
--- libisoburn-1.5.4/debian/patches/series  2021-09-18 10:13:15.0 
+0200
+++ libisoburn-1.5.4/debian/patches/series  2022-06-07 10:57:10.0 
+0200
@@ -1,2 +1,3 @@
 01-kfreebsd-without-libcam.patch
 99-autoupdate.patch
+0002-Patch-releng-run_all_auto.patch
diff -Nru libisoburn-1.5.4/debian/tests/control 
libisoburn-1.5.4/debian/tests/control
--- libisoburn-1.5.4/debian/tests/control   1970-01-01 01:00:00.0 
+0100
+++ libisoburn-1.5.4/debian/tests/control   2022-06-07 10:57:10.0 
+0200
@@ -0,0 +1,3 @@
+Test-Command: cd ./releng && ./run_all_auto -x $(which xorriso)
+Depends: xorriso, g++, libburn-dev, libisofs-dev
+Restrictions: allow-stderr

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Thorsten Glaser]

Control: tag -1 - moreinfo

Diederik de Haas dixit:

>In Debian, the release before 4.19.235-1 was 4.19.232-1 which should also have
>this bug. The release before that was 4.19.208-1, which shouldn't.
>Can you verify that?

Not easily any more, but I know it worked some weeks ago, and I *think*
I particularily remember 208 as working. But I do have a clone of linux
on another box and so I can look at ↓

>So I'm inclined to think that 92833e8b5db6c209e9311ac8c6a44d3bf1856659 is
>the commit which brought the bug back.

Yes, definitely. The lines…

if (!qdisc)
return;

… from near the beginning of the now-static qdisc_destroy must
be moved to the beginning of the new qdisc_put function.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Thorsten Glaser]

Diederik de Haas dixit:

>It's a bit 'above my paygrade', but if qdisk_put() can accept a NULL pointer
>then I'm curious whether that would be allowed for other functions in that file
>as well ... there are several having "struct Qdisc *qdisc" as (only)
>parameter, but only qdisk_put() checks for NULL.
>That is also true for the current 'master' branch ...

AIUI the check was added because qdisc_destroy() could accept one,
and several qdiscs are using that, it’s like free(3) in that regard,
the other functions aren’t.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#1009888: rust-h2, existing version is badly broken, new upstream needs new package

[Jonas Smedegaard]

What is status of this bug?

Reading backlog it seems there was progress, but conversation when quiet
more than a month ago...


 - Jonas

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

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

signature.asc
Description: signature

Bug#1012664: Rudamentary patch

[Gard Spreemann]

A prebuilt package with the patch can be found at

 https://nonempty.org/packages/sid/network-manager-openvpn/


 -- Gard
 


signature.asc
Description: PGP signature

Bug#1008992: xwayland: all X clients hang indefinitely waiting for /tmp/.X11-unix/X0

[Paul Cercueil]

Hi Michel,

Xwayland is started automatically when I am trying to run "xterm", and 
it does not crash. coredumpctl reports "no coredumps found" and I can 
see Xwayland running in htop - but xterm does not start.


-Paul


Le mar., juin 21 2022 at 13:06:35 +0200, Michel Dänzer 
 a écrit :

On 2022-06-21 12:35, Paul Cercueil wrote:

 Package: xwayland
 Version: 2:22.1.2-1
 Followup-For: Bug #1008992

 I get that too.

 This is the result of lsof /tmp/.X11-unix/X0:

 lsof: WARNING: can't stat() tracefs file system 
/sys/kernel/debug/tracing

   Output information may be incomplete.
 COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF  NODE 
NAME

 Xwayland 6587 paul5u  unix 0xe0c291f2  0t0 26890
 /tmp/.X11-unix/X0 type=STREAM (LISTEN)


Does

 coredumpctl | tail

show any Xwayland crashes which happened after logging in? If so, can 
you run


 coredumpctl gdb Xwayland

and then at the gdb prompt

 bt full

and provide the output?


--
Earthling Michel Dänzer|  
https://redhat.com
Libre software enthusiast  | Mesa and Xwayland 
developer

Bug#1013309: vlc-cache-gen segfaults while dpkg is processing triggers for libvlc-bin

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2022-06-21 10:49:40, Job Bautista wrote:
> Package: libvlc-bin
> Version: 3.0.17.4-3
> Severity: important
> 
> While I was upgrading my system, I noticed the following warning after dpkg 
> finishes:
> 
> Segmentation fault
> WARNING: Regenerating VLC plugin cache failed.
> Please run '/usr/lib/x86_64-linux-gnu/vlc/vlc-cache-gen 
> /usr/lib/x86_64-linux-gnu/vlc/plugins' manually.
> 
> I ran the command as told, and it still resulted in segfault.
> 
> I've hooked up a gdb, and here's what gdb tells me:
> 
> (gdb) set args /usr/lib/x86_64-linux-gnu/vlc/plugins
> (gdb) run
> Starting program: /usr/lib/x86_64-linux-gnu/vlc/vlc-cache-gen 
> /usr/lib/x86_64-linux-gnu/vlc/plugins
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> 
> Program received signal SIGSEGV, Segmentation fault.
> __GI___pthread_rwlock_wrlock (rwlock=0x0) at pthread_rwlock_wrlock.c:27
> 27  pthread_rwlock_wrlock.c: No such file or directory.
> 
> > 
> Cheers,


> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers experimental
>   APT policy: (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.18.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=en_PH.UTF-8, LC_CTYPE=en_PH.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_PH:en
> Shell: /bin/sh linked to /bin/dash
> Init: OpenRC (via /run/openrc), PID 1: init
> LSM: AppArmor: enabled
> 
> Versions of packages libvlc-bin depends on:
> ii  libc62.33-7
> ii  libvlc5  3.0.17.4-3
> 
> libvlc-bin recommends no packages.
> 
> libvlc-bin suggests no packages.
> 
> Versions of packages libvlc5 depends on:
> ii  libc62.33-7
> ii  libvlccore9  3.0.17.4-3
> 
> libvlc5 recommends no packages.
> 
> Versions of packages vlc depends on:
> ii  vlc-bin  3.0.17.4-3
> ii  vlc-plugin-base  3.0.17.4-3
> ii  vlc-plugin-qt3.0.17.4-3
> ii  vlc-plugin-video-output  3.0.17.4-3
> 
> Versions of packages vlc recommends:
> ii  vlc-l10n   3.0.17.4-3
> pn  vlc-plugin-access-extra
> ii  vlc-plugin-notify  3.0.17.4-3
> ii  vlc-plugin-samba   3.0.17.4-3
> ii  vlc-plugin-skins2  3.0.17.4-3
> ii  vlc-plugin-video-splitter  3.0.17.4-3
> ii  vlc-plugin-visualization   3.0.17.4-3
> 
> Versions of packages vlc suggests:
> ii  vlc-plugin-fluidsynth  3.0.17.4-3
> pn  vlc-plugin-jack
> ii  vlc-plugin-pipewire3-2
> pn  vlc-plugin-svg 
> 
> Versions of packages vlc-bin depends on:
> ii  libc62.33-7
> ii  libvlc5  3.0.17.4-3
> 
> Versions of packages vlc-plugin-base depends on:
> ii  liba52-0.7.4 0.7.4-20
> ii  libarchive13 3.6.0-1
> ii  libaribb24-0 1.0.3-2
> ii  libasound2   1.2.6.1-2+b1
> ii  libass9  1:0.16.0-1
> ii  libavahi-client3 0.8-6
> ii  libavahi-common3 0.8-6
> ii  libavc1394-0 0.5.4-5
> ii  libavcodec58 7:4.4.2-1+b3
> ii  libavformat587:4.4.2-1+b3
> ii  libavutil56  7:4.4.2-1+b3
> ii  libbluray2   1:1.3.1-2
> ii  libc62.33-7
> ii  libcairo21.16.0-5
> ii  libcddb2 1.3.2-7
> ii  libchromaprint1  1.5.1-2
> ii  libdav1d61.0.0-2
> ii  libdbus-1-3  1.14.0-1devuan1

Unless this happens on a pure Debian system, please file this bug report
with Devuan

Cheers

> ii  libdc1394-25 2.2.6-4
> ii  libdca0  0.0.7-2
> ii  libdvbpsi10  1.3.3-1
> ii  libdvdnav4   6.1.1-1
> ii  libdvdread8  6.1.3-1
> ii  libebml5 1.4.2-2
> ii  libelogind-compat [libsystemd0]  246.10-5
> ii  libeudev1 [libudev1] 3.2.11-1
> ii  libfaad2 2.10.0-2
> ii  libflac8 1.3.4-2
> ii  libfontconfig1   2.13.1-4.4
> ii  libfreetype6 2.12.1+dfsg-2
> ii  libfribidi0  1.0.8-2.1
> ii  libgcc-s112.1.0-2
> ii  libgcrypt20  1.10.1-2
> ii  libglib2.0-0 2.72.2-2
> ii  libgnutls30  3.7.4-2
> ii  libgpg-error01.45-2
> ii  libharfbuzz0b2.7.4-1+b1
> ii  libixml101:1.8.4-2
> ii  libjpeg62-turbo  1:2.1.2-1
> ii  libkate1 0.4.1-11
> ii  liblirc-client0  0.10.1-7
> ii  liblua5.2-0  

Bug#1013311: libgl1-mesa-dri: mesa 22.x package build removes support for Intel Gen2 and Gen3 chipsets

[Jason Richards]

Package: libgl1-mesa-dri
Version: 22.0.5-1
Severity: normal
X-Debbugs-Cc: deb...@jasonworld.co.uk

Dear Maintainer,

Mesa 22 removed support for the legacy i915 driver but a Gallium i915 driver 
exists in it's place.

>From what I can gather, Debian stopped building this driver for historic 
>reasons due to it's poor quality back 2011. The quote from the changelog at 
>the time is:

"Stop building i915g at all, it's apparently never going to be a suitable 
replacement for i915c."

This is no longer true. The Gallium i915 driver has been receiving considerable 
attention upstream and is now the only choice for Intel Gen2 and Gen3 chipsets.

May is propose this driver is reinstated to the package build?


Kind Regards
Jason

Bug#1012664: Rudamentary patch

[Gard Spreemann]

Hello,

I'm also affected by this bug. Inspection of the upstream code shows
that the NetworkManager OpenVPN plugin has no notion of the
--data-ciphers flag of OpenVPN. The previously used --cipher flag, which
NM does know about, used to imply appending the cipher to the
--data-ciphers list, but that is no longer the case as of OpenVPN 2.6 [1].

I've attached a very rudamentary patch that adds support for
--data-ciphers to network-manager-openvpn, and passes the corresponding
string on as an OpenVPN argument. The patch is a bit crude, and treats
--data-ciphers _exactly_ like --ciphers was already treated. That might
not be appropriate, as the former has the structure of a colon-separated
list, and any GUI/TUI interface might want to reflect that
visually/functionally. My patch treats it as an opaque string.

With the patch, one can in a network-manager-openvpn VPN connection add
an entry of the form

 data-ciphers = WHATEVER

to the .data field of the VPN connection, and WHATEVER will be passed on
to OpenVPN's --data-ciphers argument.

I'll try to have this patch upstreamed, but in the meantime it might be
appropriate for inclusion into Debian so as not to break people's
NM-managed VPN connections upon upgrading OpenVPN.


PS: Simon, you incidate that you are having trouble due to being
unfamiliar with Debian packaging. Do let me know if you'd like me to
provide a precompiled package with the patch included.


[1] 
https://github.com/OpenVPN/openvpn/blob/0dbcaba4f301c21e68a5cd032a4b56eb75c17c37/Changes.rst

 Best,
 Gard
 From: Gard Spreemann 
Date: Tue, 21 Jun 2022 11:20:25 +0200
Subject: Add support for OpenVPN's --data-ciphers

---
 properties/import-export.c| 11 +++
 properties/tests/test-import-export.c | 12 
 shared/nm-service-defines.h   |  1 +
 shared/utils.h|  1 +
 src/nm-openvpn-service.c  |  3 +++
 5 files changed, 28 insertions(+)

diff --git a/properties/import-export.c b/properties/import-export.c
index 51049de..2ab3bf3 100644
--- a/properties/import-export.c
+++ b/properties/import-export.c
@@ -1344,6 +1344,15 @@ do_import (const char *path, const char *contents, gsize contents_len, GError **
 			continue;
 		}
 
+		if (NM_IN_STRSET (params[0], NMV_OVPN_TAG_DATA_CIPHERS)) {
+			if (!args_params_check_nargs_n (params, 1, &line_error))
+goto handle_line_error;
+			if (!args_params_check_arg_utf8 (params, 1, NULL, &line_error))
+goto handle_line_error;
+			setting_vpn_add_data_item (s_vpn, NM_OPENVPN_KEY_DATA_CIPHERS, params[1]);
+			continue;
+		}
+
 		if (NM_IN_STRSET (params[0], NMV_OVPN_TAG_TLS_CIPHER)) {
 			if (!args_params_check_nargs_n (params, 1, &line_error))
 goto handle_line_error;
@@ -2103,6 +2112,8 @@ do_export_create (NMConnection *connection, const char *path, GError **error)
 
 	args_write_line_setting_value (f, NMV_OVPN_TAG_CIPHER, s_vpn, NM_OPENVPN_KEY_CIPHER);
 
+	args_write_line_setting_value (f, NMV_OVPN_TAG_DATA_CIPHERS, s_vpn, NM_OPENVPN_KEY_DATA_CIPHERS);
+
 	args_write_line_setting_value (f, NMV_OVPN_TAG_TLS_CIPHER, s_vpn, NM_OPENVPN_KEY_TLS_CIPHER);
 
 	args_write_line_setting_value_int (f, NMV_OVPN_TAG_KEYSIZE, s_vpn, NM_OPENVPN_KEY_KEYSIZE);
diff --git a/properties/tests/test-import-export.c b/properties/tests/test-import-export.c
index cefb2b1..369b61e 100644
--- a/properties/tests/test-import-export.c
+++ b/properties/tests/test-import-export.c
@@ -226,6 +226,7 @@ test_password_import (void)
 	_check_item (s_vpn, NM_OPENVPN_KEY_TA, NULL);
 	_check_item (s_vpn, NM_OPENVPN_KEY_TA_DIR, NULL);
 	_check_item (s_vpn, NM_OPENVPN_KEY_CIPHER, "AES-256-CBC");
+	_check_item (s_vpn, NM_OPENVPN_KEY_DATA_CIPHERS, NULL);
 	_check_item (s_vpn, NM_OPENVPN_KEY_LOCAL_IP, NULL);
 	_check_item (s_vpn, NM_OPENVPN_KEY_REMOTE_IP, NULL);
 	_check_item (s_vpn, NM_OPENVPN_KEY_AUTH, NULL);
@@ -319,6 +320,7 @@ test_tls_import (void)
 	_check_item (s_vpn, NM_OPENVPN_KEY_STATIC_KEY, NULL);
 	_check_item (s_vpn, NM_OPENVPN_KEY_STATIC_KEY_DIRECTION, NULL);
 	_check_item (s_vpn, NM_OPENVPN_KEY_CIPHER, NULL);
+	_check_item (s_vpn, NM_OPENVPN_KEY_DATA_CIPHERS, NULL);
 	_check_item (s_vpn, NM_OPENVPN_KEY_LOCAL_IP, NULL);
 	_check_item (s_vpn, NM_OPENVPN_KEY_REMOTE_IP, NULL);
 	_check_item (s_vpn, NM_OPENVPN_KEY_AUTH, NULL);
@@ -366,6 +368,7 @@ test_tls_import_2 (void)
 	_check_item (s_vpn, NM_OPENVPN_KEY_STATIC_KEY, NULL);
 	_check_item (s_vpn, NM_OPENVPN_KEY_STATIC_KEY_DIRECTION, NULL);
 	_check_item (s_vpn, NM_OPENVPN_KEY_CIPHER, NULL);
+	_check_item (s_vpn, NM_OPENVPN_KEY_DATA_CIPHERS, NULL);
 	_check_item (s_vpn, NM_OPENVPN_KEY_LOCAL_IP, NULL);
 	_check_item (s_vpn, NM_OPENVPN_KEY_REMOTE_IP, NULL);
 	_check_item (s_vpn, NM_OPENVPN_KEY_AUTH, NULL);
@@ -410,6 +413,7 @@ test_tls_import_3 (void)
 	_check_item (s_vpn, NM_OPENVPN_KEY_STATIC_KEY, NULL);
 	_check_item (s_vpn, NM_OPENVPN_KEY_STATIC_KEY_DIRECTION, NULL);
 	_check_item (s_vpn, NM_OPENVPN_KEY_CIPHER, NULL);
+	_check_item (s_vpn, NM_OPENVPN_KEY_DATA_CIPHERS

Bug#1013310: jsonnet: FTBFS on several release architectures

[Bastian Germann]

Source: jsonnet
Version: 0.18.0+ds-1
Severity: serious
Justification: FTBFS regression
Tags: ftbfs

jsonnet does not build on several release architecture due to:

/<>/third_party/rapidyaml/rapidyaml/ext/c4core/src/c4/ext/debugbreak/debugbreak.h: In function ‘void 
debug_break()’:
/<>/third_party/rapidyaml/rapidyaml/ext/c4core/src/c4/ext/debugbreak/debugbreak.h:111:17: error: 
‘trap_instruction’ was not declared in this scope

Bug#1008992: xwayland: all X clients hang indefinitely waiting for /tmp/.X11-unix/X0

[Paul Cercueil]

Note that trying to downgrade xwayland to the stable version 
(2:1.20.11-1+deb11u1 at the moment) will cause GDM to fail starting, 
rendering the computer unusable.


Cheers,
-Paul

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

[Alberto Garcia]

On Tue, Jun 21, 2022 at 11:40:49AM +0200, Markus Demleitner wrote:
> Well, given that I just tried to get a trackback and discovered
> that's harder than just following the advice and running
> 
>   ssh -tX  env GDK_SYNCHRONIZE=1 gdb luakit
> 
> and breaking on gdk_x_error; I figure it's because that breakpoint is
> never reached in the UI process, only in the WebKitWebProcess.
> A quick web search hasn't brought up quick advice on how to debug
> things in there -- is there a quick howto somewhere?

If the web process crashes and you have the systemd-coredump package
you should be able to see the core dump with coredumpctl.

It not you can connect gdb to a running WebProcess with 'gdb -p PID'

Berto

Bug#1008992: xwayland: all X clients hang indefinitely waiting for /tmp/.X11-unix/X0

[Paul Cercueil]

Package: xwayland
Version: 2:22.1.2-1
Followup-For: Bug #1008992

I get that too.

This is the result of lsof /tmp/.X11-unix/X0:

lsof: WARNING: can't stat() tracefs file system /sys/kernel/debug/tracing
  Output information may be incomplete.
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
Xwayland 6587 paul5u  unix 0xe0c291f2  0t0 26890
/tmp/.X11-unix/X0 type=STREAM (LISTEN)

Cheers,
-Paul


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (200, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: aarch64, arm64, armhf, arm

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

Versions of packages xwayland depends on:
ii  libc6   2.33-7
ii  libdrm2 2.4.110-1
ii  libepoxy0   1.5.10-1
hi  libgbm1 21.3.8-1
ii  libgcrypt20 1.10.1-2
ii  libgl1  1.4.0-1
ii  libpixman-1-0   0.40.0-1
ii  libtirpc3   1.3.2-2
ii  libwayland-client0  1.20.0-1
ii  libxau6 1:1.0.9-1
ii  libxcvt00.1.1-3
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.5-1
ii  libxshmfence1   1.3-1
ii  xserver-common  2:21.1.3-2

xwayland recommends no packages.

xwayland suggests no packages.

-- no debconf information

Bug#1013273: [Pkg-rust-maintainers] Bug#1013273: linking problems on ppc64el

[Frédéric Bonnard]

Hi Sylvestre,
at first, I thought it may be a squeekboard coding issue too, but the fact that 
the
same code breaks with rustc 1.59 and not 1.58 made me think of a
regression (be it squeekboard 1.17.1 or 1.18.0). Also, only rust
components where changed for this test : exact same gcc etc ..
If rustc changed it's behaviour in between, at least the compiler would
have given an advice or a tip. Anyway this does not occur on other
architectures, so yes, I rather think it may be some thorny ppc64el
regression on rustc side, but that is only an assumption.
I'm no rust expert to maybe try a different layout of the code or maybe
rust link option that could help and workaround that linking issue for
the time being.

F.


signature.asc
Description: PGP signature

Bug#1013308: O: netatalk -- Apple Filing Protocol service

[Jonas Smedegaard]

Package: wnpp
Severity: normal
Control: affects -1 src:netatalk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I intend to orphan the netatalk package.

The package description is:
 Netatalk is an implementation of the Apple Filing Protocol (AFP),
 for offering file service (mainly) to macOS clients.
 .
 Compared to the Windows-native SMB protocol
 (which is also supported on macOS),
 the Macintosh-native AFP protocol is accessible from a different network,
 can be simpler to setup and faster for some operations
 (e.g. server-to-server copying),
 and some features (e.g. the backup service Time Machine)
 may work more reliably than over SMB.
 .
 This package contains all daemon and utility programs
 as well as Netatalk's libraries.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmKxnXEACgkQLHwxRsGg
ASErIA/+LM9AxdTeT5MstoJvKyu6zdny/KZID4BBObvq0ST5MStHgC6IlI38thq2
o0CrQswWKxOznu+CpWf2UHe3LGr01V8Py6PAESXAHhY3yjHIKijvNtl/Q52yJH+O
89Lg2+YXxlXFyc3mEIBzHptikYUYJF5Zpm4dWqlXEziSvYz1BmKyxY6eweg9jcXw
VjNzzqEFxjivRUcrNKkRazpFrqlPod42VPXasLakFb9DjCSGDXa1MFe2NGinj14+
7AlaDrPxfI6MUiNm1U8yoseNj6HkMdQ+SPuz8Iz2W+F/9g0bBz+YhRCY9bFIvsVK
1Zpvv3JGbGQKxIiaMQKXajUL1k71Vnrs7bB5Wiw7+bOxYwXy/244x/vwqz1dbFXp
Dk1a7HRmfWzC38+6OoSFTjK2kunAMYpf+HKgPlCLFdPkKfNkzqomz49IZOqJKfU9
K7ZCULkaUwZ6QgfUvsFD2HwjRS5otWs4mQ7Mu3E1yEg3m3Y0U5CTYNj5fSSIPn+d
QtilYsHpfzTXm0BJadwJ3M5Mx/ZYpuVtOfeoD4Io/tnUf5y7+4JQRhe9U7Uoy1vP
fb41xmpVrMOslTAvoP0ePNGwUcv1mRPWDErcU9dbCeDEvFQWEhR0JDnqywAjJ+/f
vsIb9P470KyU7G5X5Beb0SGu6g1lLeCT6b8pnEsuLWDKeantcuU=
=UKNp
-END PGP SIGNATURE-

Bug#877914: eurephia -- flexible OpenVPN authentication module

[Балашов Эдик]

Hello! I would like to take a package, how to do it?

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Diederik de Haas]

On dinsdag 21 juni 2022 11:49:26 CEST you wrote:
> https://lore.kernel.org/all/20190921063607.ga1083...@kroah.com/ is about the
> 4.19.75 release and that contains that change in commit
> 7a1bad565cebfbf6956f9bb36dba734a48fa31d4 titled "net_sched: let qdisc_put()
> accept NULL pointer" which actually modifies the qdisc_destroy function
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/net/sc
> hed/sch_generic.c?h=linux-4.19.y#n1004 OTOH, does indeed not have that NULL
> check.

It's a bit 'above my paygrade', but if qdisk_put() can accept a NULL pointer 
then I'm curious whether that would be allowed for other functions in that file 
as well ... there are several having "struct Qdisc *qdisc" as (only) 
parameter, but only qdisk_put() checks for NULL.
That is also true for the current 'master' branch ...

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

Bug#1013307: sfxr-qt: FTBFS with glibc 2.34

[Graham Inggs]

Source: sfxr-qt
Version: 1.5.0+ds-1
Severity: important
Tags: ftbfs

Hi Maintainer

Your package uses a vendored copy of catch.hpp.  It will FTBFS once
glibc is upgraded to 2.34 due to MINSIGSTKSZ and SIGSTKSZ no longer
being defined as constants.

You could take this opportunity to switch to using the catch2 package
[1] in Debian where this is already fixed.

Regards
Graham


[1] https://tracker.debian.org/pkg/catch2

Bug#1013306: bullseye-pu: package libsdl2/2.0.14+dfsg2-3+deb11u1

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: secur...@debian.org

[ Reason ]
Backport two out-of-bounds reads, one of which has a CVE ID, presumably
because it could be an exploitable vulnerability for games that are
willing to load untrusted graphics data.

The security team marked the CVE as unimportant and didn't open a bug,
so presumably they don't intend to do a DSA.

[ Impact ]
If not approved, SDL games that load untrusted graphics could maybe be
crashed or otherwise interfered with by an attacker.

[ Tests ]
No specific test coverage. From the upstream bug reports, it seems that
these issues are usually only noticeable in practice if SDL is rebuilt
with AddressSanitizer.

The proposed version seems to work OK in brief testing with a few games
(0ad, openarena, warzone2100).

[ Risks ]
Low risk: the patches are trivial and have been in testing since January
without apparent regressions.

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

[ Changes ]

d/p/Fixed-potential-buffer-overflow-in-YUV-conversion.patch,
src/video/yuv2rgb/yuv_rgb.c: ensure that the index in a 512-element
lookup table is clamped to the range 0 to 511 inclusive, even if the input
data is malformed.

d/p/Always-create-a-full-256-entry-map-in-case-color-values-a.patch,
src/video/SDL_pixels.c: always allocate palettes for palette-based formats
with 256 entries and zero out the ones that are not used, so that
out-of-range pixel values resolve to transparent black
(red = green = blue = alpha = 0) instead of causing an out-of-bounds read.
diffstat for libsdl2-2.0.14+dfsg2 libsdl2-2.0.14+dfsg2

 debian/changelog   |   12 +++
 debian/gbp.conf|1 
 debian/patches/Always-create-a-full-256-entry-map-in-case-color-values-a.patch |   34 ++
 debian/patches/Fixed-potential-buffer-overflow-in-YUV-conversion.patch |   23 ++
 debian/patches/series  |2 
 src/video/SDL_pixels.c |4 -
 src/video/yuv2rgb/yuv_rgb.c|2 
 7 files changed, 75 insertions(+), 3 deletions(-)

diff -Nru libsdl2-2.0.14+dfsg2/debian/changelog libsdl2-2.0.14+dfsg2/debian/changelog
--- libsdl2-2.0.14+dfsg2/debian/changelog	2021-01-18 14:35:30.0 +
+++ libsdl2-2.0.14+dfsg2/debian/changelog	2022-06-20 22:05:21.0 +0100
@@ -1,3 +1,15 @@
+libsdl2 (2.0.14+dfsg2-3+deb11u1) bullseye; urgency=medium
+
+  * d/gbp.conf: Set branch for Debian 11 updates
+  * d/p/Always-create-a-full-256-entry-map-in-case-color-values-a.patch:
+Avoid out-of-bounds read while loading malformed BMP file.
+libsdl-org/SDL#5042 upstream, CVE-2021-33657.
+  * d/p/Fixed-potential-buffer-overflow-in-YUV-conversion.patch:
+Avoid out-of-bounds read during YUV to RGB conversion.
+libsdl-org/SDL#5043 upstream, no known CVE ID.
+
+ -- Simon McVittie   Mon, 20 Jun 2022 22:05:21 +0100
+
 libsdl2 (2.0.14+dfsg2-3) unstable; urgency=medium
 
   * d/libsdl2-2.0-0.symbols: SDL_LinuxSetThreadPriority is Linux-only
diff -Nru libsdl2-2.0.14+dfsg2/debian/gbp.conf libsdl2-2.0.14+dfsg2/debian/gbp.conf
--- libsdl2-2.0.14+dfsg2/debian/gbp.conf	2021-01-18 14:35:30.0 +
+++ libsdl2-2.0.14+dfsg2/debian/gbp.conf	2022-06-20 22:05:21.0 +0100
@@ -1,6 +1,7 @@
 [DEFAULT]
 pristine-tar = True
 sign-tags = True
+debian-branch = debian/bullseye
 
 [import-orig]
 filter = [ 'Android.mk', 'android-project', 'debian', 'src/hidapi/android', 'src/hidapi/ios', 'src/hidapi/linux/hid.cpp', 'src/hidapi/mac', 'src/hidapi/testgui', 'src/hidapi/windows', 'src/render/metal/SDL_shaders_metal_*.h', 'src/video/os2/my_gradd.h', 'VisualC', 'VisualC-WinRT', 'Xcode', 'Xcode-iOS' ]
diff -Nru libsdl2-2.0.14+dfsg2/debian/patches/Always-create-a-full-256-entry-map-in-case-color-values-a.patch libsdl2-2.0.14+dfsg2/debian/patches/Always-create-a-full-256-entry-map-in-case-color-values-a.patch
--- libsdl2-2.0.14+dfsg2/debian/patches/Always-create-a-full-256-entry-map-in-case-color-values-a.patch	1970-01-01 01:00:00.0 +0100
+++ libsdl2-2.0.14+dfsg2/debian/patches/Always-create-a-full-256-entry-map-in-case-color-values-a.patch	2022-06-20 22:05:21.0 +0100
@@ -0,0 +1,34 @@
+From: Sam Lantinga 
+Date: Tue, 30 Nov 2021 12:36:46 -0800
+Subject: Always create a full 256-entry map in case color values are out of
+ range
+
+Bug: https://github.com/libsdl-org/SDL/issues/5042
+Bug-CVE: CVE-2021-33657
+Origin: upstream, 2.0.20, commit:8c91cf7dba5193f5ce12d06db1336515851c9ee9
+---
+ src/video/SDL_pixels.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 d

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Diederik de Haas]

Control: tag -1 moreinfo

On Tuesday, 21 June 2022 08:10:54 CEST Thorsten Glaser wrote:
> Package: src:linux
> Version: 4.19.235-1
> Severity: critical
> Tags: upstream
> Justification: breaks the whole system
> 
> A recent upstream “stable” upgrade backported the removal of the
> qdisc_destroy() function (which, in itself, is questionable enough
> already and caused no small amount of fun) using qdisc_put() instead.
> 
> However, qdisc_put() does not accept NULL pointers, causing oopses
> in several qdiscs that can be configured on a system. This breaks
> sudo (su works), networking and even deconfiguration is not possible,
> only /proc/sysrq-trigger makes it possible to recover.
> 
> https://www.mail-archive.com/netdev@vger.kernel.org/msg314288.html
> fixes this but was not backported along.

https://lore.kernel.org/all/20190921063607.ga1083...@kroah.com/ is about the 
4.19.75 release and that contains that change in commit 
7a1bad565cebfbf6956f9bb36dba734a48fa31d4 titled "net_sched: let qdisc_put() 
accept NULL pointer" which actually modifies the qdisc_destroy function

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/net/sched/sch_generic.c?h=linux-4.19.y#n1004
OTOH, does indeed not have that NULL check.

In commit 92833e8b5db6c209e9311ac8c6a44d3bf1856659, part of v4.19.221, titled
"net: sched: rename qdisc_destroy() to qdisc_put()" wasn't actually a straight
rename, but some code moved around into a new qdisc_put function, 
which doesn't have the NULL check.

In Debian, the release before 4.19.235-1 was 4.19.232-1 which should also have
this bug. The release before that was 4.19.208-1, which shouldn't.
Can you verify that?

So I'm inclined to think that 92833e8b5db6c209e9311ac8c6a44d3bf1856659 is
the commit which brought the bug back.

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

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

[Markus Demleitner]

On Tue, Jun 14, 2022 at 01:33:34PM +, Alberto Garcia wrote:
> 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.

Well, given that I just tried to get a trackback and discovered
that's harder than just following the advice and running

  ssh -tX  env GDK_SYNCHRONIZE=1 gdb luakit

and breaking on gdk_x_error; I figure it's because that breakpoint is
never reached in the UI process, only in the WebKitWebProcess.
A quick web search hasn't brought up quick advice on how to debug
things in there -- is there a quick howto somewhere?

Thanks,

  Markus

Bug#697700: New watch file for Ubuntu

[Alexandre Ghiti]

Hi,

In Ubuntu, we intend to add the following watch file in case you're
interested.

Thanks!


debdiff_jigit
Description: Binary data

Bug#1013305: tootle: please update to newer version

[Evangelos Ribeiro Tzaras]

Package: tootle
Version: 1.0-alpha2-1+b1
Severity: wishlist

I just noticed there's a 1.0 version out.

Would be cool to have this in unstable
(and perhaps the latest 2.0 alpha in experimental).

Thank you for maintaining tootle!

Evangelos

Bug#1011263: [riscv] https://salsa.debian.org/science-team/teem/-/merge_requests/1

[肖盛文]

Hi,

    I'd do MR for this bug used the patch supplied by Bo Yu:

https://salsa.debian.org/science-team/teem/-/merge_requests/1

Welcome to review and upload to fix #1011263


Thanks!

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012721: RFP: chezmoi -- manage your dotfiles across multiple machines, securely

[Ryan Kavanagh]

On Mon, Jun 13, 2022 at 03:01:25PM -0400, Ryan Kavanagh wrote:
> I use chezmoi on several of my systems, and packaging it has been on my
> todo list. I can package it over the next few weeks.

As a heads up, getting chezmoi into the archives requires packaging a
bunch of dependencies:

 *  github.com/bradenhilton/mozillainstallhash
 *  github.com/twpayne/go-xdg
 *  github.com/google/gops
 *  howett.net/plist
 *  github.com/zalando/go-keyring
 *  github.com/twpayne/go-shell
 *  github.com/muesli/combinator
 *  github.com/twpayne/go-pinentry
 *  github.com/twpayne/go-vfs

I've started on go-xdg and go-vfs, and will pluck away at the rest as I
have time.

—RAK

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


signature.asc
Description: PGP signature