Bug#995838: Should condor be removed?

2023-12-19 Thread Bastian Germann

Hi Tim,

I have checked the git repo and found the work-in-progress v23.0.0+dfsg-1 to 
build fine.
Maybe we should get it into Debian so that the pile of bugs that have 
accumulated can be resolved.
I am happy to sponsor the update if Michael Hanke is not available.

Cheers,
Bastian

On Tue, 1 Aug 2023 17:15:52 +0200 Bastian Germann  wrote:

Hi Tim,

I see you imported 10.3 into Debian. Please let me know if I can help you.

Thanks,
Bastian

On Fri, 2 Dec 2022 09:03:27 -0600 Tim Theisen  wrote:
> Hello Bastian,
> 
> I am working on this.
> 
> Twice I had everything building and ready for upload and then something 
> changed on sid.
> 
> First change, moving to openssl 3 caused condor to FTBFS.
> 
> Then migration to cgroups v2 caused condor to FTBFS.
> 
> Right now I have it building. However, some change is causing the 
> install step to not place files in the proper directories. Perhaps, 
> something to do with usrmerge or some change in the build tools. Still 
> working on that one.
> 
> ...Tim
> 
> On 11/30/22 11:05, Bastian Germann wrote:

> > X-Debbugs-Cc: andr...@an3as.eu
> >
> > Any news on condor? Upstream has released the announced version but 
> > the Debian package has only advanced in git.







Bug#1059034: Impossible to install: Depends on missing package,librust-ego-tree-0.6+default-dev

2023-12-19 Thread Peter Green

Impossible to install: Depends on missing package
librust-ego-tree-0.6+default-dev


rust-ego-tree was uploaded but rejected.

https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2023-December/037170.html



Bug#1059047: ITP: ruby-vite-ruby -- Vite.js in Ruby, bringing joy to people's JavaScript experience

2023-12-19 Thread weepingclown
package: wnpp
Severity: wishlist
Owner: Ananthu C V 

*Package Name: ruby-vite-ruby
 Version: 3.5.0
 Upstream Author: Máximo Mussini
*URL: https://github.com/ElMassimo/vite_ruby
*License: Expat
*Description: Vite.js in Ruby, bringing joy to people's JavaScript experience
 vite_ruby is the core library for Rack apps, used by vite_rails and 
vite_hanami.

Bug#874030: Anyenv

2023-12-19 Thread gregor herrmann
On Tue, 19 Dec 2023 20:05:01 +0100, Mikko Johannes Koivunalho wrote:

> I am interested in packaging but my own time is limited, too.
> Do you have any resources to help in packaging Bash scripts?

https://wiki.debian.org/Packaging is a good starting point;
personally I can especially recommend Lucas' "Packaging Tutorial"
(linked from there or:) 
https://www.debian.org/doc/devel-manuals#packaging-tutorial
 

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#1059005: libssh2: CVE-2023-48795

2023-12-19 Thread Salvatore Bonaccorso
Hello,

On Tue, Dec 19, 2023 at 03:04:35PM -0500, Nicolas Mora wrote:
> Hello,
> 
> Le 2023-12-19 à 14 h 32, Salvatore Bonaccorso a écrit :
> > 
> > It's not the same version :).
> > 
> > bookworm has 0.10.0 based version, whereas in testing and bove we have
> > 1.11.0 based one. For bookworm and older there is no haCha20-Poly1305
> > and CBC-EtM support, which was only introduced after the 0.10.0
> > release.
> > 
> > Thus for libssh2 only unstable needs fixing (and then the fix mgirate
> > to testing).
> > 
> > Does this help?
> > 
> My bad, I missed the difference between 1.10 and 1.11 :p

Yeah the same Debian revision was confusing, after your question I had
to double check again :)

> I'll prepare a fix for unstable then, thanks!

Looking from the commit activity in the upstream repository and last
commits touching the release notes I guess upstream is finalizing a
new release? If so it might be worth to just go to the new upstream
version rather than cherry-picking the commit adding strict KEX
support.

But that said, fully trusting you on the matter and up to you on next
steps.

Thanks for working on it!

Regards,
Salvatore



Bug#1059046: boost1.83: *_fcontext functions missing from libboost_context.so.1.83.0 on riscv64

2023-12-19 Thread Aurelien Jarno
Source: boost1.83
Version: 1.83.0-1
Severity: important
Tags: patch upstream fixed-upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear maintainer,

The libboost_context.so.1.83.0 library misses the jump_fcontext,
make_fcontext and ontop_fcontext functions. This causes at least
icinga2 [1] and simgrid [2] to FTBFS.

This issue has been introduced upstream when fixing arm64 support and
makes the riscv64 ABI to be detected as AAPCS instead of SysV. The issue
as has already been fixed [3]. Could you please include the upstream
patch in the Debian package?

Thanks,
Aurelien

[1] 
https://buildd.debian.org/status/fetch.php?pkg=icinga2=riscv64=2.13.8-1%2Bb1=1702979912=0
[2] 
https://buildd.debian.org/status/fetch.php?pkg=simgrid=riscv64=3.35-1%2Bb2=1702983045=0
[3] 
https://github.com/boostorg/context/commit/819c2d6423b4e0f55c5f69e334bf81570e82f68f



Bug#1059045: gnome-shell: Stopping the screen recorder and Closing the shell extension settings leaves an orphaned gjs process behind.

2023-12-19 Thread vikas gautam
Package: gnome-shell
Version: 44.7-1
Severity: normal

Dear Maintainer,

I encountered two bad behavior based on the same bug.
- Stopping the screen recorder leaves an orphaned gjs instance running.
- Closing the extension settings panel leaves an orphaned gjs instance
running.
I reported the bugs upstream via
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7250 and
they issued a patch to fix the issue via
https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/ebe1a4d303281f2ceb465dc1a76506a3976fc914
.
This patch is part of the main branch and has not been added to minor
versions of either gnome-shell v44 or v45.

Please read the bug report linked above for more details like screenshots
and a screencast on the issue.
I didn't know that, as a Debian user, I am required to report it to Debian
Maintainers and not upstream.
So just reporting it.

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

Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8) (ignored: LC_ALL set to
en_IN), LANGUAGE=en_IN
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-accountsservice-1.0   23.13.9-5
ii  gir1.2-adw-1 1.4.2-1
ii  gir1.2-atk-1.0   2.50.0-1
ii  gir1.2-atspi-2.0 2.50.0-1
ii  gir1.2-freedesktop   1.78.1-5
ii  gir1.2-gcr-3 3.41.1-3
ii  gir1.2-gdesktopenums-3.0 45.0-2
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-3
ii  gir1.2-gdm-1.0   45.0.1-1
ii  gir1.2-geoclue-2.0   2.7.1-1
ii  gir1.2-glib-2.0  1.78.1-5
ii  gir1.2-gnomebg-4.0   44.0-2
ii  gir1.2-gnomebluetooth-3.042.7-1
ii  gir1.2-gnomedesktop-4.0  44.0-2
ii  gir1.2-graphene-1.0  1.10.8-2
ii  gir1.2-gstreamer-1.0 1.22.7-1
ii  gir1.2-gtk-4.0   4.12.4+ds-3
ii  gir1.2-gweather-4.0  4.4.0-1
ii  gir1.2-ibus-1.0  1.5.29~rc2-1
ii  gir1.2-mutter-12 44.7-1
ii  gir1.2-nm-1.01.44.2-6
ii  gir1.2-nma4-1.0  1.10.6-2
ii  gir1.2-pango-1.0 1.51.0+ds-3
ii  gir1.2-polkit-1.0123-3
ii  gir1.2-rsvg-2.0  2.54.7+dfsg-2
ii  gir1.2-soup-3.0  3.4.4-2
ii  gir1.2-upowerglib-1.01.90.2-7
ii  gir1.2-webkit2-4.1   2.42.4-1
ii  gnome-backgrounds45.0-1
ii  gnome-settings-daemon45.0-1
ii  gnome-shell-common   44.7-1
ii  gsettings-desktop-schemas45.0-2
ii  gstreamer1.0-pipewire1.0.0-1
ii  libatk-bridge2.0-0   2.50.0-1
ii  libatk1.0-0  2.50.0-1
ii  libc62.37-12
ii  libcairo21.18.0-1
ii  libecal-2.0-23.50.2-1
ii  libedataserver-1.2-273.50.2-1
ii  libgcr-base-3-1  3.41.1-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3
ii  libgirepository-1.0-11.78.1-5
ii  libgjs0g 1.78.1-1
ii  libgles2 1.7.0-1
ii  libglib2.0-0 2.78.3-1
ii  libglib2.0-bin   2.78.3-1
ii  libgnome-autoar-0-0  0.4.4-2
ii  libgnome-desktop-4-2 44.0-2
ii  libgraphene-1.0-01.10.8-2
ii  libgtk-3-0   3.24.38-6
ii  libgtk-4-1   4.12.4+ds-3
ii  libical3 3.0.17-1
ii  libjson-glib-1.0-0   1.8.0-2
ii  libmutter-12-0   44.7-1
ii  libnm0   1.44.2-6
ii  libpango-1.0-0   1.51.0+ds-3
ii  libpolkit-agent-1-0  123-3
ii  libpolkit-gobject-1-0123-3
ii  libpulse-mainloop-glib0  16.1+dfsg1-2+b1
ii  libpulse016.1+dfsg1-2+b1
ii  libsecret-1-00.21.1-1
ii  libsystemd0  254.5-1
ii  

Bug#1059005: libssh2: CVE-2023-48795

2023-12-19 Thread Nicolas Mora

Hello,

Le 2023-12-19 à 14 h 32, Salvatore Bonaccorso a écrit :


It's not the same version :).

bookworm has 0.10.0 based version, whereas in testing and bove we have
1.11.0 based one. For bookworm and older there is no haCha20-Poly1305
and CBC-EtM support, which was only introduced after the 0.10.0
release.

Thus for libssh2 only unstable needs fixing (and then the fix mgirate
to testing).

Does this help?


My bad, I missed the difference between 1.10 and 1.11 :p

I'll prepare a fix for unstable then, thanks!

/Nicolas



Bug#1051521: rust-palette: autopkgtest failures

2023-12-19 Thread Jonas Smedegaard
Quoting Peter Green (2023-12-19 20:46:56)
> tags 105121 +patch
> thanks
> 
> > rust-palette is unable to migrate to Testing because its
> > autopkgtests are failing.
> 
> I prepared a fix for the autopkgtest issues. While I was at
> it I also bumped the clap dev-dependency and the associated
> build and test dependencies to version 4 as we would like
> to phase out clap version 3.
> 
> I discussed the clap upgrade with upstream, they said it was
> only used for examples but they did not want to bump it
> upstream at this time due to msrv.
> 
> https://github.com/Ogeon/palette/issues/364
> 
> If I get no response I will likely NMU this in a week or so.

Thanks for looking into this.

Wound you mind sharing the patch you mention having prepared?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature


Bug#1059044: Konqueror (V.4:22.12.3-1 stable) URL sftp:// not be completed. Protocols sftp, ftp, and smb does not work

2023-12-19 Thread katzka
Package: konqueror
Version: 4:22.12.3-1
Severity: important
X-Debbugs-Cc: kat...@linuxmail.org


Protocols sftp, ftp and and smb:// does not work

Location bar similar to sftp://user@127.0.0.1 :

  The requested operation could not be completed
  Request Aborted By User
  Details of the Request:
    - URL: error:/?error=1errText=User canceled
action%0A%23sftp://user@127.0.0.1
    - Protocol: error
    - Date and Time: Sunday, 19 November 2023 21:49:45 CET
    - Additional Information: error
  Description:
    The request was not completed because it was aborted.

  Possible Solutions:
    Retry the request.


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

Kernel: Linux 6.1.0-16-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8),
LANGUAGE=es:en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages konqueror depends on:
ii  dolphin  4:22.12.3-1
ii  install-info 6.8-6+b1
ii  kio  5.103.0-1
ii  libc62.36-9+deb12u3
ii  libkf5archive5   5.103.0-1
ii  libkf5bookmarks5 5.103.0-1
ii  libkf5codecs55.103.0-1
ii  libkf5completion55.103.0-1
ii  libkf5configcore55.103.0-2
ii  libkf5configgui5 5.103.0-2
ii  libkf5configwidgets5 5.103.0-1
ii  libkf5coreaddons55.103.0-1
ii  libkf5crash5 5.103.0-1
ii  libkf5dbusaddons55.103.0-1
ii  libkf5i18n5  5.103.0-1
ii  libkf5iconthemes55.103.0-1
ii  libkf5itemviews5 5.103.0-1
ii  libkf5jobwidgets55.103.0-1
ii  libkf5kcmutils5  5.103.0-3
ii  libkf5kiocore5   5.103.0-1
ii  libkf5kiofilewidgets55.103.0-1
ii  libkf5kiogui55.103.0-1
ii  libkf5kiowidgets55.103.0-1
ii  libkf5konq6  4:22.12.3-1
ii  libkf5parts5 5.103.0-1
ii  libkf5service-bin5.103.0-1
ii  libkf5service5   5.103.0-1
ii  libkf5sonnetcore55.103.0-1
ii  libkf5sonnetui5  5.103.0-1
ii  libkf5textwidgets5   5.103.0-1
ii  libkf5wallet-bin 5.103.0-1
ii  libkf5wallet55.103.0-1
ii  libkf5widgetsaddons5 5.103.0-1
ii  libkf5windowsystem5  5.103.0-1
ii  libkf5xmlgui55.103.0-1
ii  libqt5core5a 5.15.8+dfsg-11
ii  libqt5dbus5  5.15.8+dfsg-11
ii  libqt5gui5   5.15.8+dfsg-11
ii  libqt5network5   5.15.8+dfsg-11
ii  libqt5printsupport5  5.15.8+dfsg-11
ii  libqt5webenginecore5 5.15.13+dfsg-1~deb12u1
ii  libqt5webenginewidgets5  5.15.13+dfsg-1~deb12u1
ii  libqt5widgets5   5.15.8+dfsg-11
ii  libqt5x11extras5 5.15.8-2
ii  libqt5xml5   5.15.8+dfsg-11
ii  libstdc++6   12.2.0-14

Versions of packages konqueror recommends:
ii  kfind  4:22.12.3-1

Versions of packages konqueror suggests:
ii  konq-plugins  4:22.12.3-1

-- no debconf information
Thank you for using reportbug



Bug#1051521: rust-palette: autopkgtest failures

2023-12-19 Thread Peter Green

tags 105121 +patch
thanks


rust-palette is unable to migrate to Testing because its
autopkgtests are failing.


I prepared a fix for the autopkgtest issues. While I was at
it I also bumped the clap dev-dependency and the associated
build and test dependencies to version 4 as we would like
to phase out clap version 3.

I discussed the clap upgrade with upstream, they said it was
only used for examples but they did not want to bump it
upstream at this time due to msrv.

https://github.com/Ogeon/palette/issues/364

If I get no response I will likely NMU this in a week or so.



Bug#1058943: some update to the info

2023-12-19 Thread weepingclown
There was quite a bit of up in the original ITP mail. Some corrected info;

Version: 3.0.17
Description: Vite.js in Rails, brining joy to people's javascript experience

Bug#1059043: RFP: flashprog -- Identify, read, write, erase, and verify BIOS/ROM/flash chips

2023-12-19 Thread Nico Huber
Package: wnpp
Severity: wishlist

* Package name: flashprog
  Version : 1.0
  Upstream Contact: Nico Huber 
* URL : https://flashprog.org/
* License : GPL
  Programming Lang: C
  Description : Identify, read, write, erase, and verify BIOS/ROM/flash 
chips

flashprog is a tool for identifying, reading, writing, verifying and erasing 
flash chips. It's often used to flash BIOS/EFI/coreboot/firmware/optionROM 
images in-system using a supported mainboard, but it also supports flashing of 
network cards (NICs), SATA controller cards, and other external devices which 
can program flash chips.

It supports a wide range of DIP32, PLCC32, DIP8, SO8/SOIC8, TSOP32/40/48, and 
BGA chips, which use various protocols such as LPC, FWH, parallel flash, or SPI.

The tool can be used to flash BIOS/firmware images for example -- be it 
proprietary BIOS images or coreboot (previously known as LinuxBIOS) images.

It can also be used to read the current existing BIOS/firmware from a flash 
chip.

Currently supported programmers include:

  * internal (for in-system flashing in the mainboard)
  * dummy (virtual programmer for testing flashprog)
  * atahpt (for flash ROMs on Highpoint ATA/RAID controllers)
  * atapromise (for flash ROMs on Promise PDC2026x ATA/RAID controllers)
  * atavia (for flash ROMs on VIA VT6421A SATA controllers)
  * buspirate_spi (for SPI flash ROMs attached to a Bus Pirate)
  * ch341a_spi (for SPI flash ROMs attached to WCH CH341A)
  * ch347_spi (for SPI flash ROMs attached to WCH CH347)
  * dediprog (for SPI flash ROMs attached to a Dediprog SF100)
  * developerbox_spi (for SPI flash ROMs on the 96Boards Developerbox)
  * digilent_spi (for SPI flash ROMs on iCEblink40 development boards)
  * dirtyjtag_spi (for SPI flash ROMs attached to DirtyJTAG-compatible devices)
  * drkaiser (for flash ROMs on Dr. Kaiser PC-Waechter PCI cards)
  * ft2232_spi (for SPI flash ROMs attached to an FT2232/FT4232H/FT232H family
based USB SPI programmer), including the DLP Design DLP-USB1232H,
FTDI FT2232H Mini-Module, FTDI FT4232H Mini-Module, openbiosprog-spi,
Amontec JTAGkey/JTAGkey-tiny/JTAGkey-2, Dangerous Prototypes Bus Blaster,
Olimex ARM-USB-TINY/-H, Olimex ARM-USB-OCD/-H, TIAO/DIYGADGET USB
Multi-Protocol Adapter (TUMPA), TUMPA Lite, GOEPEL PicoTAP,
Google Servo v1/v2, and FIC OpenMoko Neo1973 Debug board.
  * gfxnvidia (for flash ROMs on NVIDIA graphics cards)
  * it8212 (for flash ROMs on ITE IT8212F ATA/RAID controller)
  * jlink_spi (for SPI flash ROMs attached to SEGGER J-Link and
compatible devices)
  * linux_gpio_spi (for SPI flash ROMs accessible via /dev/gpiochipX on Linux)
  * linux_mtd (for SPI flash ROMs accessible via /dev/mtdX on Linux)
  * linux_spi (for SPI flash ROMs accessible via /dev/spidevX.Y on Linux)
  * mstarddc_spi (for SPI flash ROMs accessible through DDC in MSTAR-equipped
displays)
  * nic3com (for flash ROMs on 3COM network cards)
  * nicintel (for parallel flash ROMs on Intel 10/100Mbit network cards)
  * nicintel_eeprom (for SPI EEPROMs on Intel Gigabit network cards)
  * nicintel_spi (for SPI flash ROMs on Intel Gigabit network cards)
  * nicnatsemi (for flash ROMs on National Semiconductor DP838* network cards)
  * nicrealtek (for flash ROMs on Realtek and SMC 1211 network cards)
  * ogp_spi (for SPI flash ROMs on Open Graphics Project graphics card)
  * pickit2_spi (for SPI flash ROMs accessible via Microchip PICkit2)
  * pony_spi (for SPI flash ROMs attached to a SI-Prog serial port
bitbanging adapter)
  * rayer_spi (for SPI flash ROMs attached to a RayeR parport based programmer)
  * satamv (for flash ROMs on Marvell SATA controllers)
  * satasii (for flash ROMs on Silicon Image SATA/IDE controllers)
  * serprog (for flash ROMs attached to a programmer speaking serprog),
including AVR flasher by Urja Rannikko, AVR flasher by eightdot,
Arduino Mega flasher by fritz, InSystemFlasher by Juhana Helovuo,
and atmegaXXu2-flasher by Stefan Tauner.
  * stlinkv3_spi (for SPI flash ROMs attached to STMicroelectronics
STLINK V3 devices)
  * usbblaster_spi (for SPI flash ROMs attached to an Altera USB-Blaster)

--

flashprog is a fork of flashrom and a continuation of flashrom-stable.
Hence the copied description (with sorted and updated device list).
flashprog, like flashrom-stable before, provides far more regular
releases and newer chipset support compared to flashrom, so up-to-date
chipset support can hopefully make it into stable distributions in time.



Bug#1059042: munge: FTBFS if libsystemd-dev is installed

2023-12-19 Thread Gianfranco Costamagna

Package: munge
Version: 0.5.15-3
Severity: serious
Tags: patch

Hello, if libsystemd-dev is installed (or something similar, didn't dig too 
much into this), the package FTBFS due to service file not being installed from 
debian/tmp

checking for systemdunitdir... ${prefix}/lib/systemd/system
[...]
dh_missing: warning: usr/lib/systemd/system/munge.service exists in debian/tmp 
but is not installed to anywhere
dh_missing: error: missing files, aborting

This happens e.g. in Ubuntu builders.

Adding the file in not-installed works, but maybe we can just drop that 
debian/rules override_dh_install hack?

G.


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1050727: zlib: please make the build reproducible

2023-12-19 Thread Vagrant Cascadian
Version: 1:1.3.dfsg-3

On 2023-08-28, Chris Lamb wrote:
> This is because it embeds the absolute build path in the minizip and
> miniunzip scripts.
>
> A patch attached that uses sed to remove these, (although there might
> be a cleaner way to inform autotools/libtool to not do this code
> injection).

I am unable to locally reproduce the issue with the current version in
Debian, marking as done.

While tests.reproducible-builds.org also confirms no unreproducibility
results for this version, it no longer tests for build path related
issues.


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#1059040: libxml2: ABI change? (undefined references)

2023-12-19 Thread Rene Engelhard
Am Tue, Dec 19, 2023 at 08:03:56PM +0100 schrieb Rene Engelhard:
> LibreOffice builds (patch available), but doesn't yet build with 2.12.

"... but doesn't yet succeed the tests with 2.12"

> S=/home/rene/LibreOffice/git/libreoffice-24-2 && I=$S/instdir && W=$S/workdir 
> &&  /usr/bin/ccache x86_64-linux-gnu-g++ -pthread  -flto=jobserver 
> -fuse-linker-plugin -O2  -Wl,-z,origin '-Wl,-rpath,$ORIGIN/../Library' 
> -Wl,-rpath-link,$I/program  -Wl,-z,defs -Wl,-rpath-link,/lib:/usr/lib 
> -Wl,-z,combreloc  -Wl,--hash-style=gnu  -Wl,-Bsymbolic-functions 
> -L$W/LinkTarget/StaticLibrary -L$I/sdk/lib  -L$I/program  -L$I/program  
> -L$W/LinkTarget/Library -ffat-lto-objects -Wl,-z,relro
> $W/CxxObject/xmlsecurity/workben/pdfverify.o   -Wl,--start-group
> -Wl,--end-group -Wl,--no-as-needed -luno_cppu -luno_cppuhelpergcc3 -luno_sal 
> -lxmlsecurity -lmergedlo  -o $W/LinkTarget/Executable/pdfverify
> /usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to 
> `xmlIOFTPMatch@LIBXML2_2.4.30'
> /usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to 
> `xmlNanoFTPCleanup@LIBXML2_2.4.30'
> /usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to 
> `xmlIOFTPOpen@LIBXML2_2.4.30'
> /usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to 
> `xmlIOFTPClose@LIBXML2_2.4.30'
> /usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to 
> `xmlIOFTPRead@LIBXML2_2.4.30'
> /usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to 
> `xmlNanoFTPInit@LIBXML2_2.4.30'
> collect2: error: ld returned 1 exit status
> make[3]: *** 
> [/home/rene/LibreOffice/git/libreoffice-24-2/solenv/gbuild/LinkTarget.mk:853: 
> /home/rene/LibreOffice/git/libreoffice-24-2/workdir/LinkTarget/Executable/pdfverify]
>  Error 1
> 
> Do we have removed symbols/removed versions here? (libxmlsec.so.1 was
> not rebuilt)

After a rebuild of libxmlsec1 this link succeeds...

Regards,

Rene



Bug#1059005: libssh2: CVE-2023-48795

2023-12-19 Thread Salvatore Bonaccorso
Hi Nicolas,

On Tue, Dec 19, 2023 at 01:35:50PM -0500, Nicolas Mora wrote:
> Hello, thanks for the notification!
> 
> Le 2023-12-19 à 03 h 26, Salvatore Bonaccorso a écrit :
> > Source: libssh2
> > Version: 1.11.0-3
> > Severity: important
> > Tags: security upstream
> > Forwarded: https://github.com/libssh2/libssh2/issues/1290
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> > 
> I've noticed on [1] that this CVE is fixed for libssh2 on bookworm and
> under, is it the case?
> 
> I'm wondering also because they have the same version in bookworm and
> trixie, and the issue on github doesn't mention the version that is
> affected, therefore I assume all versions are vulnerable, isn't it?

It's not the same version :).

bookworm has 0.10.0 based version, whereas in testing and bove we have
1.11.0 based one. For bookworm and older there is no haCha20-Poly1305
and CBC-EtM support, which was only introduced after the 0.10.0
release.

Thus for libssh2 only unstable needs fixing (and then the fix mgirate
to testing). 

Does this help?

Regards,
Salvatore



Bug#1059041: Xorg segfault when unlocking from Xscreensaver while video playback

2023-12-19 Thread Eduard Bloch
Package: xserver-xorg-video-amdgpu
Version: 23.0.0-1
Severity: important

Prerequisites:

- icewm
- xscreensaver
- vlc

Repro:

a) let a fullscreen video run in VLC
b) wait until xscreensaver blackens the screen
c) push any key in the very same second

Result:

Whole Xorg going down, see below. Following the trace dump smells like
the error would originate in the video driver.

$ coredumpctl dump > /tmp/xorg-video-playback-crash.log


   PID: 1011552 (Xorg)
   UID: 0 (root)
   GID: 0 (root)
Signal: 6 (ABRT)
 Timestamp: Tue 2023-12-19 20:09:34 CET (5min ago)
  Command Line: /usr/lib/xorg/Xorg :0 -seat seat0 -auth 
/var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
Executable: /usr/lib/xorg/Xorg
 Control Group: /system.slice/lightdm.service
  Unit: lightdm.service
 Slice: system.slice
   Boot ID: 67cdd05639504fd48e987b5f02106871
Machine ID: ae90e3d096ca29949df8c700456b394f
  Hostname: zombie
   Storage: 
/var/lib/systemd/coredump/core.Xorg.0.67cdd05639504fd48e987b5f02106871.1011552.170301297400.zst
 (present)
  Size on Disk: 7.1M
   Message: Process 1011552 (Xorg) of user 0 dumped core.

Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64
Module libsystemd.so.0 from deb systemd-255-1.amd64
Module libudev.so.1 from deb systemd-255-1.amd64
Stack trace of thread 1011552:
#0  0x7fb1494a80fc __pthread_kill_implementation (libc.so.6 
+ 0x8a0fc)
#1  0x7fb14945a472 __GI_raise (libc.so.6 + 0x3c472)
#2  0x7fb149b2 __GI_abort (libc.so.6 + 0x264b2)
#3  0x5577d8f7ae30 OsAbort (Xorg + 0x1d8e30)
#4  0x5577d8f80649 n/a (Xorg + 0x1de649)
#5  0x5577d8f81619 FatalError (Xorg + 0x1df619)
#6  0x5577d8f78019 n/a (Xorg + 0x1d6019)
#7  0x7fb14945a510 __restore_rt (libc.so.6 + 0x3c510)
#8  0x7fb149186702 n/a (amdgpu_drv.so + 0x16702)
#9  0x7fb149186c96 n/a (amdgpu_drv.so + 0x16c96)
#10 0x5577d8e75a6b xf86DPMSSet (Xorg + 0xd3a6b)
#11 0x5577d8e41485 n/a (Xorg + 0x9f485)
#12 0x5577d8eb5c56 n/a (Xorg + 0x113c56)
#13 0x5577d8f57335 mieqProcessInputEvents (Xorg + 0x1b5335)
#14 0x5577d8e4177d ProcessInputEvents (Xorg + 0x9f77d)
#15 0x5577d8e01f93 n/a (Xorg + 0x5ff93)
#16 0x5577d8e062cc n/a (Xorg + 0x642cc)
#17 0x7fb1494456ca __libc_start_call_main (libc.so.6 + 
0x276ca)
#18 0x7fb149445785 __libc_start_main_impl (libc.so.6 + 
0x27785)
#19 0x5577d8def281 _start (Xorg + 0x4d281)

Stack trace of thread 1011555:
#0  0x7fb1494a3156 __futex_abstimed_wait_common64 
(libc.so.6 + 0x85156)
#1  0x7fb1494a5818 __pthread_cond_wait_common (libc.so.6 + 
0x87818)
#2  0x7fb146d198ed n/a (radeonsi_dri.so + 0x1198ed)
#3  0x7fb146cf96cb n/a (radeonsi_dri.so + 0xf96cb)
#4  0x7fb146d1981b n/a (radeonsi_dri.so + 0x11981b)
#5  0x7fb1494a63ec start_thread (libc.so.6 + 0x883ec)
#6  0x7fb149526a5c __clone3 (libc.so.6 + 0x108a5c)

Stack trace of thread 1011556:
#0  0x7fb1494a3156 __futex_abstimed_wait_common64 
(libc.so.6 + 0x85156)
#1  0x7fb1494a5818 __pthread_cond_wait_common (libc.so.6 + 
0x87818)
#2  0x7fb146d198ed n/a (radeonsi_dri.so + 0x1198ed)
#3  0x7fb146cf96cb n/a (radeonsi_dri.so + 0xf96cb)
#4  0x7fb146d1981b n/a (radeonsi_dri.so + 0x11981b)
#5  0x7fb1494a63ec start_thread (libc.so.6 + 0x883ec)
#6  0x7fb149526a5c __clone3 (libc.so.6 + 0x108a5c)

Stack trace of thread 1011557:
#0  0x7fb1494a3156 __futex_abstimed_wait_common64 
(libc.so.6 + 0x85156)
#1  0x7fb1494a5818 __pthread_cond_wait_common (libc.so.6 + 
0x87818)
#2  0x7fb146d198ed n/a (radeonsi_dri.so + 0x1198ed)
#3  0x7fb146cf96cb n/a (radeonsi_dri.so + 0xf96cb)
#4  0x7fb146d1981b n/a (radeonsi_dri.so + 0x11981b)
#5  0x7fb1494a63ec start_thread (libc.so.6 + 0x883ec)
#6  0x7fb149526a5c __clone3 (libc.so.6 + 0x108a5c)

Stack trace of thread 1011562:
#0  0x7fb1494a3156 __futex_abstimed_wait_common64 
(libc.so.6 + 0x85156)
#1  0x7fb1494a5818 __pthread_cond_wait_common (libc.so.6 + 
0x87818)
#2  0x7fb146d198ed n/a (radeonsi_dri.so + 0x1198ed)
#3  0x7fb146cf96cb n/a (radeonsi_dri.so + 0xf96cb)

Bug#1059040: libxml2: ABI change? (undefined references)

2023-12-19 Thread Rene Engelhard
Package: libxml2
Version: 2.12.3+dfsg-0exp1
Severity: serious

Dear Maintainer,

Hi,

LibreOffice builds (patch available), but doesn't yet build with 2.12.
But that is not the point of this issue.

While test building current 24.2 snapshot which will become 24.2 rc1
later this week I get

[build LNK] Executable/pdfverify
S=/home/rene/LibreOffice/git/libreoffice-24-2 && I=$S/instdir && W=$S/workdir 
&&  mkdir -p $W/Dep/LinkTarget/Executable/ && RESPONSEFILE=/tmp/gbuild.yEebjc 
&& SYSTEM_BOOST="TRUE" 
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program"   
$W/LinkTarget/Executable/concat-deps ${RESPONSEFILE} > 
$W/Dep/LinkTarget/Executable/pdfverify.d.tmp && rm -f ${RESPONSEFILE}
mv 
/home/rene/LibreOffice/git/libreoffice-24-2/workdir/Dep/LinkTarget/Executable/pdfverify.d.tmp
 
/home/rene/LibreOffice/git/libreoffice-24-2/workdir/Dep/LinkTarget/Executable/pdfverify.d
S=/home/rene/LibreOffice/git/libreoffice-24-2 && I=$S/instdir && W=$S/workdir 
&&  /usr/bin/ccache x86_64-linux-gnu-g++ -pthread  -flto=jobserver 
-fuse-linker-plugin -O2  -Wl,-z,origin '-Wl,-rpath,$ORIGIN/../Library' 
-Wl,-rpath-link,$I/program  -Wl,-z,defs -Wl,-rpath-link,/lib:/usr/lib 
-Wl,-z,combreloc  -Wl,--hash-style=gnu  -Wl,-Bsymbolic-functions 
-L$W/LinkTarget/StaticLibrary -L$I/sdk/lib  -L$I/program  -L$I/program  
-L$W/LinkTarget/Library -ffat-lto-objects -Wl,-z,relro
$W/CxxObject/xmlsecurity/workben/pdfverify.o   -Wl,--start-group
-Wl,--end-group -Wl,--no-as-needed -luno_cppu -luno_cppuhelpergcc3 -luno_sal 
-lxmlsecurity -lmergedlo  -o $W/LinkTarget/Executable/pdfverify
/usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to 
`xmlIOFTPMatch@LIBXML2_2.4.30'
/usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to 
`xmlNanoFTPCleanup@LIBXML2_2.4.30'
/usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to 
`xmlIOFTPOpen@LIBXML2_2.4.30'
/usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to 
`xmlIOFTPClose@LIBXML2_2.4.30'
/usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to 
`xmlIOFTPRead@LIBXML2_2.4.30'
/usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to 
`xmlNanoFTPInit@LIBXML2_2.4.30'
collect2: error: ld returned 1 exit status
make[3]: *** 
[/home/rene/LibreOffice/git/libreoffice-24-2/solenv/gbuild/LinkTarget.mk:853: 
/home/rene/LibreOffice/git/libreoffice-24-2/workdir/LinkTarget/Executable/pdfverify]
 Error 1

Do we have removed symbols/removed versions here? (libxmlsec.so.1 was
not rebuilt)

Regards,

Rene



Bug#1056937: RFS: allegro5/2:5.2.9.0+dfsg-1 -- portable library for cross-platform game and multimedia development

2023-12-19 Thread Tobias Frost
Control: tags -1 moreinfo

Hi Andreas,

my lintian is quite unhappy:

there are many of those (and similar)

E: allegro5-doc: privacy-breach-uses-embedded-file You may use the 
node-html5shiv package (virtual package). 
(//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js) 
[usr/share/doc/allegro5-doc/refman/acodec.html]

W: allegro5-doc: groff-message troff::104: warning: cannot 
select font 'C' [usr/share/man/man3/al_set_target_bitmap.3alleg5.gz:4]

Can you please fix those and I'll upload the package.

Thanks!

-- 
tobi



Bug#874030: Anyenv

2023-12-19 Thread Mikko Johannes Koivunalho

Hello,

Okay, I understand.

I am interested in packaging but my own time is limited, too.

Do you have any resources to help in packaging Bash scripts?

Thank you. I appreciate all help.

Sincerely,
Mikko Koivunalho

On 08/12/2023 01:05, ChangZhuo Chen (陳昌倬) wrote:

On Thu, Dec 07, 2023 at 12:59:06AM +0100, Mikko Johannes Koivunalho wrote:

Has there been any interest? I am a permanent Anyenv user and contributor
and I'd very much like to see it packaged for Debian.

I'm also willing to help, if needed, but I know very little about Debian
packaging.

Sorry, I don't have time for this. If you are interested in packaing, I
can help to sponsor.





Bug#1058696: bugs.debian.org: Can we change the mail address of the release.debian.org pseudo package?

2023-12-19 Thread Paul Gevers

Hi Cord,

On 19-12-2023 19:38, Cord Beermann wrote:

Hallo! Du (Don Armstrong) hast geschrieben:


On Sat, 16 Dec 2023, Cord Beermann wrote:

However: if we implement this, i'd consider this as a workaround as
mails that should not be distributed, should not be sent out in the
first place.


That works for me; there's a missing feature in the BTS currently to
turn off e-mails to maintainers, so when that is in place, this
workaround can be removed.


So I need some examples.


Are links to the lists.d.o enough? Or should I send you messages (with 
full headers)? (I'll start with the former)


https://lists.debian.org/debian-release/2023/11/msg0.html
https://lists.debian.org/debian-release/2023/11/msg7.html
https://lists.debian.org/debian-release/2023/11/msg00020.html
https://lists.debian.org/debian-release/2023/11/msg00029.html

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1058999: linux-image-6.5.0-5-amd64: System hangs when connecting an ethernet NIC to network which was not connected on boot

2023-12-19 Thread Diederik de Haas
On Tuesday, 19 December 2023 19:16:33 CET Erwan David wrote:
> Same behaviour with 6.6.3-1 from experimental (that's what apt gave me,
> maybe tomoroow the 6.6.4).

Either your APT cache should be updated or you're using a mirror which is 
rather severely out of date.
6.6.4-1 was uploaded to Debian on 2023-12-03, a day after .3-1.

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


Bug#1059005: libssh2: CVE-2023-48795

2023-12-19 Thread Nicolas Mora

Hello, thanks for the notification!

Le 2023-12-19 à 03 h 26, Salvatore Bonaccorso a écrit :

Source: libssh2
Version: 1.11.0-3
Severity: important
Tags: security upstream
Forwarded: https://github.com/libssh2/libssh2/issues/1290
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

I've noticed on [1] that this CVE is fixed for libssh2 on bookworm and 
under, is it the case?


I'm wondering also because they have the same version in bookworm and 
trixie, and the issue on github doesn't mention the version that is 
affected, therefore I assume all versions are vulnerable, isn't it?


/Nicolas

[1] https://security-tracker.debian.org/tracker/source-package/libssh2
[2] https://github.com/libssh2/libssh2/issues/1290



Bug#1058696: bugs.debian.org: Can we change the mail address of the release.debian.org pseudo package?

2023-12-19 Thread Cord Beermann
Hallo! Du (Don Armstrong) hast geschrieben:

> On Sat, 16 Dec 2023, Cord Beermann wrote:
> > However: if we implement this, i'd consider this as a workaround as
> > mails that should not be distributed, should not be sent out in the
> > first place.
> 
> That works for me; there's a missing feature in the BTS currently to
> turn off e-mails to maintainers, so when that is in place, this
> workaround can be removed.

So I need some examples.


Yours,
Cord, Debian Listmaster of the day
-- 
https://lists.debian.org



Bug#925657: condor: ftbfs with GCC-9

2023-12-19 Thread Bastian Germann

Control: tags -1 - bookworm bullseye
Control: tags 936323 - bookworm bullseye
Control: tags 966726 - bookworm bullseye

The package was not released with bookworm or bullseye.



Bug#1058999: linux-image-6.5.0-5-amd64: System hangs when connecting an ethernet NIC to network which was not connected on boot

2023-12-19 Thread Erwan David

Le 19/12/2023 à 09:10, Salvatore Bonaccorso a écrit :

Control: tags -1 + moreinfo

On Tue, Dec 19, 2023 at 08:49:45AM +0100, Erwan David wrote:

Package: src:linux
Version: 6.5.13-1
Severity: important

On a Dell Latitude 7490, with 1 intergated e1000e nic, and an extrenal Dock 
with Realtek8153. If ethernet on one of those NICs is
connected at boot, it runs OK. However, if a NIC is connected to network while 
the kernel runs (or when coming back from
hibernation), system hangs, any network related process is stuck (even a simple 
ip a) and load climbs.
Clean shutdown is not possible because disk cannot be unmounted because of 
those processes.

Status here is obviously on a fresh booted system, without the problem. I know 
how to reproduce, and there is a small time window
where I might be able to launch some diagnostic commands at the beginning of 
the problem.

As there won't be any further updates in the 6.5.y series and we will
move at some point to the 6.6.y one, can you test it against the
version which is currently in experimental? (6.6.4-1~exp1).

Regards,
Salvatore

Same behaviour with 6.6.3-1 from experimental (that's what apt gave me, 
maybe tomoroow the 6.6.4). I tested with a Lenovo T590 on an Aten dock 
with also a realtek5183 NIC. It works with 6.5.0-5 On the Dell it works 
with 6.5.0-4 which makes me think the hardware is good.


One difference between the lenovo and the Dell : since the Dell has a 
smaller disk and was installed in 2020 then upgraded, the /boot is small 
and initramfs is in "dep" mode, with some modules forced for the dock. 
At the end of week I'll be able to test the Dell on same Dock as the 
lenovo (not the other way around, Dell and its dock are work issued and 
I cannot connect a personnal laptop on the dock), and try to use the 
"most mode for initramfs. I'll also check carefully the differences 
between the package lists, especially firmwares.




Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak

2023-12-19 Thread Tobias Frost
Am Sat, Dec 09, 2023 at 12:15:29PM +0300 schrieb Igor B. Poretsky:
> Hello Tobias,
> 
> > "Tobias" == Tobias Frost  writes:
> 
> Tobias> The "-1" is the Debian revision; it is orthogonal to the
> Tobias> upstream version, (except the rules where it resets to
> Tobias> usually -1, of course)
> 
> So, what should I do if my package has not been yet sponsored, but a new
> upstream release actually has some sensible fixes? As I understand, I
> may update my upload on mentors.debian.net. But what should I do in
> debian/changelog? Should I add a new entry with a new upstream version
> or amend the one that closes the ITP bug? I think that the latter option
> is better. Am I right?

You amend it. To avoid ambigiouness:

Until the first upload is sponsored, you just keep a single changelog entry.
In the case of a new upstream version, you just change the version accordingly.

For example a fictional package foobar, updating from 1.0.0 to 1.0.1:

foobar (1.0.0-1) unstable; urgency=medium

 * Initial Package (Closes: #…)

would become:

foobar (1.0.1-1) unstable; urgency=medium

 * Initial Package (Closes: #…)

Version 1.0.0-1 will NOT be mentioned in d/changelog, as there are no changes
to the Debian package if there was no prior upload.


-- 
Cheers,
tobi



Bug#1058755: logcheck: Email not report log lines

2023-12-19 Thread Richard Lewis
control: close -1
thanks

On Tue, 19 Dec 2023, 08:39 Stefano Callegari, 
wrote:

>
>

> > The logs lines there are, but after the header I see many blank lines: I
> > use mutt in a full screen console (more than 50 lines) and I need to
> press
> > page down for 16 times before reach the first line of logs (in the last
> one
> > email).
> >




> May be the problem is related with irqbalance.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058886
> https://bugs.launchpad.net/ubuntu/+source/irqbalance/+bug/2046470
> https://ubuntuforums.org/showthread.php?t=2493441=14169790
>
>
that loooks quite likely to be it - although trailing space does get
removed, it looks like the lines end with lots of dashes.

You can filter these lines like any other, and setting SORTUNIQ reduces
duplication (a bit)


> > If you think, close the bug.
>

thanks - yes the output looks normal. the "output" is actually on stderr so
to save it, use ... 2>&1 or similar.


Bug#1059039: usrmerge: installing usrmerge on a chroot with /usr on a separate partition fails

2023-12-19 Thread stef
Package: usrmerge
Version: 38
Severity: important

howdy,

trying to update a debian unstable system, and it breaks due to usrmerge.

Preparing to unpack .../archives/usrmerge_38_all.deb ...
/usr is a standalone filesystem, this requires using an initramfs.
dpkg: error processing archive /var/cache/apt/archives/usrmerge_38_all.deb 
(--install):
 new usrmerge package pre-installation script subprocess returned error exit 
status 1

thx.

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

Kernel: Linux 6.5.3-0-edge (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages usrmerge depends on:
ii  libfile-find-rule-perl  0.34-3
ii  perl5.36.0-10

usrmerge recommends no packages.

usrmerge suggests no packages.



Bug#1051296: freecad: still crashes with version 0.21.2

2023-12-19 Thread Leonardo Canducci
Package: freecad
Version: 0.21.2+dfsg1-1
Followup-For: Bug #1051296

Dear Maintainer,
I'm experiencing a simular behaviour with the latest version. FreeCAD
crashes when open a file o creating a new one when launched on gnome
with wayland. All is fine when launched on XFCE. The appimage package
from upstream works fine in both desktop environments.

Using the suggested fix solves the problem right now and doesn't slow
down FreeCAD's execution as with version 0.20. Overall this update is an
improvement and I can stop using the appimage package.

Regards,
Leonardo

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

Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.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 freecad depends on:
ii  freecad-python3  0.21.2+dfsg1-1

Versions of packages freecad recommends:
ii  calculix-ccx2.20-1
ii  graphviz2.42.2-7+b3
ii  python3-opencamlib  2023.01.11-4+b1

Versions of packages freecad suggests:
pn  povray  

-- no debconf information



Bug#1058991: firmware-misc-nonfree: Possible missing firmware for module nouveau, kernel crash in nouveau

2023-12-19 Thread Diederik de Haas
Control: tag -1 +patch

On dinsdag 19 december 2023 17:14:22 CET you wrote:
> > If you manually create those links from the above "+Link:" lines,
> > would that fix the issues?
> 
> I've added only the ga107 symlinks (since this is what is needed
> for my machine) with
> ...
> and this fixes all the issues

Thanks, submitted the following MR to get the Debian package updated:
https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/80

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


Bug#1057967: This bug is not resolved completely - update

2023-12-19 Thread Artur Swat

There is a newer image in backports, I installed version:
# apt list --installed | grep linux-image.*back
linux-image-6.5.0-0.deb12.4-amd64/stable-backports,now 6.5.10-1~bpo12+1 
amd64 [installed]


After reboot version changed:
# uname -a
Linux P7730 6.5.0-0.deb12.4-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
6.5.10-1~bpo12+1 (2023-11-23) x86_64 GNU/Linux


And problem (when connecting cable network) is gone, network and Gnome 
work as usual :-)




Bug#1058960: dpkg: warning: unable to delete old directory '/usr/share/debian-reference': Directory not empty

2023-12-19 Thread Sven Joachim
On 2023-12-18 22:57 +0100, Christoph Anton Mitterer wrote:

> Package: debian-reference
> Version: 2.109
> Severity: normal
>
>
> Hey.
>
> Something looks odd with the package’s files registration in Debian.
> On upgrade from 2.108 to 2.109 I got:
> Unpacking debian-reference-common (2.109) over (2.108) ...
> dpkg: warning: unable to delete old directory 
> '/usr/share/debian-reference/images': Directory not empty
> Preparing to unpack .../01-debian-reference-en_2.109_all.deb ...
> Unpacking debian-reference-en (2.109) over (2.108) ...
> dpkg: warning: unable to delete old directory '/usr/share/debian-reference': 
> Directory not empty
>
>
> And indeed, none of these files seem to belong to a Debian package:
> $ dpkg -S /usr/share/debian-reference/images/*
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/images/caution.png
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/images/home.png
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/images/important.png
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/images/next.png
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/images/note.png
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/images/prev.png
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/images/tip.png
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/images/up.gif
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/images/warning.png
> $ dpkg -S /usr/share/debian-reference/*
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/apa.en.html
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/ch01.en.html
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/ch02.en.html
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/ch03.en.html
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/ch04.en.html
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/ch05.en.html
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/ch06.en.html
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/ch07.en.html
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/ch08.en.html
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/ch09.en.html
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/ch10.en.html
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/ch11.en.html
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/ch12.en.html
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/debian-reference.css
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/debian-reference.en.pdf
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/debian-reference.en.txt.gz
> dpkg-query: no path found matching pattern /usr/share/debian-reference/images
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/index.en.html
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/index.html
> dpkg-query: no path found matching pattern 
> /usr/share/debian-reference/pr01.en.html
>
> These files do however seem to exist in the package, though registered as:
> $ grep /usr/share/doc/debian-reference-common/docs 
> /var/lib/dpkg/info/debian-reference-common.list
> /usr/share/doc/debian-reference-common/docs
> /usr/share/doc/debian-reference-common/docs/.htaccess
> /usr/share/doc/debian-reference-common/docs/debian-reference.css
> /usr/share/doc/debian-reference-common/docs/images
> /usr/share/doc/debian-reference-common/docs/images/caution.png
> /usr/share/doc/debian-reference-common/docs/images/home.png
> /usr/share/doc/debian-reference-common/docs/images/important.png
> /usr/share/doc/debian-reference-common/docs/images/next.png
> /usr/share/doc/debian-reference-common/docs/images/note.png
> /usr/share/doc/debian-reference-common/docs/images/prev.png
> /usr/share/doc/debian-reference-common/docs/images/tip.png
> /usr/share/doc/debian-reference-common/docs/images/up.gif
> /usr/share/doc/debian-reference-common/docs/images/warning.png
> /var/lib/dpkg/info$ grep /usr/share/doc/debian-reference-common/docs 
> /var/lib/dpkg/info/debian-reference-en.list
> /usr/share/doc/debian-reference-common/docs
> /usr/share/doc/debian-reference-common/docs/apa.en.html
> /usr/share/doc/debian-reference-common/docs/ch01.en.html
> /usr/share/doc/debian-reference-common/docs/ch02.en.html
> /usr/share/doc/debian-reference-common/docs/ch03.en.html
> /usr/share/doc/debian-reference-common/docs/ch04.en.html
> /usr/share/doc/debian-reference-common/docs/ch05.en.html
> /usr/share/doc/debian-reference-common/docs/ch06.en.html
> 

Bug#1058991: firmware-misc-nonfree: Possible missing firmware for module nouveau, kernel crash in nouveau

2023-12-19 Thread Vincent Lefevre
On 2023-12-19 14:32:31 +0100, Diederik de Haas wrote:
> If you manually create those links from the above "+Link:" lines,
> would that fix the issues?

I've added only the ga107 symlinks (since this is what is needed
for my machine) with

for i in acr nvdec sec2
do
  mkdir /usr/lib/firmware/nvidia/ga107/$i &&
  cd /usr/lib/firmware/nvidia/ga107/$i &&
  ln -s ../../ga102/$i/* .
done

and this fixes all the issues: the "Possible missing firmware" messages
(for ga107), the kernel crashes that were mentioned in the journalctl
output, and the black screen issue.

Thank you,

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



Bug#1059038: python3-django-q: Upgrade to django-q2?

2023-12-19 Thread Roland Mas
Package: python3-django-q
Version: 1.3.9-4
Severity: wishlist

Dear Maintainer,

https://github.com/Koed00/django-q seems to be unmaintained, but
there's a fork at
https://github.com/django-q2/django-q2 that seems to be more like a
continuation than a fork. It proposes to be a drop-in replacement, but
it also adds some interesting features such as the ability to separate
tasks across multiple queues, and improved compatibility with new
versions of Django.

I suggest django-q2 be packaged either as a replacement for django-q,
or as a different package with a Provides/Conflicts/Replaces.

Thanks,

Roland

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

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

Versions of packages python3-django-q depends on:
ii  libjs-sphinxdoc 5.3.0-4
ii  python3 3.11.2-1+b1
ii  python3-arrow   1.2.3-1
ii  python3-blessed 1.19.1-1
ii  python3-django  3:3.2.19-1+deb12u1
ii  python3-django-picklefield  3.1.0-1
ii  python3-future  0.18.2-6
ii  python3-redis   4.3.4-3

python3-django-q recommends no packages.

Versions of packages python3-django-q suggests:
pn  python3-boto3 
pn  python3-croniter  
pn  python3-django-redis  
pn  python3-hiredis   
ii  python3-psutil5.9.4-1+b1
pn  python3-pymongo   

-- no debconf information



Bug#1059037: debian-live: Unable to boot

2023-12-19 Thread Janusz Bień

Package: debian-live
Severity: grave
X-Debbugs-Cc: jsb...@mimuw.edu.pl

Trying to boot Debian Live 12.4.0 amd 64 Gnome I get the black screen 
with a large cursor.


Some info about the computer:

ASRock B360M-ITX/AC
Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz   3.19 GHz

Actually the installed system no longer boots, so to be able to use the 
live version is very important for me until I solve the problem of the 
installed version.


Best regards

JSB



Bug#1059036: mdevctl FTBFS with nocheck profile: missing Build-Depends

2023-12-19 Thread Helmut Grohne
Source: mdevctl
Version: 1.2.0-5
Severity: serious
Tags: ftbfs

mdevctl fails to build from source when building with the nocheck build
profile. Since trixie, such a failure is considered release critical by
the release team. A build log ends as follows:

|dh_auto_install --destdir=debian/mdevctl/ -O--buildsystem=cargo
| install -m0755 -d /<>/debian/mdevctl
| find . ! -newermt 'jan 01, 2000' -exec touch -d@1698049260 {} +
| env DESTDIR=debian/mdevctl /usr/share/cargo/bin/cargo install
| debian cargo wrapper: options, profiles, parallel, lto: ['nocheck', 
'parallel=1'] ['nocheck'] ['-j1'] 0
| debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, 
x86_64-linux-gnu
| debian cargo wrapper: installing into destdir 'debian/mdevctl' prefix '/usr'
| debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', 
'CARGO_TARGET_DIR=/<>/target', '/usr/bin/cargo', 
'-Zavoid-dev-deps', 'install', '--verbose', '--verbose', '-j1', '--target', 
'x86_64-unknown-linux-gnu', '--path', '/<>', '--root', 
'debian/mdevctl/usr'],) {'check': True}
|   Installing mdevctl v1.2.0 (/<>)
| error: failed to compile `mdevctl v1.2.0 (/<>)`, intermediate 
artifacts can be found at `/<>/target`
| 
| Caused by:
|   no matching package named `tempfile` found
|   location searched: registry `crates-io`
|   required by package `mdevctl v1.2.0 (/<>)`
| Traceback (most recent call last):
|   File "/usr/share/cargo/bin/cargo", line 257, in 
| sys.exit(main(*sys.argv[1:]))
|  ^^^
|   File "/usr/share/cargo/bin/cargo", line 247, in main
| return install(os.getenv("DESTDIR", ""),
|^
|   File "/usr/share/cargo/bin/cargo", line 134, in install
| logrun(["env", "RUST_BACKTRACE=1",
|   File "/usr/share/cargo/bin/cargo", line 76, in logrun
| return subprocess.run(*args, **kwargs)
|^^^
|   File "/usr/lib/python3.11/subprocess.py", line 571, in run
| raise CalledProcessError(retcode, process.args,
| subprocess.CalledProcessError: Command '['env', 'RUST_BACKTRACE=1', 
'CARGO_TARGET_DIR=/<>/target', '/usr/bin/cargo', 
'-Zavoid-dev-deps', 'install', '--verbose', '--verbose', '-j1', '--target', 
'x86_64-unknown-linux-gnu', '--path', '/<>', '--root', 
'debian/mdevctl/usr']' returned non-zero exit status 101.
| dh_auto_install: error: env DESTDIR=debian/mdevctl /usr/share/cargo/bin/cargo 
install returned exit code 1
| make: *** [debian/rules:9: binary] Error 25
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

I guess that librust-tempfile-dev really shouldn't be annotated
.

Helmut



Bug#1055192: RFS: golang-github-apenella-go-ansible

2023-12-19 Thread weepingclown
Hi Maytham,

Once again, thanks for the care, and what you mentioned once again made sense 
so I've implemented them after testing. While I feel bad at the fact that I've 
missed these more than once, in the process I also just solved something that 
had been bugging me. That said, I'd rather I haven't missed more things xD

Thanks again :)

Best,
Ananthu

On 18 December 2023 1:19:10 pm IST, Maytham Alsudany  
wrote:
>Hi Ananthu,
>
>On Sat, 2023-12-16 at 16:07 +0530, weepingclown wrote:
>> DH_GOLANG_EXCLUDES_ALL is true by default since DH_COMPAT 12 (according to 
>> the
>> manual at least). I also confirmed that examples/ is not installed in
>> /usr/share/gocode. Nonetheless, thank you for showing the care :)
>
>My mistake, I didn't notice that in the manual. :)
>
>Here's some more things I've found (in go-ansible):
>
>  - golang-github-go-errors-errors-dev is only used in
>pkg/vault/variableVaulter_test.go, should it be  and removed from
>Deps?
>  - golang-github-spf13-cobra-dev is only used in the examples (specifically
>examples/ansibleplaybook-cobra-cmd/ansibleplaybook-cobra-cmd.go), should it
>be removed from (B-)Deps?
>
>Kind regards,
>Maytham


Bug#1059035: RFS: geeqie/1:2.1-2 -- image viewer using GTK+

2023-12-19 Thread Andreas Rönnquist
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : geeqie
   Version  : 1:2.1-2
 * URL  : http://geeqie.org/
 * License  : GPL-2+, GFDL-1.2+
 * Vcs  : https://salsa.debian.org/debian/geeqie
   Section  : graphics

The source builds the following binary packages:

  geeqie - image viewer using GTK+
  geeqie-common - data files for Geeqie

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/g/geeqie/geeqie_2.1-2.dsc

Changes since the last upload:

 geeqie (1:2.1-2) unstable; urgency=medium
 .
   * Add webp-pixbuf-loader to build-dependencies
   * Add patch to add loongarch64 support (Closes: #1058719)

Regards,
-- 
  Andreas Rönnquist



Bug#1059031: qbittorrent: Crash when starting download with new torrent

2023-12-19 Thread Christian Marillat
On 19 déc. 2023 10:12, Boyuan Yang  wrote:

> Package: qbittorrent
> Version: 4.6.2-1
> Severity: grave
> X-Debbugs-CC: maril...@debian.org
>
> Dear Debian qbittorrent maintainers,
>
> Current qbittorrent in Debian Sid will crash when a new download task is
> initiated and started with a torrent file.

The problem come libtorrent-rasterbar2.0 and the rebuild with boost 1.83

Downgrading libtorrent-rasterbar2.0 from 2.0.9-2+b1 to 2.0.9-2 fix this
issue.

Christian



Bug#1058938: bookworm-pu: package onionprobe/1.0.0+ds-2.1+deb12u1

2023-12-19 Thread Antoine Beaupré
I have reviewed this patch and it looks sane to me. I have deployed the
updated package on our servers and it is so far running without flaw.

A.

-- 
There is no cloud, it's just someone else's computer.
   - Chris Watterson



Bug#1059034: librust-scraper-dev: depends on missing package librust-ego-tree-0.6+default-dev

2023-12-19 Thread Jonas Smedegaard
Package: librust-scraper-dev
Version: 0.18.1-1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Impossible to install: Depends on missing package
librust-ego-tree-0.6+default-dev
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWBuOIACgkQLHwxRsGg
ASGlYA//UV+wJpnvVAi6Ey3ERwr2hbc24wKonaKlF5CS0op+gLkMiTAql8XVOk8q
qdh4anfXvhUmdSiklXeYACEM8mcuXThdiIDnfN9gHAF9Af1mh/hAVXzXpDG+qL+h
MheIScVhm8KSx7d88mG1zQA5bbom6+WrhucVxHwyU1GRc05SxLjwFd2VEwXc5bU1
p30OLZ3br3vHfBnFeNu5Msu2z5PhpPTDdlpAGsAmrQ+zaIdCorLII5vHP5ooOxJP
bMSMag9xnsdbioLP/MN4UmUzhplBjJi5OxjGnXn0Jd48Tp9bSEbMeBkFCfl7mBmM
dLTKflLV5o4rEVFdqxaU9jQLi5d7avv/SeXZBhXylvSS9p6fWk7T5p1iqf5vIdIv
99PlSZU1qXWwPvWUXNWzylH/dZT9SeGRjImYb5fLVVuwUlcCkwI+NpaCZtIiZTSW
gWWAqFVHIZBgNaObaYez75F5ndHmzXeySSxXeWdZgxPZeVgIpUl52WluSfaef1qB
h1g0AT/apoLbed2nyLtMOaYKw6dWUNHZ7b6dtEqg2GtBlbwoH0UjtCF8h89KgRYn
NB4xq48b6bxcrLFft/1kLWjMtCQmqDkrtgGWbDArrzfVMw4cDZEWTwBt2ZOBqfyc
y8QVhRoNXKjnW8+4BXoWY1jjoYmVNl5gcRmY4z+77hvTCqrbG5g=
=goZD
-END PGP SIGNATURE-



Bug#1056984: bind9: regression: the branch 9.19 misses some commits from the branch 9.18

2023-12-19 Thread Bernhard Schmidt
Control: forwarded -1 
https://salsa.debian.org/dns-team/bind9/-/merge_requests/26

On 27/11/23 09:12 PM, Arnaud Rebillout wrote:

Hi,

> In https://bugs.debian.org/1025519 was reported a bug in bind9 apparmor
> configuration. It was fixed on the branch `debian/9.18`, with commit
> https://salsa.debian.org/dns-team/bind9/-/commit/5c03f25e, and released
> version `1:9.18.10-2` of bind9 (released in December 2022).
> 
> However today the issue is back. The regression is due to the fact that
> the commit 5c03f25e was not applied in the branch `debian/9.19`, which
> is currently in Debian unstable.
> 
> Looking at the changelog (on branch `debian/9.19`), it jumps straight
> from `9.18.2-1` to `9.19.0-1`, makes me wonder how many good commits
> from the branch 9.18 are missing in the branch 9.19... Please have a
> look, and at least apply 5c03f25e, it's a must!

I have taken a look and identified four missing commits. 

@Ondrej: Could you have a look at
https://salsa.debian.org/dns-team/bind9/-/merge_requests/26 ?

Bernhard



Bug#1059033: asterisk: CVE-2023-49786

2023-12-19 Thread Salvatore Bonaccorso
Source: asterisk
Version: 1:20.5.0~dfsg+~cs6.13.40431414-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for asterisk.

CVE-2023-49786[0]:
| Asterisk is an open source private branch exchange and telephony
| toolkit. In Asterisk prior to versions 18.20.1, 20.5.1, and 21.0.1;
| as well as certified-asterisk prior to 18.9-cert6; Asterisk is
| susceptible to a DoS due to a race condition in the hello handshake
| phase of the DTLS protocol when handling DTLS-SRTP for media setup.
| This attack can be done continuously, thus denying new DTLS-SRTP
| encrypted calls during the attack. Abuse of this vulnerability may
| lead to a massive Denial of Service on vulnerable Asterisk servers
| for calls that rely on DTLS-SRTP. Commit
| d7d7764cb07c8a1872804321302ef93bf62cba05 contains a fix, which is
| part of versions 18.20.1, 20.5.1, 21.0.1, amd 18.9-cert6.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-49786
https://www.cve.org/CVERecord?id=CVE-2023-49786
[1] https://github.com/asterisk/asterisk/security/advisories/GHSA-hxj9-xwr8-w8pq
[2] 
https://github.com/asterisk/asterisk/commit/d7d7764cb07c8a1872804321302ef93bf62cba05

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#1059032: asterisk: CVE-2023-49294

2023-12-19 Thread Salvatore Bonaccorso
Source: asterisk
Version: 1:20.5.0~dfsg+~cs6.13.40431414-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for asterisk.

CVE-2023-49294[0]:
| Asterisk is an open source private branch exchange and telephony
| toolkit. In Asterisk prior to versions 18.20.1, 20.5.1, and 21.0.1,
| as well as certified-asterisk prior to 18.9-cert6, it is possible to
| read any arbitrary file even when the `live_dangerously` is not
| enabled. This allows arbitrary files to be read. Asterisk versions
| 18.20.1, 20.5.1, and 21.0.1, as well as certified-asterisk prior to
| 18.9-cert6, contain a fix for this issue.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-49294
https://www.cve.org/CVERecord?id=CVE-2023-49294
[1] https://github.com/asterisk/asterisk/security/advisories/GHSA-8857-hfmw-vg8f
[2] 
https://github.com/asterisk/asterisk/commit/424be345639d75c6cb7d0bd2da5f0f407dbd0bd5

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#1059031: qbittorrent: Crash when starting download with new torrent

2023-12-19 Thread Boyuan Yang
Package: qbittorrent
Version: 4.6.2-1
Severity: grave
X-Debbugs-CC: maril...@debian.org

Dear Debian qbittorrent maintainers,

Current qbittorrent in Debian Sid will crash when a new download task is
initiated and started with a torrent file.

Steps to reproduce:

(1) Open an arbitrary torrent file, such as the one downloaded from
https://archive.org/details/need-for-speed-hot-pursuit-2 .

(2) Open the torrent file from qbittorrent.

(3) Select any download target folder and start the download.

(4) The program will crash.

*
Please file a bug report at https://bug.qbittorrent.org and provide the
following information:

qBittorrent version: v4.6.2

Caught signal: SIGSEGV
```
 0# getStacktrace[abi:cxx11]() in /usr/bin/qbittorrent
 1# 0x55FDE9219DD6 in /usr/bin/qbittorrent
 2# 0x7F6200C5A510 in /lib/x86_64-linux-gnu/libc.so.6
 3# libtorrent::announce_entry::~announce_entry() in /lib/x86_64-linux-
gnu/libtorrent-rasterbar.so.2.0
 4# NativeTorrentExtension::NativeTorrentExtension(libtorrent::torrent_handle
const&, ExtensionData*) in /usr/bin/qbittorrent
 5# NativeSessionExtension::new_torrent(libtorrent::torrent_handle const&,
libtorrent::client_data_t) in /usr/bin/qbittorrent
 6# 0x7F62022B9149 in /lib/x86_64-linux-gnu/libtorrent-rasterbar.so.2.0
 7# 0x7F62022CA8E0 in /lib/x86_64-linux-gnu/libtorrent-rasterbar.so.2.0
 8# 0x7F62022CAF7D in /lib/x86_64-linux-gnu/libtorrent-rasterbar.so.2.0
 9# 0x7F620228CF38 in /lib/x86_64-linux-gnu/libtorrent-rasterbar.so.2.0
10# 0x7F6202296738 in /lib/x86_64-linux-gnu/libtorrent-rasterbar.so.2.0
11# 0x7F62020FE7E4 in /lib/x86_64-linux-gnu/libtorrent-rasterbar.so.2.0
12# 0x7F6202280651 in /lib/x86_64-linux-gnu/libtorrent-rasterbar.so.2.0
13# 0x7F62022808E7 in /lib/x86_64-linux-gnu/libtorrent-rasterbar.so.2.0
14# 0x7F6200EDC483 in /lib/x86_64-linux-gnu/libstdc++.so.6
15# 0x7F6200CA63EC in /lib/x86_64-linux-gnu/libc.so.6
16# 0x7F6200D26A5C in /lib/x86_64-linux-gnu/libc.so.6
```

QObject::installEventFilter(): Cannot filter events for objects in a different
thread.
[1]9890 segmentation fault  /usr/bin/qbittorrent



Thanks,
Boyuan Yang


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


Bug#1058706: mariadb-server-core: mariadbd fails to start on fresh install on armel

2023-12-19 Thread Scott Barker
For myself, I am not using XEN/KVM/Docker. I am installing this on a NAS 
device with an ARM chip and only 512M of RAM. I tried adding a 2G swap file, 
but it did not make a difference. I was able to start mariadb by disabling 
INNODB and using MyISAM instead with the options:


--innodb=OFF --default-storage-engine=MyISAM

On Mon, Dec 18, 2023 at 09:23:55AM +0200, Tuukka Pasanen wrote:

Hello,

Have you monitored that is memory exhausted at the installation? This 
could lead error like that.


I assume your XEN/KVM/Docker base machine is some older system with 
not so fancy CPU or is there any particular reason to use armel build?


Sincerly,

Tuukka

Scott Barker kirjoitti 17.12.2023 klo 19.15:

Same result with the latest kernel:

Linux nas-1 6.1.0-16-marvell #1 Debian 6.1.67-1 (2023-12-12) 
armv5tel GNU/Linux


On Sun, Dec 17, 2023 at 09:59:23AM -0700, Scott Barker wrote:
Prior to the installation, /var/lib/mysql did not exist. After 
installation:


61559 4 drwxr-xr-x 2 mysql  mysql  4096 Dec 17 09:56 
/var/lib/mysql
61975 4 -rw-rw 1 mysql  mysql    52 Dec 17 09:56 
/var/lib/mysql/aria_log_control
61983 12304 -rw-rw 1 mysql  mysql  12582912 Dec 17 09:56 
/var/lib/mysql/ibdata1
61963 0 -rw-r--r-- 1 root   root  0 Dec 17 09:56 
/var/lib/mysql/debian-10.11.flag
61990 98404 -rw-rw 1 mysql  mysql 100663296 Dec 17 09:56 
/var/lib/mysql/ib_logfile101
61982    16 -rw-rw 1 mysql  mysql 16384 Dec 17 09:56 
/var/lib/mysql/aria_log.0001


uname -a reports:

Linux nas-1 5.10.0-26-marvell #1 Debian 5.10.197-1 (2023-09-29) 
armv5tel GNU/Linux


On Sun, Dec 17, 2023 at 11:48:16PM +0800, Otto Kekäläinen wrote:

Hi Scott and Kr!

Did you note this line?

2023-12-14 14:51:33 0 [Note] InnoDB: Header page consists of 
zero bytes in

datafile: ./ibdata1, Space ID:0, Flags: 0

Can you include the output of  `find /var/lib/mysql -ls` so we 
can see what

files your system has?

What is the hardware you have? The report shows 'Linux 
5.10.0-26-marvell '.

What does `uname -a` yield?

The test suite passes on armhf at 
e.g. https://launchpad.net/~mysql-ubuntu/
+archive/ubuntu/mariadb-10.11/+builds?build_text=_state=all. 
At https://
ci.debian.net/packages/m/mariadb/unstable/armel/ it fails due to 
regression in

subselect which is unrelated to what you reported.



--
Scott Barker

--
To unsubscribe, send mail to 1058706-unsubscr...@bugs.debian.org.




--
Scott Barker



Bug#1059030: goverlay missing dependency libglu1-mesa

2023-12-19 Thread Joshua AE Lee

Package: goverlay

Version: 0.9.1-1
Severity: important

Dear Maintainer,

Attempting to open Goverlay to try out the packlage as I'm fairly new to 
trying out mangohud.


After trying to launch it via a graphical application launcher (in this 
case rofi) I got the result of no action.
So as a good linux user I fire up ye old faithful terminal and attempt 
to run goverlay from there netting this response:


joshua@desktop:~$ goverlay
[FORMS.PP] ExceptionOccurred
  Sender=Exception
  Exception=Could not load library: libGLU.so.1
  Stack trace:
  $005F720B
Exception at 005F720B: Exception:
Could not load library: libGLU.so.1.

After a quick apt search libglu I saw that libglu1-mesa was not 
installed and as a curious I just install it and now goverlay launches
fine. Checking both testing and unstable branches I see that it's called 
there as a dependency.


So since this fix was simple can someone add libglu1-mesa as a depency
for this package? I would work on submitting the patch myself but I'll
be honest and say I don't know the first thing about working with a deb
file.

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


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

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/12 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 goverlay depends on:
ii  libc6 2.36-9+deb12u3
ii  libgl1    1.6.0-1
ii  libqt5pas1    2.6+2.2.0+dfsg1-3
ii  libx11-6  2:1.8.4-2+deb12u2
ii  mangohud  0.6.8-2
ii  mesa-utils    8.5.0-1
ii  vulkan-tools  1.3.239.0+dfsg1-1

Versions of packages goverlay recommends:
ii  gamescope  3.11.49-1
ii  git    1:2.39.2-1.1
ii  vkbasalt   0.3.2.8-1

goverlay suggests no packages.

-- no debconf information



Bug#1055511: progress-linux-container: diversions need to be updated to deal with DEP17 P3

2023-12-19 Thread Daniel Baumann

Hi Helmut

On 12/19/23 15:13, Helmut Grohne wrote:

Based on the work on molly-guard, I'm ataching an updated patch and it
really is a copy of the one on bfh-container #1055509, so see there for
the why its done the way its done.


great, thanks!
I'll test it tomorrow and upload.

Regards,
Daniel



Bug#1015370: cmocka: ftbfs with LTO (link time optimization) enabled

2023-12-19 Thread Hefee
Control: reassign -1 binutils 2.41.50.20231206-1
Control: affects -1 cmocka
Control: forwarded -1  https://sourceware.org/bugzilla/show_bug.cgi?id=24415
Control: retitle ld.gold - -Wl,--wrap not supported with LTO and optimization

Hey,

this is not a bug in cmocka. It is actually an bug in ld.gold , that does not 
correctly handles - -Wl,--wrap with LTO together correctly:

https://gitlab.com/cmocka/cmocka/-/issues/20

The workaround is to disable building examples, as it is the only place where 
this feature is used. 

Current state is that ld.bfd and ld.lld are fixed. But ld.gold fails :(

https://sourceware.org/bugzilla/show_bug.cgi?id=24415

Regards,

hefee


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


Bug#967809: wmdrawer: depends on deprecated GTK 2

2023-12-19 Thread Bastian Germann

Control: tags -1 patch

I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru wmdrawer-0.10.5/debian/changelog wmdrawer-0.10.5/debian/changelog
--- wmdrawer-0.10.5/debian/changelog2021-10-26 12:47:39.0 +0200
+++ wmdrawer-0.10.5/debian/changelog2023-12-19 15:12:38.0 +0100
@@ -1,3 +1,10 @@
+wmdrawer (0.10.5-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace Build-Depends on gtk2 with subset (closes: #967809).
+
+ -- Bastian Germann   Tue, 19 Dec 2023 14:12:38 +
+
 wmdrawer (0.10.5-6) unstable; urgency=medium
 
   [ Jeremy Sowden ]
diff -Nru wmdrawer-0.10.5/debian/control wmdrawer-0.10.5/debian/control
--- wmdrawer-0.10.5/debian/control  2021-10-26 11:53:15.0 +0200
+++ wmdrawer-0.10.5/debian/control  2023-12-19 15:12:38.0 +0100
@@ -6,7 +6,9 @@
Jeremy Sowden 
 Build-Depends: debhelper-compat (= 13),
libgdk-pixbuf-xlib-2.0-dev | libgdk-pixbuf2.0-dev,
-   libgtk2.0-dev
+   libglib2.0-dev,
+   libxext-dev,
+   libxi-dev
 Rules-Requires-Root: no
 Standards-Version: 4.6.0
 Homepage: http://people.easter-eggs.org/~valos/wmdrawer/


Bug#1059029: RFS: harmony/0.7.2-1~bpo12+1 -- program and library for creating and managing Discord accounts

2023-12-19 Thread Patrick ZAJDA

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : harmony
Version : 0.7.2-1~bpo12+1
Upstream contact :
* URL : https://github.com/taylordotfish/harmony/
* License : GPL-3+
* Vcs :
Section : web

The source builds the following binary packages:

python3-harmony - program and library for creating and managing Discord 
accounts


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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/h/harmony/harmony_0.7.2-1~bpo12+1.dsc


Changes since the last upload:

harmony (0.7.2-1~bpo12+1) bookworm-backports; urgency=medium
.
* Rebuild for bookworm-backports.
.
harmony (0.7.2-1) unstable; urgency=medium
.
* New upstream release.
* New maintainer (closes: #1032369)
* Use tags to determine upstream version
* Declare compliance with Debian Policy 4.6.2, no changes needed.

Regards,
--
Patrick ZAJDA


OpenPGP_0x9D4AD35BEA273DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#916475: ghdl: various suggestions to simplify the packaging

2023-12-19 Thread Nicolas Boulenguez
Source: ghdl
Followup-For: Bug #916475

Hello.

The remaining suggestions are rebased and attached.

> Dh-builtusing

If you agree in principle with attachment #1 but do not want to apply
it for now, please keep a reminder (this bug, a pull request or
whatever fits your workflow).

> This is kind of obscure, think of the (lack of an) error message. If we
> skip this we'll get an "undefined $2" error due to set -u, which I find is
> more helpful than a quiet exit rv>0.

Attachment #2 should answer your concern.

> I've finally pushed your patches through to salsa after build testing and
> verifying the resulting binary packages packages are equivalent using
> debdiff. Differences are seem to come down to to dependency versions
> changing:

This seems OK to me, or unrelated for the dependency on libzstd1.
>From ea21a75e408397b0ed6e926ad4c34179f5d13e3b Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Sun, 1 Oct 2023 01:14:25 +0200
Subject: [PATCH 1/2] Delegate computation of Built-Using to dh-builtusing

---
 debian/control | 7 ---
 debian/rules   | 9 -
 2 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/debian/control b/debian/control
index 585ee55e..545c44b4 100644
--- a/debian/control
+++ b/debian/control
@@ -5,6 +5,7 @@ Maintainer: Debian Electronics Team 
 Build-Depends: debhelper-compat (= 13),
dh-ada-library (>= 8.1),
+   dh-sequence-builtusing,
gnat-12, gcc-12, g++-12,
gcc-12-source ,
libisl-dev (>= 0.14) ,
@@ -80,7 +81,7 @@ Description: VHDL compiler/simulator (mcode backend)
 Package: ghdl-gcc
 Architecture: any
 Build-Profiles: 
-Built-Using: ${Built-Using-GCC}
+Built-Using: ${dh-builtusing:gcc-S-source}
 Depends: ghdl-common (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends},
 	gcc, zlib1g-dev
 Description: VHDL compiler/simulator (GCC backend)
@@ -122,7 +123,7 @@ Description: VHDL compiler/simulator (tools)
 
 Package: libghdl-3-0-0
 Architecture: any
-Built-Using: ${Built-Using-GCC}
+Built-Using: ${dh-builtusing:gcc-S-source} 
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Multi-Arch: same
 Description: VHDL compiler/simulator (shared library)
@@ -135,7 +136,7 @@ Description: VHDL compiler/simulator (shared library)
 
 Package: libghdl-dev
 Architecture: any
-Built-Using: ${Built-Using-GCC}
+Built-Using: ${dh-builtusing:gcc-S-source} 
 Depends: libghdl-3-0-0 (= ${binary:Version}), ${misc:Depends}
 Multi-Arch: same
 Description: VHDL compiler/simulator (library development files)
diff --git a/debian/rules b/debian/rules
index 5821f85d..138b8581 100755
--- a/debian/rules
+++ b/debian/rules
@@ -95,15 +95,6 @@ override_dh_strip:
 	dh_strip -N libghdl-3-0-0
 	dh_strip -p libghdl-3-0-0 --dbgsym-migration='libghdl-2-0-0'
 
-override_dh_gencontrol:
-ifneq ($(filter gcc,$(BACKENDS)),)
-	dh_gencontrol -- -VBuilt-Using-GCC="$(shell dpkg-query -f '$${Source} (= $${Version})' -W gcc-$(DEB_GNAT_VERSION)-source)"
-else
-	dh_gencontrol
-endif
-
-
-
 configure-llvm-stamp configure-mcode-stamp: configure-%-stamp:
 	$(announce)
 	mkdir -p $(BUILDDIR)/$*
-- 
2.39.2

>From 07b885622c11d970f3e3c5102578c9265b5491d4 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 5 Oct 2023 14:39:35 +0200
Subject: [PATCH 2/2] test driver: move error reporting to a separate procedure

---
 debian/tests/ghdl-tests | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/debian/tests/ghdl-tests b/debian/tests/ghdl-tests
index 871d594b..eae5e43c 100755
--- a/debian/tests/ghdl-tests
+++ b/debian/tests/ghdl-tests
@@ -6,29 +6,32 @@ set -C -e -f -u
 # Debian yet.
 TESTS="sanity gna vests synth vpi vhpi"
 
-test $# = 2
+error() {
+echo >&2 "$0: $1"
+exit 1
+}
+
+test $# = 2 || error "bad argument count: $#"
 
 case "$2" in
 gcc|llvm|mcode)
-	BACKEND=$2
-	;;
+BACKEND=$2
+;;
 *)
-	echo >&2 "Invalid backend specification"
-	exit 1
+error "invalid backend specification: $2"
 esac
 
 case "$1" in
 buildtest)
-	RUNDIR=testrundir/$BACKEND
-	GHDL="$PWD/$RUNDIR/usr/bin/ghdl-$BACKEND"
-	;;
+RUNDIR=testrundir/$BACKEND
+GHDL="$PWD/$RUNDIR/usr/bin/ghdl-$BACKEND"
+;;
 autopkgtest)
-	RUNDIR="$AUTOPKGTEST_TMP"
-	GHDL=/usr/bin/ghdl-$BACKEND
-	;;
+RUNDIR="$AUTOPKGTEST_TMP"
+GHDL=/usr/bin/ghdl-$BACKEND
+;;
 *)
-	echo >&2 "Invalid test environment specification"
-	exit 1
+error "invalid test environment specification: $1"
 esac
 
 # Copy testsuite into $RUNDIR to execute there, so that no cleanup is necessary
@@ -50,6 +53,5 @@ if ./testsuite.sh $TESTS -- --keep-going; then
 elif test $BACKEND = llvm; then
 echo "Tests for backend llvm failed (but ignored for now)."
 else
-echo >&2 "Tests for backend $BACKEND failed."
-exit 1
+error "tests for backend $BACKEND failed."
 fi
-- 
2.39.2



Bug#1055511: progress-linux-container: diversions need to be updated to deal with DEP17 P3

2023-12-19 Thread Helmut Grohne
Control: tags -1 + patch

On Wed, Nov 08, 2023 at 08:45:55PM +0100, Helmut Grohne wrote:
> I'm attaching a patch. I don't have high confidence, because it fails
> piuparts with left-over files. Given the mess in piuparts, I have no
> intentions to further test this. You may use the patch as a starting
> point.

I'm now glad I missed attaching the patch. The same patch for
molly-guard was horribly broken.

Based on the work on molly-guard, I'm ataching an updated patch and it
really is a copy of the one on bfh-container #1055509, so see there for
the why its done the way its done.

Also please remember to go for experimental first (just like bfh-container).

Helmut
diff -Nru progress-linux-metapackages-20221002/debian/changelog 
progress-linux-metapackages-20221002/debian/changelog
--- progress-linux-metapackages-20221002/debian/changelog   2023-12-08 
10:53:05.0 +0100
+++ progress-linux-metapackages-20221002/debian/changelog   2023-12-19 
14:51:05.0 +0100
@@ -1,3 +1,11 @@
+progress-linux-metapackages (20221002-10.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop diversion migration from bullseye.
+  * Duplicate diversion via DEP17 M18. (Closes: #1055511)
+
+ -- Helmut Grohne   Tue, 19 Dec 2023 14:51:05 +0100
+
 progress-linux-metapackages (20221002-10) sid; urgency=medium
 
   * Uploading to sid.
diff -Nru 
progress-linux-metapackages-20221002/debian/progress-linux-container.postrm 
progress-linux-metapackages-20221002/debian/progress-linux-container.postrm
--- progress-linux-metapackages-20221002/debian/progress-linux-container.postrm 
2023-12-08 10:43:13.0 +0100
+++ progress-linux-metapackages-20221002/debian/progress-linux-container.postrm 
2023-12-19 14:50:55.0 +0100
@@ -6,12 +6,12 @@
remove)
for FILE in halt poweroff reboot shutdown coldreboot
do
-   dpkg-divert --package progress-linux-container --quiet 
--remove --rename --divert /lib/container/divert/${FILE}.orig /sbin/${FILE}
+   dpkg-divert --package progress-linux-container --quiet 
--remove --rename --divert "/lib/container/divert/$FILE.orig.usr-is-merged" 
"/sbin/$FILE"
done
 
-   for FILE in pm-hibernate pm-suspend pm-suspend-hybrid
+   for FILE in halt poweroff reboot shutdown coldreboot 
pm-hibernate pm-suspend pm-suspend-hybrid
do
-   dpkg-divert --package progress-linux-container --quiet 
--remove --rename --divert /lib/container/divert/${FILE}.orig /usr/sbin/${FILE}
+   dpkg-divert --package progress-linux-container --quiet 
--remove --rename --divert "/usr/lib/container/divert/$FILE.orig" 
"/usr/sbin/$FILE"
done
;;
 
diff -Nru 
progress-linux-metapackages-20221002/debian/progress-linux-container.preinst 
progress-linux-metapackages-20221002/debian/progress-linux-container.preinst
--- 
progress-linux-metapackages-20221002/debian/progress-linux-container.preinst
2023-12-08 10:43:13.0 +0100
+++ 
progress-linux-metapackages-20221002/debian/progress-linux-container.preinst
2023-12-19 14:51:05.0 +0100
@@ -4,30 +4,40 @@
 
 case "${1}" in
install|upgrade)
-   # upgrade from bullseye
-   if ls /lib/open-infrastructure/container/divert/*.orig > 
/dev/null 2>&1
-   then
-   for FILE in halt poweroff reboot shutdown coldreboot
-   do
-   dpkg-divert --package progress-linux-container 
--quiet --remove --rename --divert 
/lib/open-infrastructure/container/divert/${FILE}.orig /sbin/${FILE}
-   done
-
-   for FILE in pm-hibernate pm-suspend pm-suspend-hybrid
-   do
-   dpkg-divert --package progress-linux-container 
--quiet --remove --rename --divert 
/lib/open-infrastructure/container/divert/${FILE}.orig /usr/sbin/${FILE}
-   done
-   fi
-
mkdir -p /lib/container/divert
 
for FILE in halt poweroff reboot shutdown coldreboot
do
-   dpkg-divert --package progress-linux-container --quiet 
--add --rename --divert /lib/container/divert/${FILE}.orig /sbin/${FILE}
+   TRUENAMEUSR=$(dpkg-divert --truename "/usr/sbin/$FILE")
+   TRUENAMEALIAS=$(dpkg-divert --truename "/sbin/$FILE")
+   RENAME_FLAG=--no-rename
+   if test "$TRUENAMEUSR" = "/usr/sbin/$FILE"; then
+   if test "$TRUENAMEALIAS" = "/sbin/$FILE"; then
+   RENAME_FLAG=--rename
+   fi
+   dpkg-divert --package progress-linux-container 
--quiet --add "$RENAME_FLAG" --divert "/usr/lib/container/divert/$FILE.orig" 

Bug#1055509: bfh-container: diversions need to be updated to deal with DEP17 P3

2023-12-19 Thread Helmut Grohne
On Wed, Nov 08, 2023 at 08:07:29PM +0100, Helmut Grohne wrote:
> I'm proposing the attached patch to implement DEP17 mitigation M18. I
> caution that the patch is untested, because piuparts failed for
> unrelated reasons. open-infrastructure-compute-tools.postinst and
> sudo.prerm fail inside piuparts. So consider this a starting point.

The original patch didn't work at all. molly-guard was using the same
approach and it failed on multiple accounts. After quite some back and
forth, molly-guard now has a patch that looks reasonably good and I've
ported the approach to bfh-container.

Notable:
 * Diversion targets must differ in more than aliasing.
 * Since bfh-container does not need access to the diverted files, we
   can continue to move them to a different directory.
 * To avoid the conflicts-is-not-conflicts problem, bfh-container must
   support aliased as well as canonicalized versions and not declare
   Breaks or Conflicts for diverted packages such as systemd-sysv.

Since systemd-sysv now Conflits with bfh-container testing the patch in
unstable is difficult. I've tested installing, removing and upgrading it
in bookworm though and that all works. Also the diversions look
reasonable to me.

When uploading this, please target experimental. Then we'll update
systemd-sysv to add a version to their breaks and further test the patch
before uploading to unstable.

Helmut
diff -Nru bfh-metapackages-20211009/debian/bfh-container.postrm 
bfh-metapackages-20211009/debian/bfh-container.postrm
--- bfh-metapackages-20211009/debian/bfh-container.postrm   2023-08-14 
09:07:46.0 +0200
+++ bfh-metapackages-20211009/debian/bfh-container.postrm   2023-12-19 
14:08:37.0 +0100
@@ -6,12 +6,12 @@
remove)
for FILE in halt poweroff reboot shutdown coldreboot
do
-   dpkg-divert --package bfh-container --quiet --remove 
--rename --divert /lib/container/divert/${FILE}.orig /sbin/${FILE}
+   dpkg-divert --package bfh-container --quiet --remove 
--rename --divert "/lib/container/divert/${FILE}.orig.usr-is-merged" 
"/sbin/${FILE}"
done
 
-   for FILE in pm-hibernate pm-suspend pm-suspend-hybrid
+   for FILE in halt poweroff reboot shutdown coldreboot 
pm-hibernate pm-suspend pm-suspend-hybrid
do
-   dpkg-divert --package bfh-container --quiet --remove 
--rename --divert /lib/container/divert/${FILE}.orig /usr/sbin/${FILE}
+   dpkg-divert --package bfh-container --quiet --remove 
--rename --divert "/usr/lib/container/divert/${FILE}.orig" "/usr/sbin/${FILE}"
done
;;
 
diff -Nru bfh-metapackages-20211009/debian/bfh-container.preinst 
bfh-metapackages-20211009/debian/bfh-container.preinst
--- bfh-metapackages-20211009/debian/bfh-container.preinst  2023-08-14 
09:07:46.0 +0200
+++ bfh-metapackages-20211009/debian/bfh-container.preinst  2023-12-19 
14:12:04.0 +0100
@@ -8,12 +8,36 @@
 
for FILE in halt poweroff reboot shutdown coldreboot
do
-   dpkg-divert --package bfh-container --quiet --add 
--rename --divert /lib/container/divert/${FILE}.orig /sbin/${FILE}
+   TRUENAMEUSR=$(dpkg-divert --truename "/usr/sbin/$FILE")
+   TRUENAMEALIAS=$(dpkg-divert --truename "/sbin/$FILE")
+   RENAME_FLAG=--no-rename
+   if test "$TRUENAMEUSR" = "/usr/sbin/$FILE"; then
+   if test "$TRUENAMEALIAS" = "/sbin/$FILE"; then
+   RENAME_FLAG=--rename
+   fi
+   dpkg-divert --package bfh-container --quiet 
--add "$RENAME_FLAG" --divert "/usr/lib/container/divert/$FILE.orig" 
"/usr/sbin/$FILE"
+   fi
+   # DEP17 M18 duplicated diversion. Can be removed after 
trixie.
+   if test "$TRUENAMEALIAS" = "/sbin/$FILE"; then
+   dpkg-divert --package bfh-container --quiet 
--add "$RENAME_FLAG" --divert "/lib/container/divert/$FILE.orig.usr-is-merged" 
"/sbin/$FILE"
+   elif test "$TRUENAMEALIAS" != 
"/lib/container/divert/$FILE.orig.usr-is-merged"; then
+   dpkg-divert --package bfh-container --quiet 
--remove --no-rename "/sbin/$FILE"
+   dpkg-divert --package bfh-container --quiet 
--add --no-rename --divert "/lib/container/divert/$FILE.orig.usr-is-merged" 
"/sbin/$FILE"
+   if test -e "$TRUENAMEALIAS" || test -h 
"$TRUENAMEALIAS"; then
+   mv "$TRUENAMEALIAS" 
"/lib/container/divert/$FILE.orig.usr-is-merged"
+   fi
+   fi
done
 
for FILE in pm-hibernate 

Bug#1059028: elogind FTBFS with nocheck: missing mount dependency

2023-12-19 Thread Helmut Grohne
Source: elogind
Version: 252.9-1debian2
Severity: serious
Tags: ftbfs trixie sid

elogind fails to build from source with the nocheck build profile. Note
that since trixie such a failure is considered release critical by the
release team. The relevant part of the build log is:

| Found pkg-config: YES (/usr/bin/pkg-config) 1.8.1
| Run-time dependency libcap found: YES 2.66
| Did not find CMake 'cmake'
| Found CMake: NO
| Run-time dependency mount found: NO (tried pkgconfig)
| 
| ../meson.build:1335:11: ERROR: Dependency "mount" not found, tried pkgconfig
| 
| A full log can be found at /<>/build/meson-logs/meson-log.txt
|   cd build && tail -v -n \+0 meson-logs/meson-log.txt

I suspect that libmount-dev is pulled via some dependency that happens
to be tagged  and therefore a regular build succeeds. You
should add an explicit build dependency on libmount-dev anyhow.

Helmut



Bug#1059027: libfprint FTBFS with nocheck profile: missing dependencies

2023-12-19 Thread Helmut Grohne
Source: libfprint
Version: 1:1.94.6-2
Severity: serious
Tags: ftbfs

libfprint fails to build from source when built with the nocheck build
profile. Note that this is considered a release critical bug since
trixie by the release team. Here is the relevant part of the build log:


| Program unittest_inspector.py found: YES 
(/<>/tests/unittest_inspector.py)
| Program umockdev-test.py found: YES (/<>/tests/umockdev-test.py)
| 
| ../tests/meson.build:99:16: ERROR: Command 
`/<>/tests/unittest_inspector.py 
/<>/tests/virtual-image.py` failed with status 77.
| 
| A full log can be found at 
/<>/obj-x86_64-linux-gnu/meson-logs/meson-log.txt
|   cd obj-x86_64-linux-gnu && tail -v -n \+0 meson-logs/meson-log.txt
| ==> meson-logs/meson-log.txt <==

...

| Program unittest_inspector.py found: YES 
(/<>/tests/unittest_inspector.py)
| Program umockdev-test.py found: YES (/<>/tests/umockdev-test.py)
| Running command: /<>/tests/unittest_inspector.py 
/<>/tests/virtual-image.py
| --- stdout ---
| Missing dependencies: No module named 'gi'
| 
| --- stderr ---
| 
| 
| 
| ../tests/meson.build:99:16: ERROR: Command 
`/<>/tests/unittest_inspector.py 
/<>/tests/virtual-image.py` failed with status 77.
| dh_auto_configure: error: cd obj-x86_64-linux-gnu && 
DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 meson setup .. 
--wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
--localstatedir=/var --libdir=lib/x86_64-linux-gnu -Dpython.bytecompile=-1 
-Dudev_hwdb=enabled -Dudev_hwdb_dir=/lib/udev/hwdb.d 
-Dudev_rules_dir=/lib/udev/rules.d -Ddrivers=all -Dgtk-examples=false returned 
exit code 1
| make[1]: *** [debian/rules:19: override_dh_auto_configure] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:16: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

I suggest that python3-gi is wrongly annotated  or tests are
not properly disabled.

Helmut



Bug#1058991: firmware-misc-nonfree: Possible missing firmware for module nouveau, kernel crash in nouveau

2023-12-19 Thread Diederik de Haas
Control: severity -1 important
Control: tag -1 moreinfo

On Tuesday, 19 December 2023 13:57:51 CET Vincent Lefevre wrote:
> Another piece of information: this is a regression.
> 
> With the 6.1.0-16-amd64 kernel from stable, "journalctl -b -g ga107"
> gives
> 
> Dec 19 04:57:07 qaa kernel: nouveau :01:00.0: NVIDIA GA107 (b77000a1)
> Dec 19 04:57:07 qaa kernel: nouveau :01:00.0: firmware: failed to load
> nvidia/ga107/nvdec/scrubber.bin (-2) Dec 19 04:57:07 qaa kernel: nouveau
> :01:00.0: firmware: failed to load nvidia/ga107/nvdec/scrubber.bin (-2)
> 
> and I don't have any issue with the machine.
> 
> With the 6.5.0-5-amd64 kernel, "journalctl -b -1 -g ga107" gives

Upstream kernel commit 4b569ded09fdadb0c14f797c8dae4e8bc4bbad9f added lines to 
load the firmware files and was merged into kernel 6.2, so that it doesn't show 
up in a 6.1 kernel is expected.

Upstream firmware commit 2c2be4215fe29870dcd9a059ff8778e73269ddc1 added the 
files 
but it seems the Link lines weren't added to the Debian package in commit
9714742762ab2b278fd0961652a4dd54ff82ea8b

```
$ git show 2c2be4215fe29870dcd9a059ff8778e73269ddc1 | grep Link
@@ -5182,6 +5182,71 @@ Link: nvidia/tu117/nvdec/scrubber.bin -> ../../tu116/
nvdec/scrubber.bin
 Link: nvidia/tu117/sec2/desc.bin -> ../../tu116/sec2/desc.bin
 Link: nvidia/tu117/sec2/image.bin -> ../../tu116/sec2/image.bin
 Link: nvidia/tu117/sec2/sig.bin -> ../../tu116/sec2/sig.bin
+Link: nvidia/ga103/acr/ucode_ahesasc.bin -> ../../ga102/acr/ucode_ahesasc.bin
+Link: nvidia/ga103/acr/ucode_asb.bin -> ../../ga102/acr/ucode_asb.bin
+Link: nvidia/ga103/acr/ucode_unload.bin -> ../../ga102/acr/ucode_unload.bin
+Link: nvidia/ga103/nvdec/scrubber.bin -> ../../ga102/nvdec/scrubber.bin
+Link: nvidia/ga103/sec2/desc.bin -> ../../ga102/sec2/desc.bin
+Link: nvidia/ga103/sec2/hs_bl_sig.bin -> ../../ga102/sec2/hs_bl_sig.bin
+Link: nvidia/ga103/sec2/image.bin -> ../../ga102/sec2/image.bin
+Link: nvidia/ga103/sec2/sig.bin -> ../../ga102/sec2/sig.bin
+Link: nvidia/ga104/acr/ucode_ahesasc.bin -> ../../ga102/acr/ucode_ahesasc.bin
+Link: nvidia/ga104/acr/ucode_asb.bin -> ../../ga102/acr/ucode_asb.bin
+Link: nvidia/ga104/acr/ucode_unload.bin -> ../../ga102/acr/ucode_unload.bin
+Link: nvidia/ga104/nvdec/scrubber.bin -> ../../ga102/nvdec/scrubber.bin
+Link: nvidia/ga104/sec2/desc.bin -> ../../ga102/sec2/desc.bin
+Link: nvidia/ga104/sec2/hs_bl_sig.bin -> ../../ga102/sec2/hs_bl_sig.bin
+Link: nvidia/ga104/sec2/image.bin -> ../../ga102/sec2/image.bin
+Link: nvidia/ga104/sec2/sig.bin -> ../../ga102/sec2/sig.bin
+Link: nvidia/ga106/acr/ucode_ahesasc.bin -> ../../ga102/acr/ucode_ahesasc.bin
+Link: nvidia/ga106/acr/ucode_asb.bin -> ../../ga102/acr/ucode_asb.bin
+Link: nvidia/ga106/acr/ucode_unload.bin -> ../../ga102/acr/ucode_unload.bin
+Link: nvidia/ga106/nvdec/scrubber.bin -> ../../ga102/nvdec/scrubber.bin
+Link: nvidia/ga106/sec2/desc.bin -> ../../ga102/sec2/desc.bin
+Link: nvidia/ga106/sec2/hs_bl_sig.bin -> ../../ga102/sec2/hs_bl_sig.bin
+Link: nvidia/ga106/sec2/image.bin -> ../../ga102/sec2/image.bin
+Link: nvidia/ga106/sec2/sig.bin -> ../../ga102/sec2/sig.bin
+Link: nvidia/ga107/acr/ucode_ahesasc.bin -> ../../ga102/acr/ucode_ahesasc.bin
+Link: nvidia/ga107/acr/ucode_asb.bin -> ../../ga102/acr/ucode_asb.bin
+Link: nvidia/ga107/acr/ucode_unload.bin -> ../../ga102/acr/ucode_unload.bin
+Link: nvidia/ga107/nvdec/scrubber.bin -> ../../ga102/nvdec/scrubber.bin
+Link: nvidia/ga107/sec2/desc.bin -> ../../ga102/sec2/desc.bin
+Link: nvidia/ga107/sec2/hs_bl_sig.bin -> ../../ga102/sec2/hs_bl_sig.bin
+Link: nvidia/ga107/sec2/image.bin -> ../../ga102/sec2/image.bin
+Link: nvidia/ga107/sec2/sig.bin -> ../../ga102/sec2/sig.bin
```

If you manually create those links from the above "+Link:" lines, would that 
fix the issues?

On Tuesday, 19 December 2023 13:36:17 CET Vincent Lefevre wrote:
> for the above firmware, there's no "acr" directory in nvidia/ga107:

The directory is not physically present, but it ought to consists of symlinks 
to the ga102 directory, which does have an `acr` directory.

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


Bug#1040910: Nvidia firmware missing on Testing

2023-12-19 Thread Vincent Lefevre
On 2023-07-12 11:30:22 +0200, Mauro Sacchetto wrote:
> Package: firmware-misc-nonfree
> Version: 20230515-3
> 
> My machine (with Cinnamon) has Nvidia GTX 670.
> On Testing, after the last upgrades I receive:
> 
> root@debian:~# update-initramfs -u
> update-initramfs: Generating /boot/initrd.img-6.3.0-1-amd64
> W: Possible missing firmware /lib/firmware/nvidia/ga107/acr/ucode_ahesasc.bin 
> for module nouveau
[...]
> 
> Some drivers missing?

*firmware*, not drivers.

I reported

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

last night. My GPU (GA107GLM) is affected, and the kernel is unusable.

You can see whether the kernel on your machine attempts to load
such a firmware with

  journalctl -b -g 'firmware: failed to load'

(this is the command for the current boot).

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



Bug#1059026: transition: rocksdb

2023-12-19 Thread GCS
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: affects -1 + src:rocksdb

Hi RMs,

Small transition of RocksDB to the 8.9.1 release, available from
experimental. Affected packages are balboa, oxigraph and sortmerna.
While oxigraph is Sid only currently, all three build fine with this
version of RocksDB as well.

Thanks for considering,
Laszlo/GCS



Bug#1058993: ITP: golang-github-cloudsoda-go-smb2 -- client implementation of the SMB 2 & 3 protocols

2023-12-19 Thread Maytham Alsudany
Package is ready at
https://salsa.debian.org/go-team/packages/golang-github-cloudsoda-go-smb2

I haven't sent an RFS to debian-go yet, waiting for my previous RFS' to be
cleared up, don't want to overload sponsors.

Kind regards,
Maytham


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


Bug#1059025: lltsv: add build support for loongarch64

2023-12-19 Thread zhangdandan

Source: lltsv
Version: 0.7.0-2
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

The lltsv source package lacks LoongArch architecture support.
We need to add build support for loongarch64 in d/control.
Please consider the patch I have attached.

The lltsv source package was compiled successfully on my local loong64 
rootfs environment.

If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang

diff -Nru lltsv-0.7.0/debian/control lltsv-0.7.0/debian/control
--- lltsv-0.7.0/debian/control  2022-11-19 13:24:52.0 +
+++ lltsv-0.7.0/debian/control  2022-11-19 13:24:52.0 +
@@ -19,7 +19,7 @@
 XS-Go-Import-Path: github.com/sonots/lltsv
 
 Package: lltsv
-Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x 
powerpc ppc64 riscv64 sparc64
+Architecture: amd64 arm64 armel armhf i386 loong64 mips64el mipsel ppc64el 
s390x powerpc ppc64 riscv64 sparc64
 Depends: ${misc:Depends},
  ${shlibs:Depends}
 Built-Using: ${misc:Built-Using}


Bug#1058991: firmware-misc-nonfree: Possible missing firmware for module nouveau, kernel crash in nouveau

2023-12-19 Thread Vincent Lefevre
Another piece of information: this is a regression.

With the 6.1.0-16-amd64 kernel from stable, "journalctl -b -g ga107"
gives

Dec 19 04:57:07 qaa kernel: nouveau :01:00.0: NVIDIA GA107 (b77000a1)
Dec 19 04:57:07 qaa kernel: nouveau :01:00.0: firmware: failed to load 
nvidia/ga107/nvdec/scrubber.bin (-2)
Dec 19 04:57:07 qaa kernel: nouveau :01:00.0: firmware: failed to load 
nvidia/ga107/nvdec/scrubber.bin (-2)

and I don't have any issue with the machine.

With the 6.5.0-5-amd64 kernel, "journalctl -b -1 -g ga107" gives

Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: NVIDIA GA107 (b77000a1)
Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: failed to load 
nvidia/ga107/acr/ucode_ahesasc.bin (-2)
Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: failed to load 
nvidia/ga107/acr/ucode_ahesasc.bin (-2)
Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: direct-loading 
firmware nvidia/ga107/gr/NET_img.bin
Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: direct-loading 
firmware nvidia/ga107/gr/fecs_bl.bin
Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: direct-loading 
firmware nvidia/ga107/gr/fecs_sig.bin
Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: direct-loading 
firmware nvidia/ga107/gr/gpccs_bl.bin
Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: direct-loading 
firmware nvidia/ga107/gr/gpccs_sig.bin
Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: failed to load 
nvidia/ga107/sec2/sig.bin (-2)
Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: failed to load 
nvidia/ga107/sec2/sig.bin (-2)
Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: failed to load 
nvidia/ga107/nvdec/scrubber.bin (-2)
Dec 19 04:21:16 qaa kernel: nouveau :01:00.0: firmware: failed to load 
nvidia/ga107/nvdec/scrubber.bin (-2)

and I get the crashes, and as soon as I log out or after
"xset dpms force off" is run, the screen remains black.

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



Bug#1059024: libcrcutil: Please add loong64 binary output for Loongarch

2023-12-19 Thread yalingfang

Source: libcrcutil
Version: 1.0-5.2
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64


Dear Maintainer,

     Currently no loong64 binary output for libcrcutil in Loongarch env.
The buildd link is following:
https://buildd.debian.org/status/package.php?p=++libcrcutil%E2%80%8B=sid


I have verified by Add loong64 to debian/control file, All test cases 
are passed in my local env.

Attach the control patch.

Please add support for it. Thanks!
Any question, contact me!


add_loong64_binary_output_for_loongarch.patch
Description: Binary data


Bug#1059023: rocksdb: add build support for loongarch64

2023-12-19 Thread zhangdandan

Source: rocksdb
Version: 8.5.4-1
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

The LoongArch architecture has been supported in rocksdb upstream.
But, the rocksdb source package lacks LoongArch architecture support. We 
need to add build support for loongarch64 in d/control, for examples,

```
Package: librocksdb-dev
-Architecture: amd64 arm64 armel armhf ppc64el mips mipsel mips64el 
s390x i386 riscv64
+Architecture: amd64 arm64 armel armhf ppc64el loong64 mips mipsel 
mips64el s390x i386 riscv64


Package: librocksdb8.5
-Architecture: amd64 arm64 armel armhf ppc64el mips mipsel mips64el 
s390x i386 riscv64
+Architecture: amd64 arm64 armel armhf ppc64el loong64 mips mipsel 
mips64el s390x i386 riscv64


Package: rocksdb-tools
-Architecture: amd64 arm64 armel armhf ppc64el mips mipsel mips64el 
s390x i386 riscv64
+Architecture: amd64 arm64 armel armhf ppc64el loong64 mips mipsel 
mips64el s390x i386 riscv64

```

I would like to remind you that the compilation dependencies of loong64 
rocksdb are not yet satisfied.

If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang



Bug#1058991: firmware-misc-nonfree: Possible missing firmware for module nouveau, kernel crash in nouveau

2023-12-19 Thread Vincent Lefevre
On 2023-12-19 04:32:02 +0100, Vincent Lefevre wrote:
> firmware-misc-nonfree triggers the following warnings:
> 
> update-initramfs: Generating /boot/initrd.img-6.5.0-5-amd64
[...]
> W: Possible missing firmware /lib/firmware/nvidia/ga107/acr/ucode_ahesasc.bin 
> for module nouveau
[...]
> while https://forums.debian.net/viewtopic.php?t=155793 says that
> the solution is to install firmware-misc-nonfree!

I would add that even the section "Firmware missing from Debian" in
https://wiki.debian.org/Firmware does not apply because, for instance
for the above firmware, there's no "acr" directory in nvidia/ga107:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/nvidia/ga107
contains only a "gr" directory.

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



Bug#1059022: rdma-core: Please add support for loongarch64

2023-12-19 Thread zhangdandan

Source: rdma-core
Version: 48.0-1
Severity: wishlist
Tags: ftbfs
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

The LoongArch architecture has been supported in rdma-core upstream [1], 
please see the following link [2].
Please add support for loongarch64 (64-bit LoongArch) in rdma-core 
source package.


Would it be possible to include the support for LoongArch in the next 
upload?

Your opinions are welcome.

[1]:https://github.com/linux-rdma/rdma-core
[2]:https://github.com/linux-rdma/rdma-core/pull/1035

thanks,
Dandan Zhang



Bug#1059021: baconqrcode: add loongarch64 support

2023-12-19 Thread Zhang Na
Source: baconqrcode
Version: 2.0.8-2
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Add loongarch64 support, thanks!


-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 853fa5b2b72851a26f29498335c2e4b99523cee7 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Tue, 19 Dec 2023 12:32:08 +
Subject: [PATCH] add loongarch64 support

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 9205873..8cdd33b 100644
--- a/debian/control
+++ b/debian/control
@@ -18,7 +18,7 @@ Rules-Requires-Root: no
 Depends: php, ${phpcomposer:Debian-require}
 
 Package: php-bacon-qr-code
-Architecture: any-amd64 any-arm64 any-ppc64 any-ppc64el any-s390x any-mips64el 
any-riscv64 any-sparc64 any-sparc64 any-ia64
+Architecture: any-amd64 any-arm64 any-ppc64 any-ppc64el any-s390x any-mips64el 
any-riscv64 any-sparc64 any-sparc64 any-ia64 any-loong64
 Depends: php-imagick, ${misc:Depends}, ${phpcomposer:Debian-require}
 Recommends: ${phpcomposer:Debian-recommend}
 Suggests: ${phpcomposer:Debian-suggest}
-- 
2.43.0



Bug#1059020: ettercap: Disable luajit for loong64

2023-12-19 Thread yalingfang

Source: ettercap
Version: 0.8.3.1-12
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64


Dear Maintainer,

     Currently there is no luajit for loongarch platform.

Maybe in a long time there is no loongarch support for luajit , 
because the patch is not received by luajit repo maintainer.


So we disabled the luajit conf in ettercap  workaround. We verified  and 
compiled pass in loongarch Platform.



Attach the ettercap's patch for loong64.

Please add support for it. Thanks!
Any question, contact me!


no_luajit_support.patch
Description: Binary data


Bug#1056225: aioquic's autopkg tests fail with Python 3.12

2023-12-19 Thread Dale Richards
Empty Message



Bug#1059019: rm: librust-bindgen+clap-dev librust-bindgen+default-dev librust-bindgen+env-logger-dev librust-bindgen+log-dev librust-bindgen+logging-dev librust-bindgen+runtime-dev librust-bindgen+sta

2023-12-19 Thread Peter Green

Package: ftp.debian.org

Please remove the binary packages librust-bindgen+clap-dev
librust-bindgen+default-dev librust-bindgen+env-logger-dev
librust-bindgen+log-dev librust-bindgen+logging-dev librust-bindgen+runtime-dev
librust-bindgen+static-dev librust-bindgen+which-dev

These packages have been converted from physical packages to virtual packages.
The cruft report claims that various packages will have their dependencies
and/or build-dependencies broken, but this is because the dependency analysis
used in the cruft report does not take into account virtual packages.

dak rm -o -m "[auto-cruft] NBS (no longer built by rust-bindgen)" -s unstable 
-a amd64,arm64,armel,armhf,i386,mips64el,ppc64el,riscv64,s390x -p -R -b 
librust-bindgen+clap-dev librust-bindgen+default-dev librust-bindgen+env-logger-dev 
librust-bindgen+log-dev librust-bindgen+logging-dev librust-bindgen+runtime-dev 
librust-bindgen+static-dev librust-bindgen+which-dev



Bug#1059018: Add support for loong64

2023-12-19 Thread liuxiang

Package: varnish-modules
Version: 0.20.0-2
Severity: normal
X-Debbugs-Cc: liuxi...@loongson.cn

Dear Maintainer,

  Please add loong64 support, patch file is attached.

Thanks

diff -ruN varnish-modules-0.20.0-bk/debian/control varnish-modules-0.20.0/debian/control
--- varnish-modules-0.20.0-bk/debian/control	2022-08-13 08:05:00.0 +
+++ varnish-modules-0.20.0/debian/control	2023-12-19 11:38:47.914550110 +
@@ -15,7 +15,7 @@
 Homepage: https://github.com/varnish/varnish-modules
 
 Package: varnish-modules
-Architecture: amd64 arm64 i386 mips64el mipsel ppc64el s390x alpha hppa ia64 m68k powerpc ppc64 riscv64 sh4 x32
+Architecture: amd64 arm64 i386 mips64el mipsel ppc64el s390x alpha hppa ia64 m68k powerpc ppc64 riscv64 sh4 x32 loong64
 Depends: ${shlibs:Depends},
  ${misc:Depends},
  ${Varnish:ABI}


Bug#1058706: Aw: Re: Bug#1058706: mariadb-server-core: mariadbd fails to start on fresh install on armel

2023-12-19 Thread Tuukka Pasanen

Hello,

I've investigate this yesterday and I could reproduce this one:

Dec 17 11:17:55 gast1 mariadbd[1291]: 2023-12-17 11:17:55 0 [ERROR] Could not open 
mysql.plugin table: "Table 'mysql.plugin' doesn't exist". Some plugins may be 
not loaded
Dec 17 11:17:55 gast1 mariadbd[1291]: 2023-12-17 11:17:55 0 [ERROR] 
Unknown/unsupported storage engine: InnoDB
Dec 17 11:17:55 gast1 mariadbd[1291]: 2023-12-17 11:17:55 0 [ERROR] Aborting

Can you do (Please on testing machine not production will destroy your 
database!!!)
apt purge mariadb-server
# check is your database is not available /var/lib/mysql if it is remote it
mkdir -p /var/lib/mysql
chown mysql:mysql /var/lib/mysql
and then re-install mariad-server again. Does it work then? Just trying to see 
if my findings are correct. What comes to this InnoDB corruption I can't 
reproduce that.

Sincerely,
Tuukka

k-...@web.de kirjoitti 19.12.2023 klo 12.18:

Hi Tuukka,
I don't think the issue is related to the armel hardware.
I see the same error on my XEN-VM (1 VCPU) based on a Intel(R) Celeron(R) CPU 
G3900 @ 2.80GHz processor with 2 cores.
No lack of memory could be seen during installation of mariadb-server package. 
I tested it with 2 or 8 GB of assigned RAM.

Regards,
Konstantin
   


Gesendet: Montag, 18. Dezember 2023 um 08:23 Uhr
Von: "Tuukka Pasanen"
An: "Scott Barker",1058...@bugs.debian.org, "Otto 
Kekäläinen",k-...@web.de
Cc: "Faustin Lammler"
Betreff: Re: Bug#1058706: mariadb-server-core: mariadbd fails to start on fresh 
install on armel
Hello,

Have you monitored that is memory exhausted at the installation? This
could lead error like that.

I assume your XEN/KVM/Docker base machine is some older system with not
so fancy CPU or is there any particular reason to use armel build?

Sincerly,

Tuukka

Scott Barker kirjoitti 17.12.2023 klo 19.15:

Same result with the latest kernel:

Linux nas-1 6.1.0-16-marvell #1 Debian 6.1.67-1 (2023-12-12) armv5tel
GNU/Linux

On Sun, Dec 17, 2023 at 09:59:23AM -0700, Scott Barker wrote:

Prior to the installation, /var/lib/mysql did not exist. After
installation:

61559 4 drwxr-xr-x 2 mysql  mysql  4096 Dec 17 09:56
/var/lib/mysql
61975 4 -rw-rw 1 mysql  mysql    52 Dec 17 09:56
/var/lib/mysql/aria_log_control
61983 12304 -rw-rw 1 mysql  mysql  12582912 Dec 17 09:56
/var/lib/mysql/ibdata1
61963 0 -rw-r--r-- 1 root   root  0 Dec 17 09:56
/var/lib/mysql/debian-10.11.flag
61990 98404 -rw-rw 1 mysql  mysql 100663296 Dec 17 09:56
/var/lib/mysql/ib_logfile101
61982    16 -rw-rw 1 mysql  mysql 16384 Dec 17 09:56
/var/lib/mysql/aria_log.0001

uname -a reports:

Linux nas-1 5.10.0-26-marvell #1 Debian 5.10.197-1 (2023-09-29)
armv5tel GNU/Linux

On Sun, Dec 17, 2023 at 11:48:16PM +0800, Otto Kekäläinen wrote:

Hi Scott and Kr!

Did you note this line?

2023-12-14 14:51:33 0 [Note] InnoDB: Header page consists of zero
bytes in
datafile: ./ibdata1, Space ID:0, Flags: 0

Can you include the output of  `find /var/lib/mysql -ls` so we can
see what
files your system has?

What is the hardware you have? The report shows 'Linux
5.10.0-26-marvell '.
What does `uname -a` yield?

The test suite passes on armhf at
e.g.https://launchpad.net/~mysql-ubuntu/
+archive/ubuntu/mariadb-10.11/+builds?build_text=_state=all.
At https://
ci.debian.net/packages/m/mariadb/unstable/armel/ it fails due to
regression in
subselect which is unrelated to what you reported.


--
Scott Barker

--
To unsubscribe, send mail to1058706-unsubscr...@bugs.debian.org.


Bug#999954: [Pkg-sugar-devel] Bug#999954: squeak-vm: depends on obsolete pcre3 library

2023-12-19 Thread Jonas Smedegaard
Hi again, Yavor,

Quoting Yavor Doganov (2023-12-19 12:35:06)
> Jonas Smedegaard wrote:
> > Quoting Yavor Doganov (2023-12-19 11:21:34)
> > > Please find attached a patch;
> > 
> > Is it a patch that you composed yourself, or did you work based off
> > of some upstream changeset.
> 
> The former.  I checked the new upstream release (downloaded with
> uscan) and also checked upstream SVN trunk -- the problem was not
> fixed there so I started off the current code in unstable.
> 
> This patch doesn't apply cleanly to the latest upstream release (it
> has a bit different layout and there were changes to RePlugin) but I
> guess it would be more or less trivial for me to adapt it.

Ok.  Thanks for those details, and thanks again for the patch itself.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature


Bug#999954: [Pkg-sugar-devel] Bug#999954: squeak-vm: depends on obsolete pcre3 library

2023-12-19 Thread Jonas Smedegaard
Hi Tobias,

Quoting Tobias Pape (2023-12-19 12:02:56)
> > On 19. Dec 2023, at 11:53, Jonas Smedegaard  wrote:
> > Quoting Yavor Doganov (2023-12-19 11:21:34)
> >> Please find attached a patch; unfortunately I could not find a way
> >> to test it.
> > 
> > Thanks for the patch.
> > 
> > Is it a patch that you composed yourself, or did you work based off of
> > some upstream changeset.
> 
> There is no upstream changeset for that, sadly. We should pick that up
> probably.

Thanks for checking!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature


Bug#1057967: still no wifi.

2023-12-19 Thread Salvatore Bonaccorso
Hi,

On Tue, Dec 19, 2023 at 12:41:24PM +0100, Friedhelm Mehnert wrote:
> This is to report, that even with this kernel,
> 
> > 2023-12-19T11:19:09.704363+01:00 m2 kernel: [0.00] 
> > Linux version 6.1.0-16-amd64 (debian-kern
> > e...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, 
> > GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
> > PREEMPT_DYNAMIC Debian 6.1.67-1 (2023-12-12)
> 
> the bug is NOT fixed. Wifi does not come up, when booting this kernel.
> 
> These are the relevant lines from the kernel-log:
> 
> 
> > 2023-12-19T11:19:09.706109+01:00 m2 kernel: 
> > [5.573251] SSE version of gcm_enc/dec engaged.
> > 2023-12-19T11:19:09.706110+01:00 m2 kernel: 
> > [5.671819] iwlwifi: `N' invalid for parameter `enable_ini'
> >^^
> > 2023-12-19T11:19:09.706111+01:00 m2 kernel: 
> >[5.672964] usb 1-1.6: Found UVC 1.00 device Integrated Camera (17ef:480f)

This is a misconfiguration, see some context in #1057260.

Regards,
Salvatore



Bug#1057967: still no wifi.

2023-12-19 Thread Friedhelm Mehnert
This is to report, that even with this kernel,

> 2023-12-19T11:19:09.704363+01:00 m2 kernel: [0.00] 
> Linux version 6.1.0-16-amd64 (debian-kern
> e...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, 
> GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
> PREEMPT_DYNAMIC Debian 6.1.67-1 (2023-12-12)

the bug is NOT fixed. Wifi does not come up, when booting this kernel.

These are the relevant lines from the kernel-log:


> 2023-12-19T11:19:09.706109+01:00 m2 kernel: 
> [5.573251] SSE version of gcm_enc/dec engaged.
> 2023-12-19T11:19:09.706110+01:00 m2 kernel: 
> [5.671819] iwlwifi: `N' invalid for parameter `enable_ini'
>^^
> 2023-12-19T11:19:09.706111+01:00 m2 kernel: 
>[5.672964] usb 1-1.6: Found UVC 1.00 device Integrated Camera (17ef:480f)

Thank You.
Friedhelm



Bug#967454: gpsim: depends on deprecated GTK 2

2023-12-19 Thread Bastian Germann

Control: tags -1 patch

Hi Georges,

I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff includes also my previous NMU's changes that were overridden with 
your last upload.

Thanks,
Bastiandiff -Nru gpsim-0.32.1/debian/changelog gpsim-0.32.1/debian/changelog
--- gpsim-0.32.1/debian/changelog   2023-11-04 16:45:52.0 +0100
+++ gpsim-0.32.1/debian/changelog   2023-12-19 12:00:12.0 +0100
@@ -1,3 +1,11 @@
+gpsim (0.32.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Build without GUI. Closes: #967454
+  * Drop unnecessary Build-Depends: quilt, libgtkextra-dev. Closes: #1054292
+
+ -- Bastian Germann   Tue, 19 Dec 2023 12:00:12 +0100
+
 gpsim (0.32.1-1) unstable; urgency=medium
 
   * New upstream version 0.32.1
diff -Nru gpsim-0.32.1/debian/control gpsim-0.32.1/debian/control
--- gpsim-0.32.1/debian/control 2023-11-04 16:45:52.0 +0100
+++ gpsim-0.32.1/debian/control 2023-12-19 11:59:41.0 +0100
@@ -4,7 +4,7 @@
 Maintainer: Georges Khaznadar 
 Build-Depends: debhelper-compat (=13), libreadline-dev, libncurses5-dev,
  libpopt-dev, libglib2.0-dev, libtool, flex, automake, autotools-dev,
- libtool-bin, bison, chrpath, gputils, quilt, libgtkextra-dev, libgtk2.0-dev
+ libtool-bin, bison, chrpath, gputils
 Standards-Version: 4.6.2
 Vcs-Browser:https://salsa.debian.org/georgesk/gpsim
 Vcs-Git: https://salsa.debian.org/georgesk/gpsim.git
diff -Nru gpsim-0.32.1/debian/rules gpsim-0.32.1/debian/rules
--- gpsim-0.32.1/debian/rules   2023-11-04 16:42:01.0 +0100
+++ gpsim-0.32.1/debian/rules   2023-12-19 12:00:12.0 +0100
@@ -13,8 +13,7 @@
 DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 
 
-# GUI_SWITCH = --disable-gui
-GUI_SWITCH = --enable-gui
+GUI_SWITCH = --disable-gui
 
 override_dh_auto_configure:
./configure --build=$(DEB_BUILD_GNU_TYPE) \


Bug#1059017: lomiri FTFS: fatal error: lomiridbusobject.h: No such file or directory

2023-12-19 Thread Helmut Grohne
Source: lomiri
Version: 0.1.3-1
Severity: serious
Tags: ftbfs

lomiri fails to build from source in unstable on amd64. A non-parallel
build ends as follows:

| make[4]: Entering directory '/<>/obj-x86_64-linux-gnu'
| [ 29%] Building CXX object 
tests/uqmlscene/CMakeFiles/uqmlscene.dir/uqmlscene_autogen/mocs_compilation.cpp.o
| cd /<>/obj-x86_64-linux-gnu/tests/uqmlscene && /usr/bin/c++ 
-DLOMIRI_ENABLE_TOUCH_EMULATION -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB 
-DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_NO_KEYWORDS -DQT_QMLMODELS_LIB -DQT_QML_LIB 
-DQT_QUICK_LIB -DQT_STRICT_ITERATORS 
-DQT_TESTCASE_BUILDDIR=\"/<>/obj-x86_64-linux-gnu\" 
-DQT_TESTLIB_LIB -DQT_USE_QSTRINGBUILDER 
-I/<>/obj-x86_64-linux-gnu/tests/uqmlscene/uqmlscene_autogen/include
 -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtQml -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtQuick -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtQmlModels -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtTest -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtDBus -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wdate-time -D_FORTIFY_SOURCE=2 -Wsuggest-override -fvisibility=hidden 
-fno-permissive -pedantic -Wall -Wextra -std=gnu++14 -fPIC -MD -MT 
tests/uqmlscene/CMakeFiles/uqmlscene.dir/uqmlscene_autogen/mocs_compilation.cpp.o
 -MF CMakeFiles/uqmlscene.dir/uqmlscene_autogen/mocs_compilation.cpp.o.d -o 
CMakeFiles/uqmlscene.dir/uqmlscene_autogen/mocs_compilation.cpp.o -c 
/<>/obj-x86_64-linux-gnu/tests/uqmlscene/uqmlscene_autogen/mocs_compilation.cpp
| In file included from 
/<>/obj-x86_64-linux-gnu/tests/uqmlscene/uqmlscene_autogen/VNU7RW3YIC/moc_DebuggingController.cpp:10,
|  from 
/<>/obj-x86_64-linux-gnu/tests/uqmlscene/uqmlscene_autogen/mocs_compilation.cpp:2:
| 
/<>/obj-x86_64-linux-gnu/tests/uqmlscene/uqmlscene_autogen/VNU7RW3YIC/../../../../../src/DebuggingController.h:28:10:
 fatal error: lomiridbusobject.h: No such file or directory
|28 | #include "lomiridbusobject.h"
|   |  ^~~~
| compilation terminated.
| make[4]: *** [tests/uqmlscene/CMakeFiles/uqmlscene.dir/build.make:85: 
tests/uqmlscene/CMakeFiles/uqmlscene.dir/uqmlscene_autogen/mocs_compilation.cpp.o]
 Error 1
| make[4]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[3]: *** [CMakeFiles/Makefile2:8341: 
tests/uqmlscene/CMakeFiles/uqmlscene.dir/all] Error 2
| make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[2]: *** [Makefile:149: all] Error 2
| make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j1 "INSTALL=install 
--strip-program=true" -O all doc VERBOSE=1 returned exit code 2
| make[1]: *** [debian/rules:33: override_dh_auto_build] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:21: binary] Error 2
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

Helmut



Bug#999954: [Pkg-sugar-devel] Bug#999954: squeak-vm: depends on obsolete pcre3 library

2023-12-19 Thread Yavor Doganov
Jonas Smedegaard wrote:
> Quoting Yavor Doganov (2023-12-19 11:21:34)
> > Please find attached a patch;
> 
> Is it a patch that you composed yourself, or did you work based off of
> some upstream changeset.

The former.  I checked the new upstream release (downloaded with
uscan) and also checked upstream SVN trunk -- the problem was not
fixed there so I started off the current code in unstable.

This patch doesn't apply cleanly to the latest upstream release (it
has a bit different layout and there were changes to RePlugin) but I
guess it would be more or less trivial for me to adapt it.



Bug#999954: [Pkg-sugar-devel] Bug#999954: squeak-vm: depends on obsolete pcre3 library

2023-12-19 Thread Tobias Pape
Hi


> On 19. Dec 2023, at 11:53, Jonas Smedegaard  wrote:
> 
> Hi Yavor,
> 
> Quoting Yavor Doganov (2023-12-19 11:21:34)
>> Please find attached a patch; unfortunately I could not find a way to
>> test it.
> 
> Thanks for the patch.
> 
> Is it a patch that you composed yourself, or did you work based off of
> some upstream changeset.

There is no upstream changeset for that, sadly. We should pick that up
probably.

Best regards
-Tobias Pape

> 
> I ask because it is helpful to know how close we are to upstream code,
> especially for changes that are tricky to test thoroughly.
> 
> 
> Kind regards,
> 
> - Jonas
> 
> -- 
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136  Website: http://dr.jones.dk/
> * Sponsorship: https://ko-fi.com/drjones
> 
> [x] quote me freely  [ ] ask before reusing  [ ] keep private



Bug#1059016: kicad: add loongarch64 support

2023-12-19 Thread zhangdandan

Source: kicad
Version: 7.0.9+dfsg-1
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

The kicad source package lacks LoongArch architecture support.
Please consider the patch I have attached.

The kicad source package was compiled successfully on my local loong64 
rootfs environment.

If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang

diff -Nru kicad-7.0.9+dfsg/debian/control kicad-7.0.9+dfsg/debian/control
--- kicad-7.0.9+dfsg/debian/control 2023-10-13 18:06:39.0 +
+++ kicad-7.0.9+dfsg/debian/control 2023-11-16 19:22:14.0 +
@@ -77,7 +77,7 @@
 Homepage: https://www.kicad.org
 
 Package: kicad
-Architecture: any-amd64 any-i386 arm64 armhf mips64el powerpc ppc64 ppc64el 
riscv64
+Architecture: any-amd64 any-i386 arm64 armhf loong64 mips64el powerpc ppc64 
ppc64el riscv64
 Depends:
  libngspice0,
  python3-wxgtk4.0 (>= 4.2.0+dfsg-1~),


Bug#1059002: [Pkg-erlang-devel] Bug#1059002: erlang: CVE-2023-48795

2023-12-19 Thread Salvatore Bonaccorso
Hi Sergei,

On Tue, Dec 19, 2023 at 12:12:27PM +0300, Sergei Golovan wrote:
> Hi Salvatore,
> 
> On Tue, Dec 19, 2023 at 11:24 AM Salvatore Bonaccorso  
> wrote:
> >
> > Source: erlang
> > Version: 1:25.2.3+dfsg-1
> > Severity: important
> > Tags: security upstream
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> >
> > Hi,
> >
> > The following vulnerability was published for erlang.
> >
> > CVE-2023-48795[0]:
> 
> Reading the latest announcement on the Erlang mailing list I've found
> that there is an update of ssh in Erlang 25 which addresses
> CVE-2023-48795:
> https://erlang.org/pipermail/erlang-announce/2023-December/000260.html
> 
> I will try to backport these changes to Erlang currently in stable if
> it's necessary. As for the unstable, the newest version will fix this
> as well.

Thanks for working on it. I would say, let's start top-down so go
first trough unstable upload, then we can assess the state for it for
the security supported suites (and if it needs a DSA or can go trough
a point release).

There might be e.g. mitigating factor if ChaCha20-Poly1305 and
Encrypt-then-MAC support is missing.

Regards,
Salvatore



Bug#999954: [Pkg-sugar-devel] Bug#999954: squeak-vm: depends on obsolete pcre3 library

2023-12-19 Thread Jonas Smedegaard
Hi Yavor,

Quoting Yavor Doganov (2023-12-19 11:21:34)
> Please find attached a patch; unfortunately I could not find a way to
> test it.

Thanks for the patch.

Is it a patch that you composed yourself, or did you work based off of
some upstream changeset.

I ask because it is helpful to know how close we are to upstream code,
especially for changes that are tricky to test thoroughly.


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature


Bug#1059015: crocus: Immediate glitches and GPU hangs in GNOME Shell since 23.3

2023-12-19 Thread Paul Menzel

Package: libgl1-mesa-dri
Version: 23.3.1-3
Tags: upstream
Forwarded: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10308


Dear Debian folks,


Updating from 23.2.1-1 to 23.3.1-3 there is a regression on several 
systems causing glitches [1] or even crashes [2]. (I think these all use 
Crocus driver(?), that means are all systems with Intel graphics device.)


It be great, if you cherry picked the fix [3], as currently at least 
GNOME on the affected systems is unusable.



Thank you in advance and kind regards,

Paul


[1]: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10308
[2]: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10320
[3]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26731



Bug#1012454: wireplumber: multiple permission denied errors in logs after installing

2023-12-19 Thread Dylan Aïssi
Hi,

Do you still have this problem?

Best regards,
Dylan



Bug#999954: squeak-vm: depends on obsolete pcre3 library

2023-12-19 Thread Yavor Doganov
Control: tags -1 + patch

Please find attached a patch; unfortunately I could not find a way to
test it.
Description: Port to PCRE2.
Bug-Debian: https://bugs.debian.org/54
Author: Yavor Doganov 
Forwarded: no
Last-Update: 2023-12-19
---

--- squeak-vm.orig/platforms/unix/CMakeLists.txt
+++ squeak-vm/platforms/unix/CMakeLists.txt
@@ -125,7 +125,7 @@
   USE_LIBRARY ("-framework ${fwk}")
 ENDMACRO (USE_FRAMEWORK)
 
-USE_LIBRARY_SHARED ("-lpcre")
+USE_LIBRARY_SHARED ("-lpcre2-8")
 USE_LIBRARY_SHARED ("-ljpeg")
 
 MACRO (CONFIG_DEFINE var)
--- squeak-vm.orig/platforms/Cross/plugins/RePlugin/rePlugin.h
+++ squeak-vm/platforms/Cross/plugins/RePlugin/rePlugin.h
@@ -15,11 +15,9 @@
 
 The instance variables must appear in the preceding order.  MatchSpaceObj must 
be allocated by the calling routine and contain at least 6*(numGroups+1) bytes.
 */
-#include "pcre.h"
-#include "internal.h"
+#define PCRE2_CODE_UNIT_WIDTH 8
+#include 
 
 /* Adjust malloc and free routines as used by PCRE */
-static void rePluginFree(void * aPointer);
-static void * rePluginMalloc(size_t anInteger);
-void *(*pcre_malloc)(size_t) = rePluginMalloc;
-void  (*pcre_free)(void *) = rePluginFree;
+static void rePluginFree(void * aPointer, void * aData);
+static void * rePluginMalloc(size_t anInteger, void * aData);
--- squeak-vm.orig/platforms/unix/src/vm/intplugins/RePlugin/RePlugin.c
+++ squeak-vm/platforms/unix/src/vm/intplugins/RePlugin/RePlugin.c
@@ -35,7 +35,6 @@
 /*** Constants ***/
 
 /*** Function Prototypes ***/
-static sqInt allocateByteArrayAndSetRcvrExtraPtrFrom(sqInt anExtraPtr);
 static sqInt allocateByteArrayAndSetRcvrPCREPtrFromPCRE(sqInt aPCREPtr);
 static sqInt allocateStringAndSetRcvrErrorStrFromCStr(const char *aCStrBuffer);
 #pragma export on
@@ -52,17 +51,19 @@
 EXPORT(sqInt) primPCREExecfromto(void);
 EXPORT(sqInt) primPCRENumSubPatterns(void);
 #pragma export off
-static void rePluginFree(void *  aPointer);
+static void rePluginFree(void *  aPointer, void * aData);
 #pragma export on
-EXPORT(void *) rePluginMalloc(size_t  anInteger);
+EXPORT(void *) rePluginMalloc(size_t  anInteger, void * aData);
 EXPORT(sqInt) setInterpreter(struct VirtualMachine*anInterpreter);
 #pragma export off
 /*** Variables ***/
 static sqInt compileFlags;
-static sqInt errorOffset;
+static PCRE2_SIZE errorOffset;
 static sqInt errorStr;
-static const char *  errorStrBuffer;
-static sqInt extraPtr;
+static int errorCode;
+static pcre2_general_context * genContext = NULL;
+static pcre2_compile_context * compContext = NULL;
+static pcre2_match_context * matchContext = NULL;
 
 #ifdef SQUEAK_BUILTIN_PLUGIN
 extern
@@ -86,28 +87,6 @@
 static sqInt rcvr;
 
 
-static sqInt allocateByteArrayAndSetRcvrExtraPtrFrom(sqInt anExtraPtr) {
-   sqInt extraObject;
-   void *extraByteArrayPtr;
-
-   if (anExtraPtr) {
-
-   /* Allocate a Smalltalk ByteArray -- lastAlloc contains the 
length */
-
-   extraObject = 
interpreterProxy->instantiateClassindexableSize(interpreterProxy->classByteArray(),
 sizeof(real_pcre_extra));
-   /* begin loadRcvrFromStackAt: */
-   rcvr = interpreterProxy->stackObjectValue(0);
-   extraByteArrayPtr = interpreterProxy->arrayValueOf(extraObject);
-   memcpy(extraByteArrayPtr, (void *) anExtraPtr, 
sizeof(real_pcre_extra));
-   } else {
-   extraObject = interpreterProxy->nilObject();
-   }
-   /* begin rcvrExtraPtrFrom: */
-   interpreterProxy->storePointerofObjectwithValue(3, rcvr, extraObject);
-   ;
-   return extraObject;
-}
-
 static sqInt allocateByteArrayAndSetRcvrPCREPtrFromPCRE(sqInt aPCREPtr) {
sqInt patObject;
void *patByteArrayPtr;
@@ -184,13 +163,18 @@
 
 /* , where rcvr is an object with instance variables:
 
-   'patternStr compileFlags pcrePtr extraPtr errorStr errorOffset 
matchFlags'  
+   'patternStr compileFlags pcrePtr errorStr errorOffset matchFlags'
 
 Compile the regular expression in patternStr, and if the compilation is 
successful, attempt to optimize the compiled expression.  Store the results in 
 and , or fill errorStr with a meaningful errorString and 
errorOffset with an indicator where the error was found, applying compileFlags 
throughout.  Answer nil with a clean compile (regardless of whether an 
optimization is possible, and answer with the string otherwise. */
 
 EXPORT(sqInt) primPCRECompile(void) {
sqInt anInteger;
 
+   if (!genContext)
+   genContext = pcre2_general_context_create(rePluginMalloc,
+ rePluginFree, NULL);
+   if (!compContext)
+   compContext = pcre2_compile_context_create(genContext);
/* begin loadRcvrFromStackAt: */
rcvr = interpreterProxy->stackObjectValue(0);
patternStrPtr = ((char *) (interpreterProxy->fetchArrayofObject(0, 
rcvr)));
@@ -198,24 +182,25 @@
if (interpreterProxy->failed()) {
  

Bug#1058706: Aw: Re: Bug#1058706: mariadb-server-core: mariadbd fails to start on fresh install on armel

2023-12-19 Thread k-i-r
Hi Tuukka,
I don't think the issue is related to the armel hardware.
I see the same error on my XEN-VM (1 VCPU) based on a Intel(R) Celeron(R) CPU 
G3900 @ 2.80GHz processor with 2 cores.
No lack of memory could be seen during installation of mariadb-server package. 
I tested it with 2 or 8 GB of assigned RAM.

Regards,
Konstantin 
  

Gesendet: Montag, 18. Dezember 2023 um 08:23 Uhr
Von: "Tuukka Pasanen" 
An: "Scott Barker" , 1058...@bugs.debian.org, "Otto 
Kekäläinen" , k-...@web.de
Cc: "Faustin Lammler" 
Betreff: Re: Bug#1058706: mariadb-server-core: mariadbd fails to start on fresh 
install on armel
Hello,

Have you monitored that is memory exhausted at the installation? This
could lead error like that.

I assume your XEN/KVM/Docker base machine is some older system with not
so fancy CPU or is there any particular reason to use armel build?

Sincerly,

Tuukka

Scott Barker kirjoitti 17.12.2023 klo 19.15:
> Same result with the latest kernel:
>
> Linux nas-1 6.1.0-16-marvell #1 Debian 6.1.67-1 (2023-12-12) armv5tel
> GNU/Linux
>
> On Sun, Dec 17, 2023 at 09:59:23AM -0700, Scott Barker wrote:
>> Prior to the installation, /var/lib/mysql did not exist. After
>> installation:
>>
>> 61559 4 drwxr-xr-x 2 mysql  mysql  4096 Dec 17 09:56
>> /var/lib/mysql
>> 61975 4 -rw-rw 1 mysql  mysql    52 Dec 17 09:56
>> /var/lib/mysql/aria_log_control
>> 61983 12304 -rw-rw 1 mysql  mysql  12582912 Dec 17 09:56
>> /var/lib/mysql/ibdata1
>> 61963 0 -rw-r--r-- 1 root   root  0 Dec 17 09:56
>> /var/lib/mysql/debian-10.11.flag
>> 61990 98404 -rw-rw 1 mysql  mysql 100663296 Dec 17 09:56
>> /var/lib/mysql/ib_logfile101
>> 61982    16 -rw-rw 1 mysql  mysql 16384 Dec 17 09:56
>> /var/lib/mysql/aria_log.0001
>>
>> uname -a reports:
>>
>> Linux nas-1 5.10.0-26-marvell #1 Debian 5.10.197-1 (2023-09-29)
>> armv5tel GNU/Linux
>>
>> On Sun, Dec 17, 2023 at 11:48:16PM +0800, Otto Kekäläinen wrote:
>>> Hi Scott and Kr!
>>>
>>> Did you note this line?
>>>
>>> 2023-12-14 14:51:33 0 [Note] InnoDB: Header page consists of zero
>>> bytes in
>>> datafile: ./ibdata1, Space ID:0, Flags: 0
>>>
>>> Can you include the output of  `find /var/lib/mysql -ls` so we can
>>> see what
>>> files your system has?
>>>
>>> What is the hardware you have? The report shows 'Linux
>>> 5.10.0-26-marvell '.
>>> What does `uname -a` yield?
>>>
>>> The test suite passes on armhf at
>>> e.g. https://launchpad.net/~mysql-ubuntu/
>>> +archive/ubuntu/mariadb-10.11/+builds?build_text=_state=all.
>>> At https://
>>> ci.debian.net/packages/m/mariadb/unstable/armel/ it fails due to
>>> regression in
>>> subselect which is unrelated to what you reported.
>>>
>>
>> --
>> Scott Barker
>>
>> --
>> To unsubscribe, send mail to 1058706-unsubscr...@bugs.debian.org.
>



Bug#1021530: wireplumber: No sound after upgrade to 0.4.12-1

2023-12-19 Thread Dylan Aïssi
Hi,

Are there still problems here?

I'm tempted to close this bug since wireplumber doesn't conflict with
pulseaudio. If there is a conflict it is between pulseaudio and
pipewire-pulse and/or pipewire-alsa. But installing pipewire-audio
should get ride of pulseaudio to avoid any conflicts (**after** a reboot).

Best regards,
Dylan



Bug#1059014: stunnel4: please make the build reproducible

2023-12-19 Thread Chris Lamb
Source: stunnel4
Version: 3:5.70-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
stunnel4 could not be built reproducibly.

This is because the stunnel manpage embedded the current build date. A
patch is attached that seeds this value from SOURCE_DATE_EPOCH if it is
available.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/07-reproducible-build.patch1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/07-reproducible-build.patch2023-12-19 
10:10:27.992405010 +
@@ -0,0 +1,19 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2023-12-19
+
+--- stunnel4-5.70.orig/doc/Makefile.am
 stunnel4-5.70/doc/Makefile.am
+@@ -14,9 +14,11 @@ DISTCLEANFILES = $(doc_DATA)
+ 
+ SUFFIXES = .pod.in .8.in .html.in
+ 
++BUILD_DATE = $(shell date --utc --date=@$(or $(SOURCE_DATE_EPOCH),$(shell 
date +%s)) +%Y.%m.%d)
++
+ .pod.in.8.in:
+   pod2man -u -n stunnel -s 8 -r $(VERSION) \
+-  -c "stunnel4 TLS Proxy" -d `date +%Y.%m.%d` $< $@
++  -c "stunnel4 TLS Proxy" -d $(BUILD_DATE) $< $@
+ 
+ .pod.in.html.in:
+   pod2html --index --backlink --header \
--- a/debian/patches/series 2023-12-19 09:51:42.220785283 +
--- b/debian/patches/series 2023-12-19 10:00:22.317767514 +
@@ -3,3 +3,4 @@
 03-runas-user.patch
 05-sample-sysconfdir.patch
 06-no-openssl-version-check-autopkgtest.patch
+07-reproducible-build.patch


Bug#1059013: wxmplot: please make the build reproducible

2023-12-19 Thread Chris Lamb
Source: wxmplot
Version: 0.9.58-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
wxmplot could not be built reproducibly.

This is because it embedded the current build date in the manual
pages. Patch attached that seeds this value from SOURCE_DATE_EPOCH if
available.

 [0] https://reproducible-builds.org/


Regards,

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


--- a/debian/patches/0003-reproducible-build.patch  1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/0003-reproducible-build.patch  2023-12-19 
09:55:20.149244757 +
@@ -0,0 +1,29 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2023-12-19
+
+--- wxmplot-0.9.58.orig/doc/conf.py
 wxmplot-0.9.58/doc/conf.py
+@@ -7,15 +7,20 @@
+ # serve to show the default.
+ 
+ import os
++import time
+ import sys
+-from datetime import date
+ 
+ from packaging.version import parse as version_parse
+ 
+ import wxmplot
+ 
++date_str = time.strftime(
++"%Y-%m-%d",
++time.gmtime(int(os.environ.get('SOURCE_DATE_EPOCH', time.time(
++)
++
+ project = 'wxmplot'
+-copyright = f'{date.today()}, Matthew Newville, The University of Chicago'
++copyright = f'{date_str}, Matthew Newville, The University of Chicago'
+ 
+ release = version_parse(wxmplot.__version__).public
+ 
--- a/debian/patches/series 2023-12-19 09:51:50.852805288 +
--- b/debian/patches/series 2023-12-19 09:55:19.281243090 +
@@ -1,2 +1,3 @@
 sphinx_support_mathjax.patch
 0002-removed-sphinxcontrib.video-extension.patch
+0003-reproducible-build.patch


Bug#1059012: recording lost/overwritten when reconnecting to stream

2023-12-19 Thread Björn JACKE
Package: darkice
Version: 1.3-0.3+b1
Severity: important

Darkice maintainers don't work down bug reports and submitted patches
obviously. So it would be cool if Debian would add some patches to the darkice
package. This one here is an annoying bug since years alredy:

Recording lost/overwritten when reconnecting to stream when sending SIGUSR1 to
darkice. See https://github.com/rafael2k/darkice/issues/141 for a bug report
with attached patch also.



Bug#1058926: evolution: best charset for korean

2023-12-19 Thread 황병희
On Mon, 2023-12-18 at 23:09 +, Simon McVittie wrote:
> > Nowdays most Koreans prefer UTF-8 over EUC-KR in Email:
> ...
> > -   { "EUC-KR", E_CHARSET_KOREAN, NULL },
> > +   { "UTF-8", E_CHARSET_KOREAN, NULL },
> 
> > This is a more complicated issue than i might think.
> > I will try again later.
> 
> If possible, I think this sort of change is better
> discussed with the upstream maintainers of Evolution via
> https://gitlab.gnome.org/GNOME/evolution/-/issues, rather than with
> its Debian maintainers.
> 

Simon, thank you for your kind guidance.


Sincerely, Byung-Hee from South Korea
 
-- 
^고맙습니다 _布德天下_ 감사합니다_^))//



Bug#1006365: wireplumber: Please split audio files out of the main package

2023-12-19 Thread Dylan Aïssi
Control: tag -1 wontfix

Le jeu. 24 févr. 2022 à 11:33, Laurent Bigonville  a écrit :
>
> Would it be possible to split the configuration and plugins files that
> enable the "audio" part of pipewire to an other package? That way
> pipewire-pulse could depend on that package instead?

I tag this bug as wontfix for now. Once wireplumber 0.5 is released,
we can re-evaluate it.

Best,
Dylan



Bug#934298: RFS: tsctp/0.7.11-1

2023-12-19 Thread Thomas Dreibholz

Package: sponsorship-requests
Severity: normal

Dear mentors,

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


 * Package name: tsctp
   Version: 0.7.11-1
   Upstream Author: Michael Tüxen 
 * URL: https://www.nntb.no/~dreibh/tsctp/
 * License: BSD-3-clause, GPL-3+
 * Section: net

TSCTP is an SCTP test tool. Its purpose is to perform basic SCTP 
functionality tests to check implementations interoperability and to 
verify that the SCTP stack is working.


"tsctp " builds these binary packages:

 * tsctp - SCTP Test Tool

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

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

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

dget -xhttps://mentors.debian.net/debian/pool/main/t/tsctp/tsctp_0.7.11-1.dsc

More information about "tsctp " can 
be obtained from https://www.nntb.no/~dreibh/tsctp/.


Most recent changelog entry:

tsctp (0.7.11-1ubuntu1) jammy; urgency=medium

 * New upstream release.
 * Closes: #998879 (ITP).



OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1058778: storm-lang: uses sizeof('\0') (4) instead of 1 for string termination allocations

2023-12-19 Thread Filip Strömbäck

The patch has been submitted upstream, and will likely be incorporated after 
their review processes.

The discussion is here: https://github.com/Ravenbrook/mps/issues/276

Thank you again for reporting the issue!

On 2023-12-16 19:55, Filip Strömbäck wrote:

Dear наб,

Thank you for your bug report.

I have notified the upstream developers of MPS about this, to see if the patch 
can be applied upstream as well. Regardless, I will include the fix when I 
upload the next version of the package (likely in January).

Best,
Filip

On 2023-12-16 09:50, наб wrote:

Source: storm-lang
Version: 0.6.19-1
Severity: minor
Tags: patch

Dear Maintainer,

As found by DCS query [^._]sizeof[ (]'.{1,2}' filetype:c

The website is an information black hole, didn't find a mail address
there, so submitting here.

Patch based on the git, so paths based on the mps submodule already.

Best,
наб

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

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

 From f8c2ecf90eeae779c7a03c9313717559eb3b4159 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Sat, 16 Dec 2023 01:45:44 +0100
Subject: [PATCH] sizeof('c')=4, not 1: fix overallocations
X-Mutt-PGP: OS

As found by DCS: [^._]sizeof[ (]'.{1,2}' filetype:c

Ref: 
https://paste.sr.ht/~nabijaczleweli/6ee9ccf301a2651afb693bff46e3671d3f7cdd89
Ref: https://101010.pl/@nabijaczleweli/111587138076843793
---
  code/event.h    | 2 +-
  code/eventcom.h | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/code/event.h b/code/event.h
index 954b315b..358064d9 100644
--- a/code/event.h
+++ b/code/event.h
@@ -84,7 +84,7 @@ extern Word EventKindControl;
  size_t _string_len = (length); \
  size_t size; \
  AVER(_string_len <= EventStringLengthMAX); \
-    size = offsetof(Event##name##Struct, f1) + _string_len + sizeof('\0'); \
+    size = offsetof(Event##name##Struct, f1) + _string_len + 1 /* NUL */; \
  EVENT_BEGIN(name, size) \
    _event->f0 = (p0); \
    (void)mps_lib_memcpy(_event->f1, (string), _string_len); \
diff --git a/code/eventcom.h b/code/eventcom.h
index 75886be3..243570da 100644
--- a/code/eventcom.h
+++ b/code/eventcom.h
@@ -91,7 +91,7 @@ typedef void *EventFP;  /* pointer to C 
object */
  typedef Addr EventFA;   /* address on the heap */
  typedef Word EventFW;   /* word */
  typedef unsigned EventFU;   /* unsigned integer */
-typedef char EventFS[EventStringLengthMAX + sizeof('\0')]; /* string */
+typedef char EventFS[EventStringLengthMAX + 1 /* NUL */]; /* string */
  typedef double EventFD; /* double */
  typedef unsigned char EventFB;  /* Boolean */






OpenPGP_0x16C56181D19233AF.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1059011: metview: add build support for loongarch64

2023-12-19 Thread zhangdandan

Source: metview
Version: 5.20.0-2
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

The metview source package lacks LoongArch architecture support.
We need to add build support for loongarch64 in d/control, for examples,
```
Package: metview
-Architecture: amd64 arm64 ppc64 mips64el ppc64el s390x riscv64 sparc64  
kfreebsd-amd64 ia64
+Architecture: amd64 arm64 ppc64 loong64 mips64el ppc64el s390x riscv64 
sparc64  kfreebsd-amd64 ia64


Package: libmetview0d
-Architecture: amd64 arm64 ppc64 mips64el ppc64el s390x riscv64 sparc64  
kfreebsd-amd64 ia64
+Architecture: amd64 arm64 ppc64 loong64 mips64el ppc64el s390x riscv64 
sparc64  kfreebsd-amd64 ia64


Package: libmetview-dev
-Architecture: amd64 arm64 ppc64 mips64el ppc64el s390x riscv64 sparc64  
kfreebsd-amd64 ia64
+Architecture: amd64 arm64 ppc64 mips64el ppc64el s390x riscv64 sparc64  
kfreebsd-amd64 ia64

```

I would like to remind you that the compilation dependencies of loong64 
mtview are not yet satisfied.

If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang



Bug#1059010: spice: please add support for loong64

2023-12-19 Thread wuruilong
Source: spice
Version: 0.15.1-1
Severity: normal
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

Please add support for loong64 arch in the debian/control file.

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect



Bug#998073: wireplumber: fails to automatically switch to headphones when connected

2023-12-19 Thread Dylan Aïssi
Control: fixed -1 0.4.13-1

Hi Vincent,

Le lun. 18 déc. 2023 à 23:57, Vincent Lefevre  a écrit :
>
> FYI, I have a new laptop, where I use wireplumber 0.4.13-1
> (Debian stable) with the same Bluetooth devices (speakers and
> headphones), and there are no such problems with it.

That is a good news!

> So either the bug has been fixed in wireplumber 0.4.13-1 or there
> has been something else on the old laptop that broke wireplumber.
>

I don't see any change in the changelog of 0.4.13 that could be related to
this bug. As we have no other clues, I tag this bug as fixed with 0.4.13-1
without closing it.

Best regards,
Dylan



<    1   2   3   >