date:20230412


On 12/04/2023 22.46, Klaus Ethgen wrote:

Package: nvidia-tesla-470-kernel-source
Version: 470.182.03-1
Severity: important

Version 470.161.03-2 was built without problems but 470.182.03-1 does
not build with the following error:
/usr/src/modass/usr_src/modules/nvidia-kernel/nvidia/nv-acpi.c: In function 
'nv_acpi_ddc_method':
/usr/src/modass/usr_src/modules/nvidia-kernel/nvidia/nv-acpi.c:751:43: 
error: 'struct acpi_device' has no member named 'children'
  751 | list_for_each_safe(node, next, >children)
 |   ^~


# grep -r list_for_each_safe modules/nvidia-tesla-470-kernel/

I don't know what you are compiling, but that is not 470.182.03-1

So comments below are moot.


So, instead of "Improved compatibility with recent Linux kernels.", it
breaks compatibility with recent Linux kernels.

-- Package-specific info:
uname -a:
Linux ikki 6.1.12 #2.ikki SMP Sat Feb 18 17:01:30 CET 2023 x86_64 GNU/Linux


That's a custom kernel. Vanilla? Any patches? Can you share the .config?

It works with the Debian kernels. At least it did at the time I uploaded 
it ;-)


https://ci.debian.net/data/autopkgtest/testing/amd64/n/nvidia-graphics-drivers-tesla-470/32823600/log.gz

Can you provide the full dkms make.log from the compilation failure?
(Or the full output from building with m-a as you seem to use the 
-source package)


Andreas

Bug#1033995: qtbase-opensource-src: Fix accessibility of qt5 applications run as root

2023-04-12 Thread Samuel Thibault

And again it's posing problem. As advised by svuorela on irc, here is a
version that defers the trigger. This is probably even safer since
that's what is committed upstream for the AT_SPI_BUS_ADDRESS environment
variable case.

Samuel
--- a/src/platformsupport/linuxaccessibility/bridge.cpp
+++ b/src/platformsupport/linuxaccessibility/bridge.cpp
@@ -65,6 +65,16 @@ QSpiAccessibleBridge::QSpiAccessibleBrid
 {
 dbusConnection = new DBusConnection();
 connect(dbusConnection, SIGNAL(enabledChanged(bool)), this, 
SLOT(enabledChanged(bool)));
+// Now that we have connected the signal, make sure we didn't miss a 
change,
+// e.g. when running as root or when AT_SPI_BUS_ADDRESS is set by hand.
+// But do that only on next loop, once dbus is really settled.
+QMetaObject::invokeMethod(
+this,
+[this] {
+if (dbusConnection->isEnabled())
+enabledChanged(true);
+},
+Qt::QueuedConnection);
 }
 
 void QSpiAccessibleBridge::enabledChanged(bool enabled)

Bug#1034319: debootstrap of foreign arch fails w/o recommended binfmt-support

2023-04-12 Thread Joey Hess

Package: qemu-user-static
Version: 1:7.2+dfsg-5
Severity: normal

I got a new arm64 host at Hetzner, and needed an amd64 chroot in it.
Of course that's easy, since debootstrap --arch just works for foreign
arches with qemu-user-static installed.

root@sparrow:/tmp>apt-get install debootstrap qemu-user-static
root@sparrow:/tmp>debootstrap --arch amd64 sid sid
...
W: Failure trying to run: chroot "/tmp/sid" /bin/true
W: See /tmp/sid/debootstrap/debootstrap.log for details
root@sparrow:/tmp>tail -1 /tmp/sid/debootstrap/debootstrap.log
chroot: failed to run command '/bin/true': Exec format error

Oops, so it doesn't just work. Some digging in the postinst revealed
I needed binfmt-support installed, and it was not installed. I think
because qemu-user-static Recommends: systemd | binfmt-support
and of course I have systemd installed.

If systemd by itself is supposed to somehow handle what binfmt-support
does, it did not work in my case. I had to install binfmt-support
and rerun /var/lib/dpkg/info/qemu-user-static.postinst to fix the
problem.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1034318: ITP: ruby-google-apis-storage_v1 -- simple REST client for Cloud Storage JSON API V1

2023-04-12 Thread Ravi Dwivedi


package: wnpp
Severity: wishlist
Owner: 'Ravi Dwivedi' 

*Package Name : ruby-google-apis-storage_v1
 Version : 0.22.0
 Upstream Author : Mike Moore, Chris Smith
*URL :  https://github.com/google/google-api-ruby-client
*License : Apache-2.0
*Description :   simple REST client for Cloud Storage JSON API V1

I am packaging ruby-google-apis-storage_v1 as it is needed to package 
ruby-google-cloud-storage which is required for gitlab.


---
Ravi Dwivedi


OpenPGP_0xE0E5BAFD3BBF70B3.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034317: unblock: linphone-desktop/4.4.10-3

2023-04-12 Thread Bernhard Schmidt

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: linphone-desk...@packages.debian.org
Control: affects -1 + src:linphone-desktop

Please unblock package linphone-desktop

[ Reason ]
It fixes the RC bug #1033868 where you had to agree to the upstream's ToS and
privacy policy even if not using their SIP service. This has been fixed by
Dennis by backporting a patch that has been in experimental for quite some
time (but linphone 5.0 did not make the freeze)

[ Impact ]
RC bug is not fixed

[ Tests ]
Testing done by the maintainer

[ Risks ]
Code change is trivial

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock linphone-desktop/4.4.10-3
diff -Nru linphone-desktop-4.4.10/debian/changelog 
linphone-desktop-4.4.10/debian/changelog
--- linphone-desktop-4.4.10/debian/changelog2022-11-27 18:02:24.0 
+0100
+++ linphone-desktop-4.4.10/debian/changelog2023-04-04 18:09:27.0 
+0200
@@ -1,3 +1,10 @@
+linphone-desktop (4.4.10-3) unstable; urgency=medium
+
+  * Add patch to relax needlessly strict Terms of Service dialogue
+(Closes: #1033868).
+
+ -- Dennis Filder   Tue, 04 Apr 2023 18:09:27 +0200
+
 linphone-desktop (4.4.10-2) unstable; urgency=medium
 
   * Release to unstable.
diff -Nru 
linphone-desktop-4.4.10/debian/patches/adjust-terms-of-service-barrier.patch 
linphone-desktop-4.4.10/debian/patches/adjust-terms-of-service-barrier.patch
--- 
linphone-desktop-4.4.10/debian/patches/adjust-terms-of-service-barrier.patch
1970-01-01 01:00:00.0 +0100
+++ 
linphone-desktop-4.4.10/debian/patches/adjust-terms-of-service-barrier.patch
2023-04-04 18:09:27.0 +0200
@@ -0,0 +1,25 @@
+Description: Enable creation of third-party accounts unconditionally
+ Users should be able to do it without the need for accepting BC's
+ Terms of Use and Privacy Policy.
+Author: Dennis Filder 
+Last-Update: 2022-12-13
+--- a/linphone-app/ui/views/App/Main/Assistant/AssistantHome.qml
 b/linphone-app/ui/views/App/Main/Assistant/AssistantHome.qml
+@@ -101,7 +101,7 @@
+   
+   cellHeight: height / 2
+   cellWidth: width / 2
+-  enabled: cguCheckBox.checked
++//enabled: cguCheckBox.checked
+   
+   delegate: Item {
+   height: buttons.cellHeight
+@@ -113,7 +113,7 @@
+   margins: 
AssistantHomeStyle.buttons.spacing
+   }
+   
+-  enabled: cguCheckBox.checked && 
SettingsModel[$viewType.charAt(0).toLowerCase() + $viewType.slice(1) + 
"Enabled"]
++  enabled: $viewType=='UseOtherSipAccount' || 
(cguCheckBox.checked && SettingsModel[$viewType.charAt(0).toLowerCase() + 
$viewType.slice(1) + "Enabled"])
+   text: $text.replace('%1', 
Qt.application.name.toUpperCase())
+   
+   onClicked:{ assistant.pushView($view, $props) }
diff -Nru linphone-desktop-4.4.10/debian/patches/series 
linphone-desktop-4.4.10/debian/patches/series
--- linphone-desktop-4.4.10/debian/patches/series   2022-11-27 
18:02:24.0 +0100
+++ linphone-desktop-4.4.10/debian/patches/series   2023-04-04 
18:09:27.0 +0200
@@ -5,3 +5,4 @@
 louden-find-package.patch
 guard-codec-download.patch
 #a11y.patch
+adjust-terms-of-service-barrier.patch

Bug#1034316: iwlwifi: firmware initialization errors

2023-04-12 Thread Stanislav Maslovski

Package: src:linux
Version: 6.1.20-1
Severity: normal
X-Debbugs-Cc: stanislav.maslov...@gmail.com

Dear Maintainer,

Sometimes after a rebot the following firmware initialization errors appear on
the console and in the kern.log (see below). When this happens, I reboot again
until the firmware gets loaded and initialized normally. In my experience,
this only started to happen recently, it did not hapen with older 
kernels/firmwares.

2023-04-12T21:36:57.140335+01:00 zephyrus kernel: [4.563820] iwlwifi 
:02:00.0 wlp2s0: renamed from wlan0
2023-04-12T21:37:32.235002+01:00 zephyrus kernel: [3.229415] iwlwifi 
:02:00.0: enabling device ( -> 0002)
2023-04-12T21:37:32.235013+01:00 zephyrus kernel: [3.238270] iwlwifi 
:02:00.0: firmware: direct-loading firmware iwlwifi-cc-a0-72.ucode
2023-04-12T21:37:32.235015+01:00 zephyrus kernel: [3.238283] iwlwifi 
:02:00.0: api flags index 2 larger than supported by driver
2023-04-12T21:37:32.235016+01:00 zephyrus kernel: [3.238289] iwlwifi 
:02:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37
2023-04-12T21:37:32.235017+01:00 zephyrus kernel: [3.238567] iwlwifi 
:02:00.0: loaded firmware version 72.daa05125.0 cc-a0-72.ucode op_mode 
iwlmvm
2023-04-12T21:37:32.235018+01:00 zephyrus kernel: [3.319956] iwlwifi 
:02:00.0: Detected Intel(R) Wi-Fi 6 AX200 160MHz, REV=0x340
2023-04-12T21:37:32.235040+01:00 zephyrus kernel: [3.447969] iwlwifi 
:02:00.0: Detected RF HR B3, rfid=0x10a100
2023-04-12T21:37:32.235052+01:00 zephyrus kernel: [3.513094] iwlwifi 
:02:00.0: base HW address: ---
2023-04-12T21:37:32.235053+01:00 zephyrus kernel: [3.714034] iwlwifi 
:02:00.0: firmware didn't ACK the reset - continue anyway
2023-04-12T21:37:32.235054+01:00 zephyrus kernel: [3.714158] iwlwifi 
:02:00.0: Start IWL Error Log Dump:
2023-04-12T21:37:32.235055+01:00 zephyrus kernel: [3.714170] iwlwifi 
:02:00.0: Transport status: 0x004A, valid: 6
2023-04-12T21:37:32.235057+01:00 zephyrus kernel: [3.714180] iwlwifi 
:02:00.0: Loaded firmware version: 72.daa05125.0 cc-a0-72.ucode
2023-04-12T21:37:32.235058+01:00 zephyrus kernel: [3.714192] iwlwifi 
:02:00.0: 0x0084 | NMI_INTERRUPT_UNKNOWN   
2023-04-12T21:37:32.235060+01:00 zephyrus kernel: [3.714203] iwlwifi 
:02:00.0: 0x00A0A2F0 | trm_hw_status0
2023-04-12T21:37:32.235061+01:00 zephyrus kernel: [3.714213] iwlwifi 
:02:00.0: 0x | trm_hw_status1
2023-04-12T21:37:32.235062+01:00 zephyrus kernel: [3.714223] iwlwifi 
:02:00.0: 0x004FBE16 | branchlink2
2023-04-12T21:37:32.235064+01:00 zephyrus kernel: [3.714235] iwlwifi 
:02:00.0: 0x004F23FE | interruptlink1
2023-04-12T21:37:32.235065+01:00 zephyrus kernel: [3.714245] iwlwifi 
:02:00.0: 0x004F23FE | interruptlink2
2023-04-12T21:37:32.235066+01:00 zephyrus kernel: [3.714256] iwlwifi 
:02:00.0: 0x00014DA6 | data1
2023-04-12T21:37:32.235067+01:00 zephyrus kernel: [3.714265] iwlwifi 
:02:00.0: 0x0300 | data2
2023-04-12T21:37:32.235069+01:00 zephyrus kernel: [3.714273] iwlwifi 
:02:00.0: 0x | data3
2023-04-12T21:37:32.235070+01:00 zephyrus kernel: [3.714280] iwlwifi 
:02:00.0: 0x | beacon time
2023-04-12T21:37:32.235071+01:00 zephyrus kernel: [3.714288] iwlwifi 
:02:00.0: 0x000267F2 | tsf low
2023-04-12T21:37:32.235073+01:00 zephyrus kernel: [3.714295] iwlwifi 
:02:00.0: 0x | tsf hi
2023-04-12T21:37:32.235075+01:00 zephyrus kernel: [3.714302] iwlwifi 
:02:00.0: 0x | time gp1
2023-04-12T21:37:32.235076+01:00 zephyrus kernel: [3.714309] iwlwifi 
:02:00.0: 0x0002C071 | time gp2
2023-04-12T21:37:32.235077+01:00 zephyrus kernel: [3.714316] iwlwifi 
:02:00.0: 0x0001 | uCode revision type
2023-04-12T21:37:32.235079+01:00 zephyrus kernel: [3.714325] iwlwifi 
:02:00.0: 0x0048 | uCode version major
2023-04-12T21:37:32.235080+01:00 zephyrus kernel: [3.714333] iwlwifi 
:02:00.0: 0xDAA05125 | uCode version minor
2023-04-12T21:37:32.235082+01:00 zephyrus kernel: [3.714341] iwlwifi 
:02:00.0: 0x0340 | hw version
2023-04-12T21:37:32.235083+01:00 zephyrus kernel: [3.714349] iwlwifi 
:02:00.0: 0x00C89000 | board version
2023-04-12T21:37:32.235084+01:00 zephyrus kernel: [3.714356] iwlwifi 
:02:00.0: 0x8029FD22 | hcmd
2023-04-12T21:37:32.235086+01:00 zephyrus kernel: [3.714363] iwlwifi 
:02:00.0: 0x20028000 | isr0
2023-04-12T21:37:32.235087+01:00 zephyrus kernel: [3.714370] iwlwifi 
:02:00.0: 0x | isr1
2023-04-12T21:37:32.235089+01:00 zephyrus kernel: [3.714377] iwlwifi 
:02:00.0: 0x08F2 | isr2
2023-04-12T21:37:32.235090+01:00 zephyrus kernel: [3.714383] iwlwifi 
:02:00.0: 0x00CC | isr3
2023-04-12T21:37:32.235091+01:00 zephyrus kernel: [3.714390] iwlwifi 
:02:00.0: 0x | isr4
2023-04-12T21:37:32.235093+01:00

Bug#1034191: regression -6 broke what -5 fixed

2023-04-12 Thread Ivan Sergio Borgonovo

Same problem with 5.15.8+dfsg-6, downgrading to 5.15.8+dfsg-5 fixed the 
problem.


thanks

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

Bug#1034315: ffmpeg: 5.1, 6.0 libraries not co-installable

2023-04-12 Thread Peter Samuelson

Package: libavcodec60
Version: 7:6.0-1
Severity: minor

libavcodec{59,60} cannot be co-installed because both depend on exact
versions of libswresample4.  (Also, libavfilter{8,9} have the same
issue.)

This will require an all-or-nothing library transition, and it means I
can't install ffmpeg 6.0 from experimental without rebuilding many
other things.

It was not an issue with the previous ABI update, ffmpeg 7:4.x -> 7:5.x,
because libswresample SONAME was updated as well.

Bug#1034314: gnome-settings-daemon: gsd-smartcard fails to recognise readers added post-launch

2023-04-12 Thread David Härdeman

Package: gnome-settings-daemon
Version: 43.0-4
Severity: normal
X-Debbugs-Cc: da...@hardeman.nu

gsd-smartcard currently checks for the insertion/removal of smartcards
in reader devices which where present at the time gsd-smartcard was
started, but does not account for new smartcard readers appearing
after gsd-smartcard was started.

This patch adds support for checking for the addition of new slots
(i.e. smartcard readers), which is necessary to support devices
like the Yubikey (a "reader" and a smartcard) which may be inserted
after gsd-smartcard was started.

See also: 
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/merge_requests/328

dynamic-slots.patch
Description: Binary data

Bug#1034195: Question

2023-04-12 Thread Gert van de Kraats


Hi Phil,

Thanks for soon reply.

What do you mean by upstream. I only know a ticket at filezilla, but 
this is closed.


I think this is  a regression bug at gcc 12, but I could not find a 
bugreport upstream or at Debian for gcc.


Greetings,

Gert

Bug#1033745: sequeler: Unlisted dependency on libgda-5.0-mysql

2023-04-12 Thread Yangfl

Adrien Dorsaz  于2023年4月13日周四 00:57写道：
>
> Indeed, they aren't hard dependencies to launch the sequeler application
> and use it for sqlite databases.
>
> Is it possible to add them as suggested dependencies ?
>
> This will help the user to find the link between these two libdga
> drivers and the application without needing to find the information here
> or on Github.

Yes, they could be `Recommends` dependencies, so I have not closed this bug,

Bug#1034244: unblock (pre-approval): lua-readline/3.2-2

2023-04-12 Thread Sergei Golovan

Control: tags -1 - moreinfo

On Wed, Apr 12, 2023 at 12:04 AM Sebastian Ramacher
 wrote:
> On 2023-04-11 12:15:40 +0300, Sergei Golovan wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: lua-readl...@packages.debian.org
> > Control: affects -1 + src:lua-readline
> >
> > I'd like to upload lua-readline with a bugfix for #1034078 (see [1]).
>
> Please go ahead and remove the moreinfo tag once the new version is
> available in unstable.

Done!

Cheers!
-- 
Sergei Golovan

Bug#1034303: nvidia-cuda-toolkit breaks nvidia-cuda-samples autopkgtest on amd64: bad exit status: 2


Hi Andreas,

Thanks.

On 12-04-2023 21:32, Andreas Beckmann wrote:

That needs dkms/3.0.10-8, already unblocked.


So, shouldn't it be reassigned to dkms, closed and annotated as 
Affecting nvidia-cuda-toolkit and nvidia-cuda-samples?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients

2023-04-12 Thread Leo Antunes

Sorry for the late reply. My laptop decided it was a good time to break, so 
I'll have even less time to work on this in the next few days/weeks :/

--- Original Message ---
On Sunday, March 26th, 2023 at 22:07, Reinhard Tartler  
wrote:

> Sounds good.
> 
> I'm happy to take on the easier dependencies, such as pkg/browser or 
> jellydator/ttlcache.

That would be a huge help already!

> But the dependency on boulder is giving me a massive headache. It is really 
> unfortunate that they chose to use such a heavy dependency for a rather 
> simple task (goodkey). What are your thoughts on resolving this?

I didn't dive deep into the code, but I suspect we can patch away the boulder 
dep. I'll gladly give it a try as soon as I have a workable laptop again (but 
feel free to jump in if you find the time!)

Regards,
Leo Antunes

Bug#1034311: reprotest: make it easier to compare against an existing build (eg from ftp.d.o)

2023-04-12 Thread Holger Levsen

Package: reprotest
Version: 0.7.23
Severity: wishlist

Dear Maintainer,

 i guess reprotest maybe should grow an option to do
--control-build /path/to/packages/ 
--vary=build_path=/use/this/build/path ... 
   to make it easier to use reprotest to compare against an existing 
build
   YES
 e.g. there is no way to disable buidl path variations when comparing
against an arbitrary build
   i'm reporting this as a bug to the bts, quoting your words here. 
(ok?)
 reprotest can control it's own builds ... but if i want to use 
reprotest
   against the archive packages or an sbuild 
   or pbuilder build package ... it will always have a different build 
path
  h01ger: sure!
 :) thanks


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

This too shall pass.


signature.asc
Description: PGP signature

Bug#1034303: nvidia-cuda-toolkit breaks nvidia-cuda-samples autopkgtest on amd64: bad exit status: 2


On 12/04/2023 20.17, Paul Gevers wrote:
With a recent upload of nvidia-cuda-toolkit the autopkgtest of 
nvidia-cuda-samples fails on amd64 in testing when that autopkgtest is 



    pass    fail
nvidia-cuda-toolkit    from testing    11.8.0-3
nvidia-cuda-samples    from testing    11.8~dfsg-2
all others from testing    from testing


That needs dkms/3.0.10-8, already unblocked.

Some background: src:nvidia-cuda-toolkit is too large to have 
autopkgtests on its own. So I've moved them to src:nvidia-cuda-samples. 
I recently fixed nvidia-fs-dkms (src:nvidia-cuda-toolkit) to work with 
the bookworm kernel (that's the important change in 
src:nvidia-cuda-toolkit missing in bookworm) (before it skipped that 
kernel), only to expose a bug in the dkms-autopkgtest script (src:dkms) 
since nvidia-fs-dkms is the first package in the archive making use of 
the BUILD_DEPENDS directive in dkms.conf.


Andreas

Bug#1034310: digikam crashes after upgrade from bullseye to bookworm

2023-04-12 Thread Rainer Dorsch

Package: digikam
Version: 4:7.9.0-1+b2
Severity: grave

Dear Maintainer,


after the upgrade from bullseye to bookworm, digikam does not start anymore, 
but crashes on startup.

I put the severity to grave, since I cannot judge how many users would be 
affected after an upgrade. Feel free to downgrade the bug report if there is 
any evidence, that only few users are affected.

I logged the output when starting digikam. First it stops itself, then it 
aborts:

rd@h370:~$ digikam > digikam.log 2>&1

[1]+  Stopped digikam > digikam.log 2>&1
rd@h370:~$ fg
digikam > digikam.log 2>&1
Aborted (core dumped)
rd@h370:~$

The (uncompressed) digikam.log is huge, therefore I made it available here:

https://bokomoko.de/~rd/Debian/digikam.log.xz

It might be that it is a side effect of the upgrade, but at least for apt the 
system looks ok

root@h370:~# apt full-upgrade
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Paketaktualisierung (Upgrade) wird berechnet… Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
root@h370:~#

and after very initial testing I have not seen other issues in the system.

If you need anything more, please let me know.

Thanks
Rainer

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing-debug'), (105, 
'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages digikam depends on:
ii  digikam-data  4:7.9.0-1
ii  digikam-private-libs  4:7.9.0-1+b2
ii  libc6 2.36-8
ii  libgcc-s1 12.2.0-14
ii  libkf5configcore5 5.103.0-1
ii  libkf5coreaddons5 5.103.0-1
ii  libkf5i18n5   5.103.0-1
ii  libmagick++-6.q16-8   8:6.9.11.60+dfsg-1.6
ii  libqt5core5a  5.15.8+dfsg-3
ii  libqt5gui55.15.8+dfsg-3
ii  libqt5sql55.15.8+dfsg-3
ii  libqt5sql5-mysql  5.15.8+dfsg-3
ii  libqt5sql5-sqlite 5.15.8+dfsg-3
ii  libqt5widgets55.15.8+dfsg-3
ii  libstdc++612.2.0-14
ii  perl  5.36.0-7

Versions of packages digikam recommends:
ii  chromium [www-browser] 112.0.5615.49-2
ii  ffmpegthumbs   4:22.12.3-1
ii  firefox-esr [www-browser]  102.9.0esr-2
ii  konqueror [www-browser]4:22.12.3-1
ii  lynx [www-browser] 2.9.0dev.12-1

Versions of packages digikam suggests:
ii  breeze-icon-theme  4:5.103.0-1
pn  digikam-doc
ii  systemsettings 4:5.27.2-1

-- no debconf information

Bug#1034213: arno-iptables-firewall: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

2023-04-12 Thread Sven Geuer

Hello Laurant,
Hello Andreas,

On Wed, 2023-04-12 at 13:43 +0200, Andreas Henriksson wrote:
> On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> > Package: arno-iptables-firewall
> > Version: 2.1.1-7   
> > Severity: serious
> > Tags: sid bookworm
> > User: debhel...@packages.debian.org
> > Usertags: systemd-files-in-usr-bookworm
> > 
> > Dear Maintainer,
> > 
> > It seems that your package arno-iptables-firewall is shipping files
> > (.service, .socket or
> > .timer) in /usr/lib/systemd/system.
> [...]
> 
> It seems the package has manually written maintainer scripts (instead
> of
> letting debhelper generating the proper code):
> 
> ```
> arno-iptables-firewall-2.1.1> grep -R deb-systemd-helper debian/
> debian/postrm:  # Remove deb-systemd-helper's state file
> debian/postrm:  deb-systemd-helper purge
> arno-iptables-firewall.service
> debian/postinst:deb-systemd-helper enable
> arno-iptables-firewall.service
> ```
> 
> So while I think manually written maintscript code should be frowned
> upon (since it's a very common source of bugs), I guess this means
> this bug is not RC severity?!
> 

Laurent, as Andreas already pointed out arno-iptables-firewall (AIF)
does not make use of dh_installsystemd but instead uses deb-systemd-
helper with its maintainer scripts. A quick look into the source code
of deb-systemd-helper [1] showed that this tools can deal with a
service file stored in /usr/lib/systemd/system. This matches my
observation that since arno-iptables-firewall 2.1.1-5 local debci runs
using qemu as well as those at the Ubuntu site [2] were processed
successfully. Debian's CI [3] unfortunately does not support the
isolation-machine restriction, so there are no successful tests logged
there.

Therefore this bug against arno-iptables-firewall seems like a false
negative to me, and I would like to ask you to check my arguments and
close the bug eventually. Let me know if you still believe the service
file should be moved back to /lib from /usr/lib.

Andreas, I am not sure how it might be possible to have everything
created automatically by debhelper, especially the part creating an
initial configuration from user input might prevent this. If you have
any suggestions how to simplify the maintainer scripts I am happy to
adopt these.

Best,
Sven

[1] 
https://sources.debian.org/src/init-system-helpers/1.65.2/script/deb-systemd-helper/#L153
[2] https://autopkgtest.ubuntu.com/packages/arno-iptables-firewall/jammy/amd64
[3] https://ci.debian.net/packages/a/arno-iptables-firewall/

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585

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

Bug#1034309: RM: gradm2 -- RoM; obsolete

2023-04-12 Thread GCS

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:gradm2

Hi FTP Masters,

Please remove src:gradm2 from unstable - and from Bookworm as well if
a separate 'dak rm' is needed. It is an outdated, obsolete package
version that should not be part of our next stable release nor be part
of the project anymore.

Thanks,
Laszlo/GCS

Bug#1033570: unblock: kdenlive/22.12.3-2


Control: tags -1 moreinfo

Hi Patrick

On 27-03-2023 17:06, Patrick Matthäi wrote:

as mentioned in my unblock #1033554 for mlt I were a bit too stupid to read the
freeze policy correctly. I would like to see kdenlive 22.12.3-2 in bookworm,
it just fixes some upstream bugs and two Debian bugs (missing dependencies).


Can you please elaborate? It appears that this is a bug fix only 
release, can you confirm? What's the upstream policy for such releases? 
I didn't spot any upstream changelog, can you describe what the changes 
are supposed to achieve?



The debdiff is - except of the translation files - small.


Might have been nice to filter them out :).


Fixing annoying upstream bugs and missing dependencies in the packaging.


Any pointers to which bugs those are?


Software with known fixed bugs :)


Ack.


[ Risks ]
If mlt is not allowed to enter bookworm the "risk" would be that I would like
to request a upload of this kdenlive version directly to testing?


You may have guessed from the silence (see also our FAQ [1]) that we're 
not enthusiastic about mlt. I'm currently leaning towards the tpu route 
for kdenlive.


Paul

[1] https://release.debian.org/testing/FAQ.html


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034308: RM: lcab -- RoQA; orphaned, abandoned upstream, has alternative

2023-04-12 Thread Stephen Kitt

Package: ftp.debian.org
Severity: normal

Dear FTP team,

Please remove lcab; it was last released upstream in 2007, has been
orphaned since 2019, has had no significant upload since 2013, and
everything it does can be done with gcab.

Regards,

Stephen

Bug#1034307: RFP: tiktoken -- fast BPE tokeniser for use with OpenAI's models



Package: wnpp
Severity: wishlist

  Package name: tiktoken
  Version : 0.3.3
  Upstream Author : Shantanu Jain 
  URL : https://github.com/openai/tiktoken
  License : MIT
  Programming Lang: Python, Rust
  Description : fast BPE tokeniser for use with OpenAI's models

I have created draft packaging rules in
https://salsa.debian.org/deeplearning-team/tiktoken.git >.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1034306: O: easy-rsa -- simple shell based CA utility

2023-04-12 Thread Bastian Germann


Package: wnpp

The maintainer seems to be missing in action, so I orphan easy-rsa.
Please only adopt the package if you have the time and skills to maintain it.

Bug#1034305: deja-dup: Enable support for restic backend

2023-04-12 Thread Jacob Greenleaf

Package: deja-dup
Version: 44.0-2
Severity: wishlist

Dear Maintainer,

The attached patch enables support for restic that is present in
upstream since version 43. 

*** debian/patches/Enable-support-for-restic-0.14.patch
From: Jacob Greenleaf 
Date: Wed, 12 Apr 2023 06:02:07 -0700
Subject: Enable support for restic 0.14+

Beginning with deja-dup 43, experimental support for restic as an
optional alternative to borg has been merged into upstream and can be
enabled with the enable_restic config flag. Beginning with deja-dup 44
if restic is used it must be 0.14+ (propagating the breaking change
made in restic 0.14 for repository version 2 for copmression).

This patch enables building with restic enabled to allow using
restic. Note that users also need to opt-in to use restic through a
new "Labs" tab, this flag merely enables the option for the user to do
so. As such, adds restic and rclone to Recommends. If the user hasn't
installed restic or rclone, they will be prompted to install them
using the existing packagekit integration.
---
 debian/control    | 2 +-
 debian/control.in | 2 +-
 debian/rules  | 1 +
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 14cde49..8b1ae24 100644
--- a/debian/control
+++ b/debian/control
@@ -34,7 +34,7 @@ Homepage: https://launchpad.net/deja-dup
 Package: deja-dup
 Architecture: any
 Depends: duplicity (>= 0.7.14), ${misc:Depends}, ${shlibs:Depends}
-Recommends: gvfs-backends, packagekit, policykit-1
+Recommends: gvfs-backends, packagekit, policykit-1, restic (>= 0.14),
rclone
 Suggests: python3-pydrive2
 Description: Backup utility
  Déjà Dup is a simple backup tool. It hides the complexity of backing
up the
diff --git a/debian/control.in b/debian/control.in
index 92493f4..14059f7 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -30,7 +30,7 @@ Homepage: https://launchpad.net/deja-dup
 Package: deja-dup
 Architecture: any
 Depends: duplicity (>= 0.7.14), ${misc:Depends}, ${shlibs:Depends}
-Recommends: gvfs-backends, packagekit, policykit-1
+Recommends: gvfs-backends, packagekit, policykit-1, restic (>= 0.14),
rclone
 Suggests: python3-pydrive2
 Description: Backup utility
  Déjà Dup is a simple backup tool. It hides the complexity of backing
up the
diff --git a/debian/rules b/debian/rules
index 020145d..8cc0cdc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,5 +10,6 @@ override_dh_auto_configure:
dh_auto_configure -- \
   -Dgvfs_pkgs=gvfs-backends,python3-gi,gir1.2-
glib-2.0 \
   -Dpackagekit=enabled \
+  -Denable_restic=true \
   -Dpydrive_pkgs=python3-pydrive2 \
   -Drequests_oauthlib_pkgs=python3-requests-
oauthlib


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

Kernel: Linux 6.1.0-7-amd64 (SMP w/24 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 deja-dup depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  duplicity    0.8.22-1+b3
ii  libadwaita-1-0   1.2.2-1
ii  libc6    2.36-8
ii  libglib2.0-0 2.74.6-1
ii  libgpg-error0    1.46-1
ii  libgtk-4-1   4.8.3+ds-2
ii  libjson-glib-1.0-0   1.6.6-1
ii  libpackagekit-glib2-18   1.2.6-3
ii  libpango-1.0-0   1.50.12+ds-1
ii  libsecret-1-0    0.20.5-3
ii  libsoup-3.0-0    3.2.2-2

Versions of packages deja-dup recommends:
ii  gvfs-backends  1.50.3-1
ii  packagekit 1.2.6-3
ii  policykit-1    122-3

Versions of packages deja-dup suggests:
pn  python3-pydrive2  

-- no debconf information



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

Bug#1034304: geoalchemy2: autopkgtest regression on s390x: AssertionError


Source: geoalchemy2
Version: 0.13.1-2
Severity: serious
Tags: sid bookworm bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of geoalchemy2 the autopkgtest of geoalchemy2 fails 
in testing on s390x when that autopkgtest is run with the binary 
packages of geoalchemy2 from unstable. It passes when run with only 
packages from testing. In tabular form:


   passfail
geoalchemy2from testing0.13.1-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it? Please be reminded that 
s390x is our only big endian architecture.


[Release Team member hat on] Because we're currently in the hard freeze 
for bookworm, I have marked this bug as bookworm-ignore. Targeted fixes 
are still welcome.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=geoalchemy2

https://ci.debian.net/data/autopkgtest/testing/s390x/g/geoalchemy2/32779104/log.gz

=== FAILURES 
===
_ TestInsertionORM.test_WKTElement[postgresql] 
_


self = 
session = 
Lake = .Lake'>, setup_tables 
= None


def test_WKTElement(self, session, Lake, setup_tables):
lake = Lake(WKTElement("LINESTRING(0 0,1 1)", srid=4326))
session.add(lake)
session.flush()
session.expire(lake)
assert isinstance(lake.geom, WKBElement)

  assert str(lake.geom) == (


"010220e61002000"
"000f03ff03f"
)
E   AssertionError: assert '00200200...0' == 
'010220e6...0f03f'
E - 
010220e6100200f03ff03f
E ?  -  ^ 
^ -- - --
E + 
00200210e600023ff03ff0
E ?++ +   ^ 
+++ ^


tests/test_functional.py:297: AssertionError
_ TestInsertionORM.test_WKBElement[postgresql] 
_


self = 
session = 
Lake = .Lake'>, setup_tables 
= None


def test_WKBElement(self, session, Lake, setup_tables):
shape = LineString([[0, 0], [1, 1]])
lake = Lake(from_shape(shape, srid=4326))
session.add(lake)
session.flush()
session.expire(lake)
assert isinstance(lake.geom, WKBElement)

  assert str(lake.geom) == (


"010220e61002000"
"000f03ff03f"
)
E   AssertionError: assert '00200200...0' == 
'010220e6...0f03f'
E - 
010220e6100200f03ff03f
E ?  -  ^ 
^ -- - --
E + 
00200210e600023ff03ff0
E ?++ +   ^ 
+++ ^


tests/test_functional.py:313: AssertionError
 TestUpdateORM.test_Raster[postgresql] 
_


self = 0x3ff8900de90>

session = 
Ocean = .Ocean'>
setup_tables = None

def test_Raster(self, session, Ocean, setup_tables):
skip_postgis1(session)
polygon = WKTElement("POLYGON((0 0,1 1,0 1,0 0))", srid=4326)
o = Ocean(polygon.ST_AsRaster(5, 5))
session.add(o)
session.flush()
session.expire(o)
assert isinstance(o.rast, RasterElement)
rast_data = (

"0101009A99C93F9A99C9BFF03"

"FE61005000500440001010101010101010100"
"01010101010001"
)
>   assert o.rast.data == rast_data
E   AssertionError: assert '013F...1' == 
'0101009A...1'

E Skipping 45 identical trailing characters in diff, use -v to show
E - 
0101009A99C93F9A99C9BFF03FE61005000500440001010
E ?  ^    - --- ^^ 
 -- ---   --
E + 
013FCABFCA3FF010E600050005440001010
E ?  ^^^  ^^^ +++   ^^^ 
   ++


tests/test_functional_postgresql.py:365: AssertionError
__

Bug#1034303: nvidia-cuda-toolkit breaks nvidia-cuda-samples autopkgtest on amd64: bad exit status: 2

Source: nvidia-cuda-toolkit, nvidia-cuda-samples
Control: found -1 nvidia-cuda-toolkit/11.8.0-3
Control: found -1 nvidia-cuda-samples/11.8~dfsg-2
Severity: serious
Tags: sid bookworm bookworm-ignore
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of nvidia-cuda-toolkit the autopkgtest of
nvidia-cuda-samples fails on amd64 in testing when that autopkgtest is
run with the binary packages of nvidia-cuda-toolkit from unstable. It
passes when run with only packages from testing. In tabular form:

passfail
nvidia-cuda-toolkitfrom testing11.8.0-3
nvidia-cuda-samplesfrom testing11.8~dfsg-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of
nvidia-cuda-toolkit to testing [1]. Due to the nature of this issue, I
filed this bug report against both packages. Can you please investigate
the situation and reassign the bug to the right package?

[Release Team member hat on] Because we're currently in the hard freeze
for bookworm, I have marked this bug as bookworm-ignore.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=nvidia-cuda-toolkit

https://ci.debian.net/data/autopkgtest/testing/amd64/n/nvidia-cuda-samples/32796174/log.gz

Building module:
Cleaning build area...
'make' -j2 KVER=6.1.0-7-amd64 IGNORE_CC_MISMATCH='1'..(bad exit
status: 2)

Error! Bad return status for module build on kernel: 6.1.0-7-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-fs/2.13/build/make.log for more information.
E: nvidia-fs/2.13 failed to build for 6.1.0-7-amd64
== /var/lib/dkms/nvidia-fs/2.13/build/make.log ==
DKMS make.log for nvidia-fs-2.13 for kernel 6.1.0-7-amd64 (x86_64)
Tue Apr 11 23:11:31 UTC 2023
./configure 6.1.0-7-amd64
Picking NVIDIA driver sources from
NVIDIA_SRC_DIR=/usr/src/nvidia-current-525.89.02/nvidia. If that does
not meet your expectation, you might have a stale driver still around
and that might cause problems.

chmod +x ./create_nv.symvers.sh
./create_nv.symvers.sh 6.1.0-7-amd64
-E- Cannot locate nvidia modules!
CUDA driver must be installed before installing this package!
make: *** [Makefile:103: nv_symbols] Error 1
make: *** Waiting for unfinished jobs
checking if uaccess.h access_ok has 3 parameters... no
checking if uaccess.h access_ok has 2 parameters... yes
Checking if blkdev.h has blk_rq_payload_bytes... yes
Checking if fs.h has call_read_iter and call_write_iter... yes
Checking if fs.h has filemap_range_has_page... no
Checking if kiocb structue has ki_complete field... yes
Checking if KI_COMPLETE has 3 parameters ... no
Checking if vm_fault_t exist in mm_types.h... yes
Checking if IOCB_HIPRI flag exists in fs.h... yes
Checking if enum PCIE_SPEED_32_0GT exists in pci.h... yes
Checking if atomic64_t counter is of type long... no
Checking if RQF_COPY_USER is present or not... no
Checking if dma_drain_size and dma_drain_needed are present in struct
request_queue... no

Checking if struct proc_ops is present or not ... yes
Checking if split is present in vm_operations_struct or not ... no
Checking if mremap in vm_operations_struct has one parameter... yes
Checking if mremap in vm_operations_struct has two parameters... no
Checking if symbol module_mutex is present... no
Checking if blk-integrity.h is present... yes

I: Trying to build nvidia-fs/2.13 for 6.1.0-7-cloud-amd64
Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
'make' -j2 KVER=6.1.0-7-cloud-amd64 IGNORE_CC_MISMATCH='1'..(bad
exit status: 2)
Error! Bad return status for module build on kernel: 6.1.0-7-cloud-amd64
(x86_64)

Consult /var/lib/dkms/nvidia-fs/2.13/build/make.log for more information.
E: nvidia-fs/2.13 failed to build for 6.1.0-7-cloud-amd64
== /var/lib/dkms/nvidia-fs/2.13/build/make.log ==
DKMS make.log for nvidia-fs-2.13 for kernel 6.1.0-7-cloud-amd64 (x86_64)
Tue Apr 11 23:11:53 UTC 2023
./configure 6.1.0-7-cloud-amd64
Picking NVIDIA driver sources from
NVIDIA_SRC_DIR=/usr/src/nvidia-current-525.89.02/nvidia. If that does
not meet your expectation, you might have a stale driver still around
and that might cause problems.

chmod +x ./create_nv.symvers.sh
./create_nv.symvers.sh 6.1.0-7-cloud-amd64
-E- Cannot locate nvidia modules!
CUDA driver must be installed before installing this package!
make: *** [Makefile:103: nv_symbols] Error 1
make: *** Waiting for unfinished jobs
checking if uaccess.h access_ok has 3 parameters... no
checking if uaccess.h access_ok has 2 parameters... yes
Checking if blkdev.h has blk_rq_payload_bytes... yes
Checking if

Bug#1020481: Ready to Implement

2023-04-12 Thread Soren Stoutner

The dependencies are finally in place so this can be implemented.

To make things simpler for dictionary packagers, we are using a virtual 
package and an unversioned path for the conversion tool so that dictionary 
packagers don’t have to make modifications to their packages when the versions 
of Qt change in Debian.

All you should need to do is the following:

1.  Build-depend on `convert-bdic`.
2.  Create a temporary copy of the dictionaries and remove the IGNORE commands 
from 
the .aff files.
2.  Use /usr/bin/convert-bdic to do the dictionary conversion.
3.  Place the .bdic files in /usr/share/hunspell-bdic.

More detailed information can be found in the dictionary packager 
documentation at:

file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic

Thanks,

Soren

-- 
Soren Stoutner
so...@stoutner.com


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

Bug#1033900: pre-approval: dkms/3.0.10-10


Hi,

On 12-04-2023 12:00, Andreas Beckmann wrote:

On 12/04/2023 10.52, Sebastian Ramacher wrote:

+Restrictions:
+ allow-stderr,
+ needs-root,
+ breaks-testbed,


With these restrictions, I don't think the tests would run on debci
(Paul, please correct me if I am wrong). I hardly see the benefit of
granting an exception here for tests that won't be triggered.


These restrictions are the ones also used by the autodep8 dkms tests 
which happily run on the CI infrastructure:


The only real existing restriction that ci.d.n doesn't support is 
isolation-machine. The rest is supported.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033745: sequeler: Unlisted dependency on libgda-5.0-mysql

2023-04-12 Thread Adrien Dorsaz

On Sat, 1 Apr 2023 09:58:47 +0800 Yangfl  wrote:
> Brian Vaughan  于2023年4月1日周六 01:33写道：
> >
> > Versions of packages sequeler depends on:
> > ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4
> > ii libc6 2.36-8
> > ii libcairo2 1.16.0-7
> > ii libgda-5.0-4 5.2.10-3
> > ii libgee-0.8-2 0.20.6-1
> > ii libglib2.0-0 2.74.6-1
> > ii libgranite6 6.2.0-3
> > ii libgtk-3-0 3.24.37-2
> > ii libgtksourceview-3.0-1 3.24.11-2+b1
> > ii libsecret-1-0 0.20.5-3
> > ii libssh2-1 1.10.0-3+b1
> >
> > sequeler recommends no packages.
> >
> > sequeler suggests no packages.
> >
> > -- no debconf information
>
> This does not stop user using sqlite connection, so they are not
> qualified as hard dependencies.
>

Indeed, they aren't hard dependencies to launch the sequeler application 
and use it for sqlite databases.

Is it possible to add them as suggested dependencies ?

This will help the user to find the link between these two libdga  
drivers and the application without needing to find the information here 
or on Github.

Bug#913190: bash-completion: Update 'java' completion to support '.java' files

2023-04-12 Thread Geoffrey Thomas

Control: severity -1 normal

A side effect of the lack of support for .java files is that
bash-completion will turn slashes into dots for a Java command line. For
instance, if you type

$ java /home/

and press TAB, it will turn into

$ java .home.

IMO this raises the request from a new feature to a borderline bug,
because instead of simply failing to complete the final path component
(but letting the user type it in themselves or use M-/), it corrupts the
command line already entered by the user.

--
Geoffrey Thomas
geo...@twosigma.com

Bug#1034302: passwordsafe: Cherry-pick clean-up commits for desktop file

2023-04-12 Thread Amr Ibrahim

Package: passwordsafe
Version: 1.16.0+dfsg-1
Severity: normal
Tags: upstream

Dear Maintainer,

In Debian 11, passwordsafe 1.12.0 runs fine on Wayland through GTK3. However at
some point in time and in passwordsafe 1.16.0, upstream "erroneously" enforced
X11 in the desktop file.

Upstream have accepted my pull request to clean up the desktop file including
not to enforce X11 and let passwordsafe run normally on Wayland:
https://github.com/pwsafe/pwsafe/pull/905

Please cherry-pick the commits to be part of Debian 12. I have tested them in
Debian testing and passwordsafe runs fine.

Best,
Amr


-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing'), (100, 'unstable'), 
(50, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages passwordsafe depends on:
ii  libc62.36-8
ii  libgcc-s112.2.0-14
ii  libmagic11:5.44-3
ii  libqrencode4 4.1.1-1
ii  libstdc++6   12.2.0-14
ii  libuuid1 2.38.1-5+b1
ii  libwxbase3.2-1   3.2.2+dfsg-2
ii  libwxgtk3.2-13.2.2+dfsg-2
ii  libx11-6 2:1.8.4-2
ii  libxerces-c3.2   3.2.4+debian-1
ii  libxtst6 2:1.2.3-1.1
ii  libykpers-1-11.20.0-3
ii  passwordsafe-common  1.16.0+dfsg-1

Versions of packages passwordsafe recommends:
pn  xvkbd  

passwordsafe suggests no packages.

-- no debconf information

Bug#1034301: [thunderbird on armhf & amd64] not the same release on Debian bullseye 11.6 ?

2023-04-12 Thread Jean-Marc LACROIX


Source: thunderbird
Version: 1:102.9.0-1~deb11u1
Severity: normal

Dear Debian team,

I'm trying to  install  (via apt) the   "thunderbird" package on   the
Debian version  "bullseye". The  installation  is  carried out on  two
devices  in "armhf" and  "amd64"  architecture. The  first is an amd64
architecture (hostname hn-asusgl752-400)  and the  second is an  armhf
(hostname vn-bullseye-armhf-260).

Because files /etc/apt/preferences/xxx are the same, i dont understand
why "apt" does not install the same release on the two architectures.

Please find bellow my configurations...

test 01: lsb_release -a

ansible@hn-asusgl752-400:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
ansible@hn-asusgl752-400:~$

ansible@vn-bullseye-armhf-260:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
ansible@vn-bullseye-armhf-260:~$

test 02: uname -a

ansible@hn-asusgl752-400:~$ uname -a
Linux hn-asusgl752-400 6.0.0-0.deb11.6-rt-amd64 #1 SMP PREEMPT_RT Debian 
6.0.12-1~bpo11+1 (2022-12-19) x86_64 GNU/Linux

ansible@hn-asusgl752-400:~$

ansible@vn-bullseye-armhf-260:~$ uname -a
Linux vn-bullseye-armhf-260 6.1.0-0.deb11.6-armmp #1 SMP Debian 
6.1.15-1~bpo11+1 (2023-03-16) armv7l GNU/Linux

ansible@vn-bullseye-armhf-260:~$

test 03: cat /etc/apt/preferences.d/* |grep -v "#" |grep -v ^$
ansible@hn-asusgl752-400:~$ cat /etc/apt/preferences.d/* |grep -v "#" 
|grep -v ^$

Package: dhcpcd5
Pin: release *
Pin-Priority: -1

Package: xserver-xorg-video-nouveau
Pin: release *
Pin-Priority: -1
Package: *
Pin: release o=Debian,l=Debian,n=bullseye/updates
Pin-Priority: 500
Package: *
Pin: release o=Debian,l=Debian,n=bullseye-update
Pin-Priority: 500
Package: *
Pin: release o=Debian,l=Debian,n=bullseye
Pin-Priority: 500
Package: *
Pin: release o=Debian,l=Debian,n=bullseye-backports
Pin-Priority: 100
Package: *
Pin: release o=Debian,l=Debian,n=buster
Pin-Priority: 90
Package: *
Pin: release o=Debian,l=Debian,n=bookworm
Pin-Priority: 80
Package: *
Pin: release o=Debian,l=Debian,n=sid
Pin-Priority: 70
Package: *
Pin: release o=Debian,l=Debian,n=experimental
Pin-Priority: 60
ansible@hn-asusgl752-400:~$


ansible@vn-bullseye-armhf-260:~$ cat /etc/apt/preferences.d/* |grep -v 
"#" |grep -v ^$

Package: *
Pin: release o=Debian,l=Debian,n=bullseye/updates
Pin-Priority: 500
Package: *
Pin: release o=Debian,l=Debian,n=bullseye-update
Pin-Priority: 500
Package: *
Pin: release o=Debian,l=Debian,n=bullseye
Pin-Priority: 500
Package: *
Pin: release o=Debian,l=Debian,n=bullseye-backports
Pin-Priority: 100
Package: *
Pin: release o=Debian,l=Debian,n=buster
Pin-Priority: 90
Package: *
Pin: release o=Debian,l=Debian,n=bookworm
Pin-Priority: 80
Package: *
Pin: release o=Debian,l=Debian,n=sid
Pin-Priority: 70
Package: *
Pin: release o=Debian,l=Debian,n=experimental
Pin-Priority: 60
Package: dhcpcd5
Pin: release *
Pin-Priority: -1
ansible@vn-bullseye-armhf-260:~$

test 04:  cat /etc/apt/sources.list.d/*  |grep -v "#" |grep -v ^$

ansible@hn-asusgl752-400:~$ cat /etc/apt/sources.list.d/*  |grep -v "#" 
|grep -v ^$

deb http://ftp.de.debian.org/debian bullseye-backports main contrib non-free
deb http://ftp.de.debian.org/debian/ bullseye main contrib non-free
deb http://ftp.de.debian.org/debian/ buster main contrib non-free
deb http://repository.spotify.com stable non-free
deb http://security.debian.org/debian-security bullseye-security main 
contrib non-free

deb http://ftp.de.debian.org/debian bullseye-updates main contrib non-free
deb http://ppa.launchpad.net/yubico/stable/ubuntu cosmic main
ansible@hn-asusgl752-400:~$

ansible@vn-bullseye-armhf-260:~$ cat /etc/apt/sources.list.d/*  |grep -v 
"#" |grep -v ^$

deb http://ftp.de.debian.org/debian bullseye-backports main contrib non-free
deb http://ftp.de.debian.org/debian/ bullseye main contrib non-free
deb http://ftp.de.debian.org/debian/ buster main contrib non-free
deb http://security.debian.org/debian-security bullseye-security main 
contrib non-free

deb http://ftp.de.debian.org/debian bullseye-updates main contrib non-free
ansible@vn-bullseye-armhf-260:~$

test 05:  sudo apt update && sudo apt upgrade -y

ansible@hn-asusgl752-400:~$  sudo apt update && sudo apt upgrade -y
Réception de :1 http://security.debian.org/debian-security 
bullseye-security InRelease [48,4 kB]
Atteint :2 http://ppa.launchpad.net/yubico/stable/ubuntu cosmic 
InRelease
Atteint :3 http://ftp.de.debian.org/debian bullseye-backports InRelease 


Atteint :4 http://repository.spotify.com stable InRelease
Atteint :5 http://ftp.de.debian.org/debian bullseye InRelease
Atteint :6 http://ftp.de.debian.org/debian buster InRelease
Atteint :7 http://ftp.de.debian.org/debian bullseye-updates InRelease
Réception de :8 http://ftp.de.debian.org/debian bullseye/main 
Translation-fr [2

Bug#1033714: at runtime, flanker tries to create files under /usr

2023-04-12 Thread Andrey Rakhmatullin

On Wed, Apr 12, 2023 at 07:52:53AM -0700, Daniel Kauffman wrote:
> 
> > > > > This file is updated automatically if you're using a
> > > > > different version of the library than the one with which the
> > > > > file was created originally.
> > > This seems to confirm that for each version of the package, these
> > > files should be generated from debian/rules at build time.
> > Only if you want to also regenerate them when a new python3-ply is
> > uploaded, as far as I understand it.
> The python3-flanker package **could** be tightly coupled with the
> python3-ply package, but that wouldn't be ideal.
What else do you mean by generating files at the build time then?
The same problem will exist after a new python3-ply is uploaded.

> > > In the case of python3-flanker, the package does not work until the
> > > file is generated.
> > It does for me.
> Have you used flanker.addresslib.address.parse('u...@example.com') ?
Sure. It returns "u...@example.com".

> Other commands might not generate the files.
No, only importing shows these warnings. The second line doesn't.

> Are you running as root? 
No, otherwise I wouldn't see the warnings.

> Have you already generated these files?
No, otherwise it wouldn't attempt to regenerate them and wouldn't print
these warnings.

The only difference is that I'm using Python 3.11, not 3.9, as it doesn't
exist in testing.

Bug#1033303: mergerfs: Upgrade to v2.34.1 for bookworm

2023-04-12 Thread Ritesh Raj Sarraf

On Tue, 2023-03-21 at 23:23 +, MK wrote:
> Package: mergerfs
> Version: 2.33.5~debian-bullseye
> Severity: wishlist
> 
> 

Hello. Unfortunately, I don't have the resources to do it soon, withing
the Bookworm release time frame. If I can squeeze time, I'll do it but
it is highly unlikely.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

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

Bug#1034195: GCC bug

2023-04-12 Thread Philip Wyett

On Wed, 2023-04-12 at 15:45 +0200, Gert van de Kraats wrote:
> I saw the problem already is known at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020327
> and
> https://trac.filezilla-project.org/ticket/12777
> 
> I downloaded source filezilla-3.63.2.1 from filezilla website and got
> the same problem as mentioned at that bug:
> 
> gcc -DHAVE_CONFIG_H   -I../../../src/putty -I../../config -DNO_GSSAPI 
> -D_FILE_OFFSET_BITS=64  -fpch-preprocess  -g -O2 -Wall -MT 
> libfzputtycommon_a-sshsha.o -MD -MP -MF 
> .deps/libfzputtycommon_a-sshsha.Tpo -c -o libfzputtycommon_a-sshsha.o 
> `test -f 'sshsha.c' || echo '../../../src/putty/'`sshsha.c
> In file included from /usr/lib/gcc/i686-linux-gnu/12/include/immintrin.h:98,
>   from ../../../src/putty/sshsha.c:347:
> /usr/lib/gcc/i686-linux-gnu/12/include/avx512fp16intrin.h:38:9: error: 
> ‘_Float16’ is not supported on this target
> 
> I changed the Makefile at src/putty and added -msse4.1 to CFLAGS and
> CXXFLAGS.
> After this change I could compile filezilla without a problem.
> Installing filezilla gave some problems because the files are not
> installed at the right location, but with some symbolic links
> filezilla works without a problem.
> According to "cat proc/cpuinfo" my cpu supports sse and sse2.
> 
> Like Tim Kosse I think this is a gcc-12-bug, not a filezilla-bug.
> I do not see any changes in this area at filezilla since previous
> release filezilla-3.57.0.
> If I compile sshsha.c at that release with gcc-12, I get the same error.
> If I compile sshsha.c at both releases with gcc-11, I get no error.
> 
> If a pragma GCC target is activated for some source, then the
> compiler should not generate an error if the build target is not
> supporting this. This makes cross-compilation impossible.
> 
> In that case it is the responsibility of the programmer to assure that
> this code is only executed if the specified target is available.
> 
> I think   pragma GCC target sse4.1 (locally) and -msse4.1 (globally)
> should do the same thing.

Hi,

If you wish to add this to the upstream bug report, I will look at testing it 
on the i386 builders
if and when it makes it into a release.

Regards

Phil

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


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1034026: podman-docker: missing /usr/share/user-tmpfiles.d/podman-docker.conf

2023-04-12 Thread Niels Thykier


Scott Edlund:
@nthykier do you think it's worth extending dh_installtmpfiles to 
include support for /usr/share/user-tmpfiles.d ?



[...]


Yes. Though it would have to be after the freeze (debhelper is covered 
by the toolchain freeze).


Feel free to file a wishlist bug for it.

Best regards,
Niels

Bug#1028002: dash: sid dash globs no longer allow [^...] to negate a class; upcoming breaking change from bullseye

2023-04-12 Thread Santiago Ruano Rincón

Control: severity -1 important

Hi!

On Fri, 6 Jan 2023 12:31:47 +0100 =?utf-8?B?0L3QsNCx?= 
 wrote:
> Hi!
> 
> On Fri, Jan 06, 2023 at 10:52:31AM +0100, Andrej Shadura wrote:
> > On Thu, 5 Jan 2023, at 21:32, наб wrote:
> > > Bisecting over the upstream git, I got
> > >   commit 8f9cca055bc661c4c690a5f5e1ca71370d129bc3 (HEAD, refs/bisect/bad)
> > >   Author: Herbert Xu 
> > >   Date:   Wed Jan 19 16:37:54 2022 +1100
> > >  
> > >   expand: Always quote caret when using fnmatch
> > 
> > > as the first bad commit with default configuration (HAVE_FNMATCH=1).
> > >
> > > I /cannot/ find a set-up where configuring like Debian
> > > (--disable-fnmatch --disable-lineno --disable-glob)
> > > isn't broken.
> > 
> > I’m not sure why this also affects configurations with --disable-fnmatch — 
> > from the description of it, it shouldn’t?
> 
> Well, dash's built-in globs Just Don't Support ^. Never have.
> (Defined as "current code doesn't and it blames to start-of-git".)
> They're strictly POSIX, and ^ is a regular character for them.
> 
> 8f9cca0 fixes the fact that glibc fnmatch() has a special meaning for ^
> by unconditionally escaping it (if configured for libc fnmatch) ‒
> it normalises [^0-9] to always mean [0-9^],
> regardless of --with-fnmatch/--disable-fnmatch.
> 
> > > Y'know what, I bisected the Salsa git, too, but then I consulted POSIX.
> > > Apparently, this is fine.
> > 
> > > Please for the love of god add this to the NEWS.
> > > I /guarantee/ people are using '[^0-9]' to mean "not 0-9",
> > > and similar constructs, even if they are well-versed in the shell 
> > > language.
> > >
> > > This is a breaking change going from bullseye, and quite an insidious one.
> > > I assume my reaction is gonna mirror others' quite well.
> > >
> > > /Please/ add this to the NEWS.
> > 
> > I’m actually considering reverting that patch, as it seems a bit too late 
> > in the release cycle to introduce such a breaking change.
> 
> I've bisected across snapshot.d.o, and the first Debian version
> that exhibits this behaviour is 0.5.11+git20210903+057cd650a4ed-4:
>   
> http://snapshot.debian.org/package/dash/0.5.11%2Bgit20210903%2B057cd650a4ed-4/
> 
> Which, if I understand it right, has landed in sid on 2022-03-04.
> Since march of last year, sid and testing have been using this;
> quoth tracker.d.o:
>   [2022-03-07] dash 0.5.11+git20210903+057cd650a4ed-7 MIGRATED to testing 
> (Debian testing watch) 
> 
> So it's been a good part of a year and no-one's complained
> (maybe I'm the idiot what doesn't know globs are negated with !s),
> from the point of view of "system compatibility",
> I think this has passed the test.
> 
> From the point of user code, a NEWS entry I'd consider sufficient,
> as usual for breaking-for-compat user-observable changes.
> 
> Reverting this now would probably have the opposite effect

I am taking the liberty to increase the severity of this bug. I'd say it
is serious, but I'd let the maintainer or the release team to decide on
that.

I am aware of at least one user hit by this. If the current behaviour
would be part of bookworm, a NEWS entry would be great.

Thanks,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1033714: at runtime, flanker tries to create files under /usr

2023-04-12 Thread Daniel Kauffman




This file is updated automatically if you're using a different 
version of the library than the one with which the file was created 
originally. 
This seems to confirm that for each version of the package, these 
files should be generated from debian/rules at build time. 
Only if you want to also regenerate them when a new python3-ply is 
uploaded, as far as I understand it.
The python3-flanker package **could** be tightly coupled with the 
python3-ply package, but that wouldn't be ideal.


Also I think 
https://github.com/mailgun/flanker/commit/96d774eb6d67b1c5fafe711394c3756df7bb14ad 
(not released yet) is probably about this issue.
That would be great! If the files are not generated at either build time 
or run time, then this particular issue would be solved without special 
handling for Debian packaging, which is always preferred.


Looks like this commit should be in the next release after v0.9.15 
(released March 3, 2023).


In the case of python3-flanker, the package does not work until the 
file is generated. 
It does for me. 
Have you used flanker.addresslib.address.parse('u...@example.com') ? 
Other commands might not generate the files.


Are you running as root? In this case, the files would be generated and 
saved without permission errors.


Have you already generated these files? Possibly by previously running 
as root or possibly by previously installing flanker in a user environment?

Bug#1034195: GCC bug

2023-04-12 Thread Gert van de Kraats


I saw the problem already is known at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020327
and
https://trac.filezilla-project.org/ticket/12777

I downloaded source filezilla-3.63.2.1 from filezilla website and got
the same problem as mentioned at that bug:

gcc -DHAVE_CONFIG_H   -I../../../src/putty -I../../config -DNO_GSSAPI 
-D_FILE_OFFSET_BITS=64  -fpch-preprocess  -g -O2 -Wall -MT 
libfzputtycommon_a-sshsha.o -MD -MP -MF 
.deps/libfzputtycommon_a-sshsha.Tpo -c -o libfzputtycommon_a-sshsha.o 
`test -f 'sshsha.c' || echo '../../../src/putty/'`sshsha.c

In file included from /usr/lib/gcc/i686-linux-gnu/12/include/immintrin.h:98,
 from ../../../src/putty/sshsha.c:347:
/usr/lib/gcc/i686-linux-gnu/12/include/avx512fp16intrin.h:38:9: error: 
‘_Float16’ is not supported on this target


I changed the Makefile at src/putty and added -msse4.1 to CFLAGS and
CXXFLAGS.
After this change I could compile filezilla without a problem.
Installing filezilla gave some problems because the files are not
installed at the right location, but with some symbolic links
filezilla works without a problem.
According to "cat proc/cpuinfo" my cpu supports sse and sse2.

Like Tim Kosse I think this is a gcc-12-bug, not a filezilla-bug.
I do not see any changes in this area at filezilla since previous
release filezilla-3.57.0.
If I compile sshsha.c at that release with gcc-12, I get the same error.
If I compile sshsha.c at both releases with gcc-11, I get no error.

If a pragma GCC target is activated for some source, then the
compiler should not generate an error if the build target is not
supporting this. This makes cross-compilation impossible.

In that case it is the responsibility of the programmer to assure that
this code is only executed if the specified target is available.

I think   pragma GCC target sse4.1 (locally) and -msse4.1 (globally)
should do the same thing.

Bug#1033424: image-factory: FTBFS in testing: AssertionError: pylint found issues:

2023-04-12 Thread Josef Schneider


Hello,

I have attached a debdiff where I replace the broad exception types with 
appropriate error types. This patch satisfies the pylint test and allows 
the package to build without issues. I can upload this RC bug fix as a 
NMU if you want. Thanks!


--
Josef Schneider

GPG Fingerprint 3267 0331 DB61 A817 7D25 4D05 5A44 BC12 F2A8 E58F
diff -Nru image-factory-1.0.2/debian/changelog 
image-factory-1.0.2/debian/changelog
--- image-factory-1.0.2/debian/changelog2021-11-12 16:52:40.0 
+0100
+++ image-factory-1.0.2/debian/changelog2023-04-12 15:50:18.0 
+0200
@@ -1,3 +1,11 @@
+image-factory (1.0.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches: Add 0001-replace-broad-exceptions.patch.
++ Pass pylint test and fix FTBFS (Closes: #1033424).
+
+ -- Josef Schneider   Wed, 12 Apr 2023 15:50:18 +0200
+
 image-factory (1.0.2-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru 
image-factory-1.0.2/debian/patches/0001-replace-broad-exceptions.patch 
image-factory-1.0.2/debian/patches/0001-replace-broad-exceptions.patch
--- image-factory-1.0.2/debian/patches/0001-replace-broad-exceptions.patch  
1970-01-01 01:00:00.0 +0100
+++ image-factory-1.0.2/debian/patches/0001-replace-broad-exceptions.patch  
2023-04-12 15:50:18.0 +0200
@@ -0,0 +1,43 @@
+From a32952d31c02d2ce2425032e1960c0c292a29855 Mon Sep 17 00:00:00 2001
+From: Josef Schneider 
+Date: Wed, 12 Apr 2023 15:49:41 +0200
+Subject: [PATCH] replace broad exceptions
+
+---
+ image-factory | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/image-factory b/image-factory
+index f8dffe0..5130fd7 100755
+--- a/image-factory
 b/image-factory
+@@ -61,7 +61,7 @@ def get_config():
+ if env_name in os.environ:
+ config_files = [os.environ[env_name]]
+ if not os.path.isfile(config_files[0]):
+-raise Exception(
++raise FileNotFoundError(
+ "'" + config_files[0] + "' (set in " + env_name + ") is not a 
valid file."
+ )
+ else:
+@@ -135,7 +135,7 @@ def cache_file(cache_dir, source):
+ elif source.startswith("rsync:"):
+ call_command(["rsync", "--no-motd", source, destination])
+ else:
+-raise Exception(f"No download handler for file '{source}' found.")
++raise ValueError(f"No download handler for file '{source}' found.")
+ return relative_destination
+ 
+ 
+@@ -163,7 +163,7 @@ def download_and_publish(config, image, source, filename):
+ elif source.startswith("rsync:"):
+ call_command(["rsync", "--no-motd", source, destination])
+ else:
+-raise Exception(f"No download handler for file '{source}' found.")
++raise ValueError(f"No download handler for file '{source}' found.")
+ return destination
+ 
+ 
+-- 
+2.38.1
+
diff -Nru image-factory-1.0.2/debian/patches/series 
image-factory-1.0.2/debian/patches/series
--- image-factory-1.0.2/debian/patches/series   1970-01-01 01:00:00.0 
+0100
+++ image-factory-1.0.2/debian/patches/series   2023-04-12 15:50:18.0 
+0200
@@ -0,0 +1 @@
+0001-replace-broad-exceptions.patch


OpenPGP_0x5A44BC12F2A8E58F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034300: RFP: simplex-chat -- messaging platform operating without user identifiers of any kind

2023-04-12 Thread Praveen Arimbrathodiyil


Package: wnpp
Severity: wishlist
Control: forwarded -1 
https://github.com/simplex-chat/simplex-chat/issues/415


Source is at https://github.com/simplex-chat/simplex-chat under AGPL-3.0

Though currently it does not build on sid due to compiler version 
mismatch being tracked at 
https://github.com/simplex-chat/simplex-chat/issues/415


SimpleX - the first messaging platform operating without user 
identifiers of any kind - 100% private by design!


They have a CLI version and their prebuilt binaries are amd64 only.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034299: unblock: geocode-glib/3.26.3-6

2023-04-12 Thread Jeremy Bícha

Package: release.debian.org
Control: affects -1 + src:geocode-glib
X-Debbugs-Cc: geocode-g...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package geocode-glib

[ Reason ]
This update fixes geolocation in the Initial Setup & GNOME Clocks
apps, perhaps others.

Also, the -common package is now installed by the library which
includes icons that could be used by some apps using the API.

[ Impact ]
Although Initial Setup is included by default (for the first time) in
Debian GNOME Bookworm, the location page is unlikely to be seen
since it is only used in New User mode. To get to New User mode
requires a system without any regular users configured, which is not
typical for Desktop installs of Debian.

GNOME Clocks is included by default and geolocation is used trivially
to show a location for the local clock.

[ Tests ]
The upstream test suite was successfully run as build tests and as
installed tests using autopkgtest.

I tested that geolocation now works for me with both Clocks and Initial Setup.

[ Risks ]

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock geocode-glib/3.26.3-6

Thank you,
Jeremy Bicha

Bug#1034298: unblock: unbound/1.17.1-2

2023-04-12 Thread Michael Tokarev

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package unbound

[ Reason ]
There was a small bug in one of the package scripts (#1019140)
which results in unbound being unable to start (and package
failure) depending on the system configuration (quite common
configurations are affected).  I hoped do fix this issue together
with another unbound package upload but forgot about that one,
and the issue went into the freeze period.

[ Impact ]
System upgrade failure or unbound failing to startup in
certain configurations.

[ Tests ]
The issue is well-located so it was easy to verify the bug is
fixed after the change. The whole thing is rather trivial.

[ Risks ]
The thing is trivial once you see what's going on.
And the change is trivial too, see the (helper) startup script
diff below.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock unbound/1.17.1-2


diff -Nru unbound-1.17.1/debian/changelog unbound-1.17.1/debian/changelog
--- unbound-1.17.1/debian/changelog 2023-01-12 18:28:54.0 +0300
+++ unbound-1.17.1/debian/changelog 2023-04-09 15:59:14.0 +0300
@@ -1,3 +1,10 @@
+unbound (1.17.1-2) unstable; urgency=medium
+
+  * unbound-helper: return 0 explicitly in a few places
+(Closes: #1019140)
+
+ -- Michael Tokarev   Sun, 09 Apr 2023 15:59:14 +0300
+
 unbound (1.17.1-1) unstable; urgency=medium
 
   [ Michael Tokarev ]
diff -Nru unbound-1.17.1/debian/unbound-helper 
unbound-1.17.1/debian/unbound-helper
--- unbound-1.17.1/debian/unbound-helper2022-08-12 13:04:20.0 
+0300
+++ unbound-1.17.1/debian/unbound-helper2023-01-12 18:49:26.0 
+0300
@@ -24,7 +24,7 @@
 fi
 
 do_resolvconf_start() {
-[ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return
+[ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return 0
 
 unbound-checkconf $CHROOT_DIR/$UNBOUND_CONF -o interface | {
 default=yes
@@ -44,13 +44,13 @@
 }
 
 do_resolvconf_stop() {
-[ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return
+[ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return 0
 
 /sbin/resolvconf -d lo.unbound
 }
 
 do_chroot_setup() {
-[ -n "$CHROOT_DIR" -a -d "$CHROOT_DIR" ] || return
+[ -n "$CHROOT_DIR" -a -d "$CHROOT_DIR" ] || return 0
 if [ "$CHROOT_DIR" != "$UNBOUND_BASE_DIR" ]; then
 # we probably should not do the force-recreate but just a refresh
 rm -rf   "$CHROOT_DIR/$UNBOUND_BASE_DIR"

Bug#1034297: unblock: cfengine3/3.21.0-2

2023-04-12 Thread Christoph Martin

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: mar...@uni-mainz.de, schla...@uni-mainz.de

Please unblock package cfengine3

3.21.0-2 includes a fix for the installation path of the systemd unit
files. It closes the RC bug #1034218.

[ Reason ]
Fixes RC bug #1034218.

[ Impact ]
The unit file beeing in the wrong path might result in not activated units.

[ Risks ]
I don't see any risks.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock cfengine3/3.21.0-2
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-
-rw-r--r--  root/root   /lib/systemd/system/cf-apache.service
-rw-r--r--  root/root   /lib/systemd/system/cf-execd.service
-rw-r--r--  root/root   /lib/systemd/system/cf-hub.service
-rw-r--r--  root/root   /lib/systemd/system/cf-monitord.service
-rw-r--r--  root/root   /lib/systemd/system/cf-postgres.service
-rw-r--r--  root/root   /lib/systemd/system/cf-reactor.service
-rw-r--r--  root/root   /lib/systemd/system/cf-runalerts.service
-rw-r--r--  root/root   /lib/systemd/system/cf-serverd.service
-rw-r--r--  root/root   /lib/systemd/system/cfengine3.service
-rwxr-xr-x  root/root   DEBIAN/prerm

Files in first .deb but not in second
-
-rw-r--r--  root/root   /usr/lib/systemd/system/cf-apache.service
-rw-r--r--  root/root   /usr/lib/systemd/system/cf-execd.service
-rw-r--r--  root/root   /usr/lib/systemd/system/cf-hub.service
-rw-r--r--  root/root   /usr/lib/systemd/system/cf-monitord.service
-rw-r--r--  root/root   /usr/lib/systemd/system/cf-postgres.service
-rw-r--r--  root/root   /usr/lib/systemd/system/cf-reactor.service
-rw-r--r--  root/root   /usr/lib/systemd/system/cf-runalerts.service
-rw-r--r--  root/root   /usr/lib/systemd/system/cf-serverd.service
-rw-r--r--  root/root   /usr/lib/systemd/system/cfengine3.service

Control files: lines which differ (wdiff format)

Depends: lsb-base (>= 3.0-6), e2fsprogs, libacl1 (>= 2.2.23), libc6 (>= 2.34), 
liblmdb0 (>= 0.9.11), libpam0g (>= 0.99.7.1), libpcre3, libpromises3 (= 
[-3.21.0-1),-] {+3.21.0-2),+} libssl3 (>= 3.0.0), libvirt0 (>= 0.5.0), libxml2 
(>= 2.7.4), libyaml-0-2
Installed-Size: [-2133-] {+2142+}
Version: [-3.21.0-1-] {+3.21.0-2+}

Bug#1034296: unblock: seabios/1.16.2-1

2023-04-12 Thread Michael Tokarev

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pkg-qemu-de...@lists.alioth.debian.org

Please unblock package seabios

[ Reason ]
This debian release syncronizes with the upstream stable/bugfix
release of 1.16.2.  Previous debian release of this package had
1.16.1 difference as a patch because upstream forgot to publish
the tarball.  1.16.2-1 has exactly the same stuff the previous
debian revision had (1.16.1), plus two more changes from upstream
stable/bugfix release 1.16.2.

One of the changes is a bugfix for usb hid devices init (which
I've hit myself but thought it's some difficult to diagnose
QEMU bug). It's definitely worth to have this one on bookworm.

The second change is not strictly necessary for bookworm, but
I thought there's no good reason to remove it from the upstream
stable/bugfix release.  It is related to the way how seabios
detects Xen, for the rare HVM Xen domU.  This change will be
useful for more recent qemu (8.0+) though.

[ Impact ]
There's a relatively small issue with USB HID devices init which
can only trigger in certain configurations, which will be unfixed.
Plus it will be just a bit more work for the further package
maintenance.

[ Tests ]
I tested the new bios package locally with both qemu (bookworm
one and the next version), *and* with actual Xen HVM domU, the
change does not break my setups, but allows new qemu to run
Xen HVM domains too.  Upstream has it integrated into the QEMU
CI tests.

[ Risks ]
I don't see much risks with this change. All involved code paths
are quite well tested.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]
Unfortunately the debdiff isn't very useful due to 1.16.1=>upstream
source move.  So I'm also adding the diff with patches applied,
which shows only the 2 changes I mentioned above.  First comes the
diff, next comes the debdiff.

unblock seabios/1.16.2-1

== begin diff ==
--- seabios-1.16.0/debian/changelog 2022-12-01 17:06:24.0 +0300
+++ seabios-1.16.2/debian/changelog 2023-04-11 16:08:25.0 +0300
@@ -1,3 +1,14 @@
+seabios (1.16.2-1) unstable; urgency=medium
+
+  * sync with upstream stable 1.16.2 release (rel-1.16.2 tag):
+this brings up to the exactly same state as our rel-1.16.1.patch
+did, and brings up 2 more fixes:
+- usb: fix wrong init of keyboard/mouse's if first interface
+  is not boot protocol
+- xen: require Xen info structure at 0x1000 to detect Xen
+
+ -- Michael Tokarev   Tue, 11 Apr 2023 16:08:25 +0300
+
 seabios (1.16.0-5) unstable; urgency=medium
 
   * d/rules: vgabios.bin compatibility symlink for qemu (Closes: #1024382)
diff -u -r -x '*.pc/*' seabios-1.16.0/debian/patches/series 
seabios-1.16.2/debian/patches/series
--- seabios-1.16.0/debian/patches/series2022-12-01 17:06:12.0 
+0300
+++ seabios-1.16.2/debian/patches/series2023-04-11 16:07:44.0 
+0300
@@ -1,2 +1 @@
 nogitversion.patch
-rel-1.16.1.patch
diff -u -r -x '*.pc/*' seabios-1.16.0/src/fw/xen.c seabios-1.16.2/src/fw/xen.c
--- seabios-1.16.0/src/fw/xen.c 2022-03-02 04:29:02.0 +0300
+++ seabios-1.16.2/src/fw/xen.c 2023-02-02 04:14:39.0 +0300
@@ -40,16 +40,25 @@
 u32 e820_nr;
 } PACKED;
 
-static void validate_info(struct xen_seabios_info *t)
+static struct xen_seabios_info *validate_info(void)
 {
-if ( memcmp(t->signature, "XenHVMSeaBIOS", 14) )
-panic("Bad Xen info signature\n");
+struct xen_seabios_info *t = (void *)INFO_PHYSICAL_ADDRESS;
 
-if ( t->length < sizeof(struct xen_seabios_info) )
-panic("Bad Xen info length\n");
+if ( memcmp(t->signature, "XenHVMSeaBIOS", 14) ) {
+dprintf(1, "Bad Xen info signature\n");
+return NULL;
+}
+
+if ( t->length < sizeof(struct xen_seabios_info) ) {
+dprintf(1, "Bad Xen info length\n");
+return NULL;
+}
 
-if (checksum(t, t->length) != 0)
-panic("Bad Xen info checksum\n");
+if (checksum(t, t->length) != 0) {
+dprintf(1, "Bad Xen info checksum\n");
+return NULL;
+}
+return t;
 }
 
 void xen_preinit(void)
@@ -86,7 +95,10 @@
 dprintf(1, "No Xen hypervisor found.\n");
 return;
 }
-PlatformRunningOn = PF_QEMU|PF_XEN;
+if (validate_info())
+PlatformRunningOn = PF_QEMU|PF_XEN;
+else
+dprintf(1, "Not enabling Xen support due to lack of Xen info\n");
 }
 
 static int hypercall_xen_version( int cmd, void *arg)
@@ -122,10 +134,14 @@
 
 void xen_biostable_setup(void)
 {
-struct xen_seabios_info *info = (void *)INFO_PHYSICAL_ADDRESS;
-void **tables = (void*)info->tables;
+struct xen_seabios_info *info = validate_info();
+void **tables;
 int i;
 
+if (!info)
+panic("Xen info corrupted\n");
+
+tables = (void*)info->tables;

Bug#1034295: unblock: mozjs102/102.10.0-1

2023-04-12 Thread Jeremy Bícha

Package: release.debian.org
Control: affects -1 + src:mozjs102
X-Debbugs-Cc: mozjs...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package mozjs102

[ Reason ]
The new mozjs102 stable point release includes multiple security fixes.

[ Impact ]
mozjs102 is only used by gjs which in turn is used by GNOME Shell and
several GNOME apps written in JavaScript.

[ Tests ]
The build tests have passed successfully and the gjs autopkgtests
triggered by this upload have passed too. (mozjs102 itself
does not have autopkgtests yet).

I also completed the manual test cases from
https://wiki.ubuntu.com/DesktopTeam/TestPlans/gjs
on Debian Testing.

[ Risks ]

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]
mozjs102 is the SpiderMonkey JavaScript engine from the current
Firefox ESR stable branch. There are monthly releases until August.

https://whattrainisitnow.com/calendar/

I am unaware of anyone using Firefox vulnerabilities to attack GNOME
Shell, but I think it's good to be prudent and apply available
security updates. I don't think the Debian Security Team has done
security uploads for mozjs*, in part because Mozilla's lifecycle is so
short that it's difficult for an upstream supported mozjs to be in a
Debian stable release.

For more info about the commits, see the Github mirror:
https://github.com/mozilla/gecko-dev/commits/esr102/js

unblock mozjs102/102.10.0-1

Thank you,
Jeremy Bicha


mozjs102_102.10.0-1.debdiff
Description: Binary data

Bug#1034026: podman-docker: missing /usr/share/user-tmpfiles.d/podman-docker.conf

2023-04-12 Thread Scott Edlund

@nthykier do you think it's worth extending dh_installtmpfiles to 
include support for /usr/share/user-tmpfiles.d ?



On 12/04/2023 18:01, Reinhard Tartler wrote:

Control: tag -1 help

On Thu, Apr 6, 2023 at 2:06 PM Scott Edlund  wrote:

podman-docker.conf was configured for use with rootless podman
starting
in 4.3.0rc1 .   Please install the tmpfiles configuration also in
user-tmpfiles.

See

https://github.com/containers/podman/commit/b47c54ab69d56f05bc586e443d04fe572de8ff8f


It seems that dh_installtmpfiles(1) does not take care of that, I hoped
that it would.

I'm struggling to find out what's the right debhelper to use here. Any 
suggestions on
how to modify 
https://salsa.debian.org/debian/libpod/-/tree/debian/sid/debian in

the most elegant way?

-rt


--
regards,
    Reinhard

Bug#1034289: inkscape: canvas stops updating completely when trying to edit a text box

2023-04-12 Thread Giuseppe Bilotta

Package: inkscape
Version: 1.2.2-2+b1
Followup-For: Bug #1034289

Additional information: the issue I'm seeing seems to match upstream
issue #3664
https://gitlab.com/inkscape/inkscape/-/issues/3664
and seems to be related to a GTK bug when GTK_IM_MODULE=xim
Unsetting the variable or testing one of the values recommended in the
comments to the bug solves the issue for me.

Bug#1034293: cross-instal-location.diff no longer applies

Source: gcc-13
Version: 13-20230411-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi Matthias,

cross-install-location.diff no longer applies. I'm attaching a fix for
your convenience.

Helmut
diff --minimal -Nru gcc-13-13-20230411/debian/changelog 
gcc-13-13-20230411/debian/changelog
--- gcc-13-13-20230411/debian/changelog 2023-04-11 14:08:31.0 +0200
+++ gcc-13-13-20230411/debian/changelog 2023-04-12 07:17:42.0 +0200
@@ -1,3 +1,10 @@
+gcc-13 (13-20230411-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix application of cross-install-location.diff. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 12 Apr 2023 07:17:42 +0200
+
 gcc-13 (13-20230411-1) experimental; urgency=medium
 
   * New upstream snapshot, taken from the trunk.
diff --minimal -Nru 
gcc-13-13-20230411/debian/patches/cross-install-location.diff 
gcc-13-13-20230411/debian/patches/cross-install-location.diff
--- gcc-13-13-20230411/debian/patches/cross-install-location.diff   
2023-01-27 07:12:51.0 +0100
+++ gcc-13-13-20230411/debian/patches/cross-install-location.diff   
2023-04-12 07:17:42.0 +0200
@@ -382,9 +382,9 @@
  gcc_version := $(shell @get_gcc_base_ver@ $(srcdir)/../gcc/BASE-VER)
 -libexecsubdir := $(libexecdir)/gcc/$(target_noncanonical)/$(gcc_version)
 +libexecsubdir := $(libexecdir)/gcc-cross/$(target_noncanonical)/$(gcc_version)
+ INSTALL := @INSTALL@
  INSTALL_PROGRAM := @INSTALL_PROGRAM@
  INSTALL_STRIP_PROGRAM := $(srcdir)/../install-sh -c -s
- AUTOCONF := @AUTOCONF@
 --- a/src/libgm2/libm2cor/Makefile.am
 +++ b/src/libgm2/libm2cor/Makefile.am
 @@ -27,7 +27,7 @@ MAKEOVERRIDES=
diff --minimal -Nru gcc-13-13-20230411/debian/target 
gcc-13-13-20230411/debian/target
--- gcc-13-13-20230411/debian/target1970-01-01 01:00:00.0 +0100
+++ gcc-13-13-20230411/debian/target2023-04-12 07:17:15.0 +0200
@@ -0,0 +1 @@
+arm64

Bug#1034294: libspandsp-dev: ships headers declaring missing symbols

Package: libspandsp-dev
Version: 0.0.6+dfsg-2

Hi,

I noticed that libspandsp-dev ships some headers that refer to missing
symbols. For instance g1050.h refers to symbols containing g1050, but
the installed shared libraries do not contain such symbols. The affected
headers originate from
https://sources.debian.org/src/spandsp/0.0.6%2Bdfsg-2/spandsp-sim/Makefile.am/#L52
and I think they shouldn't be included as libspandsp_sim isn't included
either.

Unfortunately, building spandsp-sim is controlled via --enable-tests.
So this flag doesn't just enable or disable build-time testing, it
really affects the package contents and thus we cannot at present
conditionalize --enable-tests to DEB_BUILD_OPTIONS=nocheck without
breaking reproducibility.

Having DEB_BUILD_OPTIONS=nocheck imply --disable-tests would help with
making spandsp cross buildable.

So back to the first issue, can we drop the spandsp-sim headers from the
libspandsp-dev package?

Helmut

Bug#1034292: convert jbigkit-testdata to Architecture: all

Source: jbigkit
Version: 2.1-6.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags ftcbfs

jbigkit-testdata actually contains data that is the same for all
architectures. As such, it should be an Arch:all package. I'm attaching
a patch to do so for your convenience.

As it happens, generation of jbigkit-testdata breaks cross compilation.
By moving it into an indep package, it becomes irrelevant to cross
compilation and thus cross compilation is fixed.

Helmut
--- jbigkit-2.1/debian/changelog
+++ jbigkit-2.1/debian/changelog
@@ -1,3 +1,10 @@
+jbigkit (2.1-6.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert jbigkit-testdata to Arch: all. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 11 Apr 2023 13:25:14 +0200
+
 jbigkit (2.1-6.1) unstable; urgency=medium
 
   * Non-maintainer upload.
--- jbigkit-2.1/debian/control
+++ jbigkit-2.1/debian/control
@@ -23,7 +23,8 @@
 
 Package: jbigkit-testdata
 Section: graphics
-Architecture: any
+Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Description: JBIG-KIT testdata
  JBIG-KIT provides a portable library of compression and decompression 
functions
--- jbigkit-2.1/debian/patches/split-arch-indep.patch
+++ jbigkit-2.1/debian/patches/split-arch-indep.patch
@@ -0,0 +1,35 @@
+--- jbigkit-2.1.orig/Makefile
 jbigkit-2.1/Makefile
+@@ -10,7 +10,7 @@
+ export CC CFLAGS
+ 
+ VERSION=2.1
+-.PHONY: all lib pbm test clean install
++.PHONY: all lib pbm test clean install install-lib install-pbm 
install-testdata
+ 
+ all: lib pbm testdata
+   @echo "Enter 'make test' in order to start some automatic tests."
+@@ -47,16 +47,22 @@
+   rsync -t jbigkit-$(VERSION).tar.gz $(HOME)/public_html/download/
+   rsync -t jbigkit-$(VERSION)/CHANGES $(HOME)/public_html/jbigkit/
+ 
+-install: all
++install-lib: lib
+   install -d $(DESTDIR)/usr/lib/$(DEB_HOST_MULTIARCH)
+   install -m 644 libjbig/*.so.* libjbig/*.a 
$(DESTDIR)/usr/lib/$(DEB_HOST_MULTIARCH)
+   /sbin/ldconfig -n $(DESTDIR)/usr/lib/$(DEB_HOST_MULTIARCH)
+   ln -s libjbig.so.0 $(DESTDIR)/usr/lib/$(DEB_HOST_MULTIARCH)/libjbig.so
+   install -d $(DESTDIR)/usr/include
+   install -m 644 libjbig/*.h $(DESTDIR)/usr/include
++
++install-pbm: pbm
+   install -d $(DESTDIR)/usr/bin
+   install -m 755 pbmtools/jbgtopbm pbmtools/jbgtopbm85 pbmtools/pbmtojbg 
pbmtools/pbmtojbg85 $(DESTDIR)/usr/bin
+   install -d $(DESTDIR)/usr/share/man/man1
+   install -m 644 pbmtools/*.1 $(DESTDIR)/usr/share/man/man1
++
++install-testdata: testdata
+   install -d $(DESTDIR)/usr/share/jbigkit-testdata
+   install -m 644 examples/*.pgm examples/*.jbg pbmtools/test-t82.pbm 
$(DESTDIR)/usr/share/jbigkit-testdata
++
++install: install-lib install-pbm install-testdata
--- jbigkit-2.1/debian/patches/series
+++ jbigkit-2.1/debian/patches/series
@@ -5,3 +5,4 @@
 improve-upstream-Makefiles.diff
 create-testdata.diff
 pic-so.diff
+split-arch-indep.patch
--- jbigkit-2.1/debian/rules
+++ jbigkit-2.1/debian/rules
@@ -9,6 +9,18 @@
 
 pkg_run = jbigkit-bin
 
+override_dh_auto_build-arch:
+   dh_auto_build -- lib pbm
+
+override_dh_auto_build-indep:
+   dh_auto_build -- testdata
+
+override_dh_auto_install-arch:
+   $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install-lib install-pbm
+
+override_dh_auto_install-indep:
+   $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install-testdata
+
 override_dh_installman:
dh_installman -p$(pkg_run) debian/jbgtopbm85.1 debian/pbmtojbg85.1

Bug#1034291: snowball FTCBFS: fails running snowball compiler

Source: snowball
Version: 2.2.0-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

snowball fails to cross build from source, because it fails running the
built snowball compiler. The compiler is not installed anywhere and
produces source code as output. It should be built for the build
architecture rather than the host architecture. I'm attaching a patch
for your convenience.

Helmut
diff --minimal -Nru snowball-2.2.0/debian/changelog 
snowball-2.2.0/debian/changelog
--- snowball-2.2.0/debian/changelog 2022-10-18 18:07:33.0 +0200
+++ snowball-2.2.0/debian/changelog 2023-04-12 10:07:12.0 +0200
@@ -1,3 +1,11 @@
+snowball (2.2.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Build snowball compiler for the build architecture. (Closes:
+#-1)
+
+ -- Helmut Grohne   Wed, 12 Apr 2023 10:07:12 +0200
+
 snowball (2.2.0-2) unstable; urgency=medium
 
   * Bump Standards-Version to 4.6.1, no changes needed.
diff --minimal -Nru snowball-2.2.0/debian/rules snowball-2.2.0/debian/rules
--- snowball-2.2.0/debian/rules 2022-10-18 18:07:33.0 +0200
+++ snowball-2.2.0/debian/rules 2023-04-12 10:07:12.0 +0200
@@ -1,11 +1,13 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
 include /usr/share/dpkg/pkg-info.mk
 
 %:
dh $@
 
 override_dh_auto_build:
+   dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_build -- snowball
dh_auto_build -- $(shell dpkg-buildflags --export=configure)
 ifneq (,$(filter python3-snowballstemmer,$(shell dh_listpackages)))
$(MAKE) dist_libstemmer_python

Bug#1034290: bmap-tools: option --psplash is fully broken

2023-04-12 Thread Felix Moessbauer

Package: bmap-tools
Version: 3.6-2
Severity: normal

Dear Maintainer,

when using the option --psplash, the following error occurs:

  File "/usr/bin/bmaptool", line 11, in 
sys.exit(main())
 ^^
  File "/usr/lib/python3/dist-packages/bmaptools/CLI.py", line 725, in main
args.func(args)
  File "/usr/lib/python3/dist-packages/bmaptools/CLI.py", line 486, in 
copy_command
writer.set_psplash_pipe(args.psplash_pipe)
  File "/usr/lib/python3/dist-packages/bmaptools/BmapCopy.py", line 231, in 
set_psplash_pipe
if os.path.exists(pipe) and stat.S_ISFIFO(os.stat(pipe).st_mode):
  
NameError: name 'pipe' is not defined

The reason is a simple typo in the source code. Instead of "pipe",
"path" would be correct. An upstream patch is availabe in [1].

Best regards,
Felix Moessbauer
Siemens AG

[1] 
https://github.com/intel/bmap-tools/commit/06fa51d0270f84d9553c044bd7391f01459a70e8

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

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

Versions of packages bmap-tools depends on:
ii  python3  3.11.2-1+b1
ii  python3-six  1.16.0-4

Versions of packages bmap-tools recommends:
ii  bzip2 1.0.8-5+b1
ii  lzop  1.04-2
ii  xz-utils  5.4.1-0.2

Versions of packages bmap-tools suggests:
ii  lz41.9.4-1
ii  pbzip2 1.1.13-1
pn  pigz   
pn  python3-gpgme  
ii  unzip  6.0-28

-- no debconf information

Bug#1033900: closed by Sebastian Ramacher (unblock dkms)

2023-04-12 Thread Sebastian Ramacher

Control: reopen -1

On 2023-04-12 13:59:17 +0200, Andreas Beckmann wrote:
> Did you mean to unblock -8 #1034287 instead?

Yes, that mail went to the wrong bug.

Cheers

> 
> Andreas
> 

-- 
Sebastian Ramacher

Bug#1033900: closed by Sebastian Ramacher (unblock dkms)


Did you mean to unblock -8 #1034287 instead?

Andreas

Bug#1034213: arno-iptables-firewall: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> Package: arno-iptables-firewall
> Version: 2.1.1-7   
> Severity: serious
> Tags: sid bookworm
> User: debhel...@packages.debian.org
> Usertags: systemd-files-in-usr-bookworm
> 
> Dear Maintainer,
> 
> It seems that your package arno-iptables-firewall is shipping files 
> (.service, .socket or
> .timer) in /usr/lib/systemd/system.
[...]

It seems the package has manually written maintainer scripts (instead of
letting debhelper generating the proper code):

```
arno-iptables-firewall-2.1.1> grep -R deb-systemd-helper debian/
debian/postrm:  # Remove deb-systemd-helper's state file
debian/postrm:  deb-systemd-helper purge
arno-iptables-firewall.service
debian/postinst:deb-systemd-helper enable
arno-iptables-firewall.service
```

So while I think manually written maintscript code should be frowned
upon (since it's a very common source of bugs), I guess this means
this bug is not RC severity?!

Regards,
Andreas Henriksson

Bug#1030200: closed by Debian FTP Masters (reply to Salvatore Bonaccorso ) (Bug#1030200: fixed in linux 6.1.20-2)

2023-04-12 Thread наб

On Sat, Apr 08, 2023 at 03:57:10PM +, Debian Bug Tracking System wrote:
> Source: linux
> Source-Version: 6.1.20-2
> Done: Salvatore Bonaccorso 
Yep!

$ uname -a
Linux babtop 6.1.0-7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.20-2 (2023-04-08) 
x86_64 Linux
# keyctl list %:.builtin_trusted_keys
2 keys in keyring:
15714: ---lswrv 0 0 asymmetric: Debian Secure Boot CA: 
6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1
82694: ---lswrv 0 0 asymmetric: Debian Secure Boot Signer 2022 - 
linux: 14011249c2675ea8e5148542202005810584b25f
# keyctl list %:.platform
2 keys in keyring:
249704648: ---lswrv 0 0 asymmetric: Debian Secure Boot CA: 
6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1
121771219: ---lswrv 0 0 asymmetric: babtop.nabijaczleweli.xyz 
SecureBoot DB 2023: 00befacaa0
# keyctl list %:.secondary_trusted_keys
2 keys in keyring:
858292207: ---lswrv 0 0 keyring: .builtin_trusted_keys
1022385710: ---lswrv 0 0 keyring: .machine
# keyctl list %:.machine
keyring is empty
# certutil -L sql:secureboot -n 'babtop DB 2023' | grep -iA1 serial
Serial Number:
00:be:fa:ca:a0
$ zfs version
zfs-2.1.9-3
zfs-kmod-2.1.9-3

наб


signature.asc
Description: PGP signature

Bug#1034214: tcmu-runner: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> Package: tcmu-runner
> Version: 1.5.4-4   
> Severity: serious
> Tags: sid bookworm
> User: debhel...@packages.debian.org
> Usertags: systemd-files-in-usr-bookworm
> 
> Dear Maintainer,
> 
> It seems that your package tcmu-runner is shipping files (.service, .socket or
> .timer) in /usr/lib/systemd/system.
[...]

tcmu-1.5.4> grep -R systemd.system .
./debian/tcmu-runner.install:debian/tmp/usr/lib/systemd/system/tcmu-runner.service
./README.md:1. If using systemd, copy `org.kernel.TCMUService1.service` to 
`/usr/share/dbus-1/system-services/` and `tcmu-runner.service` to 
`/lib/systemd/system`.
./CMakeLists.txt:  install(FILES tcmu-runner.service DESTINATION 
/usr/lib/systemd/system/)

These paths are wrong and the culprit of this bug report.

You could change them to use the currently correct path, but then you
would have to revert that again after bookworm is released when the
paths will change again.

A better solution would derive the path from systemd.pc, eg.
pkg-config --variable=systemdsystemunitdir systemd

(Note: this needs pkg-config and systemd in build-deps)

Since the upstream build system is CMake, there are plenty of others
to look at of how to implement using pkg-config and querying the
variable in CMake.
This should give you atleast a few hits that could be possible
examples to follow:
https://codesearch.debian.net/search?q=systemdsystemunitdir+path%3ACMake=0
https://codesearch.debian.net/search?q=systemdsystemunitdir+path%3AFindSystemd=0

Regards,
Andreas Henriksson

Bug#1034215: drkonqi: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

Hello again,

On Wed, Apr 12, 2023 at 01:19:52PM +0200, Andreas Henriksson wrote:
> On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> > Package: drkonqi
> > Version: 5.27.2-1  
> > Severity: serious
> > Tags: sid bookworm
> > User: debhel...@packages.debian.org
> > Usertags: systemd-files-in-usr-bookworm
> > 
> > Dear Maintainer,
> > 
> > It seems that your package drkonqi is shipping files (.service, .socket or
> > .timer) in /usr/lib/systemd/system.
> [...]
> 
> ```
> $ apt-file show drkonqi | grep systemd/system
> drkonqi: /usr/lib/systemd/system/drkonqi-coredump-processor@.service
> ```

I forgot to mention that since this is a template unit (@.service)
maybe the severity should not be RC.
As far as I know debhelper will not enable any instance of a template
unit by default anyway, so the consequences that bigon warned about
probably doesn't apply here?


> 
> From ./src/coredump/processor/CMakeLists.txt :
> 
> ```
> configure_file(
> drkonqi-coredump-processor@.service.cmake
> ${CMAKE_CURRENT_BINARY_DIR}/drkonqi-coredump-processor@.service
> )
> install(
> FILES ${CMAKE_CURRENT_BINARY_DIR}/drkonqi-coredump-processor@.service
> DESTINATION ${KDE_INSTALL_SYSTEMDUNITDIR}/system
> )
> ```
> 
> So apparently KDE_INSTALL_SYSTEMDUNITDIR is not set correctly.
> 
> I'm not sure where this variable comes from. The above line is the
> only hit on
> https://codesearch.debian.net/search?q=KDE_INSTALL_SYSTEMDUNITDIR=1
> 
> Maybe someone with better understanding of KDE and CMake can help figure this 
> out.
> 
> If not, I guess you can always add a hack that appends to dh_install to move
> the file into the correct directory as returned by
> `pkg-config --variable=systemdsystemunitdir systemd`.
> (Note: make sure to have systemd.pc available by build-dep on systemd)
 
 
Regards,
Andreas Henriksson

Bug#1034215: drkonqi: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> Package: drkonqi
> Version: 5.27.2-1  
> Severity: serious
> Tags: sid bookworm
> User: debhel...@packages.debian.org
> Usertags: systemd-files-in-usr-bookworm
> 
> Dear Maintainer,
> 
> It seems that your package drkonqi is shipping files (.service, .socket or
> .timer) in /usr/lib/systemd/system.
[...]

```
$ apt-file show drkonqi | grep systemd/system
drkonqi: /usr/lib/systemd/system/drkonqi-coredump-processor@.service
```

>From ./src/coredump/processor/CMakeLists.txt :

```
configure_file(
drkonqi-coredump-processor@.service.cmake
${CMAKE_CURRENT_BINARY_DIR}/drkonqi-coredump-processor@.service
)
install(
FILES ${CMAKE_CURRENT_BINARY_DIR}/drkonqi-coredump-processor@.service
DESTINATION ${KDE_INSTALL_SYSTEMDUNITDIR}/system
)
```

So apparently KDE_INSTALL_SYSTEMDUNITDIR is not set correctly.

I'm not sure where this variable comes from. The above line is the
only hit on
https://codesearch.debian.net/search?q=KDE_INSTALL_SYSTEMDUNITDIR=1

Maybe someone with better understanding of KDE and CMake can help figure this 
out.

If not, I guess you can always add a hack that appends to dh_install to move
the file into the correct directory as returned by
`pkg-config --variable=systemdsystemunitdir systemd`.
(Note: make sure to have systemd.pc available by build-dep on systemd)

Regards,
Andreas Henriksson

Bug#1034289: inkscape: canvas stops updating completely when trying to edit a text box

2023-04-12 Thread Giuseppe Bilotta

Package: inkscape
Version: 1.2.2-2+b1
Severity: serious

Adding or editing a text box causes the canvas to stop updating
altogether. Writing, selecting, etc still works, but the canvas does not
refresh anymore until Inkscape is closed and reopened.
This is also with the Preferences > Rendering > Update strategy
set to "Full redraw".



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

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

Versions of packages inkscape depends on:
ii  lib2geom1.2.0  1.2.2-3
ii  libatkmm-1.6-1v5   2.28.3-1
ii  libboost-filesystem1.74.0  1.74.0+ds1-20
ii  libc6  2.36-9
ii  libcairo-gobject2  1.16.0-7
ii  libcairo2  1.16.0-7
ii  libcairomm-1.0-1v5 1.14.4-2
ii  libcdr-0.1-1   0.1.6-2+b2
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   2.12.1+dfsg-4
ii  libgc1 1:8.2.2-3
ii  libgcc-s1  12.2.0-14
ii  libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1
ii  libglib2.0-0   2.74.6-2
ii  libglibmm-2.4-1v5  2.66.5-2
ii  libgomp1   12.2.0-14
ii  libgsl27   2.7.1+dfsg-3+b1
ii  libgspell-1-2  1.12.0-1+b2
ii  libgtk-3-0 3.24.37-2
ii  libgtkmm-3.0-1v5   3.24.7-1
ii  libharfbuzz0b  6.0.0+dfsg-3
ii  libjpeg62-turbo1:2.1.5-2
ii  liblcms2-2 2.14-2
ii  libmagick++-6.q16-88:6.9.11.60+dfsg-1.6
ii  libpango-1.0-0 1.50.12+ds-1
ii  libpangocairo-1.0-01.50.12+ds-1
ii  libpangoft2-1.0-0  1.50.12+ds-1
ii  libpangomm-1.4-1v5 2.46.3-1
ii  libpng16-161.6.39-2
ii  libpoppler-glib8   22.12.0-2+b1
ii  libpoppler126  22.12.0-2+b1
ii  libpotrace01.16-2
ii  libreadline8   8.2-1.3
ii  librevenge-0.0-0   0.0.5-3
ii  librsvg2-common2.54.5+dfsg-1
ii  libsigc++-2.0-0v5  2.12.0-1
ii  libsoup2.4-1   2.74.3-1
ii  libstdc++6 12.2.0-14
ii  libvisio-0.1-1 0.1.7-1+b3
ii  libwpg-0.3-3   0.3.3-1
ii  libx11-6   2:1.8.4-2
ii  libxml22.9.14+dfsg-1.1+b3
ii  libxslt1.1 1.1.35-1
ii  python33.11.2-1+b1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages inkscape recommends:
ii  aspell   0.60.8-4+b1
ii  fig2dev  1:3.2.8b-3
ii  imagemagick  8:6.9.11.60+dfsg-1.6
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.6
ii  imagemagick-7 [imagemagick]  8:7.1.1.6-dmo1
ii  libimage-magick-perl 8:6.9.11.60+dfsg-1.6
ii  libwmf-bin   0.2.12-5
ii  python3-cssselect1.2.0-2
ii  python3-lxml 4.9.2-1+b1
ii  python3-numpy1:1.24.2-1
ii  python3-scour0.38.2-2

Versions of packages inkscape suggests:
ii  dia   0.97.3+git20220525-5
pn  inkscape-tutorials
pn  libsvg-perl   
ii  pstoedit  3.78-2
ii  python3-packaging 23.0-1
pn  python3-uniconvertor  
ii  ruby  1:3.1

-- no debconf information

Bug#1034286: RFP: ffmpeg-python -- Python bindings for FFmpeg with complex filtering support



block 1034091 by 1034286
thanks

Gave Whisper dependency its own WNPP request.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1034288: RM: igdiscover/0.11-3

2023-04-12 Thread Andreas Tille

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-Cc: igdisco...@packages.debian.org, 1032...@bugs.debian.org, 
steffen_moel...@gmx.de
Control: affects -1 + src:igdiscover

According to bug #1032975 the package is non-functional and should not
be released with bookworm.

My last response to the bug report has refreshed the autoremoval timer
which is not needed.  Please remove the package from testing to clean up
the release status.

Thanks a lot for your work on the Debian release
   Andreas.

Bug#1034287: unblock: dkms/3.0.10-8

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package dkms

[ Reason ]
Lots of bugfixes, especially a behavioral regression from bullseye
(inconsistent success/failure depending of the installation order of
foo-dkms and linux-headers-something).

[ Impact ]
Currently there are some unneccessary dkms-related upgrade failures.
(This does not intend to fix kernel postinst aka dkms failing due to
(third-party) dkms modules incompatible with newer kernels. That is not
a regression. All *-dkms packages in bookworm are compatible with the
kernels in bookworm and make use of Testsuite: autopkgtest-pkg-dkms)

[ Tests ]
Most of the patches are cherry-picked from upstream or waiting to be
merged upstream.
Most fixes also have tests added to the upstream testsuite, stripped
while cherry-picking since they depend on additional testing
infrastructure improvements.
For improving the autopkgtest coverage of dkms in Debian CI see
dkms 3.0.10-9 in experimental and #1033900.

[ Risks ]
dkms has been neglected for too long ...
It's quite possible that further improved testing will uncover more bugs
that have been lingering around. Since I've dug into codebase now, I
should be able attempt fixing more ...

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
Once all my fixes (and most of the other patches we carry) got merged
upstream, I'll try to get a new upstream release and upload that s.t.
we get even more fixes and the improved testsuite.

unblock dkms/3.0.10-8

+dkms (3.0.10-8) unstable; urgency=medium
+
+  * Disable tests broken by fix-builtin-archive-dkms-coinstallation.patch.
+(Closes: #1033396)
+  * Run autopkgtest for all architectures using the headers from the
+linux-headers-generic (virtual) meta-package.
That virtual package does not exist on armel, I'll add an alternative
test dependency for armel in the next upload.

+  * Generate dh_dkms.1 at build time.
+  * Clean up /boot/*.old-dkms on upgrades from bullseye.  (Closes: #717584)
+  * Clean up obsolete /etc/dkms/sign_helper.sh on upgrades. (Closes: #1019563)
+  * dkms-autopkgtest: Try to 'dkms install' its BUILD_DEPENDS before testing a
+module. (Single level only, without recursion.)
This fixes an autokgtest regression in src:nvidia-cuda-samples (on
behalf of src:nvidia-cuda-toolkit which cannot have autopkgtests on its
own due to the size of the source package).
nvidia-fs-dkms is the only package in the archive using BUILD_DEPENDS in
its dkms.conf and I only recently fixed its support for the bookworm kernel.

+  * Fix fallback value for BUILD_MODULE_NAME[0].  (Closes: #651973)
+  * dkms.8: Clarify 'dkms add' arguments.  (Closes: #704917)
+  * Print a warning if /proc is not mounted.  (Closes: #810665, #968074)
+  * dkms_autoinstaller: Skip autoinstall if headers are missing (like
+dkms_common.postinst).  (Closes: #1030595)
+  * Use return code 77 if skipping due to BUILD_EXCLUSIVE_*.
This caused some regression in Ubuntu since some script (not present in
Debian) expected to old return code.

+  * Sort kernels by version.
+
+ -- Andreas Beckmann   Fri, 31 Mar 2023 14:01:26 +0200
+
+dkms (3.0.10-7) unstable; urgency=medium
+
+  [ Dimitri John Ledkov ]
+  * Fix release regression preventing co-installing in-archive dkms
+packages with kernels that built-in identical or newer versions of the
+same dkms package. LP: #2008269
+
+ -- Gianfranco Costamagna   Wed, 22 Mar 2023 
00:02:08 +0100


Andreas


dkms-3.0.10-8.diff.gz
Description: application/gzip

Bug#1034216: boinc-client: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> Package: boinc-client
> Version: 7.20.5+dfsg-1
> Severity: serious
> Tags: sid bookworm
> User: debhel...@packages.debian.org
> Usertags: systemd-files-in-usr-bookworm
> 
> Dear Maintainer,
> 
> It seems that your package boinc-client is shipping files (.service, .socket 
> or
> .timer) in /usr/lib/systemd/system.
[...]

So the package already contains this patch:
./debian/patches/systemd-directory.patch

 where the (currently) wrong path is used.

Simply updating the patch would work, but then would have to be reverted
again once it's changed in the future (after bookworm release).

A better solution would be to use pkg-config and query systemd.pc
for the correct path, eg.
pkg-config --variable=systemdsystemunitdir systemd

Note: that this needs systemd.pc to be available, thus you'll need to
build-depend on the systemd package (as you already list
pkg-config in build-deps).

Regards,
Andreas Henriksson

Bug#1034026: podman-docker: missing /usr/share/user-tmpfiles.d/podman-docker.conf

2023-04-12 Thread Reinhard Tartler

Control: tag -1 help

On Thu, Apr 6, 2023 at 2:06 PM Scott Edlund  wrote:

> podman-docker.conf was configured for use with rootless podman starting
> in 4.3.0rc1 .   Please install the tmpfiles configuration also in
> user-tmpfiles.
>
> See
>
> https://github.com/containers/podman/commit/b47c54ab69d56f05bc586e443d04fe572de8ff8f
>
>
It seems that dh_installtmpfiles(1) does not take care of that, I hoped
that it would.

I'm struggling to find out what's the right debhelper to use here. Any
suggestions on
how to modify
https://salsa.debian.org/debian/libpod/-/tree/debian/sid/debian in
the most elegant way?

-rt

-- 
regards,
Reinhard

Bug#1033058: Booting mini.iso : kernel hangs on ppc64el

2023-04-12 Thread Frédéric Bonnard

Thank you so much Cyril!

> That being said, we don't have all modules shipped in the installer, and
> some other module might be available and used in the installed system
> (e.g. dedicated driver as opposed to fbdev during a graphical install on
> amd64), which can explain differences. The bootloader configuration
> might be different too.
> 
> As you suggested, this is a regression via a7f0ec26cd, first shipped in
> v6.1.12, which didn't account for the disappearing of-display device
> node in the framebuffer driver. I've tested a trivial patch (see MR)
> and a netboot mini.iso d-i build (similar to daily builds, against udebs
> from unstable) gives me the installer's interface. Available for 15 days
> at: https://people.debian.org/~kibi/bug-1033058/
> 
> I'll open a bug report upstream and submit my patch there. In mainline
> master, another module (not found in 6.1.y) is affected as well, so I
> have this queued up too (but untested):

Excellent!
I was worried seeing the issue coming in rc1 of Bookworm
but also in latest snapshots of Ubuntu 23.04 ( I also
pointed Canonical to this bug and your proposed fix :
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2015994 ).

F.


signature.asc
Description: PGP signature

Bug#1031694: Libxisf in kde neon

2023-04-12 Thread Dušan Poizl


Hi,

great. Can I copy this when I will package it for Debian? 
https://salsa.debian.org/debian-astro-team/libxisf


Thanks.

Dňa 12. 4. 2023 o 4:00 Carlos De Maine napísal(a):


Hi


I've packaged this in KDE neon so that Kstars and indi can utilise it.


https://invent.kde.org/neon/neon-packaging/libxisf


It should hit the archives later today.


Cheers

Carlos

Bug#1033826: podman: Cannot load gzip compressed images

2023-04-12 Thread Reinhard Tartler

On Wed, Apr 12, 2023 at 6:41 AM Reinhard Tartler  wrote:

> Control: reassign -1 golang-github-klauspost-pgzip 1.2.5-2
> Control: affects -1 libpod
> Control: forwarded -1 https://github.com/containers/podman/issues/15944
> Control: severity -1 important
>
>
I've prepared an MR for this at
https://salsa.debian.org/go-team/packages/golang-github-klauspost-pgzip/-/merge_requests/4

I'm looking for opinions whether this code change is appropriate for
bookwork at this point.

Best,
-rt

-- 
regards,
Reinhard

Bug#1034286: RFP: ffmpeg-python -- Python bindings for FFmpeg with complex filtering support



Package: wnpp
Severity: wishlist

  Package name: ffmpeg-python
  Version : 0.2.0
  Upstream Author : Karl Kroening 
  URL : https://github.com/kkroening/ffmpeg-python
  License : Apache-2.0
  Programming Lang: Python
  Description : Python bindings for FFmpeg with complex filtering support

This is a simple python library used by OpenAI Whisper to load audio
files into its speech recognision system.  Upstream seem to be inactive.

I have created draft packaging rules in
https://salsa.debian.org//pere/ffmpeg-python.git >.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1034285: mirror listing update for linux.purple-cat.net

2023-04-12 Thread Mike Hosken

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: linux.purple-cat.net
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Mike Hosken 
Country: NZ New Zealand
Location: Dunedin 
Sponsor: Unifone NZ https://unifone.net.nz/
Comment: Updated information as not on list anymore. Ip address has changed. 
Also full Debian ports repo on debian-ports and Debian archive on debian-archive




Trace Url: http://linux.purple-cat.net/debian/project/trace/
Trace Url: 
http://linux.purple-cat.net/debian/project/trace/ftp-master.debian.org
Trace Url: http://linux.purple-cat.net/debian/project/trace/linux.purple-cat.net

Bug#1034091: RFP: whisper -- Robust Speech Recognition via Large-Scale Weak Supervision

[Petter Reinholdtsen]
> I created a draft build setup for tiktoken in
> https://salsa.debian.org/pere/tiktoken >.  It currently build but
> I am not convinced it is working.

The repository has been moved to
https://salsa.debian.org/deeplearning-team/tiktoken >.
I have also started on packaging for triton, which is available from
https://salsa.debian.org/deeplearning-team/triton >.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1033826: podman: Cannot load gzip compressed images

2023-04-12 Thread Reinhard Tartler

Control: reassign -1 golang-github-klauspost-pgzip 1.2.5-2
Control: affects -1 libpod
Control: forwarded -1 https://github.com/containers/podman/issues/15944
Control: severity -1 important

Hi Antonio,

Thanks for your report.

I've looked through the source code, and while the exact error message
doesn't exactly match, I did confirm that the current debian/sid podman is
indeed built with golang 1.19, and uses an older version of
klauspost/pgzip that doesn't have that code change from
https://github.com/klauspost/pgzip/pull/50. I'd argue it is necessary for
golang 1.19.

In order to fix this, the code change needs to go into pgzip and libpod
needs to be rebuilt.

-rt

On Sun, Apr 2, 2023 at 6:51 AM Antonio Cebrián  wrote:

> Package: podman
> Version: 4.3.1
>
>
> Podman cannot load images compressed with gzip. Uncompressed images or
> bzip2 compressed images work right therefore it seems to be a problem
> related to gzip handling.
>
> It seems to be the same problem reported here:
>
> https://github.com/containers/podman/issues/15944
>
>
> Tested under Bookworm with podman 4.3.1:
>
> *$ podman image pull hello-world:latest*
> Resolved "hello-world" as an alias
> (/etc/containers/registries.conf.d/shortnames.conf)
> Trying to pull docker.io/library/hello-world:latest...
> Getting image source signatures
> Copying blob 2db29710123e done
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
> feb5d9fea6a5e9606aa995e879d862b825965ba48de054caab5ef356dc6b3412
>
> *$ podman image save hello-world:latest > hello-world.tar*
>
> *$ podman image save hello-world:latest | gzip > hello-world.tar.gz*
>
> *$ podman image save hello-world:latest | bzip2 > hello-world.tar.bz2*
>
> *$ podman image load -i hello-world.tar*
> Getting image source signatures
> Copying blob e07ee1baac5f skipped: already exists
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
> Loaded image: docker.io/library/hello-world:latest
>
> *$ podman image load -i hello-world.tar.gz*
> Error: payload does not match any of the supported image formats:
>  * oci: initializing source oci:hello-world.tar.gz:: open
> hello-world.tar.gz/index.json: not a directory
>  * oci-archive: loading index: open /var/tmp/oci3062655986/index.json: no
> such file or directory
>  * docker-archive: loading tar component manifest.json: unexpected EOF
>  * dir: open hello-world.tar.gz/manifest.json: not a directory
>
> *$ podman image load -i hello-world.tar.bz2*
> Getting image source signatures
> Copying blob e07ee1baac5f skipped: already exists
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
> Loaded image: docker.io/library/hello-world:latest
>
>
> Attached you have the debug output of the failing command:
>
> *$ podman --debug image load -i hello-world.tar.gz*
>
>
> In Bullseye with podman 3.0.1 all works as expected:
>
> *$ podman image pull hello-world:latest*
> Resolved "hello-world" as an alias
> (/etc/containers/registries.conf.d/shortnames.conf)
> Trying to pull docker.io/library/hello-world:latest...
> Getting image source signatures
> Copying blob 2db29710123e done
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
> feb5d9fea6a5e9606aa995e879d862b825965ba48de054caab5ef356dc6b3412
>
> *$ podman image save hello-world:latest > hello-world.tar*
> Copying blob e07ee1baac5f done
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
>
> *$ podman image save hello-world:latest | gzip > hello-world.tar.gz*
> Copying blob e07ee1baac5f done
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
>
> *$ podman image save hello-world:latest | bzip2 > hello-world.tar.bz2*
> Copying blob e07ee1baac5f done
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
>
> *$ podman image load -i hello-world.tar*
> Getting image source signatures
> Copying blob e07ee1baac5f [--] 0.0b /
> 0.0b
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
> Loaded image(s): docker.io/library/hello-world:latest
>
> *$ podman image load -i hello-world.tar.gz*
> Getting image source signatures
> Copying blob e07ee1baac5f skipped: already exists
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
> Loaded image(s): docker.io/library/hello-world:latest
>
> *$ podman image load -i hello-world.tar.bz2*
> Getting image source signatures
> Copying blob e07ee1baac5f [--] 0.0b /
> 0.0b
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
> Loaded image(s): docker.io/library/hello-world:latest
>
>
> Best regards.
>
>

-- 
regards,
Reinhard

Bug#1034284: unblock: wheel/0.38.4-2

2023-04-12 Thread Stefano Rivera

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: wh...@packages.debian.org
Control: affects -1 + src:wheel

Please unblock package wheel

Fixed an RC bug: The source package wasn't cleaning correctly.

[ Reason ]
RC Bug fix.

[ Impact ]
Stable will ship with the source-level RC bug.

[ Tests ]
Verified by hand.

[ Risks ]
Change is trivial.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock wheel/0.38.4-2
diff -Nru wheel-0.38.4/debian/changelog wheel-0.38.4/debian/changelog
--- wheel-0.38.4/debian/changelog   2022-11-10 06:24:48.0 -0400
+++ wheel-0.38.4/debian/changelog   2023-04-11 14:10:59.0 -0400
@@ -1,3 +1,9 @@
+wheel (0.38.4-2) unstable; urgency=medium
+
+  * Correctly clean. (Closes: #1034079)
+
+ -- Stefano Rivera   Tue, 11 Apr 2023 14:10:59 -0400
+
 wheel (0.38.4-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru wheel-0.38.4/debian/clean wheel-0.38.4/debian/clean
--- wheel-0.38.4/debian/clean   2022-11-10 06:24:48.0 -0400
+++ wheel-0.38.4/debian/clean   2023-04-11 14:10:59.0 -0400
@@ -1 +1,6 @@
-docs/_build
+.tox/
+dist/
+docs/_build/
+src/*.egg-info/
+tests/testdata/*/*.egg-info/
+tests/testdata/*/build/

Bug#1033058: Booting mini.iso : kernel hangs on ppc64el

2023-04-12 Thread Cyril Brulebois

Cyril Brulebois  (2023-04-12):
> I'll open a bug report upstream and submit my patch there.

Upstream bug:
  https://bugzilla.kernel.org/show_bug.cgi?id=217328

> In mainline master, another module (not found in 6.1.y) is affected as well,
> so I have this queued up too (but untested):
> 
>  drivers/gpu/drm/tiny/ofdrm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

If you have a way to confirm ofdrm is broken without the patch and fixed
with the patch, please speak up!

Upstream patches:
  https://lore.kernel.org/all/20230412095509.2196162-1-cy...@debamax.com/T/#u


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1033900: pre-approval: dkms/3.0.10-10