Bug#1059511: pocl: FTBFS on riscv64: testsuite fails: can't link double-float modules with soft-float modules

[Bo YU]

Source: pocl
Version: 5.0-1
Followup-For: Bug #1059511

I cost some time to try to fix the issue, progress is below.

Inspired by the commit:
https://github.com/pocl/pocl/issues/1088#issue-1340373438

If i build pocl by manual if follow:

```
cmake .. 
 -DCMAKE_INSTALL_PREFIX='/usr' 
 -DCMAKE_BUILD_TYPE='Debug' 
 -DPOCL_DEBUG_MESSAGES=ON
 -DLLC_HOST_CPU='sifive-u54'
```

Then there are four test failed:

```
98% tests passed, 4 tests failed out of 263

Label Time Summary:
EinsteinToolkit= 190.88 sec*proc (2 tests)
cuda   = 279.87 sec*proc (42 tests)
dlopen =   0.52 sec*proc (3 tests)
hsa=  35.00 sec*proc (4 tests)
hsa-native = 1127.40 sec*proc (82 tests)
internal   = 3317.43 sec*proc (256 tests)
kernel = 1719.95 sec*proc (76 tests)
level0 = 1446.25 sec*proc (124 tests)
matrix =  40.41 sec*proc (4 tests)
poclbin=  38.95 sec*proc (4 tests)
proxy  = 327.09 sec*proc (36 tests)
regression = 933.17 sec*proc (95 tests)
runtime= 179.38 sec*proc (31 tests)
tce=  69.97 sec*proc (9 tests)
vulkan = 176.65 sec*proc (26 tests)
workgroup  = 472.82 sec*proc (31 tests)

Total Test time (real) = 3791.39 sec

The following tests did not run:
 62 - kernel/test_shuffle_half_loopvec (Skipped)
 63 - kernel/test_shuffle_half_cbs (Skipped)
190 - runtime/clGetKernelArgInfo (Disabled)
199 - runtime/test_buffer_migration (Skipped)
200 - runtime/test_buffer_ping_pong (Skipped)

The following tests FAILED:
 76 - kernel/test_printf_vectors_loopvec (Failed)
 77 - kernel/test_printf_vectors_cbs (Failed)
 78 - kernel/test_printf_vectors_ulongn_loopvec (Failed)
 79 - kernel/test_printf_vectors_ulongn_cbs (Failed)
Errors while running CTest
```

Obviously these tests failed was due to vectors missing from riscv64
now. This is expected I think.

The result is aligned with pocl upstream support riscv64:

```
In this release we improved support for RISC-V CPUs. We tested PoCL on a 
Starfive VisionFive 2 using a Ubuntu 23.10 preinstalled image. With LLVM 17 and 
GCC 13.2, 98% tests pass (only 4 tests fail out of 253).

```
http://portablecl.org/docs/html/notes_5_0.html#risc-v-cpu-support-improved

If glance at the buildd log from riscv64:

```
-- udivmodti4 compiles without extra flags
-- Checking if LLVM is a DEBUG build
-- DEBUG build
-- Find out LLC target triple (for host riscv64-unknown-linux-gnu)
-- Find out LLC host CPU with /usr/bin/llc-15
-- Autodetected CPU sifive-u74 overridden by user to GENERIC
-- Checking clang -march vs. -mcpu flag
--   Using -None=
-- Running LLVM link test
-- LLVM link test OK
```
https://buildd.debian.org/status/fetch.php?pkg=pocl=riscv64=5.0-1=1704805199=0

So I suspect the `LLC_HOST_CPU='` was overriden by `GENERIC` then the
ABI was different. I will look at this more deeper.

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1061097: pam: CVE-2024-22365: pam_namespace: protect_dir(): use O_DIRECTORY to prevent local DoS situations

[Salvatore Bonaccorso]

Source: pam
Version: 1.5.2-9.1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.5.2-6+deb12u1
Control: found -1 1.5.2-6
Control: found -1 1.4.0-9+deb11u1
Control: found -1 1.4.0-9

Hi,

The following vulnerability was published for pam.

CVE-2024-22365[0]:
| pam_namespace: protect_dir(): use O_DIRECTORY to prevent local DoS
| situations

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-22365
https://www.cve.org/CVERecord?id=CVE-2024-22365
[1] 
https://github.com/linux-pam/linux-pam/commit/031bb5a5d0d950253b68138b498dc93be69a64cb
[2] https://github.com/linux-pam/linux-pam/releases/tag/v1.6.0

Regards,
Salvatore

Bug#1061096: bullseye-pu: package ruby-aws-sdk-core/3.104.3-3+deb11u1

[Vivek K J]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ruby-aws-sdk-c...@packages.debian.org
Control: affects -1 + src:ruby-aws-sdk-core


[ Reason ]

The oldstable version of ruby-aws-sdk-core isn't shipping the necessary VERSION
file which is required for the functionality of this package. This proposed
update is aiming to fix that bug (See: #1035389)

[ Impact ]

If the update isn't approved, the package will be unusable in bullseye

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

[ Changes ]

--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ruby-aws-sdk-core (3.104.3-3+deb11u2) bullseye; urgency=medium
+
+  * Team upload.
+  * Include VERSION file in package (Closes: #1035389)
+
+ -- Vivek K J   Thu, 18 Jan 2024 12:05:59 +0530
+
 ruby-aws-sdk-core (3.104.3-3+deb11u1) bullseye; urgency=medium
 
   * Team upload.
diff --git a/debian/rules b/debian/rules
index 8650938..3d8535e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,8 @@
 #!/usr/bin/make -f
 
 export GEM2DEB_TEST_RUNNER = --check-dependencies
-export VERSION = $(cat ../VERSION)
+export DH_RUBY = --gem-install
+
 
 %:
dh $@ --buildsystem=ruby --with ruby

Bug#1057180: Info received (bullseye-pu: package mariadb-10.5 1:10.5.23-0+deb11u1)

[Paul Gevers]

Hi,

On 18-01-2024 05:50, Otto Kekäläinen wrote:

Hi oldstable release managers,


(I'm not one of them).


I got email after my upload 11 days ago that 10.5.23 was accepted in
oldstable-proposed-updates but I don't see any updates under 'News' at
https://tracker.debian.org/pkg/mariadb-10.5 yet.

Is the update progressing automatically somewhere?


Neither https://release.debian.org/proposed-updates/oldstable.html 
refers it as being accepted nor does rmadison know about it (except in NEW):


paul@mulciber ~ $ rmadison mariadb-10.5
mariadb-10.5 | 1:10.5.21-0+deb11u1 | oldstable   | source
mariadb-10.5 | 1:10.5.21-0+deb11u1 | oldstable-debug | source
mariadb-10.5 | 1:10.5.23-0+deb11u1 | oldstable-new   | source

I also can't find the mail you refer to in my Trash folder.

Nor can I find an comments file in 
elbrus@coccia:/home/release/www/proposed-updates/bullseye_comments


Can you share the mail you are talking about?

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061062: prusa-slicer: Impossible to use Gcode produced by prusa-slicer on Ender 3 S1 Pro

[Chow Loong Jin]

On Wed, Jan 17, 2024 at 09:30:47AM +0100, mathis wrote:
> Package: prusa-slicer
> Version: 2.5.0+dfsg-4
> Severity: normal
> X-Debbugs-Cc: joussemetmat...@gmail.com
> 
> Dear Maintainer,
> -- Expected Scenario:
> Ender 3 S1 reads the Gcode
> 
> --Outcome of the actions:
> I tried many times to export directly the gcode to the sd, export it and then
> copy it to the sd, but non worked.
> Gcode produced in prusa-slicer 2.50 and cannot be used on my Ender 3 S1 Pro.
> 
> --Resolution
> The problem has already been acknoledged
> (https://github.com/prusa3d/PrusaSlicer/issues/8883) and has been fixed in
> upstream.
> Could you please update the version in stable to allow to overcome
> this bug?

Hi mathis,

Reading through the bug report, I think there isn't actually a patch
that I can backport into Debian. It looks like it's pushed out as a
configuration update, which you should be able to get from the
`Configuration > Check for configuration updates` menu item.

-- 
Kind regards,
Loong Jin


signature.asc
Description: PGP signature

Bug#1061093: ironseed: please add support for loong64

[Matija Nalis]

Hi wuruilong,

Thanks for reporting! 

Just to confirm, you've tried compiling and running it, and it works on 
loong64 architecture?

On Thu, Jan 18, 2024 at 01:42:19AM +, wuruilong wrote:
> Source: ironseed
> Severity: normal
> X-Debbugs-Cc: wuruil...@loongson.cn
> 
> Dear Maintainer,
> 
> Please modify the file to support the loong64 architecture, the content is as 
> follows:
> debian/tests/control:2:Architecture: amd64 arm64 armel armhf i386 loong64 
> mipsel mips64el ppc64el kfreebsd-amd64 kfreebsd-i386 riscv64
> debian/control:23:Architecture: amd64 arm64 armel armhf i386 loong64 mipsel 
> mips64el ppc64el kfreebsd-amd64 kfreebsd-i386 riscv64
> 
> wuruilong
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unreleased
>   APT policy: (500, 'unreleased'), (500, 'unstable')
> Architecture: loong64 (loongarch64)
> 
> Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect
> 

-- 
Opinions above are GNU-copylefted.

Bug#797956: Please Confirm Your Email Here ⬅️

[Brazzers]

#

One More Thing...

Click below to verify your email

CONFIRM EMAIL
#

STAY IN TOUCH AND FOLLOW US

http://trackog.theportalnetworks.com/?xtl=qc0hcjq5b333hsy8039gg39g90k09z63hfbbm32mbstpgvt70nw3hib436th9ivibg0k1bdthk0nmc2p6o9optk94iu1ondfj1a5w4i6n9k004jwlmkjfp0nltbd6vf2ljt&__ott=-x38bjxhvdoov&__stmp=s7fsc0=9276orlzjoxch2y7kz35d3ks8ybz1a1xyi2

http://trackog.theportalnetworks.com/?xtl=4qgdh7h7vudx1o9z5jqeiq7ny3if7dwslgp5indm0vcvgyq7jqkxyiwpq9eq0326sg5n84p481qn5fdxwxvgvy2rodl6azpr0q83jcfx89ogq3ss4s4dl2tmu99ocehv1uyj3vjo1781y468sd74johtd&__ott=-x38bjxhvdoov&__stmp=s7fsc0=9276orlzjoxch2y7kz35d3ks8ybz1a1xyi2
  

 This email and the discounted rate above is intended to be sent to 
797...@bugs.debian.org.
  You are receiving this email because your account has expired and is no 
longer active.

If you would prefer to no longer receive any future exclusive scene previews or 
updates from us, then you can follow the link below to break our hearts and 
unsubscribe.

Unsuscribe
http://trackog.theportalnetworks.com/?xul=4bh56at500lkynswz4kz3nutpy9m0i1blaaynkyi7yolgh1iwoyihhudg2tthwhtr5fws114fhyel6pqa73hewp4bgqffir2jh3qcj5h16syqxl&__ott=-x38bjxhvdoov&__stmp=s7fsc0=9276orlzjoxch2y7kz35d3ks8ybz1a1xyi2

 Our business address is:
 MG Billing US Corp, 21800 Oxnard, Suite 150, Woodland Hills, CA 91367, USA
 MG Billing Limited, 195-197 Old Nicosia-Limassol Road, Dali Industrial Zone 
2540, Block 1, Cyprus

Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

[Steve Langasek]

Hi Colin,

On Tue, Jan 09, 2024 at 01:32:11PM +, Colin Watson wrote:
> On Mon, Jan 08, 2024 at 03:01:11PM -0800, Steve Langasek wrote:
> > On Fri, Jan 05, 2024 at 09:17:52PM +0100, Paul Gevers wrote:
> > > On 05-01-2024 17:36, Rene Engelhard wrote:
> > > > Also a problem is that experimental also might already contain totally
> > > > unrelated updates like new upstream versions...

> > > I share this worry. Have you thought about how to handle the cases where 
> > > you
> > > don't have experimental to upload to? How big is this problem?



> In the current situation, though, not having experimental available
> means that there's no opportunity for dumat to weigh in regarding
> usrmerge interactions, which seems problematic given Helmut's
> preliminary analysis.

I guess this is a reply to the bits of context I retained above rather than
directly a reply to my most immediate preceding message.  In a separate
subthread, I laid out what I thought the process should be for handling the
transition of packages in that situation; but you are raising a separate
point.

Which parallels what Helmut had to say:

> Whenever you face files in aliased locations (other than systemd units),
> please go via experimental to let dumat judge your upload.  Check the
> bookworm package for files in aliased locations, not the unstable one.

I have also had other out-of-band conversations with Helmut about the
overlapping issues between usrmerge and time_t, so this was generally
speaking on my radar although I didn't address it in my proposed transition
plan.

I think it is unrealistic to ask experimental to be otherwise quiesced of
transitions to ensure that we can stage all of the affected libraries in
experimental, and I also think that making false transitions for packages
that are ALREADY in experimental because of transitions would be
counterproductive. ("False" because if the library package has a different
soname between unstable and experimental, then renaming the runtime library
package in the *experimental* version is unnecessary because there's nothing
"in the wild" depending on that package name but with the old ABI for which
upgrade compatibility is of concern.)

My preferred path forward here would be, as Helmut suggests, to check which
libraries are in the intersection of (packages in experimental for which we
won't stage time_t uploads) and (packages that exist in bookworm and need
transitioning of aliased paths), and ensure that these packages are handled
carefully according to Helmut's own guidance.  My optimistic expectation is
that the intersection will be null, or nearly; but in any case I will bring
data.

And my proposal for checking that set, since we're only talking about
runtime library packages, is to check whether any of the contents of these
packages in bookworm match ^/lib - as a runtime library package NOT matching
this pattern, but matching a pattern for one of the other aliased
directories, would be something ...  special.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1060056: mariadb-server: mariadb-hotcopy fails for performance_schema and sys

[Otto Kekäläinen]

Control: forwarded -1 https://github.com/MariaDB/server/pull/2995

This will be fixed in Debian next month when MariaDB 10.11.7 releases

Bug#1057180: Info received (bullseye-pu: package mariadb-10.5 1:10.5.23-0+deb11u1)

[Otto Kekäläinen]

Hi oldstable release managers,

I got email after my upload 11 days ago that 10.5.23 was accepted in
oldstable-proposed-updates but I don't see any updates under 'News' at
https://tracker.debian.org/pkg/mariadb-10.5 yet.

Is the update progressing automatically somewhere?

Bug#1057507: Additional information

[tony mancill]

On Thu, Jan 18, 2024 at 01:49:44PM +1300, Vladimir Petko wrote:
>   Would it be possible to consider a merge request[1] that addresses this 
> issue?
>  [1] 
> https://salsa.debian.org/java-team/jackson-datatype-joda/-/merge_requests/2

Uploaded.  Thank you for the patch.

Bug#1057613: shed: FTBFS: error: invalid use of incomplete typedef ‘WINDOW’ {aka ‘struct _win_st’}

[Bo YU]

Source: shed
Followup-For: Bug #1057613

Hi,

Just fyi, MRs will fix the issue:
https://salsa.debian.org/pkg-security-team/shed/-/merge_requests

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1061095: linux-image-6.6.11-amd64: 2.5gbit USB device with r8152 chipset only does 100baset

[Russell Coker]

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

[51076.208113] r8152-cfgselector 2-1: reset SuperSpeed USB device number 6 
using xhci_hcd
[51076.236596] r8152 2-1:1.0: firmware: direct-loading firmware 
rtl_nic/rtl8156b-2.fw
[51076.258622] r8152 2-1:1.0: ram code speedup mode fail
[51076.258647] r8152 2-1:1.0: load rtl8156b-2 v2 04/27/23 successfully
[51076.301913] r8152 2-1:1.0 eth0: v1.12.13
[51076.697896] r8152 2-1:1.0 usb2.5g: renamed from eth0
[51079.489807] r8152 2-1:1.0 usb2.5g: carrier on
[51079.745192] r8152 2-1:1.0 usb2.5g: carrier off
[51082.561105] r8152 2-1:1.0 usb2.5g: carrier on
[51152.705733] r8152 2-1:1.0 usb2.5g: carrier off
[51156.353013] r8152-cfgselector 2-1: USB disconnect, device number 6
[51156.353455] xhci_hcd :00:14.0: WARN Set TR Deq Ptr cmd failed due to 
incorrect slot or ep state.
[51156.353492] r8152 2-1:1.0 usb2.5g: Stop submitting intr, status -108

Above is the relevant kernel message logs.

# mii-tool usb2.5g
usb2.5g: 100 Mbit, half duplex, link ok

Above is the output of mii-tool, also the lights on the switch indicate
100mbit speed.   It gets 100mbit on a 1000baset switch too, so it's not a
switch issue.

[66653.451043] cdc_ncm 2-1.2:2.0 enx00e04c680225: renamed from eth0
[66656.811499] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
mbit/s uplink
[66657.067647] IPv6: ADDRCONF(NETDEV_CHANGE): enx00e04c680225: link becomes 
ready
[66657.323360] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
mbit/s uplink
[66657.835395] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
mbit/s uplink
[66658.347355] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
mbit/s uplink
[66658.859227] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
mbit/s uplink
[66659.371242] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
mbit/s uplink
[66659.883190] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
mbit/s uplink

Above is the dmesg output from a LicheePi4A running the
5.10.113-g387b6863253c-dirty kernel it ships with, when it does this the
switch LEDs indicate that it's 2500 speed.  This indicates that it's not
a problem with the hardware in the USB device but a problem with the kernel.

# ethtool usb2.5g
Settings for usb2.5g:
Supported ports: [  ]
Supported link modes:   Not reported
Supported pause frame use: No
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes:  Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Half
Auto-negotiation: off
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
MDI-X: Unknown
Current message level: 0x0007 (7)
   drv probe link
Link detected: yes

Above is the output of running ethtool on a Debian/Stable system running
kernel 6.1.0-13-amd64.  Half duplex is a problem, but less of a problem than
100baseT.  This is a regression from Debian/Stable.

-- Package-specific info:
** Version:
Linux version 6.6.11-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 
13.2.0-9) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41.50.20231227) #1 SMP 
PREEMPT_DYNAMIC Debian 6.6.11-1 (2024-01-14)

** Command line:
BOOT_IMAGE=/vmlinuz-6.6.11-amd64 root=UUID=3ff23875-d2db-43c2-ae7c-a8ead11e9e04 
ro kaslr pti=on slab_nomerge page_poison=1 slub_debug=FPZ nosmt intel_iommu=on 
security=selinux zswap.enabled=1 zswap.zpool=z3fold enforcing=0

** Not tainted

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

** Model information

** Loaded modules:
cpuid
nft_chain_nat
xt_MASQUERADE
nf_nat
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
nft_compat
nf_tables
r8153_ecm
r8152
hid_generic
snd_usb_audio
snd_usbmidi_lib
snd_rawmidi
mc
usbhid
ccm
rfcomm
snd_seq_dummy
snd_hrtimer
snd_seq
snd_seq_device
cmac
algif_hash
algif_skcipher
af_alg
bnep
uinput
btusb
btrtl
btintel
btbcm
btmtk
bluetooth
cdc_mbim
cdc_wdm
cdc_ncm
qcserial
cdc_ether
usb_wwan
usbnet
usbserial
mii
ecdh_generic
snd_sof_pci_intel_skl
snd_sof_intel_hda_common
soundwire_intel
binfmt_misc
soundwire_generic_allocation
snd_sof_intel_hda_mlink
iwlmvm
soundwire_cadence
snd_sof_intel_hda
snd_sof_pci
snd_sof_xtensa_dsp
snd_sof
snd_sof_utils
intel_rapl_msr
soundwire_bus
intel_rapl_common
snd_soc_avs
nls_ascii
intel_pmc_core_pltdrv
snd_soc_hda_codec
intel_pmc_core
mac80211
snd_soc_skl
x86_pkg_temp_thermal
nls_cp437
intel_powerclamp
coretemp
vfat
snd_soc_hdac_hda
fat
kvm_intel
snd_hda_ext_core
snd_hda_codec_hdmi
snd_soc_sst_ipc
snd_soc_sst_dsp
intel_xhci_usb_role_switch
snd_soc_acpi_intel_match
kvm
snd_ctl_led
snd_soc_acpi
libarc4
snd_hda_codec_conexant
snd_soc_core
snd_hda_codec_generic
ext4
iwlwifi
irqbypass
snd_compress
crc32_pclmul
snd_pcm_dmaengine
xhci_pci
snd_hda_intel
ghash_clmulni_intel
crc16

Bug#1058317: celery: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[Jérémy Lal]

Source: celery
Followup-For: Bug #1058317

Note the segmentation fault at the end of python 3.12 pytest run.

Using export PYTHONFAULTHANDLER=1 before running the tests, I only got
an error in garbage-collector, no trace.

It is a bit like #1055717, which was closed by
https://salsa.debian.org/python-team/packages/python-multidict/-/commit/2d54ca0b

Also I tried with celery 5.3.6, and also with kombu 5.3.5 and vine 5.1.0, no 
luck.

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

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

Bug#1061094: mmdebstrap vs. apt -o DPkg::Inhibit-Shutdown

[Trent W. Buck]

Package: apt
Version: 2.6.1
Severity: wishlist

I'm creating this bug so there's a bug number I can link to.
We discussed it on #debian-apt around 2024-01-16 08:54:47+00:00.

I noticed that since 2023-10-10, mmdebstrap triggers these errors:

2023-10-10T15:53:32+1100 hera polkitd[2696604]:
Error evaluating admin rules:
Error: Helper exited with non-zero exit status 1,
   stdout=`',
   stderr=`pkla-check-authorization: Invalid user `10': No UNIX 
user with name 10: Success
  (pkla-check-authorization:3461602): GLib-GObject-CRITICAL 
**: 15:53:32.183: g_object_unref: assertion 'G_IS_OBJECT (object)' failed'

I initially thought it was a faulty postinst, but
after several hours of digging, I managed to narrow it down:

bash5$ journalctl -o short-iso -u polkit --grep='Error evaluating admin 
rules' -fn0 &
bash5$ sudo dbus-monitor --system --pcap | tshark -r- -Y 'dbus.interface == 
"org.freedesktop.login1.Manager"' &

bash5$ mmdebstrap bookworm /dev/null --quiet
   11  24.706215  :1.1955 → org.freedesktop.login1 D-Bus 246 Inhibit() 
@ /org/freedesktop/login1
2024-01-18T10:36:10+1100 hera polkitd[1035]: Error evaluating admin rules: 
Error: Helper exited with non-zero exit status 1, stdout=`', 
stderr=`pkla-check-authorization: Invalid user `10': No UNIX user with name 
10: Success

 
(pkla-check-authorization:874223): GLib-GObject-CRITICAL **: 10:36:10.673: 
g_object_unref: assertion 'G_IS_OBJECT (object)' failed
 '
   50  37.507789  :1.1956 → org.freedesktop.login1 D-Bus 246 Inhibit() 
@ /org/freedesktop/login1
2024-01-18T10:36:23+1100 hera polkitd[1035]: Error evaluating admin rules: 
Error: Helper exited with non-zero exit status 1, stdout=`', 
stderr=`pkla-check-authorization: Invalid user `10': No UNIX user with name 
10: Success

 
(pkla-check-authorization:875795): GLib-GObject-CRITICAL **: 10:36:23.475: 
g_object_unref: assertion 'G_IS_OBJECT (object)' failed
 '

bash5$ mmdebstrap bookworm /dev/null --quiet 
'--aptopt=DPKG::Inhibit-Shutdown 0;'

The relevant code is here:


https://salsa.debian.org/apt-team/apt/-/blob/2.6.1/apt-pkg/deb/dpkgpm.cc?ref_type=tags#L1508-1509

What is happening is this:

* "apt install foo" starts
* apt/dpkg --dbus--> systemd, "please inhibit (refuse to) shutdown/reboot 
during installs"
* systemd --dbus--> polkit, "user 1234 asked to inhibit shutdowns, is that 
allowed?"
* polkit --dbus--> systemd, "user 1234 doesn't exist, therefore no"
* systemd ignores the request (maybe signalling an error?)
* apt/dpkg continues on without any real issue

This issue DOES NOT affect normal host usage of apt, because
"sudo apt install x" runs the host's apt, with a normal host-wide user that 
polkit can see.
The inhibit works there (assuming pid1 is systemd, I guess).

This issue DOES NOT affect normal chroots, because
"sudo chroot /target apt install x" cannot "see" the un-chrooted dbus, so
the inhibit attempt fails before reaching systemd/polkit.

This issue affects mmdebstrap, because mmdebstrap run's the host's apt,
with an unshare'd userns such that apt thinks the user is root, and
systemd/polkit thinks it's a transient UID with no record in nss passwd table.

(systemd DynamicUser= units and systemd-nspawn containers have similar 
transient UIDs, and
in those cases "apt install libnss-systemd libnss-machines" provides nss passwd 
entries.)



Julian suggested this change:

-if (_config->FindB("DPkg::Inhibit-Shutdown", true))
+if (_config->FindB("DPkg::Inhibit-Shutdown", _config->FindDir("Dir", 
"/") == "/"))

I like this plan.

This will fix the mmdebstrap case, because mmdebstrap runs something like 
"unshare ⋯ apt -o Dir=/tmp/mmdebstrap.XX".
(No one cares if an mmdebstrap image build is "corrupted" by a halt/reboot - 
you just rerun mmdebstrap and make a fresh one.)

This should NOT affect "sudo apt install x" or "sudo chroot /target apt install 
x", because
in both cases apt is operating on / (either the host's /, or the chroot's /).

This should NOT affect debootstrap because it only runs dpkg, not apt (I think).

This MIGHT affect someone else doing "apt -o Dir=⋯" to do custom installs, but
everything I can think of offhand is a wrapper around debootstrap, except for
https://github.com/openSUSE/obs-build/blob/master/obs-docker-support#L118

Everything I can find seems to set e.g. Dir::Etc rather than Dir itself.

https://codesearch.debian.net/search?q=apt.*-o.*Dir%5B%5E%3A%5D
https://github.com/search?q=%2Fapt.*-o.*Dir%2F=code  (requires 
Microsoft account, requires javascript)

PS: general details about the "inihibit" functionality are here:

  

Bug#1061093: ironseed: please add support for loong64

[wuruilong]

Source: ironseed
Severity: normal
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

Please modify the file to support the loong64 architecture, the content is as 
follows:
debian/tests/control:2:Architecture: amd64 arm64 armel armhf i386 loong64 
mipsel mips64el ppc64el kfreebsd-amd64 kfreebsd-i386 riscv64
debian/control:23:Architecture: amd64 arm64 armel armhf i386 loong64 mipsel 
mips64el ppc64el kfreebsd-amd64 kfreebsd-i386 riscv64

wuruilong

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

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

Bug#1061092: rust-crossbeam: please update to v0.8.4

[Jonas Smedegaard]

Source: rust-crossbeam
Version: 0.8.1-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v0.8.4.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWofvQACgkQLHwxRsGg
ASHRjg/5AaCi4QWbeDWsjWOAwwRMuGbLuu4zWsfHHYDtzbt1z53KLLfPTg9JVFvi
lmNpWKIaIg2DFgteHTdJx0xVaUbqrHxmfbCpkbwje2aA7CRTsYypkEwCUYnMH6Bi
yxjCDc96kxio4Xieg/abSjjyXzpwvPRghqZicqH9fIY5kAgGDw+6Lp01T1oN3MZ1
HEWRvj9U+2+pfzvgCn/cq04x1YBSRgLS9sYGbWThO9zu8Im3+3r5l+SV6FXRkzB4
F6JzwHKRLAOKQRAvyj0lP+eq3NgTAopytVa7tuBSLZKa+W20P7MyiDJPGfPwUQH5
YXaiEhx4lamvd+s32CgirA/KZJHj/rg3tix+PiNKmkpLaDw4/5iTJsRB4L8gMb1y
FW4QlmnTKvHban1oDSgRfXMY+1ImZsVUFpUISgmRhMs7IvQ9+9l9IDcwWm3SA1ak
CLwBhsWmA/s17ZUDlwjG12cMnGykSzWIL6DiysZcT1Y5g1zfflLgDLGa+le8OWnb
B9BkvchoXM9LpaXxTME2SeejBVOjUtJHhvd04++vaK+TJlgSIvJ9VCt3vN+6fc2o
8aCQlE6XULz19FWJrFuwSEFsZwXO/PfCFitNp8ZPfPTQ1Pn4ARTdhXCVQafi3FTT
0COrSfwWLwGbuZYdw4u3oeWB25eJmmNr+CdgQoKFogr1cAFyiLQ=
=R3Xf
-END PGP SIGNATURE-

Bug#1057507: Additional information

[Vladimir Petko]

Dear Maintainers,

  Would it be possible to consider a merge request[1] that addresses this issue?

Best Regards,
 Vladimir.

 [1] https://salsa.debian.org/java-team/jackson-datatype-joda/-/merge_requests/2

Bug#1059084: xpdf: text searching from the first page does not find matches on the other pages

[Adam Sampson]

On Wed, Dec 20, 2023 at 09:22:56AM +0100, Florian Schlichting wrote:
> > > When one does a text search (Ctrl-F) from the first page of
> > > a PDF document that has several pages, only the matches on
> > > the first page are obtained.
[...]
> Hopefully Adam has an idea what's going wrong here?

I've just reproduced this and tracked it down -- it's a bug in Poppler's
TextPage::takeText, which meant that with my new search code, matches
would only be found in the current page and the next page.

I've added a workaround to xpopple Git, and sent a fix in to Poppler:
  https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/1486

Thanks,

-- 
Adam Sampson  

Bug#1061091: syntax/fortran.vim: incorrectly highlights identifiers, when they contain some keyword

[Francesco Poli (wintermute)]

Package: vim-runtime
Version: 2:9.1.0-1
Severity: normal

Hello!

I have recently noticed a regression.
Since one of the latest package upgrades (in Debian testing),
vim began to highlight some Fortran keywords, even when they appear
as part of identifiers. This is incorrect, since a keyword should
be highlighted only where it is actually a keyword, and not where
it appears as a part of an identifier.

Please see the attached 'test.f90' Fortran example program
and a screenshot of how vim highlights its syntax.

Please forward this bug report upstream and/or fix the regression,
as appropriate.

Thanks for your time.


P.S.: I believe that 'test.f90' is so trivial that it is not copyrighted.
Should it turn out to be copyrighted in some jurisdiction, I hereby release
it under the terms of the [Expat licence].

[Expat licence]: http://www.jclark.com/xml/copying.txt


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

Kernel: Linux 6.5.0-5-amd64 (SMP w/4 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

vim-runtime depends on no packages.

Versions of packages vim-runtime recommends:
ii  vim 2:9.1.0-1
ii  vim-gtk3 [vim]  2:9.1.0-1
ii  vim-tiny2:9.1.0-1

vim-runtime suggests no packages.

-- no debconf information
program test

integer :: mycalli
integer :: myifi
integer :: myendifi
integer :: mystopi
integer :: mycasei

integer :: myselecti
integer :: mywherei

integer :: myclassi

read(*,*) mycalli, myifi, myendifi, mystopi, mycasei, &
  myselecti, mywherei, myclassi

write(*,*) mycalli + myifi + myendifi + mystopi + mycasei + &
   myselecti + mywherei + myclassi

end

Bug#1060326: reverse dependencies

[Debian/GNU]

On Sun, 14 Jan 2024 17:16:55 + (UTC) Thorsten Alteholz 
 wrote:

Control: tags -1 + moreinfo

Hi IOhannes,

there are reverse dependencies that need to be taken care of:



indeed.



In case they matter, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.





my gut feeling tells me, the ppc64el versions of all these reverse 
dependencies do not really matter.
infact, these source packages only build plugins for obs-studio (and 
therefore useless without obs-studio).


as such i would vote to remove theire ppc64el builds as well.

what is required from my side?
do i need to contact the maintainers of these packages to coordinate?


mgdsar
IOhannes

Bug#1061090: autoconf-doc: single html file should be broken into one web page per node

[Louie S.]

Package: autoconf-doc
Severity: wishlist
X-Debbugs-Cc: lshpr...@tutanota.com

Dear Maintainer,

This package ships HTML documentation in a single file, as opposed to multiple
files, with one web page per node. Generally, GNU software documentation can
target HTML format either as entirely one web page or as one web page per node
(GNU Autoconf is no exception). I believe targetting one web page per node is
better practice.


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

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

Versions of packages autoconf-doc depends on:
ii  gnu-standards  2022.03.23-0.1

autoconf-doc recommends no packages.

autoconf-doc suggests no packages.

Bug#1044403: epoptes: Fails to build source after successful build

[Vagrant Cascadian]

Control: tags 1044403 pending

On 2023-08-13, Lucas Nussbaum wrote:
> This package fails to build a source package after a successful build
> (dpkg-buildpackage ; dpkg-buildpackage -S).
...
> More information about this class of issues, included common problems and
> solutions, is available at
> https://wiki.debian.org/qa.debian.org/FTBFS/SourceAfterBuild
...
>>  dpkg-source -b .
>> dpkg-source: info: using source format '3.0 (quilt)'
>> dpkg-source: info: building epoptes using existing 
>> ./epoptes_23.01.orig.tar.gz
>> dpkg-source: warning: file epoptes-23.01/epoptes.egg-info/SOURCES.txt has no 
>> final newline (either original or modified version)
>> dpkg-source: info: local changes detected, the modified files are:
>>  epoptes-23.01/epoptes.egg-info/PKG-INFO
>>  epoptes-23.01/epoptes.egg-info/SOURCES.txt
>>  epoptes-23.01/epoptes.egg-info/dependency_links.txt
>>  epoptes-23.01/epoptes.egg-info/top_level.txt
>>  epoptes-23.01/po/epoptes.pot
>> dpkg-source: error: aborting due to unexpected upstream changes, see 
>> /tmp/epoptes_23.01-1.diff.KKkbyp
>> dpkg-source: info: Hint: make sure the version in debian/changelog matches 
>> the unpacked source tree
>> dpkg-source: info: you can integrate the local changes with dpkg-source 
>> --commit
>> dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2
>> 
>> E: Command 'cd /<> && runuser -u user42 -- dpkg-buildpackage 
>> --sanitize-env -us -uc -rfakeroot -S' failed to run.

Pushed a fix to git:

  
https://github.com/epoptes/epoptes/commit/57e25218637dd9d2264fd876c50dacdd10778e51

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1042364: closed by Debian FTP Masters (reply to Félix Sipma ) (Bug#1042364: fixed in syncthing 1.27.2~ds4-1)

[Nicholas D Steeves]

"Debian Bug Tracking System"  writes:

> #1042364: syncthing: update to v1.23.6 at least
[snip]
> Source: syncthing
> Source-Version: 1.27.2~ds4-1
> Done: Félix Sipma 

Thank you Félix!  Your work is appreciated by many Debian users (and
DDs!) who have been unhappy about having to use the 3rd party package,
and I hope that you are considering adding yourself to Uploaders :)

Kind regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1060269: /lib/cryptsetup/askpass: coordinated move to /usr for DEP17

[Helmut Grohne]

On Mon, Jan 08, 2024 at 05:48:52PM +0100, Helmut Grohne wrote:
> What I also forgot to mention is that I applied quite some testing. You
> cannot test these patches with piuparts, because they need to be
> upgraded in lockstep, so I wrote a kind of mini-piuparts based on
> debhelper that specifically validates all kinds of upgrades and checks
> for correct diversions. Also attaching the tests.

I note that the patches were still subject to a rather strange file loss
scenario:

dpkg --auto-deconfigure --unpack cryptsetup_new.deb
dpkg --install cryptsetup-nuke-password.deb

This is not something apt would do, but dpkg accepts it and the first
unpack causes loss, because the declared Conflicts do not prevent dpkg
from doing the concurrent unpack.

In evaluating this problem more generally and moving the general
discussion forward via #1060700, I had an idea to prevent the loss
reliably, but the resulting diversions incur a bit more complexity and
cryptsetup has be part of the mitigation.

cryptsetup.preinst checks whether there is a pre-/usr-merge diversion
issued by cryptsetup-nuke-password. If there is, it duplicates it to the
physical location with a temporary diversion target on behalf of
cryptsetup-nuke-password.

cryptsetup-nuke-password.preinst can deal with cryptsetup.preinst not
having run and sets up the right diversion. It also can deal with the
temporary diversion and changes it to the permanent one.

cryptsetup.postinst checks whether its temporary diversion is still
there. This can happen if cryptsetup-nuke-password was removed. It
cleans up.

cryptsetup-nuke-password.postinst cleans up the aliased diversion that
is no longer needed.

The key to making this work is having cryptsetup mess with
cryptsetup-nuke-password's diversions. That's really ugly, but only
needed for this transition.

I've rerun all the tests successfully and on top of that also checked
that upgrading cryptsetup while removing cryptsetup-nuke-password works
as well as the complex failure motivating the change:

root@localhost:/# dpkg --auto-deconfigure --unpack 
/tmp/cryptsetup_2.6.1-6.1_amd64.deb
dpkg: considering deconfiguration of cryptsetup-nuke-password, which would 
be broken by installation of cryptsetup ...
dpkg: yes, will deconfigure cryptsetup-nuke-password (broken by cryptsetup)
(Reading database ... 10381 files and directories currently installed.)
Preparing to unpack .../cryptsetup_2.6.1-6.1_amd64.deb ...
De-configuring cryptsetup-nuke-password (4+nmu1), to allow installation of 
cryptsetup (2:2.6.1-6.1) ...
Mitigating diversion of /lib/cryptsetup/askpass on behalf of 
cryptsetup-nuke-password
Adding 'diversion of /usr/lib/cryptsetup/askpass to 
/usr/lib/cryptsetup/askpass.usr-is-merged by cryptsetup-nuke-password'
Unpacking cryptsetup (2:2.6.1-6.1) over (2:2.6.1-6+b1) ...
dpkg: warning: unable to delete old directory '/lib/cryptsetup/scripts': 
Directory not empty
dpkg: warning: unable to delete old directory '/lib/cryptsetup/checks': 
Directory not empty
root@localhost:/# dpkg -i /tmp/cryptsetup-nuke-password_4+nmu2_amd64.deb
(Reading database ... 10383 files and directories currently installed.)
Preparing to unpack .../cryptsetup-nuke-password_4+nmu2_amd64.deb ...
Removing 'diversion of /usr/lib/cryptsetup/askpass to 
/usr/lib/cryptsetup/askpass.usr-is-merged by cryptsetup-nuke-password'
Adding 'diversion of /usr/lib/cryptsetup/askpass to 
/usr/lib/cryptsetup/askpass.cryptsetup by cryptsetup-nuke-password'
Removing 'diversion of /lib/cryptsetup/askpass to 
/lib/cryptsetup/askpass.cryptsetup by cryptsetup-nuke-password'
Adding 'diversion of /lib/cryptsetup/askpass to 
/lib/cryptsetup/askpass.cryptsetup.usr-is-merged by cryptsetup-nuke-password'
Unpacking cryptsetup-nuke-password (4+nmu2) over (4+nmu1) ...
dpkg: warning: unable to delete old directory '/lib/cryptsetup': Directory 
not empty
dpkg: dependency problems prevent configuration of cryptsetup-nuke-password:
 cryptsetup-nuke-password depends on cryptsetup (>= 2:2.6.1-6.1~); however:
  Package cryptsetup is not configured yet.

dpkg: error processing package cryptsetup-nuke-password (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 cryptsetup-nuke-password
root@localhost:/# dpkg --configure -a
Setting up cryptsetup (2:2.6.1-6.1) ...
Setting up cryptsetup-nuke-password (4+nmu2) ...
Removing 'diversion of /lib/cryptsetup/askpass to 
/lib/cryptsetup/askpass.cryptsetup.usr-is-merged by cryptsetup-nuke-password'
root@localhost:/# dpkg-divert --list
diversion of /usr/lib/cryptsetup/askpass to 
/usr/lib/cryptsetup/askpass.cryptsetup by cryptsetup-nuke-password
root@localhost:/# dpkg --verify
root@localhost:/#

What do you think? Yes, this adds quite some complexity to both
packages, but now I don't see any opportunities for file loss anymore
even when upgrading the 

Bug#1060889: [Pkg-clamav-devel] Bug#1060889: clamav cannot be cross-arch installed?

[Sebastian Andrzej Siewior]

On 2024-01-16 17:59:21 [+1100], Trent W. Buck wrote:
> Package: clamav-base
> Version: 1.0.3+dfsg-1~deb12u1
> Severity: minor
> 
> When trying to install clamav for non-default architecture,
> I get this error from apt:
> 
> The following packages have unmet dependencies:
>  clamav-daemon:i386 : Depends: clamav-base:i386 (= 1.0.3+dfsg-1~deb12u1) 
> but it is not installable
>  clamav-freshclam:i386 : Depends: clamav-base:i386 (>= 
> 1.0.3+dfsg-1~deb12u1) but it is not installable
> 
> This is really weird and confusing, because clamav-base is
> an Architecture: all package, not
> an Architecture: any package.
> 
> I speculate that either:
> 
> 1. apt has a bug that clamav happens to trigger; or
> 2. clamav's Depends/Conflicts/Replaces are subtly bugged, and should be 
> "fixed"; or
> 3. I've misunderstood something fundamental about how to use multiple 
> architectures in apt.

The multi-arch fields could be wrong. Let me check that.

> PS: while not really relevant to this bug report,
> the original context was:
> 
>   grr, clamd keeps getting OOM-killed because
>it loads all definitions into RAM (not mmaped or anything) which
>is 1300MB on this 4000MB system.

1.3GiB is what I see here, too. Keep in mind, there is this
ConcurrentDatabaseReload which is enabled by default. This will load a
new database (after signature update) from scratch while keeping the old
around. The old is removed once the new is completly loaded. Assuming
the DB requires 1GiB of memory then it will consume another 1GiB until
it is fully loaded.

>   /var/lib/clamav/ is only 223M, not 1300MB!

Probably compressed content, data structurs and so on.

>   I wonder if clamav:i386 halves the RAM usage?
> 
>   dpkg --add-architecture=i386;
>apt update;
>apt install clamav:i386 clamav-daemon:i386
>[doesn't work, start investigating]

On i386 I see 1,1GiB after clamav-daemon started and got idle (after
loading the database).

Sebastian

Bug#1061089: src:path.py: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: path.py
Version: 16.7.1-1
Severity: serious
Control: close -1 16.9.0-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:path.py has been trying to migrate for 36 
days [2]. Hence, I am filing this bug. The version in unstable fails its 
own autopkgtest.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=path.py



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061088: src:python-anyio: fails to migrate to testing for too long: autopkgtest issues

[Paul Gevers]

Source: python-anyio
Version: 3.7.0-1
Severity: serious
Control: close -1 4.1.0-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:python-anyio has been trying to migrate 
for 36 days [2]. Hence, I am filing this bug. The version in unstable 
fails its own autopkgtest and triggers failures in python-watchgod.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=python-anyio



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1027899: u-boot-menu: menu is not created by kernel-install command

[Vagrant Cascadian]

On 2023-01-04, Manuel Traut wrote:
> if kernel-install is called manualy the extlinux.conf file is not
> generated.
>
> This can be resolved with an .install file in /usr/lib/kernel/install.d

I uploaded a fix which calls u-boot-update from a hook in that
directory, but it does not support the newly added feature to sync DTB
files.

  # FIXME support U_BOOT_SYNC_DTBS on "add" and "remove" events

This almost makes me wonder if u-boot-update shouldn't take some
arguments so we do not have to duplicate the functionality across
/usr/lib/kernel/install.d/ and /etc/kernel/post*.d/ hooks.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1060856: [Pkg-xmpp-devel] Bug#1060856: gajim: needs gtk3 >= 3.24.30 (found 3.24.24) to run, not reflected in dependencies

[Christian Häggström]

On 2024-01-15 21:39, Martin wrote:

for a normal,
up-to-date system (or even not up-to-date, like Debian 12.0), there
shouldn't be any issue.


Correct, hence minor severity.

I tried to find the reason for bumping the minor version of package 
dependencies by looking at the git commits in the gajim repository, but 
there was no reason given in the commit comments. I have asked Philipp 
Hörist for clarification by tagging him here: 
https://dev.gajim.org/gajim/gajim/-/commit/174e8df17e4a7b987615bf94fe2f6794abbb8c87#note_213094


/ Christian

Bug#842306: ITP: falco -- Sysdig Falco is a behavioral activity monitor designed to detect anomalous activity in your applications

[Petter Reinholdtsen]

Just for the record, the latest edition of falco provide a "modern" ebpf
probe in the kernel that is provied inside the binary and no longer
require a kernel module.  This allow the binary to work independent of
kernel version, as long as the kernel is new enough.  Not sure how new,
but the feature set required has been present in the the Linux kernel
for some years now.

This make it a lot easier to deploy falco on many hosts.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1061087: RFS: bash-unit/2.1.0-1 [RFP] -- bash_unit - bash unit testing

[Martin Dosch]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "bash-unit":

 * Package name : bash-unit
   Version  : 2.1.0-1
   Upstream contact : Pascal Grange 
 * URL  : https://github.com/pgrange/bash_unit
 * License  : GPL-3
 * Vcs  : https://salsa.debian.org/mdosch/bash-unit
   Section  : devel

The source builds the following binary packages:

  bash-unit - bash_unit - bash unit testing

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

  https://mentors.debian.net/package/bash-unit/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/bash-unit/bash-unit_2.1.0-1.dsc

Changes for the initial release:

 bash-unit (2.1.0-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #839210)

Regards,
--
  Martin Dosch


signature.asc
Description: PGP signature

Bug#1061086: src:bpfcc: fails to migrate to testing for too long: FTBFS on ppc64el

[Paul Gevers]

Source: bpfcc
Version: 0.26.0+ds-1
Severity: serious
Control: close -1 0.29.1+ds-1
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:bpfcc has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build on ppc64el.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=bpfcc



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059000: mutter : Please add support for loong64

[Simon McVittie]

Control: tags -1 + moreinfo

On Tue, 19 Dec 2023 at 16:07:18 +0800, yalingfang wrote:
> Attach the mutter's patch for loong64.

The attached patch just disables some tests. On most architectures,
especially "ports" architectures, successful tests are the only evidence
we have that the package is functional.

Does this mean that mutter compiles successfully on loong64, but does
not actually work? If it doesn't work yet, then we shouldn't be making
it available to loong64 users yet.

Or is there other evidence that mutter works correctly on loong64, and
a justification for why it's OK to ignore these failing tests?

I know we already ignore test failures on several architectures, but
that's already a bad thing (technical debt), and expanding that workaround
to new architectures seems like the wrong direction to be going in.

One common reason why tests in OpenGL-based packages fail on mips64el and
riscv64 is that the Mesa llvmpipe driver is broken on those architectures
(see #1058687). If this also affects loong64, then I would recommend
that the loong64 community should look into fixing or disabling the
llvmpipe driver so that individual packages don't have to work around
it - from the discussion on #1058687, it seems that the work on that
bug that is being done by the riscv64 community is going to benefit
other architectures as well. Perhaps that includes loong64? If yes,
perhaps you can help them to get that work finished and merged?

>      When I compiled the mutter in Loongarch platform, the mutter and 
> gnome-settings-daemon depend each other.

As far as I can see, the only mutter dependency in gnome-settings-daemon
is for the tests. The standard way to bootstrap this is:

- build gnome-settings-daemon with the nocheck build profile
  (DEB_BUILD_PROFILES=nocheck);

- use that to build mutter;

- use that mutter to build gnome-settings-daemon again, this time with
  tests enabled

Breaking circular dependencies with build profiles is a standard thing
to do while bootstrapping a new architecture:
https://wiki.debian.org/DebianBootstrap

Thanks,
smcv

Bug#1057549: crowdsec: FTBFS: FAIL: TestOneShot/permission_denied

[Cyril Brulebois]

Hi Santiago,

Santiago Vila  (2023-12-05):
> […]

Thanks for the report. The relevant part didn't appear in the excerpt
so I'm quoting the full build log below:

> === RUN   TestOneShot/permission_denied
> file_test.go:234: 
>   Error Trace:
> /<>/_build/src/github.com/crowdsecurity/crowdsec/pkg/cstest/utils.go:25
>   
> /<>/_build/src/github.com/crowdsecurity/crowdsec/pkg/acquisition/modules/file/file_test.go:234
>   Error:  An error is expected but got nil.
>   Test:   TestOneShot/permission_denied
> === RUN   TestOneShot/ignored_directory
> === RUN   TestOneShot/glob_syntax_error
> === RUN   TestOneShot/no_matching_files
> === RUN   TestOneShot/test.log
> === RUN   TestOneShot/test.log.gz
> === RUN   TestOneShot/unexpected_end_of_gzip_stream
> === RUN   TestOneShot/deleted_file
> --- FAIL: TestOneShot (0.00s)
> --- FAIL: TestOneShot/permission_denied (0.00s)
> --- PASS: TestOneShot/ignored_directory (0.00s)
> --- PASS: TestOneShot/glob_syntax_error (0.00s)
> --- PASS: TestOneShot/no_matching_files (0.00s)
> --- PASS: TestOneShot/test.log (0.00s)
> --- PASS: TestOneShot/test.log.gz (0.00s)
> --- PASS: TestOneShot/unexpected_end_of_gzip_stream (0.00s)
> --- PASS: TestOneShot/deleted_file (0.00s)

I'll investigate shortly.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1058673: gdm3: add build support for loongarch64

[Simon McVittie]

Control: retitle -1 gdm3: add loong64 to the list of architectures with gjs
Control: tags -1 + pending

On Thu, 14 Dec 2023 at 19:15:40 +0800, zhangdandan wrote:
> The gdm3 source package lacks LoongArch architecture support.
> We need to add build support for loongarch64 in d/control.

There is nothing particularly architecture-specific about gdm3, but it
only works on architectures where gjs is available.

When asking for loong64 to be added to the lists of supported
architectures in various packages, it would be useful if you could look
at why there is a list of architectures, and consider whether/why loong64
should be added to that list: that would have avoided asking for it to
be added to lists of architectures that have flatpak before that was
actually true.

In the case of gdm3, it looks like gjs compiles successfully and
passes tests on loong64, so the answer is: yes, it's appropriate to add
loong64 here.

Thanks,
smcv

Bug#769748: gpm cannot distinguish between Russian and English "a" if a font is terminus unicode bold with console-cyrillic

[Jakub Wilk]

* Askar Safin , 2014-11-16 07:06:

Steps to reproduce:
* Install gpm and console-cyrillic
* Configure console-cyrillic and choose terminus unicode bold as a font
* Restart console-cyrillic
* Type Russian letters "а" and "о" (which look exactly same as English "a" and 
"o")
* Copy them to clipboard using gpm
* Paste

What I get:
* I get English "a" and "o"

What I expected to get:
* Russian "а" and "о"


This is not a gpm bug. Gpm is not deeply involved in the copying and 
pasting operation: it just tells the kernels what part of screen to copy 
and when to paste.


What your seeing is caused by limitations of the Linux kernel and a font 
design choice:


1. The kernel limits the number of glyphs in the font to 256 (or 512 if 
you're OK with reduced number of available colors).


2. To work around this limit, and to fit as many characters as possible 
into a single font, the Terminus fonts reuses the same glyphs for 
characters that look the same (or almost the same), such as Latin "a" 
and Cyrillic "а".


3. The kernel didn't track which Unicode _characters_ appeared on 
screen, only which _glyphs_ did. (So the distinction between Latin "a" 
and Cyrillic "а" got lost.)


Fortunately, the last point is partially fixed since v4.19:
if you read from a /dev/vcsuN device, the kernel will start to keep 
track of Unicode characters on screen, and they should be properly 
copy-pastable.


See the following kernel commits:
https://git.kernel.org/linus/9bfdc2611d417be453c3deb7a7ef2ffc718febfa
https://git.kernel.org/linus/d21b0be246bf3bbf569e6e239f56abb529c7154e

--
Jakub Wilk

Bug#1058679: gnome-initial-setup: enable PARENTAL_CONTROL for loongarch64

[Simon McVittie]

Control: block -1 by 1051323

On Wed, 17 Jan 2024 at 12:58:07 -0500, Jeremy Bícha wrote:
> On Thu, Dec 14, 2023 at 7:24 AM zhangdandan  wrote:
> > The gnome-initial-setup source package lacks LoongArch architecture support.
> > We need to enable PARENTAL_CONTROL for loongarch64.
> >
> > Please consider the patch I have attached.
> 
> I do not believe this change makes sense until malcontent is built on
> loong64. Please ask again then.

malcontent requires flatpak, which requires libseccomp, which requires
architecture-specific porting and is not available on loong64.

After resolving that, there is a cyclic build-dependency between
malcontent and flatpak. To break the cycle, you will need to build
malcontent on loong64 with the pkg.malcontent.nogui build profile, then
use that to build flatpak, and then you can rebuild malcontent with
full functionality. This sort of thing is a normal part of the process
of bootstrapping new architectures.

smcv

Bug#1058680: gnome-software: add support for loongarch64

[Simon McVittie]

Control: block -1 by 1051323

On Thu, 14 Dec 2023 at 20:28:43 +0800, zhangdandan wrote:
> The gnome-software source package lacks LoongArch architecture support.
> We need to add build support and enable flatpak support for loongarch64.

Similar to #1058679, this request doesn't seem like it makes sense until
flatpak is available on loong64. Please see #1058679 for more details.

smcv

Bug#1058381: casa-formats-io: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[s3v]

Dear Maintainer,

>  ERRORS 
> 
> _ ERROR collecting 
> .pybuild/cpython3_3.12_casa-formats-io/build/casa_formats_io/glue_factory.py _
> /usr/lib/python3/dist-packages/_pytest/runner.py:341: in from_call
> result: Optional[TResult] = func()
> /usr/lib/python3/dist-packages/_pytest/runner.py:372: in 
> call = CallInfo.from_call(lambda: list(collector.collect()), "collect")
> /usr/lib/python3/dist-packages/pytest_doctestplus/plugin.py:250: in collect
> module = import_path(fspath, root=self.config.rootpath)
> /usr/lib/python3/dist-packages/_pytest/pathlib.py:567: in import_path
> importlib.import_module(module_name)
> /usr/lib/python3.12/importlib/__init__.py:90: in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
> :1387: in _gcd_import
> ???
> :1360: in _find_and_load
> ???
> :1331: in _find_and_load_unlocked
> ???
> :935: in _load_unlocked
> ???
> :994: in exec_module
> ???
> :488: in _call_with_frames_removed
> ???
> casa_formats_io/glue_factory.py:7: in 
> from glue.core import Data
> /usr/lib/python3/dist-packages/glue/__init__.py:22: in 
> from .config import load_configuration
> /usr/lib/python3/dist-packages/glue/config.py:2: in 
> import imp
> E   ModuleNotFoundError: No module named 'imp'
> === short test summary info 
> 
> ERROR casa_formats_io/glue_factory.py - ModuleNotFoundError: No module named 
> ...
>  Interrupted: 1 error during collection 
> 
> === 1 error in 1.37s 
> ===

The issue comes from glue's source code.
'imp' module was removed from Python 3.12 [1]

Kind Regards

[1] https://docs.python.org/3/whatsnew/3.12.html#imp

Bug#1060117: pass-otp: oathtool safety: avoid argument splitting, send secrets via stdin instead of arguments

[Philip Rinn]

Hi Paul,

thanks, I'll have a look next week and prepare an upload.

Best,
Philip


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058432: glyphslib: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[s3v]

Dear Maintainer,

> = test session starts 
> ==
> platform linux -- Python 3.12.1, pytest-7.4.3, pluggy-1.3.0
> rootdir: /<>/.pybuild/cpython3_3.12/build
> configfile: pyproject.toml
> collected 0 items / 29 errors
> 
>  ERRORS 
> 
>  ERROR collecting tests/classes_test.py 
> 
> ImportError while importing test module 
> '/<>/.pybuild/cpython3_3.12/build/tests/classes_test.py'.
> Hint: make sure your test modules/packages have valid Python names.
> Traceback:
> /usr/lib/python3.12/importlib/__init__.py:90: in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
> tests/classes_test.py:23: in 
> from glyphsLib.classes import (
> glyphsLib/__init__.py:21: in 
> from glyphsLib.classes import GSFont, __all__ as __all_classes__
> glyphsLib/classes.py:26: in 
> import openstep_plist
> /usr/lib/python3/dist-packages/openstep_plist/__init__.py:1: in 
> from .parser import load, loads, ParseError
> E   ModuleNotFoundError: No module named 'openstep_plist.parser'
...
...


after python-openstep-plist/0.3.1-1 entered in unstable [1], your package
builds fine locally in a sid chroot environment and autopkg tests pass as well.
Please consider to close this bug when you are able to confirm that.

Kind Regards

[1] 
https://tracker.debian.org/media/packages/p/python-openstep-plist/changelog-0.3.1-1

Bug#1058388: fontmake: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[s3v]

Dear Maintainer,

> fontmake/font_project.py:946:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _
> fontmake/font_project.py:1006: in _run_from_designspace_static
> ufos.extend(
> fontmake/font_project.py:744: in interpolate_instance_ufos
> from glyphsLib.interpolation import apply_instance_data_to_ufo
> /usr/lib/python3/dist-packages/glyphsLib/__init__.py:21: in 
> from glyphsLib.classes import GSFont, __all__ as __all_classes__
> /usr/lib/python3/dist-packages/glyphsLib/classes.py:26: in 
> import openstep_plist
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _
>
> >   from .parser import load, loads, ParseError
> E   ModuleNotFoundError: No module named 'openstep_plist.parser'
>
> /usr/lib/python3/dist-packages/openstep_plist/__init__.py:1: 
> ModuleNotFoundError


after python-openstep-plist/0.3.1-1 entered in unstable [1], your package
builds fine locally in a sid chroot environment.
Please consider to close this bug when you are able to confirm that.

Kind Regards

[1] 
https://tracker.debian.org/media/packages/p/python-openstep-plist/changelog-0.3.1-1

Bug#1060740: regripper: diff for NMU version 3.0~git20221205.d588019+dfsg-1.1

[gregor herrmann]

Dear maintainer,

I've prepared and uploaded an NMU for regripper (versioned as
3.0~git20221205.d588019+dfsg-1.1). The diff is attached to this
message.

Sorry for the rush, this was one of the last blockers of the ongoing
perl 5.38 migration.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   
diff -Nru regripper-3.0~git20221205.d588019+dfsg/debian/changelog regripper-3.0~git20221205.d588019+dfsg/debian/changelog
--- regripper-3.0~git20221205.d588019+dfsg/debian/changelog	2022-12-11 09:36:06.0 +0100
+++ regripper-3.0~git20221205.d588019+dfsg/debian/changelog	2024-01-17 19:45:41.0 +0100
@@ -1,3 +1,16 @@
+regripper (3.0~git20221205.d588019+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "autopkgtest failure with Perl 5.38: changed diagnostics":
+Add patch from upstream Git repo fixing a syntax error (stray
+parenthesis) in ./plugins/clsid_tln.pl.
+Additionally add the now fixed clsid_tln plugin to
+debian/tests/testfiles/regripper-plugins.csv, the file containing the
+expected plugins.
+(Closes: #1060740)
+
+ -- gregor herrmann   Wed, 17 Jan 2024 19:45:41 +0100
+
 regripper (3.0~git20221205.d588019+dfsg-1) unstable; urgency=medium
 
   [ Jan Gruber ]
diff -Nru regripper-3.0~git20221205.d588019+dfsg/debian/patches/1060740.patch regripper-3.0~git20221205.d588019+dfsg/debian/patches/1060740.patch
--- regripper-3.0~git20221205.d588019+dfsg/debian/patches/1060740.patch	1970-01-01 01:00:00.0 +0100
+++ regripper-3.0~git20221205.d588019+dfsg/debian/patches/1060740.patch	2024-01-17 19:32:16.0 +0100
@@ -0,0 +1,22 @@
+From ca9d83387e10854093f066a1ebe80cfc6852c832 Mon Sep 17 00:00:00 2001
+From: Andreas Hunkeler 
+Date: Tue, 21 Mar 2023 19:18:29 +0100
+Subject: [PATCH] fix: remove unneeded parenthesis in clsid_tln.pl
+
+---
+ plugins/clsid_tln.pl | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/plugins/clsid_tln.pl b/plugins/clsid_tln.pl
+index adfe2df..eb57770 100644
+--- a/plugins/clsid_tln.pl
 b/plugins/clsid_tln.pl
+@@ -109,7 +110,7 @@ sub pluginmain {
+ 
+ 	eval {
+ 			  		my $scriptlet = $s->get_subkey("ScriptletURL")->get_value("")->get_data();
+-		::rptMsg($s->get_subkey("ScriptletURL")->get_timestamp())."|REG|||CLID - ".$name."\\ScriptletURL: ".$scriptlet);
++		::rptMsg($s->get_subkey("ScriptletURL")->get_timestamp()."|REG|||CLID - ".$name."\\ScriptletURL: ".$scriptlet);
+ 			  	};
+ }
+ 			}
diff -Nru regripper-3.0~git20221205.d588019+dfsg/debian/patches/series regripper-3.0~git20221205.d588019+dfsg/debian/patches/series
--- regripper-3.0~git20221205.d588019+dfsg/debian/patches/series	2022-12-11 09:36:06.0 +0100
+++ regripper-3.0~git20221205.d588019+dfsg/debian/patches/series	2024-01-17 19:32:16.0 +0100
@@ -1 +1,2 @@
 10_modify-paths-in-srcs.patch
+1060740.patch
diff -Nru regripper-3.0~git20221205.d588019+dfsg/debian/tests/testfiles/regripper-plugins.csv regripper-3.0~git20221205.d588019+dfsg/debian/tests/testfiles/regripper-plugins.csv
--- regripper-3.0~git20221205.d588019+dfsg/debian/tests/testfiles/regripper-plugins.csv	2022-12-11 09:36:06.0 +0100
+++ regripper-3.0~git20221205.d588019+dfsg/debian/tests/testfiles/regripper-plugins.csv	2024-01-17 19:45:09.0 +0100
@@ -250,3 +250,4 @@
 gpohist,,Software,Collects system/user GPO history
 imagedev,20140104,System, -- 
 winrar,20200526,NTUSER.DAT,Get WinRAR\ArcHistory entries
+clsid_tln,20200526,Software, USRCLASS.DAT,Get list of CLSID/registered classes


signature.asc
Description: Digital Signature

Bug#1060710: dnsenum: diff for NMU version 1.3.1-1.1

[gregor herrmann]

Dear maintainer,

I've prepared an NMU for dnsenum (versioned as 1.3.1-1.1). The diff
is attached to this message.

Sorry for the rush, this was one of the last blockers of the ongoing
perl 5.38 migration.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   
diff -Nru dnsenum-1.3.1/debian/changelog dnsenum-1.3.1/debian/changelog
--- dnsenum-1.3.1/debian/changelog	2022-10-25 19:05:15.0 +0200
+++ dnsenum-1.3.1/debian/changelog	2024-01-17 19:27:32.0 +0100
@@ -1,3 +1,13 @@
+dnsenum (1.3.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "autopkgtest failure with Perl 5.38: Smartmatch is deprecated":
+add patch perl5.38_smartmatch.patch, replacing smartmatch with a plain
+grep().
+(Closes: #1060710)
+
+ -- gregor herrmann   Wed, 17 Jan 2024 19:27:32 +0100
+
 dnsenum (1.3.1-1) unstable; urgency=medium
 
   * New upstream version 1.3.1.
diff -Nru dnsenum-1.3.1/debian/patches/perl5.38_smartmatch.patch dnsenum-1.3.1/debian/patches/perl5.38_smartmatch.patch
--- dnsenum-1.3.1/debian/patches/perl5.38_smartmatch.patch	1970-01-01 01:00:00.0 +0100
+++ dnsenum-1.3.1/debian/patches/perl5.38_smartmatch.patch	2024-01-17 19:21:35.0 +0100
@@ -0,0 +1,32 @@
+Description: Stop using smartmatch
+ smartmatch is deprecated in perl 5.38, throwing warnings,
+ and will be removed in perl 5.42
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/1060710
+Author: gregor herrmann 
+Last-Update: 2024-01-13
+
+--- a/dnsenum.pl
 b/dnsenum.pl
+@@ -50,9 +50,6 @@
+ use strict;
+ use warnings
+   ; #it complains about uninitialized values when it doesn't find address in RR; need to fix later
+-no
+-  if $] >= 5.018, 'warnings',
+-  "experimental::smartmatch";# Mute Experimental Warning
+ use Config;
+ use Term::ANSIColor;
+ use Getopt::Long;
+@@ -746,9 +743,9 @@
+ ##we only print / add the result if it doesn't match the wildcardaddress
+ if (
+ !(
+-$rr->can('address') && $rr->address ~~ @wildcardaddress
++$rr->can('address') && grep { $_ eq $rr->address } @wildcardaddress
+ )
+-&& !( $rr->name ~~ @wildcardcname )
++&& !( grep { $_ eq $rr->name } @wildcardcname )
+   )
+ {
+ printrr( $rr->string );
diff -Nru dnsenum-1.3.1/debian/patches/series dnsenum-1.3.1/debian/patches/series
--- dnsenum-1.3.1/debian/patches/series	2022-10-25 19:05:15.0 +0200
+++ dnsenum-1.3.1/debian/patches/series	2024-01-17 19:21:35.0 +0100
@@ -1 +1,2 @@
 010_fix-usage-output.patch
+perl5.38_smartmatch.patch


signature.asc
Description: Digital Signature

Bug#856736: ITA: pidgin-skype -- Skype plugin for libpurple messengers (common files)

[Patrick ZAJDA]

On Tue, 16 Jan 2024 10:35:20 +0100 Patrick ZAJDA  wrote:
> Currently I have created a repository on Salsa [1] where I will push
> updates step by step.
>
> [1]: https://gitlab.com/Nardol/pidgin-skype

Oops, it is now really on Salsa:

https://salsa.debian.org/Nardol/pidgin-skype

Patrick


OpenPGP_0x9D4AD35BEA273DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061063: armhf: h5py's tests expose unaligned memory accesses during the build

[Aurelien Jarno]

On 2024-01-17 09:33, Matthias Klose wrote:
> Package: src:h5py
> Version: 3.10.0-1
> Severity: serious
> Tags: sid trixie
> 
> armhf: h5py's tests expose unaligned memory accesses during the build, this
> not seen with with the 3.9.0 version. You don't see this on the Debian
> buildds itself, because they ignore these misalignments.

While it is something to fix for performance issues, I hardly see how it
is a serious issue.

It is not possible to deactivate alignment fixups on a armhf kernel. The
Debian arm64 kernels (and not just the buildds) therefore have the
COMPAT_ALIGNMENT_FIXUPS kernel option enabled to reproduce the same
behaviour for 32-bit processes.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1061084: user-session-migration: FTBFS when the build directory name contains a '+'

[Aurelien Jarno]

Source: user-session-migration
Version: 0.4.1
Severity: important
Tags: ftbfs

Dear maintainer,

user-session-migration fails to build from source when the build
directory name contains a '+'. Given this is a native package, this
happens when the package is binNMUed:

| I: NOTICE: Log filtering will replace 
'build/reproducible-path/user-session-migration-0.4.1+b1' with '<>'

...

| nosetests3
| F
| ==
| FAIL: Test subsequent runs with a new script
| --
| Traceback (most recent call last):
|   File "/<>/obj-riscv64-linux-gnu/tests/migration_tests.py", 
line 206, in test_subsequent_runs_with_new_script
| self.assertTrue(re.match("Using '{}' directory\nFile '{files}_test.sh 
already migrated, skipping\nFile '{files}_test.sh already migrated, skipping\n"
| AssertionError: None is not true
| 
| --
| Ran 9 tests in 24.626s
| 
| FAILED (failures=1)

The full build log is available here:
https://buildd.debian.org/status/fetch.php?pkg=user-session-migration=riscv64=0.4.1%2Bb1=1705471613=0

This could also happens if the package is NMUed using the +nmuX syntax,
or if an upload to (old)stable is needed using the +debXuY syntax.

Regards
Aurelien

Bug#1058679: gnome-initial-setup: enable PARENTAL_CONTROL for loongarch64

[Jeremy Bícha]

On Thu, Dec 14, 2023 at 7:24 AM zhangdandan  wrote:
> The gnome-initial-setup source package lacks LoongArch architecture support.
> We need to enable PARENTAL_CONTROL for loongarch64.
>
> Please consider the patch I have attached.

I do not believe this change makes sense until malcontent is built on
loong64. Please ask again then.

Thank you,
Jeremy Bícha

Bug#1061083: libatk1.0-dev, libatspi2.0-dev: please add ${gir:Depends}, ${gir:Provides}

[Simon McVittie]

Package: libatk1.0-dev
Version: 2.50.0-1
Severity: wishlist
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gir-provides

As part of longer-term work on trying to improve multiarch and
cross-compilation in the GObject-Introspection ecosystem, I have been
looking at adding systematic names for GIR XML in -dev packages.

libatk1.0-dev and libatspi2.0-dev contain public GIR XML files Atk-1.0.gir
and Atspi-2.0.gir, so please add Depends: ${gir:Depends} and
Provides: ${gir:Provides} to both -dev packages. Recent versions of
dh_girepository will fill in those variables automatically, resulting
in the equivalent of Provides: gir1.2-atk-1.0-dev (= ${binary:Version})
for ATK and a similar setup for Atspi.

If the package is backported, it should be OK to leave those variables in
place: their values will be empty, but that's harmless.

Adding the Provides is a step towards eventually making it possible to
cross-compile at-spi2-core, either by using qemu-user or with GIR XML
disabled by a build-profile, if that is something that a developer wants
to pursue later.

Thanks,
smcv

Bug#1061082: libharfbuzz-dev: please add ${gir:Depends}, ${gir:Provides}

[Simon McVittie]

Package: libharfbuzz-dev
Version: 8.0.1-1+b2
Severity: wishlist
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gir-provides

As part of longer-term work on trying to improve multiarch and
cross-compilation in the GObject-Introspection ecosystem, I have been
looking at adding systematic names for GIR XML in -dev packages.

libharfbuzz-dev contains a public GIR XML file Harfbuzz-0.0.gir, so please
add Depends: ${gir:Depends} and Provides: ${gir:Provides}. Recent versions
of dh_girepository will fill in those variables automatically, resulting in
the equivalent of Provides: gir1.2-harfbuzz-0.0-dev (= ${binary:Version}).

If the package is backported, it should be OK to leave those variables in
place: their values will be empty, but that's harmless.

Harfbuzz is low down in the stack (it's depended on by Pango, which is
depended on by all versions of GTK) so it would be useful for it to gain
those names sooner rather than later. That will let higher-level packages
like Pango add gir1.2-harfbuzz-0.0-dev as a build-dependency, to make it
explicit that they are relying on its GIR XML.

Thanks,
smcv

Bug#996432: ITS: newlib

[T. Joseph Carter]

Package: libnewlib-arm-none-eabi
Version: 3.3.0-1.3
Followup-For: Bug #996432

Hi John,

Your ITS was posted quite a long time ago and the maintainer is utterly
MIA on this package. It's absolutely breaking stuff so that
gcc-arm-none-eabi cannot be installed in trixie/sid alongside this
package, which is required for the things you'd install that compiler
for.

Is this still something you're willing to work on? Is there some way
folks can assist/help test/help package/something, or are you literally
waiting on sponsors or … ?

Happy to help if I can.

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

Kernel: Linux 6.5.0-5-amd64 (SMP w/16 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 libnewlib-arm-none-eabi depends on:
ii  libnewlib-dev  3.3.0-1.3

Versions of packages libnewlib-arm-none-eabi recommends:
ii  gcc-arm-none-eabi   15:12.2.rel1-1
ii  libstdc++-arm-none-eabi-newlib  15:12.2.rel1-1+23

Versions of packages libnewlib-arm-none-eabi suggests:
pn  libnewlib-doc  

-- no debconf information

Bug#1037353: lynx.1: a few formatting fixes for the manual

[G. Branden Robinson]

Hi Thomas,

At 2023-06-14T17:49:04-0400, Thomas Dickey wrote:
> On Mon, Jun 12, 2023 at 01:56:56AM +, Bjarni Ingi Gislason wrote:
> > Output from "mandoc -T lint lynx.1"
> > mandoc: lynx.1:27:2: WARNING: missing date, using "": TH
> > mandoc: lynx.1:109:2: WARNING: unknown font, skipping request: ft C 
> > 
> > mandoc: lynx.1:317:2: WARNING: unknown font, skipping request: ft C 
> > 
> > mandoc: lynx.1:366:2: WARNING: unknown font, skipping request: ft C 
> > 
> > mandoc: lynx.1:831:2: WARNING: unknown font, skipping request: ft C 
> > 
> > mandoc: lynx.1:838:2: WARNING: unknown font, skipping request: ft C 
> > 
> > mandoc: lynx.1:1131:2: WARNING: unknown font, skipping request: ft C
> > 
> 
> That seems to be harmless for nroff, but mainly is for troff (and
> groff) to select a fixed-pitch font for PDFs and PostScript.  I'll see
> if this is at least no worse than the plain "C".

groff 1.23.0 warns about that font name too.  Here's one place the issue
was explored (and remedied).

https://sourceforge.net/p/docutils/patches/205/

> Solaris 10 appears to have "CO" for "Courier" (troff), while an AIX
> that I can access uses "CR".  But on those systems, I'm not actually
> using troff :-)

As far as I can tell, font names simply were not standardized, even by
common practice.  Each troff vendor came up with their own set of names,
I would guess inspired by whatever PostScript fonts they paid to license
from relevant foundries, and aliases may have been set up on an ad hoc
basis if/as problems with document rendering arose.

> I've been using "C" quite a while, and hadn't noticed a problem with
> the indicated usage (i.e., generating PDFs, etc).

Selecting a nonexistent font is a no-op, so it's unlikely to ruin
a document's formatting.  Proportional fonts generally set with more
horizontal compactness constant-width ones, so lines written in the
expectation of, say, Courier are unlikely to overrun when set in Times.

To detect a problem, you'd have to know that a constant-width face was
expected there, and man page styling conventions were (are?) seldom
consistent enough that you'd notice this unless you were a page's
author, or an editor of a collection.

> > ###
> > 
> > Increase size of ~ (tilde) to make it more visible
> > with "troff" by using character \(ti.
> 
> That appears to be groff-specific.

Historically, the troff semantics of ~ are that it's a high-flown
character that will compose well with alphabetic glyphs when overstruck
with them.  I'm attaching a screenshot of Table I from a scan of the
CSTR #54 1976 document, Joseph Ossanna's "Nroff/Troff User's Manual".  A
tilde glyph did not exist in the Times faces, but appeared in the
"Special Mathematical Font" that Bell Labs commissioned.  One of the
purposes of that font was to get full coverage of the ASCII character
set, which typographers in those days did not respect as a necessary
basis for a font's glyph repertoire.

However, it is true that there was only variety of tilde available to
troff back then, so there was no need for a `\(ti` special character,
and none was defined.

Enter Kernighan's device-independent troff circa 1980.  An output device
could use any font names it wanted, and any special character names it
wanted.

As fonts' glyph repertoires grew, this freedom saw some exercise.
Eventually the arrival of a larger, lower tilde character necessitated
the invention of a name to refer to the "full" or "spacing" tilde as
depicted at U+007E in Unicode 2.0 and later.[1]

So, for example, while Documenter's Workbench 3.3 troff, one of several
lines of descent from Kernighan troff, does not define a `ti` special
character, its descendant Heirloom Doctools troff _does_.  And mandoc(1)
recognizes it as well.

I wouldn't expect any System V troff to do so.  But strings can be
defined to work around that problem just as they can for typographer's
(and programmers' neutral) quotation marks.

> > an.tmac:lynx.1:27: style: .TH missing third argument; suggest document 
> > modification date in ISO 8601 format (-MM-DD)
> > an.tmac:lynx.1:27: style: .TH missing fourth argument; suggest 
> > package/project name and version (e.g., "lynx ...")
> 
> maybe - there are pros/cons (the version number is in the manpage,
> and that indirectly gives an accurate date).  If I did put a date,
> it would be the modification date for _that_ file.

That appears to be a best practice, if not quite a common one, and it is
what groff_man_style(7) recommends.

 .TH topic section [footer‐middle [footer‐inside [header‐middle]]]
[...]
By convention, footer‐middle is the date of the most recent
modification to the man page source document, and footer‐
inside is the name and version or release of the project
providing it.

Regards,
Branden

[1] I don't say "Unicode [1.0]" because the standard supported 

Bug#1061080: Building with OpenSSL 3.0 uses deprecated API

[Vince Sanders]

Package:git-crypt
Version:0.7.0-0.1

When git-crypt is built with openssl 3.0 or later it uses API which have been 
deprecated.

In our derived distribution we build without deprecated API which causes 
git-crypt to completely fail to build.

To resolve this a patch is attached (formatted to be added to 
debian/patches/series) which builds using the "modern" EVP openssl API.


--- a/crypto-openssl-11.cpp
+++ b/crypto-openssl-11.cpp
@@ -30,7 +30,7 @@
 
 #include 
 
-#if OPENSSL_VERSION_NUMBER >= 0x1010L
+#if OPENSSL_VERSION_NUMBER >= 0x1010L && OPENSSL_VERSION_NUMBER < 0x3000L
 
 #include "crypto.hpp"
 #include "key.hpp"
--- a/Makefile
+++ b/Makefile
@@ -24,7 +24,7 @@
 coprocess.o \
 fhstream.o
 
-OBJFILES += crypto-openssl-10.o crypto-openssl-11.o
+OBJFILES += crypto-openssl-10.o crypto-openssl-11.o crypto-openssl-30.o
 LDFLAGS += -lcrypto
 
 XSLTPROC ?= xsltproc
--- /dev/null
+++ b/crypto-openssl-30.cpp
@@ -0,0 +1,145 @@
+/*
+ * Copyright 2012, 2014 Andrew Ayer
+ *
+ * This file is part of git-crypt.
+ *
+ * git-crypt is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * git-crypt is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with git-crypt.  If not, see .
+ *
+ * Additional permission under GNU GPL version 3 section 7:
+ *
+ * If you modify the Program, or any covered work, by linking or
+ * combining it with the OpenSSL project's OpenSSL library (or a
+ * modified version of that library), containing parts covered by the
+ * terms of the OpenSSL or SSLeay licenses, the licensors of the Program
+ * grant you additional permission to convey the resulting work.
+ * Corresponding Source for a non-source form of such a combination
+ * shall include the source code for the parts of OpenSSL used as well
+ * as that of the covered work.
+ */
+
+#include 
+
+#if OPENSSL_VERSION_NUMBER >= 0x3000L
+
+#include "crypto.hpp"
+#include "key.hpp"
+#include "util.hpp"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+void init_crypto ()
+{
+}
+
+struct Aes_ecb_encryptor::Aes_impl {
+	EVP_CIPHER_CTX *ctx;
+};
+
+Aes_ecb_encryptor::Aes_ecb_encryptor (const unsigned char* raw_key)
+: impl(new Aes_impl)
+{
+
+	impl->ctx = EVP_CIPHER_CTX_new();
+	if(impl->ctx == NULL) {
+		throw Crypto_error("Aes_ctr_encryptor::Aes_ctr_encryptor", "EVP_CIPHER_CTX_new failed");
+	}
+
+	/* convert key length into cipher specifier */
+	const EVP_CIPHER *cipher=NULL;
+	switch (KEY_LEN) {
+	case 16: /* 128 bits */
+		cipher = EVP_aes_128_ecb();
+		break;
+	case 24: /* 192 bits */
+		cipher = EVP_aes_192_ecb();
+		break;
+	case 32: /* 256 bits */
+		cipher = EVP_aes_256_ecb();
+		break;
+	default:
+		throw Crypto_error("Aes_ctr_encryptor::Aes_ctr_encryptor", "Unknown AES cipher key length");
+	}
+
+
+	if (EVP_EncryptInit_ex(impl->ctx, cipher, NULL, raw_key, NULL) != 1) {
+		throw Crypto_error("Aes_ctr_encryptor::Aes_ctr_encryptor", "EVP_EncryptInit_ex failed");
+	}
+}
+
+Aes_ecb_encryptor::~Aes_ecb_encryptor ()
+{
+	EVP_CIPHER_CTX_free(impl->ctx);
+}
+
+void Aes_ecb_encryptor::encrypt(const unsigned char* plain, unsigned char* cipher)
+{
+	int len;
+	// TODO: original implementation did not check error code, this should
+	EVP_EncryptUpdate(impl->ctx, cipher, , plain, BLOCK_LEN);
+}
+
+struct Hmac_sha1_state::Hmac_impl {
+	EVP_MAC *mac;
+	EVP_MAC_CTX *ctx;
+};
+
+Hmac_sha1_state::Hmac_sha1_state (const unsigned char* key, size_t key_len)
+: impl(new Hmac_impl)
+{
+	OSSL_PARAM params[2];
+	char digest_name[] = "SHA1";
+	params[0] = OSSL_PARAM_construct_utf8_string("digest", digest_name, 0);
+	params[1] = OSSL_PARAM_construct_end();
+
+	impl->mac = EVP_MAC_fetch(NULL, "HMAC", NULL);
+	impl->ctx = EVP_MAC_CTX_new(impl->mac);
+	EVP_MAC_init(impl->ctx, key, key_len, params);
+}
+
+Hmac_sha1_state::~Hmac_sha1_state ()
+{
+	EVP_MAC_CTX_free(impl->ctx);
+	EVP_MAC_free(impl->mac);
+}
+
+void Hmac_sha1_state::add (const unsigned char* buffer, size_t buffer_len)
+{
+	EVP_MAC_update(impl->ctx, buffer, buffer_len);
+}
+
+void Hmac_sha1_state::get (unsigned char* digest)
+{
+	// TODO: original implementation did not check error code, this should
+	size_t final_l;
+	EVP_MAC_final(impl->ctx, digest, _l, Hmac_sha1_state::LEN);
+}
+
+
+void random_bytes (unsigned char* buffer, size_t len)
+{
+	if (RAND_bytes(buffer, len) != 1) {
+		std::ostringstream	message;
+		while (unsigned long code = ERR_get_error()) {
+			char		error_string[120];
+			ERR_error_string_n(code, error_string, sizeof(error_string));
+			message << "OpenSSL Error: " << error_string 

Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts

[Helmut Grohne]

Hi Sam,

On Wed, Jan 17, 2024 at 09:33:25AM -0700, Sam Hartman wrote:
> I'd really like to understand why this is desired dpkg behavior.

I fear I have to defer to Guillem on this one. My rough understanding is
that we can minimize the window of time during which the files are
missing. Though given that apt only exercises this feature on mutual
conflicts and otherwise removes the conflicted package early, the
practical consequences of that reasoning may be questionable.

> I appreciate that even if it is not desired behavior, we might not be
> able to get it fixed in ways that matter for this discussion.

This is the main reason for me having skipped the question of whether
that behaviour is desirable.

> However my intuition is that it  will help me at least think about the
> situation.

That is a very sensible approach.

> As an example if the reason that behavior is needed has to do with some
> situation involving essential packages and conflicts, I'd like to
> understand that situation and how common it is.

Practically speaking, it cannot be very common. In the essential set, we
very much avoid Conflicts where possible and the DEP17 work will not
introduce Conflicts in the Priority: required set for mitigating P1
(file loss due to move between packages and from aliased to physical)
problems. All of those problems will use protective diversions that do
not run into the risk at hand. The one Conflicts that I plan to
introduce in essential is gzip -> zutils. Outside, apt prefers resolving
these by removing packages before there is a concurrent unpack
situation.

> It would not be the first time in this discussion that we have
> discovered a new complexity.

Sure thing. Late discovery of new complexities is the biggest risk of
the DEP17 transition.

Helmut

Bug#1057499: exec-maven-plugin: FTBFS with default Java 21

[tony mancill]

On Wed, Jan 17, 2024 at 05:30:24PM +1300, Vladimir Petko wrote:
> Dear Maintainers,
> 
>   Would it be possible to consider a merge request[1] that addresses this 
> issue?
>   Alternatively, we can update the package to the upstream version 3.1.1.
> 
> Best Regards,
>  Vladimir.
> 
>  [1]https://salsa.debian.org/java-team/exec-maven-plugin/-/merge_requests/2

Hello Vladimir,

Thank you for locating and packaging the patch.  I will upload the
current version with the patch and then look at updating 3.1.1 (after
reviewing all of the changes in the release).

Cheers,
tony

Bug#1061079: RFS: pidgin-skype/20230710+git5daf79d+dfsg-1 [ITA] -- Skype plugin for libpurple messengers (Pidgin-specific files)

[Patrick ZAJDA]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "pidgin-skype":

* Package name : pidgin-skype
Version : 20230710+git5daf79d+dfsg-1
Upstream contact : Eion Robb 
* URL : https://github.com/EionRobb/skype4pidgin
* License : GPL-3+
* Vcs : https://salsa.debian.org/Nardol/pidgin-skype
Section : net

The source builds the following binary packages:

pidgin-skype-common - Skype plugin for libpurple messengers (common files)
pidgin-skype - Skype plugin for libpurple messengers (Pidgin-specific files)
empathy-skype - Skype plugin for libpurple messengers (Empathy-specific 
files)

pidgin-skype-dbg - Skype plugin for libpurple messengers (debug symbols)

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


https://mentors.debian.net/package/pidgin-skype/

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

dget -x 
https://mentors.debian.net/debian/pool/main/p/pidgin-skype/pidgin-skype_20230710+git5daf79d+dfsg-1.dsc


Changes since the last upload:

pidgin-skype (20230710+git5daf79d+dfsg-1) unstable; urgency=medium
.
* New maintainer (Closes: #856736)
* Declare compliance with Debian Policy 4.6.2
* New upstream version
* Remove support for Skype and Skype DBus plugins
* Add SkypeWeb plugin (Closes: #788922)
* Use debian/watch to update from upstream source excluding icons
* Remove patches
* debian/controle:
- Move from contrib to main
- Adjust build dependencies
- Change descriptions, now only provide Skype web
* debian/*.links: update paths to icons
* debian/*.install: update paths to icons
* debian/rules:
- Adjust to new directory structure
- Fix custom-compression-in-debian-rules

Regards,
--
Patrick ZAJDA


OpenPGP_0x9D4AD35BEA273DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061078: ITP: oaknut -- Aarch64 (arm64) code emitter

[David James]

Package: wnpp
Severity: wishlist
Owner: David James 
X-Debbugs-Cc: debian-de...@lists.debian.org, davidjamescastor...@proton.me

* Package name: oaknut
  Version : 1.2.2
  Upstream Contact: MerryHime 
* URL : https://github.com/merryhime/oaknut
* License : MIT (Expat)
  Programming Lang: C++, CMake
  Description : Aarch64 (arm64) code emitter

Oaknut is a header-only C++20 assembler for arm64 systems. It is designed to 
process C++ code and emit it to memory at runtime.

I am in the process of packaging Citra, the Nintendo 3DS emulator. This is 
one of the dependencies required to package Citra on arm64. Without this, I 
would have to exclude the arm64 architecture entirely.

In addition to being a Citra dependency, this software would also be useful 
for anyone creating software to emulate an embedded ARM 8.0-8.2 system.

I would maintain this package myself, but would need a sponsor.

Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator

[Richard]

Am Mi., 17. Jan. 2024 um 17:08 Uhr schrieb John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de>:

> > This is exactly what it's supposed to mean. Packages distributed by
> Debian are obviously required
> > to not be broken when they hit stable. Otherwise an update wouldn't be
> accepted to  be sent to stable.
>
> The package is not broken. It works as intended by the upstream
> developers. It does not say anywhere
> that AusweisApp is supposed to work on a non-Qt system.
>

This is just not how anything works. Besides the fact that after Gnome was
made because people didn't like Qt's licensing and after a while they both
added compatibility for each others software - there basically isn't such
thing as a "non-Qt system". A non-Qt system would be a system with no Qt
dependencies available. But you'll probably never find any distro where
this is the case. That's why any package will always work with any DE, no
matter if it was build with GTK, Qt or something else. Sure, with Wayland
needing to be supported by the DEs instead of a  generic server, it can
happen that some minor things need to be harmonized, e.g. communicating a
sensible cursor size to Qt apps in a Gnome DE, but that's it. There's
absolutely nothing that makes Qt apps Plasma only or GTK apps Gnome only.

>
> > And since neither Debian with KDE nor Debian with Gnome is a separate
> distribution, obviously a
> > package is supposed to work with both.
>
> Sorry, but that's just non-sense. If an upstream project does not support
> GNOME, it will not
> support GNOME on Debian either. Again, you are barking up the wrong tree
> here.
>

Again, not how anything works.

>
> > That's why all KDE packages will pull in all necessary dependencies
> required to run in Gnome (or
> > any other DE offered by Debian) and vice versa. If any package would be
> allowed in stable in a
> > theoretical future where it only supports Wayland and not X while not
> all available DEs would
> > be supporting Wayland would be very questionable. And that's just
> another version of this exact problem.
>
> It's simply not possible to support every possible use cases. You just
> have to accept that.
>
Obviously not. But every use case supported by Debian itself must be
supported by the packages. With DEs it's not like with CPU architectures
where you can simply choose not to compile a package for a specific
architecture. Besides the fact that even that's not relevant. Even
AusweisApp is being compiled for pretty much any architecture supported by
debian, simply because there's nothing preventing it. That's at least true
for anything in the main repo. The only exception I know of is Steam, but
that's only shipped in contrib (and used to be non-free). So yes, every use
case supported by Debian stable in the main repo must be supported by every
package in that branch. Everything else wouldn't make any sense after all.

The real software world is not perfect.
>
> > > The limitations around GNOME support are an upstream issue and not
> related to packaging which
> > > is what I am doing. Claiming that a particular issue that is not a
> serious bug must be fixed
> > > before the next release is something that I would call entitlement. If
> you have figured out
> > > how to fix this particular problem, you are free to send a patch to me
> or upstream. That's
> > > how it works with community-maintained software.
> >
> > It's obviously serious since it literally renders the software unusable
> for some users. If you
> > have a different opinion, you should really re-read the severity levels'
> definitions:
> > https://www.debian.org/Bugs/Developer#severities
> > important: a bug which has a major effect on the usability of a package,
> without rendering it
> > completely unusable to everyone.
> > This is literally what this is.
>
> And you're still missing the point that the issue you are seeing here is
> not a limitation of Debian
> but of the upstream software you are using. You are blaming me for
> something that I am not responsible
> for.
>
> I am neither the upstream developer of GNOME nor of Qt or the AusweisApp.
> I am the person who is
> maintaining AusweisApp in Debian. And I am shipping the software as it is
> provided by upstream.
>
> If upstream doesn't support usecase X, I am not the person to be blamed.
>
You really should look up how "Maintainer" was defined when the concept was
introduced: https://www.debian.org/vote/2007/vote_003
One of the points: unfixed bugs may lead to the Maintainers key removal
from the Debian Maintainers keyring, effectively revoking their status of
being a Maintainer.


> > > Neither me nor the upstream maintainer are actually getting paid to
> provide this application
> > > on Linux or on Debian, so it's perfectly fine that we get to decide
> how we spend our free
> > > time.
> >
> > Nobody said otherwise. But literally with a bug this severe v2 can't and
> shouldn't be accepted
> > into stable with Trixie. And if nobody fixes it, it's 

Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

Helmut> Package: tech-ctte Given our discussion at the last CTTE
Helmut> meeting, I am turning my request for advice into a formal
Helmut> one.

Helmut> Most of the /usr-move that is happening via DEP17 seems to
Helmut> be working out, but the effects of Conflicts raise the
Helmut> question of what kinds of interactions with a package
Helmut> manager are considered supported.

Helmut> A naive reading of Debian policy 7.4 suggests that declaring
Helmut> a conflict reliably prevents concurrent unpack:

Helmut> | When one binary package declares a conflict with another
Helmut> using a | Conflicts field, dpkg will refuse to allow them to
Helmut> be unpacked on | the system at the same time.

Helmut> If you account for the effects of aliasing, this turns out
Helmut> to be a too naive reading as dpkg actually allows unpacking
Helmut> a conflicting package if the other package is scheduled for
Helmut> removal. Normally, this exception should not have observable
Helmut> consequences, but aliasing makes it observable in the form
Helmut> of file loss. I have filed #1057199 to clarify
Helmut> debian-policy.

I'd really like to understand why this is desired dpkg behavior.
I appreciate that even if it is not desired behavior, we might not be
able to get it fixed in ways that matter for this discussion.
However my intuition is that it  will help me at least think about the
situation.
As an example if the reason that behavior is needed has to do with some
situation involving essential packages and conflicts, I'd like to
understand that situation and how common it is.
It would not be the first time in this discussion that we have
discovered a new complexity.

--Sam

Bug#1061055: obs-build: init_buildsystem: improper debootstrap implementation violates assumption in Debian policy

[Andrej Shadura]

Hi all,

On Wed, 17 Jan 2024, at 17:01, Luca Boccassi wrote:
> On Wed, 17 Jan 2024 07:27:48 +0100 Helmut Grohne 
>> obs-build has its own implementation of debootstrap in
> init_buildsystem.
>> Unlike other implementations, it does not ensure that packages from
>> the essential set have been configured before unpacking non-essential
>> packages. The Debian policy requires that essential packages have to
>> work at all times after having been configured at least once. Since
>> non-essential packages may assume presence of essential in their
>> Pre-Depends, essential packages must be configured before unpacking
>> non-essential packages. obs-build's implementation does not ensure
>> this property. We can see this in e.g.
>> https://build.opensuse.org/package/live_build_log/home:unit193/certbot-dns-porkbun/Debian_Testing/x86_64
>> where essential package bash is installed after non-essential package
>> python3-cffi-backend.

> I asked the admins and the prjconf for both testing and unstable have
> been fixed so that usrmerge is installed before systemd and udev, so
> builds should be working again now.

Indeed, adding Preinstall: in the project configuration works around the issue.
Another way, and that’s how we do it in Apertis, is to use buildengine: 
debootstrap.
That way obs-build only creates a minimal chroot necessary to run debootstrap, 
and then debootstrap is going to do the right thing.

-- 
Cheers,
  Andrej

Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator

[John Paul Adrian Glaubitz]

Hello,

On Wed, 2024-01-17 at 16:24 +0100, Richard wrote:
> > There is no version 2.0.x in Debian stable nor stable-backports yet, so 
> > unless you built the
> > package yourself from the unstable sources or installed the Flatpak 
> > version, you created a
> > "FrankenDebian".
> > 
> 
> To be quoting myself:  I am running testing. AKA Trixie. So no, there's no 
> FrankenDebian at work.

Ah, I misread that. That doesn't change any of what I said though.

> > And, no, the wiki page regarding "FrankenDebian" is not contradicting 
> > itself because security
> > updates are provided through debian-security. These updates are built to 
> > target Debian stable,
> > so it's perfectly fine to install them without risking to break anything.
> > 
> 
> It is not contradicting itself page-wide, but wiki-wide. This is the Wiki 
> entry for Debian Testing,
> where it literally recommends to do what the "FrankenDebian" Wiki page 
> recommends not to do:
>
> https://wiki.debian.org/DebianTesting

I was talking about stable because the original bug was reported against the 
stable package.

> It is a good idea to install security updates from unstable since they take 
> extra time to reach
> testing and the security team only releases updates to unstable.

You're free to do that, of course. However, relevant security updates are 
migrating to testing
with a higher priority anyway. So, unless a maintainer forgot to set the proper 
urgency of
a security update, there is no need to pull stuff from unstable.

> > > Entitled? Well that's rich. The point of the whole bug reporting system 
> > > is exactly what we
> > > are doing here. So yes, if you are unwilling to maintain the package, 
> > > which will always
> > > include getting bug reports if things don't behave as intended, then 
> > > don't do it.
> > 
> > Not really. If someone steps up to maintain something, it doesn't 
> > automatically mean they
> > are responsible for supporting all possible configurations that exist 
> > within Debian which
> > is what you are asking for. The package works perfectly fine on KDE which 
> > is what I am using
> > myself.
> > 
> 
> This is exactly what it's supposed to mean. Packages distributed by Debian 
> are obviously required
> to not be broken when they hit stable. Otherwise an update wouldn't be 
> accepted to  be sent to stable.

The package is not broken. It works as intended by the upstream developers. It 
does not say anywhere
that AusweisApp is supposed to work on a non-Qt system.

> And since neither Debian with KDE nor Debian with Gnome is a separate 
> distribution, obviously a
> package is supposed to work with both.

Sorry, but that's just non-sense. If an upstream project does not support 
GNOME, it will not
support GNOME on Debian either. Again, you are barking up the wrong tree here.

> That's why all KDE packages will pull in all necessary dependencies required 
> to run in Gnome (or
> any other DE offered by Debian) and vice versa. If any package would be 
> allowed in stable in a
> theoretical future where it only supports Wayland and not X while not all 
> available DEs would
> be supporting Wayland would be very questionable. And that's just another 
> version of this exact problem.

It's simply not possible to support every possible use cases. You just have to 
accept that.

The real software world is not perfect.

> > The limitations around GNOME support are an upstream issue and not related 
> > to packaging which
> > is what I am doing. Claiming that a particular issue that is not a serious 
> > bug must be fixed
> > before the next release is something that I would call entitlement. If you 
> > have figured out
> > how to fix this particular problem, you are free to send a patch to me or 
> > upstream. That's
> > how it works with community-maintained software.
> 
> It's obviously serious since it literally renders the software unusable for 
> some users. If you
> have a different opinion, you should really re-read the severity levels' 
> definitions:
> https://www.debian.org/Bugs/Developer#severities
> important: a bug which has a major effect on the usability of a package, 
> without rendering it
> completely unusable to everyone.
> This is literally what this is.

And you're still missing the point that the issue you are seeing here is not a 
limitation of Debian
but of the upstream software you are using. You are blaming me for something 
that I am not responsible
for.

I am neither the upstream developer of GNOME nor of Qt or the AusweisApp. I am 
the person who is
maintaining AusweisApp in Debian. And I am shipping the software as it is 
provided by upstream.

If upstream doesn't support usecase X, I am not the person to be blamed.

> > Neither me nor the upstream maintainer are actually getting paid to provide 
> > this application
> > on Linux or on Debian, so it's perfectly fine that we get to decide how we 
> > spend our free
> > time.
> 
> Nobody said otherwise. But literally with a bug 

Bug#1061055: obs-build: init_buildsystem: improper debootstrap implementation violates assumption in Debian policy

[Luca Boccassi]

On Wed, 17 Jan 2024 07:27:48 +0100 Helmut Grohne 
wrote:
> Package: obs-build
> Tags: upstream
> X-Debbugs-Cc: unit...@debian.org
> 
> Hi,
> 
> obs-build has its own implementation of debootstrap in
init_buildsystem.
> Unlike other implementations, it does not ensure that packages from
the
> essential set have been configured before unpacking non-essential
> packages. The Debian policy requires that essential packages have to
> work at all times after having been configured at least once. Since
> non-essential packages may assume presence of essential in their
> Pre-Depends, essential packages must be configured before unpacking
> non-essential packages. obs-build's implementation does not ensure
this
> property. We can see this in e.g.
>
https://build.opensuse.org/package/live_build_log/home:unit193/certbot-dns-porkbun/Debian_Testing/x86_64
> where essential package bash is installed after non-essential package
> python3-cffi-backend.
> 
> The current work on /usr-merge heavily relies on this property. One
of
> the next steps is adding the aliasing symlinks to base-files. If any
> non-essential package with aliased files is installed before base-
files,
> the aliasing links will be lost and the created chroot will not work
at
> all. I think the property expected here is reasonable and the bug
> resides with obs-build. In particular, it is a bug that also affects
> upstream and the upstream deployment at build.opensuse.org.
> 
> Helmut

I asked the admins and the prjconf for both testing and unstable have
been fixed so that usrmerge is installed before systemd and udev, so
builds should be working again now.

-- 
Kind regards,
Luca Boccassi


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

Bug#1059546: pylint generates false positive 'import-error' with local editable modules.

[Mike Castle]

Easily replicable setup environment attached.


A.tar.gz
Description: application/gzip


B.tar.gz
Description: application/gzip

Bug#1031956: TrayIcon

[Richard]

Hi,
I'm sorry, but you must have misread the bug report. Nobody's talking about
autostart. When the app is opened, be it from its desktop icon or from a
terminal, in Gnome with an extension enabled to enable a tray for icons of
apps running the background, AusweisApp does add its icon to the tray
(though not actually showing an icon, so there's just an empty button). But
that's it. If it was wokring as supposed, its icon would also be added to
Gnome's dock and usually - if the app doesn't have an option enabled to
start as a background app - obviously the apps UI is supposed to open up.
Both last things don't happen. Also, from the tray icon, you can only close
the app. There's no option to toggle the window (or whatever programs call
that option). This is the whole issue, rendering the app completely
unusable for all users meeting the aforementioned criteria.

Yes, if you start it with --show, you get the UI. But if you close it, it
closes to tray with no option to get it back. And no, by no means it's
supposed to be a deamon that only shows its UI when it's used for
authentication. That's not how the Windows version works, not the Android
version and most likely no version of AusweisApp. So why should the Linux
app? Otherwise you wouldn't be able to change settings, e.g. to connect to
a smartphone to act as a card reader.

When it comes to Qt apps that act as expected, I honestly don't use that
many Qt apps - or I just can't tell if an app uses Qt or something
completely different. VLC kinda works as expected - you can have it start
only showing a tray icon and do what you like from there. But VLC is dirt
old - I was not yet able to get VLC 4 to work on Linux. KeePassXC is based
on Qt 5 and certainly works as expected. I think Telegram desktop may be
written with Qt, that's definetely working as expected. Also, I'm using a
syncing app for a cloud service based on Owncloud (or Nextcloud), the Linux
Client is based on the Owncloud Linux client, which also is based on Qt5,
also working with a tray icon as expected.
Other than that, I don't really know that many Qt based apps, even less
that can make use of a tray icon, and then less that are already based on
Qt 6, independent of their use of tray icons.

Richard

Am Mi., 17. Jan. 2024 um 15:24 Uhr schrieb A. Klitzing :

> Hi there,
>
> the AusweisApp has no autostart option on Linux. Did you add the
> AusweisApp to autostart by yourself? Why is it expected that the app
> should be in foreground if the systems starts? It is a service
> application like a "daemon" that waits until a users click on a
> eID-link in the browser. As a work-around you can add "--show" to
> cmdline option to start in foreground.
>
> The app uses Qt for the TrayIcon. We can show "Open" on Linux like we
> do for macOS if you like. You can see in Qt doc [2] the possible
> activation reason. Currently we use "Trigger" to show up the UI. This
> works for me on KDE. I tried Gnome on Debian right now and it requires
> a double-click. This looks like a bug in Qt or not documented
> behaviour. Do you know a Qt app with QSystemTrayIcon that works like
> you expected? So I can look into that.
>
> Best regards
> André
>
>
> [1]
> https://github.com/Governikus/AusweisApp/blob/master/src/ui/qml/TrayIcon.cpp#L112
> [2] https://doc.qt.io/qt-6/qsystemtrayicon.html#ActivationReason-enum
>
> --
> To unsubscribe, send mail to 1031956-unsubscr...@bugs.debian.org.
>

Bug#1059546: pylint generates false positive 'import-error' with local editable modules.

[Sandro Tosi]

since you have not provided an easily replicable setup environment,
please go ahead and test with the newly uploaded pylint/3.0.1 and
report back




--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1061059: javaws.sh fails to determine java version if extra java options exist

[Christian Schwamborn]

With a little less 'cutting' it seems to work, but I tested it only
against openjdk 8, 11 and 17. I didn't understand the need of the first
call of "cut -d'-' -f1" anyways.

--- javaws_orig.sh  2024-01-17 16:25:24.601970808 +0100
+++ javaws.sh   2024-01-17 16:25:57.982161672 +0100
@@ -97,9 +97,9 @@
 # Support Modular JDK (jigsaw):
 MODULAR_JDK="NO"
 fullversion=`${JAVA} -version 2>&1`
-version=`echo $fullversion | head -n 1 | cut -d'-' -f1 | cut -d'"' -f2
| cut -d'.' -f1`
+version=`echo $fullversion | head -n 1 | cut -d'"' -f2 | cut -d'.' -f1`
 if [ "$version" -eq "1" ]; then
-  version=`echo $fullversion | head -n 1 | cut -d'-' -f1 | cut -d'"'
-f2 | cut -d'.' -f2`
+  version=`echo $fullversion | head -n 1 | cut -d'"' -f2 | cut -d'.' -f2`
 fi
 if [ "$version" -ge "9" ]; then
   MODULAR_JDK="YES"

Bug#1059546: pylint generates false positive 'import-error' with local editable modules.

[Mike Castle]

Sorry.  I now realize that changing my local PROMPT to be the default
'$ ', I dropped an important bit of information.

The file, `t.py` is NOT in the same directory as `pyproject.toml`.
That is, while t.py was $HOME for the test, the pyproject.toml file
and associated source was in some $RANDOM directory.

Just like, if I have two python projects, A and B, living in
completely different source directories, and A depends on B.

If B is installed in normal mode, pylint against A works fine.
However, if B is installed with 'pip -e', then pylint against A cannot
find B.

mrc

Bug#1061077: golang-github-gookit-color: FTBFS in ubuntu due to unknown TERM env

[upils]

Package: golang-github-gookit-color
Version: 1.5.4-2
Severity: serious
Tags: ftbfs patch
Justification: fails to build from source
X-Debbugs-Cc: paul.m...@canonical.com

Dear Maintainer,

In ubuntu this package FTBFS because the TERM env var is set to unknown,
thus preventing some tests from working properly.

This is fixed by setting TERM to a "valid" value. Here is a patch:


diff -Nru golang-github-gookit-color-1.5.4/debian/rules 
golang-github-gookit-color-1.5.4/debian/rules
--- golang-github-gookit-color-1.5.4/debian/rules   2023-10-23 
19:08:31.0 +0200
+++ golang-github-gookit-color-1.5.4/debian/rules   2024-01-17 
15:54:30.0 +0100
@@ -3,5 +3,7 @@
 export DH_GOLANG_EXCLUDES := _examples/
 export DH_GOLANG_INSTALL_EXTRA := README.md

+export TERM=xterm-256color
+
 %:
dh $@ --builddirectory=_build --buildsystem=golang --with=golang



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

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

Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator

[Richard]

Am Di., 16. Jan. 2024 um 20:41 Uhr schrieb John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de>:

> > Who says I am? I am running testing. Also, getting security updates
> from unstable is actually
> > recommended behavior, so the stuff around "FrankenDebian" is
> contradicting itself.
>
> There is no version 2.0.x in Debian stable nor stable-backports yet, so
> unless you built the
> package yourself from the unstable sources or installed the Flatpak
> version, you created a
> "FrankenDebian".
>
To be quoting myself:  *I am running testing**. AKA Trixie. *So no, there's
no FrankenDebian at work.

>
> And, no, the wiki page regarding "FrankenDebian" is not contradicting
> itself because security
> updates are provided through debian-security. These updates are built to
> target Debian stable,
> so it's perfectly fine to install them without risking to break anything.
>
It is not contradicting itself page-wide, but wiki-wide. This is the Wiki
entry for Debian Testing, where it literally recommends to do what the
"FrankenDebian" Wiki page recommends not to do:
https://wiki.debian.org/DebianTesting

*It is a good idea to install security updates from unstable since they
take extra time to reach testing and the security team only releases
updates to unstable.*

> > Entitled? Well that's rich. The point of the whole bug reporting system
> is exactly what we
> > are doing here. So yes, if you are unwilling to maintain the
> package, which will always
> > include getting bug reports if things don't behave as intended, then
> don't do it.
>
> Not really. If someone steps up to maintain something, it doesn't
> automatically mean they
> are responsible for supporting all possible configurations that exist
> within Debian which
> is what you are asking for. The package works perfectly fine on KDE which
> is what I am using
> myself.
>
This is exactly what it's supposed to mean. Packages distributed by Debian
are obviously required to not be broken when they hit stable. Otherwise an
update wouldn't be accepted to  be sent to stable. And since neither Debian
with KDE nor Debian with Gnome is a separate distribution, obviously a
package is supposed to work with both. That's why all KDE packages will
pull in all necessary dependencies required to run in Gnome (or any other
DE offered by Debian) and vice versa. If any package would be allowed in
stable in a theoretical future where it only supports Wayland and not X
while not all available DEs would be supporting Wayland would be very
questionable. And that's just another version of this exact problem.

>
> The limitations around GNOME support are an upstream issue and not related
> to packaging which
> is what I am doing. Claiming that a particular issue that is not a serious
> bug must be fixed
> before the next release is something that I would call entitlement. If you
> have figured out
> how to fix this particular problem, you are free to send a patch to me or
> upstream. That's
> how it works with community-maintained software.
>

It's obviously serious since it literally renders the software unusable for
some users. If you have a different opinion, you should really re-read the
severity levels' definitions:
https://www.debian.org/Bugs/Developer#severities
*important: a bug which has a major effect on the usability of a package,
without rendering it completely unusable to everyone.*
This is literally what this is.

>
> Neither me nor the upstream maintainer are actually getting paid to
> provide this application
> on Linux or on Debian, so it's perfectly fine that we get to decide how we
> spend our free
> time.
>
Nobody said otherwise. But literally with a bug this severe v2 can't and
shouldn't be accepted into stable with Trixie. And if nobody fixes it, it's
questionable how long this package will be accepted to stay in the repos at
all.

Bug#1061076: kbtin: FTBFS with stack-clash-protection on armhf due to valgrind segfault

[Emanuele Rocca]

Source: kbtin
Version: 2.1-2
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: 32bit-stackclash

Hi,

kbtin currently fails to build from source on armhf. The failure is due
to an incompatibility between valgrind and stack-clash-protection on
32bit arm reported upstream at:
https://bugs.kde.org/show_bug.cgi?id=479699

While waiting for valgrind to get updated, please cosider addressing the
immediate issue by disabling stack-clash-protection on armhf with the
following snippet in d/rules:

  ifeq ($(DEB_TARGET_ARCH),armhf)
export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-stackclash
  else
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
  endif

You can find the full build logs at:
http://qa-logs.debian.net/2024/01/11/armhf/kbtin_2.1-2_unstable-armhf.log

The error is:

3: ==1751922== 
3: ==1751922== Process terminating with default action of signal 11 (SIGSEGV)
3: ==1751922==  Access not within mapped region at address 0xFEC93DC8
3: ==1751922==at 0x118336: read_rc_file.isra.0 (main.c:301)
3: ==1751922==by 0x10F025: read_rc (main.c:319)
3: ==1751922==by 0x10F025: main (main.c:374)
3: ==1751922==  If you believe this happened as a result of a stack
3: ==1751922==  overflow in your program's main thread (unlikely but
3: ==1751922==  possible), you can try to increase the size of the
3: ==1751922==  main thread stack using the --main-stacksize= flag.
3: ==1751922==  The main thread stack size used in this run was 8388608.
3: --- "/<>/tests/data/#chr, #ord, #hexord (7-bit ASCII).out"  
2022-11-06 21:51:48.0 +

Thanks,
  Emanuele

Bug#1059911: [Pkg-utopia-maintainers] Bug#1059911: System crashes when switching off WiFi

[Michael Biebl]

Control: reassign -1 src:linux
Control: found -1 6.1.0-17

Am 03.01.24 um 14:09 schrieb Lohner Roland:

Subject: network-manager: System crashes when switching of WiFi
Package: network-manager
Version: 1.42.4-1
Severity: normal

Dear Maintainer,

WiFi is on and connected. I push WiFi button in Gnome panel to switch 
WiFi off. Or switch of WiFi with keyboard function shortcut.
The whole system freezes. It is unable to start programs, or to do 
"sudo" in terminal. It is even unable to stop the laptop.

I have to force shutdown with long pushing power button.

Debian 12.04
Dell E7450

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

Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT)


Since upgrading the kernel fixed this issue, I'm reassigning the bug report.



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055228: Bug#1055750: Bug#1055228: plplot: FTBFS on armhf (test segfault)

[Emanuele Rocca]

Hi Rafael,

as a workaround for this issue, you could disable stack-clash-protection
when building for armhf. The following snippet in debian/rules should do
the trick:

  ifeq ($(DEB_TARGET_ARCH),armhf)
DEB_BUILD_MAINT_OPTIONS = hardening=+all,-stackclash
  else
DEB_BUILD_MAINT_OPTIONS = hardening=+all
  endif

Thanks,
  Emanuele

Bug#1000068: libapache2-mod-auth-cas: depends on obsolete pcre3 library

[Thijs Kinkhorst]

Hi,

> Your package still depends on the old, obsolete PCRE3[0] libraries
> (i.e. libpcre3-dev).

Thanks for the report. Indeed there's work ongoing upstream to fix this.
I'm monitoring this and we hope to get a working version well in time for
trixie.


Kind regards,
Thijs

Bug#1060658: [Debian-on-mobile-maintainers] Bug#1060658: Bug#1060658: megapixels don't start could not find any config file

[Guido Günther]

Hi,
On Wed, Jan 17, 2024 at 02:17:53PM +0530, Pirate Praveen wrote:
> 
> 
> On 16/01/24 10:01 pm, Arnaud Ferraris wrote:
> > Hi,
> > 
> > Le 12/01/2024 à 10:37, Pirate Praveen a écrit :
> > > Package: megapixels
> > > Version: 1.7.0-1
> > > Severity: grave
> > > 
> > > Running megapixels from commandline on mobian trixie fails with this error
> > > 
> > > /usr/share/megapixels/config/purism,librem5r4.ini not found.
> > 
> > This is expected, megapixels doesn't support the L5 (yet?).
> 
> I was looking at a blog post for QR code readers and mega pixel was
> mentioned
> 
> https://forums.puri.sm/t/qr-code-scanning-via-megapixels/14408
> 
> Found another reference now https://blog.brixit.nl/megapixels-2-0/
> 
> but seems this never finished.

On the L5 you can use millipixels (which is a fork of megapixels) for QR
code scanning. I've filed #1060921 to track L5 support in megapixels.

Cheers,
 -- Guido

> 
> ___
> Debian-on-mobile-maintainers mailing list
> debian-on-mobile-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers

Bug#1058932: RFP: forgejo -- a self-hosted lightweight software forge

[Wim Bertels]

On Mon, 25 Dec 2023 11:36:59 +0800 Maytham Alsudany
 wrote:
> 
> There's already an RFP for gitea (#935834), which forgejo is based
on. 
> 

Hello Maytham,

there is a comparison available on:
https://forgejo.org/compare/

to me it looks like forgejo has more a full open source (main) spirit?

mvg,
Wim

Bug#742337: t1lib is no longer part of Debian

[Georges Khaznadar]

... and packages expeyes, grace no longer depends on t1lib, so I close
this bug report. Feel free to reopen it if necessary.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1041212: Logs

[A. Klitzing]

Hi there,

that sounds strange. I tried it with telegram notification and it
works without problems. Do you have a log file of the AusweisApp?

Best regards
   André

Bug#1061075: release.debian.org: Cross compilation of kernel modules for arm64 on bookworm is broken

[Felix Moessbauer]

Package: release.debian.org
Severity: normal


The following dependencies need to be installed to cross compile a
kernel module on debian bookworm, arm64:
build-essential:amd64 crossbuild-essential-arm64:amd64 linux-headers-arm64

Currently, these have conflicting dependencies around gcc or binutils:

| The following packages have unmet dependencies:
|  g++-12 : Depends: gcc-12 (= 12.2.0-14) but it is not installable
|  cpp : Depends: cpp-12 (>= 12.2.0-1~) but it is not installable
|  g++ : Depends: gcc-12 (>= 12.2.0-1~) but it is not installable
|  gcc : Depends: gcc-12 (>= 12.2.0-1~) but it is not installable
|  dpkg-dev : Depends: binutils but it is not installable
|  gcc-12-aarch64-linux-gnu : Depends: binutils-aarch64-linux-gnu (>= 2.40)

Best regards,
Felix Moessbauer
Siemens AG

Bug#1031956: TrayIcon

[A. Klitzing]

Hi there,

the AusweisApp has no autostart option on Linux. Did you add the
AusweisApp to autostart by yourself? Why is it expected that the app
should be in foreground if the systems starts? It is a service
application like a "daemon" that waits until a users click on a
eID-link in the browser. As a work-around you can add "--show" to
cmdline option to start in foreground.

The app uses Qt for the TrayIcon. We can show "Open" on Linux like we
do for macOS if you like. You can see in Qt doc [2] the possible
activation reason. Currently we use "Trigger" to show up the UI. This
works for me on KDE. I tried Gnome on Debian right now and it requires
a double-click. This looks like a bug in Qt or not documented
behaviour. Do you know a Qt app with QSystemTrayIcon that works like
you expected? So I can look into that.

Best regards
André


[1] 
https://github.com/Governikus/AusweisApp/blob/master/src/ui/qml/TrayIcon.cpp#L112
[2] https://doc.qt.io/qt-6/qsystemtrayicon.html#ActivationReason-enum

Bug#1060388: sponsor for endless-sky

[Bo YU]

Hi!

On Wed, Jan 17, 2024 at 8:07 PM Bo YU  wrote:
>
> Hi!
>
> On Wed, Jan 17, 2024 at 12:21 PM P. J. McDermott  wrote:
> >
> > On 2024-01-17 at 10:22, Bo YU wrote:
> > > Hi,
> > >
> > > First sorry without contacting here before NMU.
> >
> > Welcome!
> >
> > > I am looking for a sponsor for my package "endless-sky":
> >
> > I'm not a DD, but I gave this a look and have a couple comments.
> >
> > >  * Vcs  : https://salsa.debian.org/games-team/endless-sky
> >

>
> I have salsa account also and I think I will wait this for one or two
> days to see how happened. If there is no DD have time to upload it and
> then I will send MR to here.

Now I open MRs to submit upload to it:
https://salsa.debian.org/games-team/endless-sky/-/merge_requests

So please review it there.
Thanks.

BR,
Bo

>
> BR,
> Bo

Bug#1058937: Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts

[Helmut Grohne]

On Fri, Jan 12, 2024 at 01:31:18PM +0100, Helmut Grohne wrote:
> The relevant situation is not entirely trivial to construct:
> 
>  * Package $first contains an aliased file $file and this is moved to
>package $second in an update.
>OR
>Package $first diverts aliased location $file normally owned by
>package $second.
> 
>  * An update to package $second moves $file to its physical location
>below /usr.
> 
>  * Package $second declares a versioned conflict for package $first with
>any version that contains or diverts the aliased $file.
> 
> Then we can construct a file loss scenario:
> 
>  * Install package $first.
>  * Schedule $first for removal:
>echo "$first remove" | dpkg --set-selections
>  * Install the updated $second:
>dpkg --unpack $second.deb

I somehow missed how Ben's libnfsidmap bug #1058937 works slightly
simpler. Given that $second has a conflict with the installed version of
$first, one can skip that second step and instead install $second
directly with dpkg -i. So no, this weird selections stuff is not
technically necessary.

In general, when doing these dances there are two outcomes. Either,
$first is unpacked (or removed) before $second is unpacked or the other
way round. The latter case always shows a message like this:

dpkg: considering removing $first in favour of $second ...
dpkg: yes, will remove $first in favour of $second

It is these cases that exhibit the buggy behaviour.

> In most upgrade scenarios, apt will remove/upgrade package $first before
> performing the unpack of $second. In these cases, no loss happens.

I tried to get an idea of what "most" means precisely. For one thing, I
constructed various bullseye->bookworm and bookworm->unstable upgrades
followed by dpkg --verify. This included large installations such as
task-gnome-desktop with recommends and targeted cases where I hoped to
find problems such as upgrading molly-guard or nfs-ganesha or and a few
more. In none of the cases (where doing plain apt-get dist-upgrade), I
was able to make dpkg --verify unhappy.

Another route was searching for existing evidence. piuparts has lots of
logs of upgrading packages and in >= bookworm, I found exactly one
having that "yes, will remove" content. It was
https://piuparts.debian.org/testing2sid/pass/rubber_1.6.0-2.log and
that's due to texlive-base declaring a versioned Conflict with
texlive-latex-base and texlive-latex-base declaring versioned Breaks
with texlive-base. This is the mutual Conflicts case that also broke
stuff in a draft patch for molly-guard. This data point confirms what
David Kalnischkies said about this earlier: In the absence of mutual
conflicts, apt removes $first before unpacking $second.

I also tried a web search for "yes, will remove" and really most of logs
I found, dpkg was used directly (though without --set-selections). That
texlive mutual conflict was an exception. Evidently, this is rarely
happening on real installations.

> Therefore, I hope that the loss cannot be experienced when upgrading
> with apt or frontends using apt such as aptitude, but there is no proof
> of this.

So all the evidence I found confirms the guess that the problem cannot
be observed with apt unless mutual conflicts exist. On the flip side,
simply installing a package that declares Conflicts occasionally
triggers this and if you happen to do this to a package that replaces
aliased files, then your files vanish.

In particular, this raises the question whether we consider the upgrade
that Ben describes in #1058937 as supported or whether we can close the
bug. In effect, that's the question to ask here.

I note that netplan.io/0.107.1-2/#1060661 just opted for not doing
Conflicts and instead employed protective diversions (M8). In principle,
we could generally prefer M8 (for P1, but not for P7) and thereby reduce
the problem at the cost of making the mitigation more complex. At least
for the essential set, there is not much choice as employing Conflicts
is known to lead to bad things.

> One takeaway from the CTTE meeting was that this loss should be
> mitigated when it may make a system unbootable. That is a property that
> is difficult to capture and would likely require mitigating half of the
> conflicts.

While this may seem like an obvious rule-of-thumb, it very much is
not. For many of the packages, one can plausibly construct crazy boot
schemes involving them. Though cryptsetup quite clearly falls within
scope.

> The way of mitigation also is non-trivial. In the window between unpack
> of files that will be lost and actual loss, no maintainer script is run
> reliably. Hence, copies of affected files have to be installed
> elsewhere:
>  * systemd-sysv looses only symlinks whose target is specified in
>postinst.
>  * gzip looses shell scripts that will be embedded in its postinst.
>  * For larger files such as dhclient, we consider moving the file to an
>unaffected location and then pointing a symlink at it such that 

Bug#728752: [getbuildlog] get compressed buildlogs

[Jakub Wilk]

* James McCoy , 2013-11-20 00:58:

On Mon, Nov 04, 2013 at 10:12:45PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
Since gcc became mor everbose on it builds it's not strange to find 
enourmous build logs (200+MB).


It would be really cool if getbuildlog could get the compressed 
buildlog to save bandwith.


You may want to give pkgkde-getbuildlogs (from pkg-kde-tools) a try: it 
requests compressed responses and (IMHO) has a nicer API.


As far as I know, there isn't a "compressed buildlog" available.  We 
could change our wget call to specify "Accept-Encoding: deflate, gzip"


Yup, that should be a matter of passing --compress=auto to wget.


but that relies on the server being configured to offer compression.


buildd.debian.org supports it. :) That said, it seems it compresses the 
logs on the fly, which slows down things significantly. For example:


   $ 
url='https://buildd.debian.org/status/fetch.php?pkg=gcc-12=i386=12.3.0-13=1702656593=1'
   $ wget "$url" -O /dev/null
   --2024-01-17 13:53:58--  
https://buildd.debian.org/status/fetch.php?pkg=gcc-12=i386=12.3.0-13=1702656593=1
   Resolving buildd.debian.org (buildd.debian.org)... 2607:f8f0:614:1::1274:60, 
209.87.16.60
   Connecting to buildd.debian.org 
(buildd.debian.org)|2607:f8f0:614:1::1274:60|:443... connected.
   HTTP request sent, awaiting response... 200 OK
   Length: unspecified [text/plain]
   Saving to: ‘/dev/null’

   /dev/null [ <=>  ]  48.09M  15.6MB/sin 3.4s

   2024-01-17 13:54:02 (14.2 MB/s) - ‘/dev/null’ saved [50423419]

   $ wget --compress=auto "$url" -O /dev/null
   --2024-01-17 13:54:08--  
https://buildd.debian.org/status/fetch.php?pkg=gcc-12=i386=12.3.0-13=1702656593=1
   Resolving buildd.debian.org (buildd.debian.org)... 2607:f8f0:614:1::1274:60, 
209.87.16.60
   Connecting to buildd.debian.org 
(buildd.debian.org)|2607:f8f0:614:1::1274:60|:443... connected.
   HTTP request sent, awaiting response... 200 OK
   Length: unspecified [text/plain]
   Saving to: ‘/dev/null’

   /dev/null [ <=>  ]   2.70M  1.05MB/sin 2.6s

   2024-01-17 13:54:12 (1.05 MB/s) - ‘/dev/null’ saved [50423419]

The compressed log was ~18 times smaller, but the download took only 25% 
less time. It's not clear --compress=auto is always going be a net 
benefit.


--
Jakub Wilk

Bug#1061074: ITP: golang-github-hugelgupf-p9 -- p9 implementation written in golang

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist

* Package name: golang-github-hugelgupf-p9
  Version : 0.3.0
  Upstream Author : gvisor authors
* URL or Web page : https://github.com/hugelgupf/p9
* License : Apache 2.0
  Description : p9 implementation written in golang

This package provides a p9 server and client implementation written in
 golang. It is part of the gvisor security platform.

Intend to maintain this under the pkg-golang umbrella. It is a new
dependency of podman (used by podman machine to transfer files to VMs it
manages).

Bug#1061066: Debian Trixie package gir1.2-freedesktop & gir1.2-glib-2.0 breaks sysstem

[Tom Kleingeld]

On Wed, 17 Jan 2024 at 10:44:52 +, Simon McVittie wrote:


On Wed, 17 Jan 2024 at 10:21:09 +0100, Tom Kleingeld wrote:

Package: gir1.2-freedesktop
Version: 1.78.1-10

Apt removes gnome-shell, gnome-session, gdm and others (gnome) and breaks
system


I tried upgrading a GNOME virtual machine from an outdated version of
trixie to current trixie, and that did not reproduce this problem.
The only packages that were held back by `apt upgrade` were unrelated to
gobject-introspection (related to the Boost version transition).


What command are you using to upgrade? An ordinary `apt upgrade` should
not be proposing to remove packages.


According to a reply sent privately, the answer is that it was synaptic
and not apt that removed (proposed to remove?) these packages.


What was logged in /var/log/apt/history.log and /var/log/apt/term.log
during this upgrade?


Please could you answer this? It will help to figure out why this
happened. Please reply to the bug address rather than to me personally,
so that other team members are able to help you.

It would also be helpful to see the output of:

apt --dry-run dist-upgrade

which will help us to see why apt is now holding back these packages.

Thanks,
smcv

---

output:
# apt --dry-run dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  gir1.2-girepository-2.0
The following packages will be upgraded:
  gir1.2-freedesktop gir1.2-glib-2.0
2 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Inst gir1.2-freedesktop [1.78.1-6] (1.78.1-10 Debian:testing [amd64]) []
Inst gir1.2-glib-2.0 [1.78.1-6] (1.78.1-10 Debian:testing [amd64]) 
[python3-gi:amd64 libgjs0g:amd64 ]
Inst gir1.2-girepository-2.0 (1.78.1-10 Debian:testing [amd64])
Conf gir1.2-freedesktop (1.78.1-10 Debian:testing [amd64])
Conf gir1.2-glib-2.0 (1.78.1-10 Debian:testing [amd64])
Conf gir1.2-girepository-2.0 (1.78.1-10 Debian:testing [amd64])

Seems like after # apt upgrade now synaptic updates gir1.2-freedesktop 
gir1.2-glib-2.0 without removing gnome packages.
Only thing that changed to the system was installing fonts-droid-fallback.

Sorry for sending private message. I am kind of new to debian / bugreporting.

Regards,
TomK

Bug#1060057: lirc: diff for NMU version 0.10.2-0.5

[Gianfranco Costamagna]

Package: lirc
Version: 0.10.2-0.4
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for lirc (versioned as 0.10.2-0.5) and
uploaded it1060...@bugs.debian.org.

Regards.

Gianfranco
diff -Nru lirc-0.10.2/debian/changelog lirc-0.10.2/debian/changelog
--- lirc-0.10.2/debian/changelog2024-01-08 16:30:19.0 +0100
+++ lirc-0.10.2/debian/changelog2024-01-17 14:21:20.0 +0100
@@ -1,3 +1,14 @@
+lirc (0.10.2-0.5) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Michael Biebl ]
+  * Update dependency to systemd-dev (Closes: #1060557)
+  [ Svante Signell, Samuel Thibault ]
+  * Fix build on hurd (Closes: #1060093)
+
+ -- Gianfranco Costamagna   Wed, 17 Jan 2024 
14:21:20 +0100
+
 lirc (0.10.2-0.4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru lirc-0.10.2/debian/control lirc-0.10.2/debian/control
--- lirc-0.10.2/debian/control  2024-01-08 16:30:19.0 +0100
+++ lirc-0.10.2/debian/control  2024-01-17 14:21:18.0 +0100
@@ -20,7 +20,7 @@
  libasound2-dev [linux-any kfreebsd-any],
  libftdi1-dev,
  libpython3-dev (>= 3.5),
- libsystemd-dev [linux-any],
+ systemd-dev [linux-any],
  libudev-dev [linux-any],
  libusb-dev,
  libusb-1.0-0-dev,
diff -Nru lirc-0.10.2/debian/patches/include_media_lirc.h.diff 
lirc-0.10.2/debian/patches/include_media_lirc.h.diff
--- lirc-0.10.2/debian/patches/include_media_lirc.h.diff1970-01-01 
01:00:00.0 +0100
+++ lirc-0.10.2/debian/patches/include_media_lirc.h.diff2024-01-17 
14:21:20.0 +0100
@@ -0,0 +1,133 @@
+Description:
+ Lirc FTBFS on HURD
+ This is due to usage of __u32 (and __u16,__u64) in
+ include/media/lirc.h, which is not defined on GNU/Hurd. Additionally
+ inclusion of header files is ifdef-ed and config.h is included.
+
+Author: Svante Signell 
+Bug-Debian: https://bugs.debian.org/1060093
+
+Index: lirc-0.10.2/include/media/lirc.h
+===
+--- lirc-0.10.2.orig/include/media/lirc.h
 lirc-0.10.2/include/media/lirc.h
+@@ -6,8 +6,27 @@
+ #ifndef _LINUX_LIRC_H
+ #define _LINUX_LIRC_H
+ 
++#include "config.h"
++
++#ifdef HAVE_STDINT_H
++#include 
++#endif
++
++#ifdef HAVE_LINUX_TYPES_H
+ #include 
++#endif
++
++#ifdef HAVE_LINUX_IOCTL_H
+ #include 
++#endif
++
++#ifdef HAVE_SYS_IOCTL_H
++#include 
++#endif
++
++#ifdef __GNU__
++#include 
++#endif
+ 
+ #define PULSE_BIT   0x0100
+ #define PULSE_MASK  0x00FF
+@@ -93,55 +112,55 @@
+ 
+ /*** IOCTL commands for lirc driver ***/
+ 
+-#define LIRC_GET_FEATURES  _IOR('i', 0x, __u32)
++#define LIRC_GET_FEATURES  _IOR('i', 0x, uint32_t)
+ 
+-#define LIRC_GET_SEND_MODE _IOR('i', 0x0001, __u32)
+-#define LIRC_GET_REC_MODE  _IOR('i', 0x0002, __u32)
+-#define LIRC_GET_REC_RESOLUTION_IOR('i', 0x0007, __u32)
++#define LIRC_GET_SEND_MODE _IOR('i', 0x0001, uint32_t)
++#define LIRC_GET_REC_MODE  _IOR('i', 0x0002, uint32_t)
++#define LIRC_GET_REC_RESOLUTION_IOR('i', 0x0007, uint32_t)
+ 
+-#define LIRC_GET_MIN_TIMEOUT   _IOR('i', 0x0008, __u32)
+-#define LIRC_GET_MAX_TIMEOUT   _IOR('i', 0x0009, __u32)
++#define LIRC_GET_MIN_TIMEOUT   _IOR('i', 0x0008, uint32_t)
++#define LIRC_GET_MAX_TIMEOUT   _IOR('i', 0x0009, uint32_t)
+ 
+ /* code length in bits, currently only for LIRC_MODE_LIRCCODE */
+-#define LIRC_GET_LENGTH_IOR('i', 0x000f, __u32)
++#define LIRC_GET_LENGTH_IOR('i', 0x000f, uint32_t)
+ 
+-#define LIRC_SET_SEND_MODE _IOW('i', 0x0011, __u32)
+-#define LIRC_SET_REC_MODE  _IOW('i', 0x0012, __u32)
++#define LIRC_SET_SEND_MODE _IOW('i', 0x0011, uint32_t)
++#define LIRC_SET_REC_MODE  _IOW('i', 0x0012, uint32_t)
+ /* Note: these can reset the according pulse_width */
+-#define LIRC_SET_SEND_CARRIER  _IOW('i', 0x0013, __u32)
+-#define LIRC_SET_REC_CARRIER   _IOW('i', 0x0014, __u32)
+-#define LIRC_SET_SEND_DUTY_CYCLE   _IOW('i', 0x0015, __u32)
+-#define LIRC_SET_TRANSMITTER_MASK  _IOW('i', 0x0017, __u32)
++#define LIRC_SET_SEND_CARRIER  _IOW('i', 0x0013, uint32_t)
++#define LIRC_SET_REC_CARRIER   _IOW('i', 0x0014, uint32_t)
++#define LIRC_SET_SEND_DUTY_CYCLE   _IOW('i', 0x0015, uint32_t)
++#define LIRC_SET_TRANSMITTER_MASK  _IOW('i', 0x0017, uint32_t)
+ 
+ /*
+  * when a timeout != 0 is set the driver will send a
+  * LIRC_MODE2_TIMEOUT data packet, otherwise LIRC_MODE2_TIMEOUT is
+  * never sent, timeout is disabled by default
+  */
+-#define LIRC_SET_REC_TIMEOUT   _IOW('i', 0x0018, __u32)
++#define LIRC_SET_REC_TIMEOUT   _IOW('i', 0x0018, uint32_t)
+ 
+ /* 1 enables, 0 disables timeout reports in MODE2 */
+-#define LIRC_SET_REC_TIMEOUT_REPORTS   _IOW('i', 0x0019, 

Bug#1060101: Boost 1.81 removal

[Dirk Eddelbuettel]

On 14 January 2024 at 06:49, Dirk Eddelbuettel wrote:
| 
| FYI two days before you filed #1060101 I actually happened to have updated
| r-cran-bh to 1.84.0 (upstream, which is me, went to the 1.84.0 version
| released in December as Boost releases every four months) using 1.83:
| 
|r-cran-bh (1.84.0-1) unstable; urgency=medium
| 
|  * debian/control: Update Depends back to libboost-dev which will ensure
|use of Boost 1.83 matching the just-updated BH package at CRAN which
|is now at Boost 1.84 (released in December) which should be close
|enough for our needs; a versioned name is no longer needed as the
|default is now 1.83.0-2+b2
|
|  * debian/control: Set Build-Depends: to current R version
|  * debian/control: Switch to virtual debhelper-compat (= 13)
| 
| -- Dirk Eddelbuettel   Wed, 10 Jan 2024 07:20:09 -0600
| 
| So this should sort itself out by itself in a matter of days. r-cran-bh is
| healthy:
| 
|https://tracker.debian.org/pkg/r-cran-bh

And it did, as expected. So no issues from r-cran-bh.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1061073: dfwinreg: please package version 20221218

[Alexandre Detiste]

Source: dfwinreg
Version: 20201006-1.1
Severity: normal

Hi,

I'm investigating the removal of old, depreaced, pitfall libraries
python3-six & python3-mock.

Please package the new release and check if these dependencies
are still needed.

(I can do the work via a Salsa MR)

Greetings


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1060388: sponsor for endless-sky

[Bo YU]

Hi!

On Wed, Jan 17, 2024 at 12:21 PM P. J. McDermott  wrote:
>
> On 2024-01-17 at 10:22, Bo YU wrote:
> > Hi,
> >
> > First sorry without contacting here before NMU.
>
> Welcome!
>
> > I am looking for a sponsor for my package "endless-sky":
>
> I'm not a DD, but I gave this a look and have a couple comments.
>
> >  * Vcs  : https://salsa.debian.org/games-team/endless-sky
>
> Do you have an account on Salsa?  You could fork the repository and
> submit an MR so that the changes are ready to merge and upload.  If not,
> that's OK; I think the changes are small enough for one of us to just
> commit in one shot.

Thanks.

I have salsa account also and I think I will wait this for one or two
days to see how happened. If there is no DD have time to upload it and
then I will send MR to here.

BR,
Bo
>
> >  endless-sky (0.10.4-0.1) UNRELEASED; urgency=medium
> >  .
> >* Non-maintainer upload.
> >* New upstream version 0.10.4. (Closes: #1059987)
> >* rebase debian/patches
>
> I see out/troff.patch and out/spelling.patch were applied upstream and
> removed from debian/patches/series, but the patch files are still under
> debian/patches/.  They should be removed.
>
> >* Change Build-Depends on 'cmake' to'cmake (>= 3.21)'.
> >  (Closes: #1054624).
>
> (Coincidentally, seeing this bug on Friday reminded me to do a similar
> cmake B-D version bump in another package.)
>
> Other than the suggestions of Git and removing patch files, this looks
> OK to me for an NMU.  But of course it needs a DD's review (ideally
> Damyan).
>
> Since the changes are apparently not in Git, here's the diff I
> reviewed:
>
>  changelog |   10 ++
>  control   |2 +-
>  patches/atomics.patch |   29 ++---
>  patches/series|2 --
>  4 files changed, 29 insertions(+), 14 deletions(-)
> ---
> diff -Naur endless-sky-0.10.2/debian/changelog 
> endless-sky-0.10.4/debian/changelog
> --- endless-sky-0.10.2/debian/changelog 2023-10-10 10:57:15.0 -0400
> +++ endless-sky-0.10.4/debian/changelog 2024-01-07 20:42:17.0 -0500
> @@ -1,3 +1,13 @@
> +endless-sky (0.10.4-0.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * New upstream version 0.10.4. (Closes: #1059987)
> +  * rebase debian/patches
> +  * Change Build-Depends on 'cmake' to'cmake (>= 3.21)'.
> +(Closes: #1054624).
> +
> + -- Bo YU   Mon, 08 Jan 2024 09:42:17 +0800
> +
>  endless-sky (0.10.2-6) unstable; urgency=medium
>
>[ Adrian Bunk ]
> diff -Naur endless-sky-0.10.2/debian/control endless-sky-0.10.4/debian/control
> --- endless-sky-0.10.2/debian/control   2023-10-06 09:23:26.0 -0400
> +++ endless-sky-0.10.4/debian/control   2024-01-07 20:42:17.0 -0500
> @@ -8,7 +8,7 @@
>  Vcs-Git: https://salsa.debian.org/games-team/endless-sky.git
>  Homepage: https://endless-sky.github.io
>  Build-Depends:
> - cmake,
> + cmake (>= 3.21),
>   debhelper-compat (= 13),
>   g++ (>=4.6),
>   libgl-dev,
> diff -Naur endless-sky-0.10.2/debian/patches/atomics.patch 
> endless-sky-0.10.4/debian/patches/atomics.patch
> --- endless-sky-0.10.2/debian/patches/atomics.patch 2023-10-05 
> 06:08:09.0 -0400
> +++ endless-sky-0.10.4/debian/patches/atomics.patch 2024-01-07 
> 20:42:17.0 -0500
> @@ -1,17 +1,24 @@
> -Description: link with libatomic
> - On armel and mipsel, there are a bunch of missing __atomic_load_8 symbols
> - during linking
> - .
> - These are provided by libatomic and that is even in the build-dependencies,
> - but is missing on the linker command line.
> - .
> - The right spot to add it is a bit tricky, appending it to SConstrict near
> - 'pthread' doesn't seem to have any effect, but adding to CMakeLists.txt 
> works.
> -Author: Damyan Ivanov 
> +From: Damyan Ivanov 
> +Date: Mon, 8 Jan 2024 07:21:47 +0800
> +Subject: link with libatomic
>
> +On armel and mipsel, there are a bunch of missing __atomic_load_8 symbols
> +during linking
> +
> +These are provided by libatomic and that is even in the build-dependencies,
> +but is missing on the linker command line.
> +
> +The right spot to add it is a bit tricky, appending it to SConstrict near
> +'pthread' doesn't seem to have any effect, but adding to CMakeLists.txt 
> works.
> +---
> + CMakeLists.txt | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/CMakeLists.txt b/CMakeLists.txt
> +index fa0903a..d7807e9 100644
>  --- a/CMakeLists.txt
>  +++ b/CMakeLists.txt
> -@@ -123,7 +123,7 @@ target_link_libraries(ExternalLibraries
> +@@ -125,7 +125,7 @@ target_link_libraries(ExternalLibraries INTERFACE 
> SDL2::SDL2 PNG::PNG JPEG::JPEG
>   if(WIN32)
> target_link_libraries(ExternalLibraries INTERFACE rpcrt4 Winmm)
>   else()
> diff -Naur endless-sky-0.10.2/debian/patches/series 
> endless-sky-0.10.4/debian/patches/series
> --- endless-sky-0.10.2/debian/patches/series2023-10-05 02:53:48.0 
> -0400
> +++ 

Bug#1060346: live-boot-initramfs-tools: Debian Live ISO not bootable on exfat partition (loopback)

[Mexit Dev]

I am sending the corrected patch (manpages):

diff --git a/backend/initramfs-tools/live.hook
b/backend/initramfs-tools/live.hook
index 
ff8f4210690e21961dd5e8c3f1d7b3a5b14d4167..7c476ea6159c0664e47497f82145b6da8391
100755
--- a/backend/initramfs-tools/live.hook
+++ b/backend/initramfs-tools/live.hook
@@ -133,6 +133,12 @@ then
  manual_add_modules vfat
 fi

+# Filesystem: exfat
+if [ "${DISABLE_EXFAT:-}" != "true" ] && [ "${DISABLE_EXFAT:-}" != "yes" ]
+then
+ manual_add_modules exfat
+fi
+
 # Filesystem: ntfs
 if [ "${DISABLE_NTFS:-}" != "true" ] && [ "${DISABLE_NTFS:-}" != "yes" ]
 then
diff --git a/manpages/en/live-boot.7 b/manpages/en/live-boot.7
index 
02b355da2f124208a951ffa428874b9148665f55..5a7ec9824bfb05794108c44f75b7174b1f40ea5e
100644
--- a/manpages/en/live-boot.7
+++ b/manpages/en/live-boot.7
@@ -38,6 +38,10 @@ Disable support for dm-verity. If set to true
\fItrue\fR' mkinitramfs will build
 \fBDISABLE_FAT\fR=[\fItrue\fR|\fIfalse\fR]
 Disable support for booting from FAT file systems.  If set to
'\fItrue\fR' mkinitramfs will build an initramfs without the kernel
module vfat and some nls_* modules.

+.TP
+\fBDISABLE_EXFAT\fR=[\fItrue\fR|\fIfalse\fR]
+Disable support for booting from exFAT file systems.  If set to
'\fItrue\fR' mkinitramfs will build an initramfs without the kernel
module exfat.
+
 .TP
 \fBDISABLE_FUSE\fR=[\fItrue\fR|\fIfalse\fR]
 Disable support for booting from FUSE-based file systems.  If set to
'\fItrue\fR' mkinitramfs will build an initramfs without the kernel
module fuse and file systems that depend on it (like curlftpfs and
httpfs2).
diff --git a/manpages/po/es/live-boot.7.po b/manpages/po/es/live-boot.7.po
index 
28f916cedbe59b89a986f5f1eb72878383bc4219..edc3da10e3a2f7775515211785053853767c8827
100644
--- a/manpages/po/es/live-boot.7.po
+++ b/manpages/po/es/live-boot.7.po
@@ -194,6 +194,19 @@ msgid ""
 "nls_* modules."
 msgstr ""

+#. type: TP
+#: en/live-boot.7:41
+#, no-wrap
+msgid "B=[I|I]"
+msgstr ""
+
+#. type: Plain text
+#: en/live-boot.7:43
+msgid ""
+"Disable support for booting from exFAT file systems.  If set to 'I' "
+"mkinitramfs will build an initramfs without the kernel module exfat."
+msgstr ""
+
 #. type: TP
 #: en/live-boot.7:37
 #, no-wrap
diff --git a/manpages/po/fr/live-boot.7.po b/manpages/po/fr/live-boot.7.po
index 
2f51f42e7ff3c61d434c2038dbd3a9a5c6453dcf..de52868c31bca54e93bcba8f5929874ec7724197
100644
--- a/manpages/po/fr/live-boot.7.po
+++ b/manpages/po/fr/live-boot.7.po
@@ -192,6 +192,19 @@ msgid ""
 "nls_* modules."
 msgstr ""

+#. type: TP
+#: en/live-boot.7:41
+#, no-wrap
+msgid "B=[I|I]"
+msgstr ""
+
+#. type: Plain text
+#: en/live-boot.7:43
+msgid ""
+"Disable support for booting from exFAT file systems.  If set to 'I' "
+"mkinitramfs will build an initramfs without the kernel module exfat."
+msgstr ""
+
 #. type: TP
 #: en/live-boot.7:37
 #, no-wrap
diff --git a/manpages/po/ja/live-boot.7.po b/manpages/po/ja/live-boot.7.po
index 
8a3224748f80845c5c45731d15c0b52e6749f59d..398de013c4c6749a4e5d2d174102a8e0aa719ae2
100644
--- a/manpages/po/ja/live-boot.7.po
+++ b/manpages/po/ja/live-boot.7.po
@@ -189,6 +189,19 @@ msgid ""
 "nls_* modules."
 msgstr ""

+#. type: TP
+#: en/live-boot.7:41
+#, no-wrap
+msgid "B=[I|I]"
+msgstr ""
+
+#. type: Plain text
+#: en/live-boot.7:43
+msgid ""
+"Disable support for booting from exFAT file systems.  If set to 'I' "
+"mkinitramfs will build an initramfs without the kernel module exfat."
+msgstr ""
+
 #. type: TP
 #: en/live-boot.7:37
 #, no-wrap
diff --git a/manpages/pot/live-boot.7.pot b/manpages/pot/live-boot.7.pot
index 
dee33bb55cf9ad13f53c04edc8d2dc1ed08a2030..b37a0361ff16dca067684a92c09fb2609de947ca
100644
--- a/manpages/pot/live-boot.7.pot
+++ b/manpages/pot/live-boot.7.pot
@@ -165,6 +165,19 @@ msgid ""
 "nls_* modules."
 msgstr ""

+#. type: TP
+#: en/live-boot.7:41
+#, no-wrap
+msgid "B=[I|I]"
+msgstr ""
+
+#. type: Plain text
+#: en/live-boot.7:43
+msgid ""
+"Disable support for booting from exFAT file systems.  If set to 'I' "
+"mkinitramfs will build an initramfs without the kernel module exfat."
+msgstr ""
+
 #. type: TP
 #: en/live-boot.7:37
 #, no-wrap

Bug#1061072: wit: debian/watch scans for binary-only release

[Bastian Germann]

Source: wit
Version: 3.01a-4.1

Please scan https://download.wiimm.de/source/wiimms-iso-tools/ which holds the 
latest source release.
The source is also available via GitHub but unfortunately, there are no tags or 
releases.

Bug#1061018: octave-splines: FTBFS: make: *** [debian/rules:5: binary] Error 134

[Sébastien Villemot]

Control: block -1 by 1061049

Le mardi 16 janvier 2024 à 20:43 +0100, Lucas Nussbaum a écrit :
> Source: octave-splines
> Version: 1.3.5-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240115 ftbfs-trixie
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> >  debian/rules binary
> > dh binary --buildsystem=octave
> >dh_update_autotools_config -O--buildsystem=octave
> >dh_autoreconf -O--buildsystem=octave
> >dh_octave_version -O--buildsystem=octave
> > Checking the Octave version... ok
> >dh_auto_configure -O--buildsystem=octave
> >dh_auto_build -O--buildsystem=octave
> >dh_auto_test -O--buildsystem=octave
> >create-stamp debian/debhelper-build-stamp
> >dh_testroot -O--buildsystem=octave
> >dh_prep -O--buildsystem=octave
> >dh_auto_install --destdir=debian/octave-splines/ -O--buildsystem=octave
> > octave --no-gui --no-history --silent --no-init-file --no-window-system 
> > /usr/share/dh-octave/install-pkg.m 
> > /<>/debian/octave-splines/usr/share/octave/packages 
> > /<>/debian/octave-splines/usr/lib/x86_64-linux-gnu/octave/packages
> > For information about changes from previous versions of the splines 
> > package, run 'news splines'.
> >dh_octave_check -O--buildsystem=octave
> > Checking package...
> > Run the unit tests...
> > Checking m files ...
> > [inst/tps_val_der.m]
> > > > > > > /<>/inst/tps_val_der.m
> > * shared a,b,x,y,x1,x2,y1,c,dy,dy0
> >  a = 2; b = -3; x = ([1:2:10 10.5 11.3])'; y = a*x;
> >  c = tpaps(x,y,1);
> > * assert (a*ones(size(x)), tps_val_der(x,c,x), 1E3*eps);
> >  [x1 x2] = meshgrid(x, x);
> >  y1 = a*x1+b*x2;
> >  c = tpaps([x1(:) x2(:)],y1(:),0.5);
> >  dy = tps_val_der([x1(:) x2(:)],c,[x1(:) x2(:)]);
> >  dy0 = tps_val_der([x1(:) x2(:)],c,[x1(:) x2(:)],false);
> > * assert (a*ones(size(x1(:))), dy(:, 1), 1E3*eps);
> > * assert (b*ones(size(x2(:))), dy(:, 2), 1E3*eps); 
> > * assert (dy0, dy, 1E3*eps);
> > 4 tests, 4 passed, 0 known failure, 0 skipped
> > [inst/bin_values.m]
> > > > > > > /<>/inst/bin_values.m
> > * shared x, y, x_bin, y_bin, w_bin, n_bin
> >  x = [1; 2; 2; 3; 4];
> >  y = [0 0; 1 1; 2 1; 3 4; 5 NaN];
> >  [x_bin y_bin w_bin n_bin] = bin_values(x, y);
> > * assert (x_bin, [1; 7/3]);
> > * assert (y_bin, [0 0; 2 2]);
> > * assert (!any(isfinite(w_bin(1, :;
> > * assert (w_bin(2, :), [3 1]);
> > * assert (n_bin, [1; 3]);
> > 5 tests, 5 passed, 0 known failure, 0 skipped
> > [inst/csaps_sel.m]
> > > > > > > /<>/inst/csaps_sel.m
> > * shared x,y,ret,p,sigma2,unc_y
> >  x = [0:0.01:1]'; y = sin(x);
> >  [ret,p,sigma2,unc_y] = csaps_sel(x,y,x);
> > malloc(): invalid size (unsorted)
> > fatal: caught signal Aborted -- stopping myself...
> > Aborted
> > make: *** [debian/rules:5: binary] Error 134

Thanks. This is a consequence of the ABI break in libcholmod5. Tagging
accordingly.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#1061017: octave-divand: FTBFS: make: *** [debian/rules:5: binary] Error 134

[Sébastien Villemot]

Control: block -1 by 1061049

Le mardi 16 janvier 2024 à 20:43 +0100, Lucas Nussbaum a écrit :
> Source: octave-divand
> Version: 1.1.2+dfsg-6
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240115 ftbfs-trixie
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> >  debian/rules binary
> > dh binary --buildsystem=octave
> >dh_update_autotools_config -O--buildsystem=octave
> >dh_autoreconf -O--buildsystem=octave
> >dh_octave_version -O--buildsystem=octave
> > Checking the Octave version... ok
> >dh_auto_configure -O--buildsystem=octave
> >dh_auto_build -O--buildsystem=octave
> >dh_auto_test -O--buildsystem=octave
> >create-stamp debian/debhelper-build-stamp
> >dh_testroot -O--buildsystem=octave
> >dh_prep -O--buildsystem=octave
> >dh_auto_install --destdir=debian/octave-divand/ -O--buildsystem=octave
> > octave --no-gui --no-history --silent --no-init-file --no-window-system 
> > /usr/share/dh-octave/install-pkg.m 
> > /<>/octave-divand-1.1.2\+dfsg/debian/octave-divand/usr/share/octave/packages
> >  
> > /<>/octave-divand-1.1.2\+dfsg/debian/octave-divand/usr/lib/x86_64-linux-gnu/octave/packages
> > For information about changes from previous versions of the divand package, 
> > run 'news divand'.
> >dh_octave_check -O--buildsystem=octave
> > Checking package...
> > Run the unit tests...
> > Checking m files ...
> > [inst/statevector_init.m]
> > > > > > > /<>/inst/statevector_init.m
> > * test
> >  mask = rand(10,10) > .5;
> >  mask_u = rand(9,10) > .5;
> >  mask_v = rand(10,9) > .5;
> >  sv = statevector_init(mask,mask_u,mask_v);
> >  var = rand(10,10); 
> >  var(mask==0) = 0;
> >  var_u = rand(9,10);
> >  var_u(mask_u==0) = 0;
> >  var(mask==0) = 0;
> >  var_v = rand(10,9);
> >  var_v(mask_v==0) = 0;
> >  [E] = statevector_pack(sv,var,var_u,var_v);
> >  [Ezeta2,Eu2,Ev2] = statevector_unpack(sv,E);
> >  assert(Ezeta2,var)
> >  assert(Eu2,var_u)
> >  assert(Ev2,var_v)
> > 1 test, 1 passed, 0 known failure, 0 skipped
> > Checking C++ files ...
> > Run tests in debian/check.m
> > [test_divand]
> > run test_interp_1d: (max difference=2.77556e-16)   OK  
> > run test_interp_2d: (max difference=2.22045e-16)   OK  
> > run test_interp_regular: (max difference=2.22045e-16)   OK  
> > run test_sparse_diff: (max difference=0)   OK  
> > run test_1dvar: malloc(): invalid size (unsorted)
> > fatal: caught signal Aborted -- stopping myself...
> > Aborted
> > make: *** [debian/rules:5: binary] Error 134

Thanks. This is a consequence of the ABI break in libcholmod5. Tagging
accordingly.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#1061066: Debian Trixie package gir1.2-freedesktop & gir1.2-glib-2.0 breaks sysstem

[Simon McVittie]

On Wed, 17 Jan 2024 at 10:44:52 +, Simon McVittie wrote:
> On Wed, 17 Jan 2024 at 10:21:09 +0100, Tom Kleingeld wrote:
> > Package: gir1.2-freedesktop
> > Version: 1.78.1-10
> > 
> > Apt removes gnome-shell, gnome-session, gdm and others (gnome) and breaks
> > system

I tried upgrading a GNOME virtual machine from an outdated version of
trixie to current trixie, and that did not reproduce this problem.
The only packages that were held back by `apt upgrade` were unrelated to
gobject-introspection (related to the Boost version transition).

> What command are you using to upgrade? An ordinary `apt upgrade` should
> not be proposing to remove packages.

According to a reply sent privately, the answer is that it was synaptic
and not apt that removed (proposed to remove?) these packages.

> What was logged in /var/log/apt/history.log and /var/log/apt/term.log
> during this upgrade?

Please could you answer this? It will help to figure out why this
happened. Please reply to the bug address rather than to me personally,
so that other team members are able to help you.

It would also be helpful to see the output of:

apt --dry-run dist-upgrade

which will help us to see why apt is now holding back these packages.

Thanks,
smcv

Bug#1061071: transition: libcamera 0.2.0

[Dylan Aïssi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: affects -1 + src:libcamera

Dear Release Team,

Please schedule a transition slot for libcamera 0.2.0.

The auto-generated ben tracker looks good:
https://release.debian.org/transitions/html/auto-libcamera.html

The unique reverse dep (pipewire 1.0.1-1) builds fine with
2 upstream patches [1], since they break the backward
compatibility, I plan to do an upload of pipewire once libcamera0.2
is in unstable.

Thanks,
Dylan

[1] https://salsa.debian.org/utopia-team/pipewire/-/commit/a48d3473

Bug#1061069: iptables FTCBFS: python3 dependency not installable for host

[Jeremy Sowden]

On 2024-01-17, at 10:43:07 +0100, Helmut Grohne wrote:
> Source: iptables
> Version: 1.8.10-2
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: cross-satisfiability
> 
> iptables cannot be cross built from source, because it depends on
> python3. More precisely, it depends on the host architecture Python
> interpreter, which cannot be run and therefore cannot be installed. It
> really needs Python as a tool during build rather than to link it or
> integrate host code with and thus it should be annotated :any or
> :native. It also only needs Python for testing and thus it should be
> annotated . Doing so immediately fixes the cross build
> failure. I'm attaching a patch for your convenience.
> 
> Helmut

> diff --minimal -Nru iptables-1.8.10/debian/changelog 
> iptables-1.8.10/debian/changelog
> --- iptables-1.8.10/debian/changelog  2024-01-11 14:08:21.0 +0100
> +++ iptables-1.8.10/debian/changelog  2024-01-17 10:04:33.0 +0100
> @@ -1,3 +1,11 @@
> +iptables (1.8.10-2.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Fix FTCBFS: Annotate python3 build dependency with :native and 
> .
> +(Closes: #-1)
> +
> + -- Helmut Grohne   Wed, 17 Jan 2024 10:04:33 +0100
> +
>  iptables (1.8.10-2) unstable; urgency=medium
>  
>* [06f4121] d/control: use tracker.d.o address for `Maintainer:`
> diff --minimal -Nru iptables-1.8.10/debian/control 
> iptables-1.8.10/debian/control
> --- iptables-1.8.10/debian/control2023-12-13 14:22:25.0 +0100
> +++ iptables-1.8.10/debian/control2024-01-17 10:04:33.0 +0100
> @@ -11,7 +11,7 @@
> libnfnetlink-dev,
> libnftnl-dev (>= 1.1.6),
> netbase (>= 6.0),
> -   python3
> +   python3:native 
>  Standards-Version: 4.6.2
>  Rules-Requires-Root: no
>  Homepage: https://www.netfilter.org/

Applied.  Will upload shortly.

J.


signature.asc
Description: PGP signature

Bug#1060387: libc6:amd64 (2.37-13) upgrade stuck at Setting up on WSL 2

[Raffaele Bratta]

On Wed, 10 Jan 2024 22:01:59 +0100 Aurelien Jarno  wrote:
> We also got another report that telinit got stuck, it wasn't the case
> before, I guess something has changed on the WSL side. Someone with
> knowledge about that system should debug the issue and provide a patch.
In my case, switching to systemd (as suggested at 
https://github.com/microsoft/WSL/issues/10955#issuecomment-1894003593 for a 
similar problem with telinit) solved the problem.


Greetings

--
Raffaele Bratta
Senior engineer - 505 Games


E: rbra...@505games.com
A: Via Tortona 37, Milano MI, 20144, Italy

Bug#1061070: mini-httpd: Installing fails with : cannot stat '/usr/share/doc/mini-httpd/examples/index.html': No such file or directory

[lortas]

Package: mini-httpd
Version: 1.30-6
Severity: important

Dear Maintainer,


# docker run -ti --rm debian:testing-slim bash -c "apt-get update && apt-get 
install -y mini-httpd"
[...]
Setting up libexpat1:amd64 (2.5.0-2+b2) ...
Setting up libssl3:amd64 (3.1.4-2) ...
Setting up libapr1:amd64 (1.7.2-3+b2) ...
Setting up mini-httpd (1.30-6) ...
cp: cannot stat '/usr/share/doc/mini-httpd/examples/index.html': No such file 
or directory
dpkg: error processing package mini-httpd (--configure):
 installed mini-httpd package post-installation script subprocess returned 
error exit status 1
Setting up libgdbm6:amd64 (1.23-5) ...
Setting up libaprutil1:amd64 (1.6.3-1+b1) ...
Setting up apache2-utils (2.4.58-1+b1) ...
Processing triggers for libc-bin (2.37-13) ...
Errors were encountered while processing:
 mini-httpd
E: Sub-process /usr/bin/dpkg returned an error code (1)



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

Kernel: Linux 5.15.0-91-generic (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages mini-httpd depends on:
ii  init-system-helpers  1.66
ii  libc62.37-13
ii  libcrypt11:4.4.36-2
ii  libssl3  3.1.4-2

Versions of packages mini-httpd recommends:
ii  apache2-utils  2.4.58-1+b1

mini-httpd suggests no packages.

-- no debconf information

Bug#1051418: bad patch: debian/patches/0013-Fix-comparision-if-char-is-unsigned.patch

[Erich Schubert]

tag 1051418 +patch
thanks

Removing the bad patch
debian/patches/0013-Fix-comparision-if-char-is-unsigned.patch
and rebuilding the package fixes this bug.

Bug#1061069: iptables FTCBFS: python3 dependency not installable for host

[Helmut Grohne]

Source: iptables
Version: 1.8.10-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

iptables cannot be cross built from source, because it depends on
python3. More precisely, it depends on the host architecture Python
interpreter, which cannot be run and therefore cannot be installed. It
really needs Python as a tool during build rather than to link it or
integrate host code with and thus it should be annotated :any or
:native. It also only needs Python for testing and thus it should be
annotated . Doing so immediately fixes the cross build
failure. I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru iptables-1.8.10/debian/changelog 
iptables-1.8.10/debian/changelog
--- iptables-1.8.10/debian/changelog2024-01-11 14:08:21.0 +0100
+++ iptables-1.8.10/debian/changelog2024-01-17 10:04:33.0 +0100
@@ -1,3 +1,11 @@
+iptables (1.8.10-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Annotate python3 build dependency with :native and .
+(Closes: #-1)
+
+ -- Helmut Grohne   Wed, 17 Jan 2024 10:04:33 +0100
+
 iptables (1.8.10-2) unstable; urgency=medium
 
   * [06f4121] d/control: use tracker.d.o address for `Maintainer:`
diff --minimal -Nru iptables-1.8.10/debian/control 
iptables-1.8.10/debian/control
--- iptables-1.8.10/debian/control  2023-12-13 14:22:25.0 +0100
+++ iptables-1.8.10/debian/control  2024-01-17 10:04:33.0 +0100
@@ -11,7 +11,7 @@
libnfnetlink-dev,
libnftnl-dev (>= 1.1.6),
netbase (>= 6.0),
-   python3
+   python3:native 
 Standards-Version: 4.6.2
 Rules-Requires-Root: no
 Homepage: https://www.netfilter.org/