Bug#1071089: RM: cpptraj [arm64 armel armhf i386 mips64el ppc64el riscv64 s390x] -- ROM; FTBFS on non-amd64 archs

[Andrius Merkys]

Package: ftp.debian.org
Severity: normal

Hello,

Please remove cpptraj binaries for the following architectures:

arm64 armel armhf i386 mips64el ppc64el riscv64 s390x

It FTBFS on non-amd64 architectures as noticed in #1035833.

Andrius

Bug#1070919: compyle: FTBFS in bullseye

[Antonio Valentino]

Dear Santiago,

On Sat, 11 May 2024 21:46:59 +0200 Santiago Vila  wrote:

Package: src:compyle
Version: 0.7-2
Severity: serious
Control: close -1 0.8.1-4
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
  debian/rules binary
dh binary --with python3 --buildsystem=pybuild
dh_update_autotools_config -O--buildsystem=pybuild
dh_autoreconf -O--buildsystem=pybuild
dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:232: python3.9 setup.py config
running config
dh_auto_build -O--buildsystem=pybuild
I: pybuild base:232: /usr/bin/python3 setup.py build
running build
running build_py
creating /<>/.pybuild/cpython3_3.9_compyle/build/compyle
copying compyle/ast_utils.py -> 
/<>/.pybuild/cpython3_3.9_compyle/build/compyle

[... snipped ...]

E   pyopencl._cl.RuntimeError: clBuildProgram failed: BUILD_PROGRAM_FAILURE 
- clBuildProgram failed: BUILD_PROGRAM_FAILURE - clBuildProgram failed: 
BUILD_PROGRAM_FAILURE
E
E   Build on :
E
E   error: unknown target CPU 'generic'
E
E   (options: -I /usr/lib/python3/dist-packages/pyopencl/cl)
E   (source saved as /tmp/tmp_oyjksbc.cl)

/usr/lib/python3/dist-packages/pyopencl/__init__.py:579: RuntimeError
 TestParallelUtilsJIT.test_scan_works_with_external_func_opencl 

func = 
args = (,)
kwargs = {'ary': }
key = ('gintp', .input_f 
at 0x7f95841ecb80>, .output_f at 0x7f957f8b1dc0>, 
'a+b', 'opencl', False, ...)

 @my_decorator
 def _deco(func, *args, **kwargs):
 # by Michele Simionato
 # http://www.phyast.pitt.edu/~micheles/python/
 key = key_func(*args, **kwargs)
 try:
>   return func._memoize_dic[key]  # pylint: disable=protected-access
E   KeyError: ('gintp', .input_f at 0x7f95841ecb80>, 
.output_f at 
0x7f957f8b1dc0>, 'a+b', 'opencl', False, True)

/usr/lib/python3/dist-packages/pytools/__init__.py:621: KeyError

During handling of the above exception, another exception occurred:

self = 




I'm sorry but I have no clue about this issue.
Looking at the log It seems that the CPU is not recognized.
Not sure, however if the issue is in compyle or in pyopencl.

Do you have an idea if the updated versions of the package (e.g. the 
ones currently in stable or in unstable) build properly on the same 
platform?



kind regards
--
Antonio Valentino

Bug#1071088: certbot: Certbot produces "AttributeError: can't set attribute"

[root]

Package: certbot
Version: 2.1.0-4
Severity: important
X-Debbugs-Cc: xxdpp...@yahoo.com

Dear Maintainer,

This is a Debian 12 system with sysvinit startup.

Certbot fails to do automatic renewals; reason unknown.
On attempting to do a manual renewal

certbot certonly

the message

"AttributeError: can't set attribute" is produced after

entering the domain names.

The error was consistent for several attempts.  The error
is reported to be solved in version 2.3.0, but the available
version is 2.1.0-4.  It was not possible to do a snapd
install of a modern certbot as the system is sysvinit,
not systemd.  A pip install also failed.  After deleting
the /etc/letsencrypt directory, removing and reinstalling
certbot several times, and more attempts at obtaining a
certificate, certbot finally succeeded - reason unknown,
many things were tried.

   * What outcome did you expect instead?

Successful obtaining of a certificate.


-- System Information:
Debian Release: 12.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 6.1.0-18-686-pae (SMP w/2 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: sysvinit (via /sbin/init)

Versions of packages certbot depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  python33.11.2-1+b1
ii  python3-certbot2.1.0-4

certbot recommends no packages.

Versions of packages certbot suggests:
pn  python-certbot-doc  
pn  python3-certbot-apache  
pn  python3-certbot-nginx   

-- Configuration Files:
/etc/cron.d/certbot [Errno 2] No such file or directory: '/etc/cron.d/certbot'

-- debconf information excluded

Bug#1071087: onionshare: Show QR Code Button Does Not Work When Setting Up Onionshare Chat

[Onion User]

Package: onionshare
Version: 2.6-5~deb12u1
Severity: normal
X-Debbugs-Cc: debus...@gmail.com

Dear Maintainer,



   * What led up to the situation?
   When attempting to set up the chat feature, pressing the button to show 
the qr code did not work.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   No QR image was shown, but produced the following error messages:
   Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/onionshare/tab/server_status.py", line 
501, in show_url_qr_code_button_clicked
self.qr_code_dialog = QRCodeDialog(
  ^
  File "/usr/lib/python3/dist-packages/onionshare/widgets.py", line 146, in 
__init__
self.qr_label.setPixmap(qrcode.make(text, image_factory=Image).pixmap())
^^
  File "/usr/lib/python3/dist-packages/qrcode/main.py", line 29, in make
return qr.make_image()
   ^^^
  File "/usr/lib/python3/dist-packages/qrcode/main.py", line 365, in make_image
im = image_factory(
 ^^
TypeError: Image.__init__() got an unexpected keyword argument 'qrcode_modules'

   * What outcome did you expect instead?
   A dialog box with the QR image showing.



-- System Information:
Debian Release: 12.5
  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-21-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages onionshare depends on:
ii  onionshare-cli 2.6-5~deb12u1
ii  python33.11.2-1+b1
ii  python3-pyside2.qtcore 5.15.8-2+b1
ii  python3-pyside2.qtwidgets  5.15.8-2+b1
ii  python3-qrcode 7.4.2-2
ii  python3-werkzeug   2.2.2-3

onionshare recommends no packages.

onionshare suggests no packages.

-- no debconf information

Bug#1071080: Acknowledgement (linux-image-6.1.0-21-amd64: segfault at amdgpu_dm_atomic_commit_tail)

[piorunz]

More crashes followed. I have not restarted my computer, it's still the
same session. These errors have not happened before in previous linux
kernel versions in Debian Stable. Maybe it's a regression?

Headers of the crashes:
amdgpu :10:00.0: drm_WARN_ON(atomic_read(>refcount) == 0)
[35485.090894] WARNING: CPU: 8 PID: 0 at
drivers/gpu/drm/drm_vblank.c:1210 drm_vblank_put+0xe4/0x100 [drm]

WARNING: CPU: 5 PID: 1153 at
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7785
amdgpu_dm_atomic_commit_tail+0x31d5/0x36f0 [amdgpu]

full dmesg:
[35485.090840] [ cut here ]
[35485.090845] amdgpu :10:00.0:
drm_WARN_ON(atomic_read(>refcount) == 0)
[35485.090894] WARNING: CPU: 8 PID: 0 at
drivers/gpu/drm/drm_vblank.c:1210 drm_vblank_put+0xe4/0x100 [drm]
[35485.090924] Modules linked in: tcp_diag udp_diag inet_diag battery
rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache
netfs uas usb_storage uvcvideo videobuf2_vmalloc videobuf2_memops
videobuf2_v4l2 videobuf2_common videodev tls macvlan snd_usb_audio
snd_usbmidi_lib snd_rawmidi snd_seq_device mc xt_CHECKSUM xt_MASQUERADE
xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp nft_compat
nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4
nf_tables nfnetlink bridge stp llc rfkill qrtr lz4 lz4_compress zram
zsmalloc sunrpc binfmt_misc nls_ascii nls_cp437 vfat fat intel_rapl_msr
intel_rapl_common amd64_edac edac_mce_amd snd_hda_codec_realtek kvm_amd
snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi kvm snd_hda_intel
snd_intel_dspcfg snd_intel_sdw_acpi irqbypass snd_hda_codec crc32_pclmul
ext4 snd_hda_core sd_mod ghash_clmulni_intel snd_hwdep sha512_ssse3 sg
sha512_generic sp5100_tco snd_pcm_oss crc16 sha256_ssse3 watchdog
mbcache snd_mixer_oss sha1_ssse3 jbd2
[35485.091005]  aesni_intel snd_pcm crypto_simd snd_timer cryptd ahci
snd wmi_bmof libahci rapl igb pcspkr k10temp soundcore i2c_piix4 ccp dca
libata button acpi_cpufreq nct6775 nct6775_core hwmon_vid jc42 msr
drivetemp scsi_mod scsi_common parport_pc ppdev lp parport loop fuse
efi_pstore dm_mod configfs ip_tables x_tables autofs4 btrfs
zstd_compress efivarfs raid10 raid456 async_raid6_recov async_memcpy
async_pq async_xor async_tx libcrc32c crc32c_generic xor raid6_pq raid1
raid0 multipath linear md_mod joydev evdev hid_generic usbhid hid amdgpu
drm_ttm_helper ttm video gpu_sched i2c_algo_bit drm_buddy
drm_display_helper drm_kms_helper xhci_pci xhci_hcd nvme drm nvme_core
t10_pi usbcore cec crc32c_intel rc_core crc64_rocksoft crc64 crc_t10dif
usb_common crct10dif_generic crct10dif_pclmul crct10dif_common wmi
[35485.091086] CPU: 8 PID: 0 Comm: swapper/8 Tainted: GW
 6.1.0-21-amd64 #1  Debian 6.1.90-1
[35485.091090] Hardware name: To Be Filled By O.E.M. X570 Steel
Legend/X570 Steel Legend, BIOS P5.50 10/13/2023
[35485.091092] RIP: 0010:drm_vblank_put+0xe4/0x100 [drm]
[35485.091115] Code: 8b 7f 08 48 8b 5f 50 48 85 db 74 26 e8 95 e8 24 f5
48 c7 c1 c8 95 6b c0 48 89 da 48 c7 c7 3e c5 6b c0 48 89 c6 e8 bc af c0
f4 <0f> 0b 5b e9 a4 d4 96 f5 48 8b 1f eb d5 66 66 2e 0f 1f 84 00 00 00
[35485.091118] RSP: 0018:bdfe40340de0 EFLAGS: 00010082
[35485.091121] RAX:  RBX: 9baec138cc00 RCX:
0027
[35485.091124] RDX: 9bbdbec203a8 RSI: 0001 RDI:
9bbdbec203a0
[35485.091126] RBP: 9baecdb6 R08:  R09:
bdfe40340c58
[35485.091128] R10: 0003 R11: 9bbdff2f6fe8 R12:
0086
[35485.091129] R13: 9baecdb60170 R14: ff00 R15:
9bb4f2c6ad80
[35485.091132] FS:  () GS:9bbdbec0()
knlGS:
[35485.091134] CS:  0010 DS:  ES:  CR0: 80050033
[35485.091136] CR2: 7f1cc7043740 CR3: 000a8e21 CR4:
00750ee0
[35485.091138] PKRU: 5554
[35485.091140] Call Trace:
[35485.091143]  
[35485.091146]  ? __warn+0x7d/0xc0
[35485.091151]  ? drm_vblank_put+0xe4/0x100 [drm]
[35485.091172]  ? report_bug+0xe2/0x150
[35485.091178]  ? handle_bug+0x41/0x70
[35485.091181]  ? exc_invalid_op+0x13/0x60
[35485.091184]  ? asm_exc_invalid_op+0x16/0x20
[35485.091190]  ? drm_vblank_put+0xe4/0x100 [drm]
[35485.091207]  dm_pflip_high_irq+0x1f8/0x2e0 [amdgpu]
[35485.091359]  amdgpu_dm_irq_handler+0x8a/0x1f0 [amdgpu]
[35485.091495]  amdgpu_irq_dispatch+0xcd/0x210 [amdgpu]
[35485.091599]  amdgpu_ih_process+0x7f/0x100 [amdgpu]
[35485.091686]  amdgpu_irq_handler+0x1f/0x60 [amdgpu]
[35485.091772]  __handle_irq_event_percpu+0x46/0x190
[35485.091776]  handle_irq_event+0x34/0x70
[35485.091779]  handle_edge_irq+0x87/0x220
[35485.091782]  __common_interrupt+0x3f/0xa0
[35485.091786]  common_interrupt+0x7d/0xa0
[35485.091789]  
[35485.091790]  
[35485.091792]  asm_common_interrupt+0x22/0x40
[35485.091794] RIP: 0010:cpuidle_enter_state+0xde/0x420
[35485.091797] Code: 00 00 31 ff e8 b3 24 97 ff 45 84 ff 74 16 9c 58 0f
1f 40 00 f6 c4 02 0f 85 25 03 00 00 31 ff e8 88 cf 9d ff fb 0f 1f 44 00
00 <45> 85 f6 0f 88 85 01 00 00 

Bug#1070033: libgnutls30: rejects numeric IPv6 addresses during connection

[Elliott Mitchell]

affects 1070033 nslcd
quit

On Wed, May 01, 2024 at 01:45:00PM +0200, Andreas Metzler wrote:
> On 2024-04-30 Elliott Mitchell  wrote:
> > On Tue, Apr 30, 2024 at 05:55:15AM +0200, Andreas Metzler wrote:
> > > On 2024-04-29 Elliott Mitchell  wrote:
> [...] 
> > > > From `nslcd` on clients I was getting the message:
> > > > nslcd[12345]: [1a2b3c]  failed to bind to LDAP 
> > > > server ldaps://[fd12:3456:7890:abcd::3]/: Can't contact LDAP server: 
> > > > The TLS connection was non-properly terminated.: Resource temporarily 
> > > > unavailable
> [...] 
> > > > Once I finally figured out `slapd`'s debug mode ('-h ldaps:/// 
> > > > ldapi:///'
> > > > is two arguments, the ldaps and ldapi are a single argument).  I got
> > > > traces from `slapd`: (serial numbers filed off)
> > > 
> > > > tls_read: want=5, got=5
> > > >   :  16 03 01 01 8f
> > > 
> > > > tls_read: want=399, got=399
> > > >   0160:fd12  
> > > >   0170::3456:7890:abcd:  
> > > >   0180::3.-.@.   
> > > > TLS: can't accept: A disallowed SNI server name has been received..
> > > > connection_read(13): TLS accept failure error=-1 id=1005, closing
> [...]
> > > I guess you used the IPv6 address as either CN or Subject Alternative
> > > Name. Both take names, not IP addresses. There is a different field for
> > > IP addresses.
> > > 
> > > gnutls-cli --port 636 fd12:3456:7890:abcd::3 
> > > 
> > > will probably give more info.
> > > 
> > > FWIW I have just generated a local test certificate with "IPAddress:"
> > > set to '::1' and things work for me as expected.
> 
> > Hmm, `gnutls-cli --port ldaps` gave a different result.  The connection
> > successfully established and I was left being able to type to `slapd`.
> [...]
> > Anything further is purely guesswork.

> well you could post the complete output of
> gnutls-cli --port 636 fd12:3456:7890:abcd::3
> perhaps even with -d10? I would reassign to openldap then if there are
> no obvious clues.

`gnutls-cli` doesn't yield anything obvious.

Problem is there are at least 3 packages where the bug could lurk:

libgnutls30's API could indicate numeric addresses are legal somewhere,
but not accept IPv6 addresses (something gets fed to
_gnutls_dnsname_is_valid() which shouldn't be).

I notice the libgnutls30 function _gnutls_dnsname_is_valid() will return
true for "127.0.0.1".  This function is almost certainly wrong as it
accepts IPv4 addresses (which are not valid in DNS), but rejects IPv6
addresses.


nslcd could be passing something which could be an IP address to the
wrong part of the libgnutls30 API.  nslcd might also be sending an IP
address in LDAP somewhere it is required to send a hostname.

slapd could be passing something which could be an IP address to the
wrong part of the libgnutls30 API.  slapd might also be assuming
something in LDAP is a hostname when it is valid to be an IP address.


Right now _gnutls_dnsname_is_valid() seems highly suspect.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#1009665: ghostscript: with -dNEWPDF=false, the ToUnicode CMap sometimes has an incorrect mapping

[Alex Cherepanov]

The problem was in pdftotext, rather than ps2pdf.
Starting from the v. 10.0.0 of Ghostscript, pdftotext
produces correct output from the attached PDF file.

Regards,

Alex Cherepanov

Bug#700981: ghostscript: ps2??? stdin stdout

[Alex Cherepanov]

On Tue, 19 Feb 2013 15:55:29 -1000 (HST) Ryo Furue  wrote:
> It would be nice if ps2epsi accepts stdin and stdout
> for input and output. For example,
>

> $ ps2epsi input.ps - | furtherprocess > result.epsi

Ghostscript writes various messages to stdout and stderr,
which may spoil the output file.

You will have better luck with named pipes. for instance:

cat INPUT.EPS |  (ps2epsi '%stdin' >(cat) >/dev/null 2>/dev/null) 
>OUTPUT.EPSI


Package maintainers don't know all the peculiarities of Ghostscript, 
which is evident

from 11 years of the response time. Ghostscript has its own bug tracker,
http:/bugs.ghostscript.com that is read daily by Ghostscript developers.

Regards,
Alex Cherepanov

Bug#1021370: any news?

[Fernando Toledo]

hi! I think I can sacrifice using nonfree instead of having my 
headphones sound horrible.

=(

--
Fernando Toledo
PressEnter - Soluciones Informáticas
http://www.pressenter.com.ar
15 5515-3794
twitter @PressEnterComAr

Bug#1070986: linux-source-6.7: Signing error building 6.7 custom kernel

[Tom Overlund]

This works in the 6.8.9 upstream kernel. So I guess the good news is it wil be 
fixed in Debian eventually.

Bug#1071000: sbuild-qemu: runs lintian on .changes file with Distribution != changelog target and lintian complains

[Francesco Poli]

On Sun, 12 May 2024 23:10:14 +0200 Johannes Schauer Marin Rodrigues wrote:

[...]
> Quoting Francesco Poli (wintermute) (2024-05-12 21:06:24)
[...]
> > Please note that my current setup with pbuilder does not have this issue:
> > pdebuild generates a .changes file with 'Distribution: UNRELEASED'
> > and with the latest changelog entry correctly quoted (with 'UNRELEASED'
> > after the version number parenthesis), and hence lintian is happy...
> 
> Wait... how is Lintian happy with UNRELEASED as the changelog entry?

After digging Lintian code for a while (sorry, my Perl knowledge is
just a smattering, and it is also a bit rusty at the time of writing!),
I found the following [code]

# issue only when not mentioned in the Distribution field
if ((any { $_ eq 'UNRELEASED' } @changesdists)
&& none { $_ eq 'UNRELEASED' } @distributions) {
$self->hint('unreleased-changes');
return;
}

[code]: 


It seems to me that the 'unreleased-changes' tag is issued, if the
distribution found in the Changes field is 'UNRELEASED' and the
distribution found in the Distribution field is not 'UNRELEASED'.
Or am I completely off-track?

[...]
> The only difference between sbuild and pbuilder should be this:
> 
> >   W: $PKG_NAME: changelog-distribution-does-not-match-changes-file 
> > unreleased != unstable [usr/share/doc/$PKG_NAME/changelog.gz:1]
> 
> The reason for that difference is, that sbuild-qemu calls sbuild with the -d
> option and that overwrites the distribution field. Christian, why does
> sbuild-qemu use the -d option?
> 
> But this lintian error should also be present with pbuilder:
> 
> >   E: $PKG_NAME changes: unreleased-changes
> 
> Can you clarify?

I checked by running lintian again on the .changes file generated by
pdebuild:

  $ lintian ${PKG_NAME}_${VERSION}_${ARCH}.changes
  
  $ lintian -EviIL +pedantic ${PKG_NAME}_${VERSION}_${ARCH}.changes

These commands produce no output.

Assuming the above analysis of what the Perl code of Lintian actually
does is correct, it seems the reason is that both Distribution and
Changes have 'UNRELEASED' as distribution:

  $ grep UNRELEASED ${PKG_NAME}_${VERSION}_${ARCH}.changes
  Distribution: UNRELEASED
   $PKG_NAME ($VERSION) UNRELEASED; urgency=medium


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpEAWsli8qCJ.pgp
Description: PGP signature

Bug#1070666: util-linux: last(1) is broken on i386 since 2.40-8

[Chris Hofstaedtler]

Control: reassign 1070666 glibc
Control: affects 1070666 util-linux

On Mon, May 06, 2024 at 11:51:50PM +0300, Eugene Berdnikov wrote:
>  Upgrade of util-linux from 2.39.3-6 to 2.40-8 on i386 systems breaks
>  last(1), while the same upgrade on amd64 systems does not break it.
>  Examples on my hosts running in 32-bit mode:
> 
> --
> root@citrine # /usr/bin/last -3
> last: unrecognized ut_type: 22985
> last: preallocation size exceeded
[..]

This is probably - I haven't checked - the struct layout problem
mentioned by Florian Weimer, supposedly fixed in glibc 2.40.

Might be nice to get that for trixie.

Thanks,
Chris

Bug#1071085: chr: FTBFS on riscv64 due to test timeout

[Aurelien Jarno]

Source: chr
Version: 0.1.78-1
Severity: important
Tags: ftbfs
X-Debbugs-Cc: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

Dear maintainer,

chr fails to build from source on riscv64 (and a few other slow
architectures) with a timeout in a test:

| tests time out (After 30 seconds)
| ――
| 1/1 tests TIMEOUT30.07s   killed by signal 15 SIGTERM
| 
| 
| Ok: 0
| Expected Fail:  0
| Fail:   0
| Unexpected Pass:0
| Skipped:0
| Timeout:1

The full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=chr=riscv64=0.1.78-1=1715582047=0

After investigation, it appears the test actually passes, but needs 68
seconds instead of the default 30 seconds it got allocated. The
following patch uses the --timeout-multiplier feature of meson to
increase the timeout. I didn't try to use a different multiplier
depending on the architecture as it has no impact on working tests.


diff -Nru chr-0.1.78/debian/rules chr-0.1.78/debian/rules
--- chr-0.1.78/debian/rules
+++ chr-0.1.78/debian/rules
@@ -22,8 +22,8 @@
dh_auto_build --builddirectory=$(build_tiny)
 
 override_dh_auto_test:
-   dh_auto_test --builddirectory=$(build_edit)
-   dh_auto_test --builddirectory=$(build_tiny)
+   dh_auto_test --builddirectory=$(build_edit) -- --timeout-multiplier=4
+   dh_auto_test --builddirectory=$(build_tiny) -- --timeout-multiplier=4
 
 override_dh_auto_install:
dh_auto_install --builddirectory=$(build_edit) --destdir=debian/chr


Note that it might also fix the same issue on hppa and sparc64.

Regards
Aurelien

Bug#1071084: locales: update-locale hides error information when invoking 'locale charmap'

[Dominik Stadler]

Package: locales
Version: 2.38-10
Severity: normal
Tags: newcomer, patch



The perl script update-local internally invokes 'locale charmap' to perform 
additional checks.

However if this call fails for some reason, update-locale always only prints 
"Error: invalid locale settings: LANG=" which can be very misleading when 
the root-cause is actually different.


I.e. sample output of "sudo /usr/sbin/update-locale LANG=de_AT.UTF-8" on Debian 
Trixie:


*** update-locale: Error: invalid locale settings:  LANG=de_AT.UTF-8



After applying the following patch:

==
--- /usr/update-locale  2024-05-13 23:42:46.584127893 +0200
+++ /usr/sbin/update-locale 2024-05-13 23:40:25.160121142 +0200
@@ -88,7 +88,7 @@
 {
#  Check that this locale does exist
my $charset = `LANG= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= 
LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE= 
LC_MEASUREMENT= LC_IDENTIFICATION= LC_ALL= $env locale charmap 2>&1`;
-   die "*** $progname: Error: invalid locale settings: $env\n"
+   die "*** $progname: Error: invalid locale settings: 
$env\n\n--$charset--\n"
if ($charset =~ m/Cannot set/);
#  If LANGUAGE is set, its first value must be compatible with 
LC_MESSAGES
if (defined $arg{LANGUAGE})
==


The output contains the actual information why the call to "locale chaarmap" 
failed, thus making it possible to investigate why the call actually failed:

===
*** update-locale: Error: invalid locale settings:  LANG=de_AT.UTF-8

--locale: Cannot set LC_CTYPE to default locale: No such file or 
directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968
--
===



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

Kernel: Linux 6.5.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.86
ii  libc-bin   2.38-10
ii  libc-l10n  2.38-10

locales recommends no packages.

locales suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "de_AT.UTF-8",
LC_MONETARY = "de_AT.UTF-8",
LC_CTYPE = "C.UTF-8",
LC_ADDRESS = "de_AT.UTF-8",
LC_TELEPHONE = "de_AT.UTF-8",
LC_NAME = "de_AT.UTF-8",
LC_MEASUREMENT = "de_AT.UTF-8",
LC_IDENTIFICATION = "de_AT.UTF-8",
LC_NUMERIC = "de_AT.UTF-8",
LC_PAPER = "de_AT.UTF-8",
LANG = "de_AT.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
  locales/locales_to_be_generated:
  locales/default_environment_locale: None

Bug#1071083: thawab: depends on no longer available gir1.2-webkit2-4.0

[Andreas Beckmann]

Package: thawab
Version: 4.1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

  The following packages have unmet dependencies:
   thawab : Depends: gir1.2-webkit2-4.0 but it is not installable

sid now has gir1.2-webkit2-4.1

Cheers,

Andreas

Bug#1048703: plm: Fails to build source after successful build

[Pierre Gruet]

Source: plm
Version: 2.9.2-1
Followup-For: Bug #1048703
Control: tags -1 patch

Dear Maintainer,

The enclosed patch will allow you to solve this bug.

Cheers,

-- 
Pierre
diff -Nru plm-2.9.2/debian/rules plm-2.9.2/debian/rules
--- plm-2.9.2/debian/rules  2020-10-11 21:54:58.0 +0200
+++ plm-2.9.2/debian/rules  2024-05-13 22:03:35.0 +0200
@@ -26,11 +26,28 @@
 %:
dh $@   --with javahelper
 
+execute_before_dh_auto_configure:
+   # Making backups of files that will be altered during the build
+   for F in $$(find l10n/engine -name "*.po" -o -name "*.pot") 
lib/resources/plm.configuration.properties; do \
+   cp $$F $${F}.save ;\
+   done
+
 override_dh_auto_clean:
dh_auto_clean
find . -type f -name \*.java.json-simple \
  -exec sh -c 'file={} && mv $$file $${file%.json-simple}' \; -print
 
+override_dh_clean:
+   dh_clean
+   # Removing files left there by the build system.
+   find . -name "*.jar" -delete
+   -rm dist/*.tar.bz2
+   -rm errors-*.txt
+   # Restoring files that were altered during the build
+   for F in $$(find . -name "*.save") ; do \
+   mv $$F $${F%.save} ;\
+   done
+
 override_dh_auto_build:
find . -type f -name \*.java -exec grep -q 'import 
@JSON_SIMPLE_PACKAGE@' {} \; \
  -exec sed -i.json-simple \

Bug#1071082: FTBFS against jgit/6.7.0-1 in unstable

[Pierre Gruet]

Source: plm
Version: 2.9.2-1
Severity: serious
Tags: ftbfs patch

Dear Maintainer,

I have just uploaded jgit/6.7.0 to unstable, in order to fix a security issue.
However, plm fails to build against it because some -- previously -- deprecated
methods have been removed.

The enclosed patch will allow you to build plm again.

Best,

-- 
Pierre
diff -Nru plm-2.9.2/debian/control plm-2.9.2/debian/control
--- plm-2.9.2/debian/control2020-10-11 21:54:58.0 +0200
+++ plm-2.9.2/debian/control2024-05-03 16:00:26.0 +0200
@@ -4,7 +4,7 @@
 Maintainer: Martin Quinson 
 Build-Depends: debhelper-compat (= 12), javahelper (>= 0.32), ant, quilt
 Build-Depends-Indep: default-jdk, scala, libmiglayout-java, 
librsyntaxtextarea-java,
-  junit4, libgettext-commons-java, libjson-simple-java, libhttpclient-java, 
libhttpmime-java, libjgit-java,
+  junit4, libgettext-commons-java, libjson-simple-java, libhttpclient-java, 
libhttpmime-java, libjgit-java (>= 6.7.0),
   jython, libgettext-ant-tasks-java, imagemagick,
   libmockito-java
 Standards-Version: 4.5.0
diff -Nru plm-2.9.2/debian/patches/jgit_6.7.0.patch 
plm-2.9.2/debian/patches/jgit_6.7.0.patch
--- plm-2.9.2/debian/patches/jgit_6.7.0.patch   1970-01-01 01:00:00.0 
+0100
+++ plm-2.9.2/debian/patches/jgit_6.7.0.patch   2024-05-03 16:00:26.0 
+0200
@@ -0,0 +1,26 @@
+Description: replacing methods removed in jgit 6.7.0
+ The method getRef in Repository had been deprecated in previous versions, and
+ is now removed.
+Author: Pierre Gruet 
+Forwarded: no
+Last-Update: 2024-05-03
+
+--- a/src/plm/core/model/tracking/GitUtils.java
 b/src/plm/core/model/tracking/GitUtils.java
+@@ -126,7 +126,7 @@
+   
+   public void mergeRemoteIntoLocalBranch(String userBranchHash) throws 
Exception {
+   try {
+-  MergeResult res = 
git.merge().setCommit(true).setFastForward(MergeCommand.FastForwardMode.FF).setStrategy(MergeStrategy.RECURSIVE).include(git.getRepository().getRef("refs/remotes/origin/"+userBranchHash)).call();
++  MergeResult res = 
git.merge().setCommit(true).setFastForward(MergeCommand.FastForwardMode.FF).setStrategy(MergeStrategy.RECURSIVE).include(git.getRepository().findRef("refs/remotes/origin/"+userBranchHash)).call();
+   
+   if(res.getMergeStatus() == 
MergeResult.MergeStatus.FAST_FORWARD) {
+   System.out.println(Game.i18n.tr("last session 
data successfully retrieved"));
+@@ -376,6 +376,6 @@
+   }
+   
+   public Ref getRepoRef(String branch) throws IOException {
+-  return git.getRepository().getRef(branch);
++  return git.getRepository().findRef(branch);
+   }
+ }
diff -Nru plm-2.9.2/debian/patches/series plm-2.9.2/debian/patches/series
--- plm-2.9.2/debian/patches/series 2020-10-11 21:54:58.0 +0200
+++ plm-2.9.2/debian/patches/series 2024-05-03 15:59:24.0 +0200
@@ -4,3 +4,4 @@
 jython-fixes
 json-simple-3.patch
 
+jgit_6.7.0.patch

Bug#838788: printer-driver-ptouch: Please announce supported hardware using AppStream

[Petter Reinholdtsen]

Any hope to have Appstream metainfo XML included in the package now?

-- 
Happy hacking
Petter Reinholdtsen

Bug#1069743: keepassxc does not support hardware keys, need to use keepassxc-full

[Michael Musenbrock]

Package: keepassxc
Version: 2.7.7+dfsg.1-2
Followup-For: Bug #1069743

I see that my initial report got hijacked into a keepassxc should be 
keepassxc-full issue.
This is NOT what the original bug report is about, the split was mentioned in 
the NEWS file,
so this is not my concern. BUT if this is seen as issue, it should be a 
different report.

The original issue is simply, that in the hardened package, hardware key 
support should imho
still be present, as it enhances security of the keepass DB, rather then 
compromising it
(as networking, ... does).
I am not fimiliar with the keepass code, maybe hardware key support does open 
up an additional
attack vector, which is not obvious.

br m

Bug#1071081: phpunit-environment/experimental FTBFS: Error: Call to undefined method SebastianBergmann\Environment\Runtime::getRawBinary()

[Adrian Bunk]

Source: phpunit-environment
Version: 7.1.0-1
Severity: serious
Tags: ftbfs
Forwarded: 
https://github.com/sebastianbergmann/environment/commit/ff8e9b0dc10315e13f3a7951eec6b227e66997e7

https://buildd.debian.org/status/fetch.php?pkg=phpunit-environment=all=7.1.0-1=1715633007=0

...
There was 1 error:

1) SebastianBergmann\Environment\RuntimeTest::testRawBinaryCanBeRetrieved
Error: Call to undefined method 
SebastianBergmann\Environment\Runtime::getRawBinary()

/<>/tests/RuntimeTest.php:48

ERRORS!
Tests: 22, Assertions: 13, Errors: 1, Skipped: 8.
make[1]: *** [debian/rules:12: override_dh_auto_test] Error 2

Bug#1071080: linux-image-6.1.0-21-amd64: segfault at amdgpu_dm_atomic_commit_tail

[piorunz]

Package: src:linux
Version: 6.1.90-1
Severity: normal
X-Debbugs-Cc: pior...@gmx.com

Dear Maintainer,

Today I found crash in linux kernel. Related to AMD Radeon graphics card I use.
I have not seen it on previous versions of Linux kernel in Debian Stable.

I was away from the computer at the time, system continue to work normally
despite this error.

System details:
CPU: AMD Ryzen 7 5800X 8-Core @ 16x 3.8GHz
GPU: AMD Radeon RX 6800 XT (navi21, LLVM 15.0.6, DRM 3.49, 6.1.0-21-amd64)
RAM: 64GB DDR4 ECC
Mobo: ASRock model: X570 Steel Legend

Graphics:
  Device-1: AMD Navi 21 [Radeon RX 6800/6800 XT / 6900 XT] driver: amdgpu
v: kernel
  Device-2: Z-Star Micro Vimicro USB Camera (Altair) type: USB
driver: uvcvideo
  Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 driver: X:
loaded: amdgpu unloaded: fbdev,modesetting,radeon,vesa dri: radeonsi
gpu: amdgpu resolution: 1: 3840x2160 2: 3840x2160~144Hz
  API: OpenGL v: 4.6 Mesa 22.3.6 renderer: AMD Radeon RX 6800 XT (navi21
LLVM 15.0.6 DRM 3.49 6.1.0-21-amd64)

[16326.665176] [ cut here ]
[16326.665183] WARNING: CPU: 10 PID: 1153 at
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7785
amdgpu_dm_atomic_commit_tail+0x31d5/0x36f0 [amdgpu]
[16326.665453] Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops
videobuf2_v4l2 videobuf2_common videodev tls macvlan snd_usb_audio
snd_usbmidi_lib snd_rawmidi snd_seq_device mc xt_CHECKSUM xt_MASQUERADE
xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp nft_compat nft_chain_nat
nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge
stp llc rfkill qrtr lz4 lz4_compress zram zsmalloc sunrpc binfmt_misc nls_ascii
nls_cp437 vfat fat intel_rapl_msr intel_rapl_common amd64_edac edac_mce_amd
snd_hda_codec_realtek kvm_amd snd_hda_codec_generic ledtrig_audio
snd_hda_codec_hdmi kvm snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi
irqbypass snd_hda_codec crc32_pclmul ext4 snd_hda_core sd_mod
ghash_clmulni_intel snd_hwdep sha512_ssse3 sg sha512_generic sp5100_tco
snd_pcm_oss crc16 sha256_ssse3 watchdog mbcache snd_mixer_oss sha1_ssse3 jbd2
aesni_intel snd_pcm crypto_simd snd_timer cryptd ahci snd wmi_bmof libahci rapl
igb pcspkr k10temp soundcore i2c_piix4 ccp dca
[16326.665569]  libata button acpi_cpufreq nct6775 nct6775_core hwmon_vid jc42
msr drivetemp scsi_mod scsi_common parport_pc ppdev lp parport loop fuse
efi_pstore dm_mod configfs ip_tables x_tables autofs4 btrfs zstd_compress
efivarfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor
async_tx libcrc32c crc32c_generic xor raid6_pq raid1 raid0 multipath linear
md_mod joydev evdev hid_generic usbhid hid amdgpu drm_ttm_helper ttm video
gpu_sched i2c_algo_bit drm_buddy drm_display_helper drm_kms_helper xhci_pci
xhci_hcd nvme drm nvme_core t10_pi usbcore cec crc32c_intel rc_core
crc64_rocksoft crc64 crc_t10dif usb_common crct10dif_generic crct10dif_pclmul
crct10dif_common wmi
[16326.665669] CPU: 10 PID: 1153 Comm: Xorg Not tainted 6.1.0-21-amd64 #1
Debian 6.1.90-1
[16326.665675] Hardware name: To Be Filled By O.E.M. X570 Steel Legend/X570
Steel Legend, BIOS P5.50 10/13/2023
[16326.665679] RIP: 0010:amdgpu_dm_atomic_commit_tail+0x31d5/0x36f0 [amdgpu]
[16326.665914] Code: 4c 89 9d 48 fd ff ff e8 39 2f 18 f5 4c 8b 9d 48 fd ff ff
e9 f8 e2 ff ff 0f 0b 49 8b 3f e8 73 6f bd ff 85 c0 0f 84 af dd ff ff <0f> 0b e9
a8 dd ff ff 0f 0b e9 e7 d8 ff ff 45 8b 44 24 60 48 c7 c1
[16326.665919] RSP: 0018:bdfe42ea7530 EFLAGS: 00010282
[16326.665924] RAX: ffea RBX: 0001 RCX:

[16326.665927] RDX: 0001 RSI: 0293 RDI:
9baecdb60154
[16326.665930] RBP: bdfe42ea78a0 R08:  R09:
9bb27fe1f400
[16326.665933] R10:  R11: 9bb0d2a449c0 R12:
9baed9608800
[16326.665936] R13: 9bb27fe1f400 R14: 9bb08f143680 R15:
9bb27fe1d600
[16326.665940] FS:  7fb246011ac0() GS:9bbdbec8()
knlGS:
[16326.665944] CS:  0010 DS:  ES:  CR0: 80050033
[16326.665947] CR2: 7f50788d9000 CR3: 00011c1a2000 CR4:
00750ee0
[16326.665950] PKRU: 5554
[16326.665953] Call Trace:
[16326.665958]  
[16326.665963]  ? __warn+0x7d/0xc0
[16326.665970]  ? amdgpu_dm_atomic_commit_tail+0x31d5/0x36f0 [amdgpu]
[16326.666201]  ? report_bug+0xe2/0x150
[16326.666209]  ? handle_bug+0x41/0x70
[16326.666215]  ? exc_invalid_op+0x13/0x60
[16326.666220]  ? asm_exc_invalid_op+0x16/0x20
[16326.666228]  ? amdgpu_dm_atomic_commit_tail+0x31d5/0x36f0 [amdgpu]
[16326.666407]  ? srso_alias_return_thunk+0x5/0x7f
[16326.666411]  ? dcn30_populate_dml_pipes_from_context+0x4b/0xc0 [amdgpu]
[16326.666589]  ? dcn30_internal_validate_bw+0xec/0x9e0 [amdgpu]
[16326.666772]  commit_tail+0x94/0x130 [drm_kms_helper]
[16326.666788]  drm_atomic_helper_commit+0x112/0x140 [drm_kms_helper]
[16326.666802]  drm_atomic_commit+0x96/0xc0 [drm]
[16326.666828]  ? 

Bug#1063563: ghostscript: ps2epsi fails with Error: /undefined in /finddevice

[Alex Cherepanov]

On Thu, 29 Feb 2024 00:01:37 -0600 Steven Robbins  wrote:
> Thank you. I can reproduce the ps2epsi failure. I have no idea what is

> wrong.

The problem is caused by mismatch between versions of ps2epsi.ps and the
Ghostscript executable. The /finddevice operator has been removed but
your ps2epsi was not updated accordingly.

See the following commit for details.

http://cgit.ghostscript.com/cgi-bin/cgit.cgi/ghostpdl.git/commit/?id=aa3352c6ca5026ab7670d196d5c89e22da356cbe

Bug#1063004: synfig: NMU diff for 64-bit time_t transition

[Adrian Bunk]

On Sat, Feb 24, 2024 at 12:41:14PM -0800, Steve Langasek wrote:
> Control: tags -1 - pending
> Control: severity -1 serious
> 
> Unfortunately, it appears synfig ftbfs in unstable and experimental:
> 
> [...]
> checking for Magick++ >= 6.4.2... configure: error:  *** Unable to find 
> Magick++
> cd synfig-core && tail -v -n \+0 config.log
> [...]
> 
>   
> (https://buildd.debian.org/status/fetch.php?pkg=synfig=amd64=1.5.1%2Bdfsg-3.1%7Eexp1=1707063449=0)
> 
> Therefore we will not be able to NMU this.  Marking the bug serious as the
> mass NMUs are imminent within a few days and this becomes a serious bug once
> the toolchain changes land.

This is due to experimental using a different dependency resolver than 
unstable, and graphicsmagick-libmagick-dev-compat also providing libmagick++-dev

An upload to unstable will likely build fine, but technically it would 
in any case be more correct to
  Build-Depends: libmagick++-dev (>= 7:6.4.2)

cu
Adrian

Bug#1071079: ipp-usb: Systemd service cannot be enabled manually

[Baptiste Jonglez]

Package: ipp-usb
Version: 0.9.23-1+b4
Severity: normal

Dear Maintainer,

I am running ipp-usb in a LXC container, with USB passthrough.

When starting the systemd service "ipp-usb.service" manually, everything
works fine, the printer is detected and exported over the network.

However, "ipp-usb.service" does not start automatically when booting the LXC
container.  It seems that the service is supposed to be started automatically 
through udev.
But udev on this system does not define ID_USB_INTERFACES, so the udev rule 
shipped with
ipp-usb does not match and thus does not start the service.

It is somewhat a cornercase, but I would like to be able to enable the service 
regardless,
and this is currently not possible:

# systemctl enable ipp-usb.service
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
 
Would it be possible to add the missing bits to the systemd service so that it
can be enabled?  Something like the following:

[Install]
WantedBy=multi-user.target

Thanks,
Baptiste


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

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

Versions of packages ipp-usb depends on:
ii  avahi-daemon  0.8-10
ii  libavahi-client3  0.8-10
ii  libavahi-common3  0.8-10
ii  libc6 2.36-9+deb12u7
ii  libusb-1.0-0  2:1.0.26-1

ipp-usb recommends no packages.

ipp-usb suggests no packages.

-- Configuration Files:
/etc/ipp-usb/ipp-usb.conf changed [not included]

-- no debconf information

Bug#1032662: elpa-debian-el: deb-view fails on zstd compressed debs

[Xiyue Deng]

Contro: tags -1 pending

Xiyue Deng  writes:

> Hi Sven,
>
> I'd like to experiment an implementation to add zstd support (as well
> as lzma if possible).  Do you know which ubuntu deb files are using zstd
> or lzma compressions so that I can use to test?

I have tested this change[1] with a zstd compressed deb file from ubuntu
to be working.  I'll merge this soon.

Note that there is actually no lzma compiled deb support in dpkg-deb
either, so I have dropped that part for now.  Will revisit in case this
is enabled in dpkg-deb later.

[1] 
https://salsa.debian.org/manphiz/debian-el/-/commit/11bcd8fc563cf36140deab8f4d3293783c7b770c
-- 
Xiyue Deng

Bug#1071078: Skip creation of start-stop-daemon compat symlink if /sbin does not exist

[Johannes Schauer Marin Rodrigues]

Package: dpkg
Version: 1.21.22
Severity: wishlist
Tags: patch

Hi,

dpkg postinst fails to create the start-stop-daemon compatibility
symlink if /usr does not exist:

ln: failed to create symbolic link '/sbin/start-stop-daemon': No such file 
or directory

Getting into this situation requires some creativity. Here is an example:

$ mmdebstrap --variant=custom 
--include=dpkg,dash,diffutils,coreutils,libc-bin,sed unstable /dev/null

Here are two patches that fix this problem by just not creating the
compatibility symlink in this situation:

--- a/debian/dpkg.postinst
+++ b/debian/dpkg.postinst
@@ -59,7 +59,8 @@ setup_aliases()
 
   # Add a backward compatibility symlink alias for s-s-d, which is now
   # installed in its canonical location.
-  if [ ! -f "$DPKG_ROOT/sbin/$prog" ]; then
+  # Skip creation of the compat symlink if /sbin is not an existing directory
+  if [ ! -f "$DPKG_ROOT/sbin/$prog" ] && [ -d "$DPKG_ROOT/sbin" ]; then
 ln -s "/usr/sbin/$prog" "$DPKG_ROOT/sbin/$prog"
   fi
 }

--- a/debian/dpkg.postinst
+++ b/debian/dpkg.postinst
@@ -59,8 +59,10 @@ setup_aliases()
 
   # Add a backward compatibility symlink alias for s-s-d, which is now
   # installed in its canonical location.
+  # Failure to create the compat symlink (for example if /usr does not
+  # exist) is non-fatal.
   if [ ! -f "$DPKG_ROOT/sbin/$prog" ]; then
-ln -s "/usr/sbin/$prog" "$DPKG_ROOT/sbin/$prog"
+ln -s "/usr/sbin/$prog" "$DPKG_ROOT/sbin/$prog" || true
   fi
 }
 

The second patch has the advantage, that the user will receive the error
message from ln about its inability to create the symlink together with the
reason for the failure.

I'm working around this issue in the mmdebstrap test suite by creating /sbin
manually in a hook. I'm filing this bug to not loose track of the situation
and to be able to add a bugnumber to the hook.

Thanks!

cheers, josch

Bug#1071077: qflipper: Add Appstream metainfo announcing HW support

[Petter Reinholdtsen]

Package: qflipper
Version: 1.3.3-1
Tags: patch
User: p...@hungry.com
Usertags: appstream-modalias

Here is a patch for qflipper to add Appstream metainfo XML announcing
the hardware handled by this package.

Including this information in the package will ensure programs mapping
hardware to packages using Appstream information, like the isenkram
package, will know that this package is useful on machines where the USB
IDs are discovered.

diff --git a/debian/copyright b/debian/copyright
index eda2553..0292776 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -45,6 +45,27 @@ Files: debian/*
 Copyright: 2022, Jakob Haufe 
 License: GPL-3+
 
+Files: debian/one.flipperzero.metainfo.xml
+Copyright: 2024 Petter Reinholdtsen 
+License: MIT
+ Permission is hereby granted, free of charge, to any person obtaining a copy
+ of this software and associated documentation files (the "Software"), to deal
+ in the Software without restriction, including without limitation the rights
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ copies of the Software, and to permit persons to whom the Software is
+ furnished to do so, subject to the following conditions:
+ .
+ The above copyright notice and this permission notice shall be included in all
+ copies or substantial portions of the Software.
+ .
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ SOFTWARE.
+
 License: BSD-3-clause
  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions are
diff --git a/debian/one.flipperzero.metainfo.xml 
b/debian/one.flipperzero.metainfo.xml
new file mode 100644
index 000..1c1a856
--- /dev/null
+++ b/debian/one.flipperzero.metainfo.xml
@@ -0,0 +1,26 @@
+
+
+  one.flipperzero
+  MIT
+  qflipper
+  Flipper Zero firmware updater
+  
+qFlipper is a desktop application for updating Flipper Zero
+firmware.
+Features include:
+
+  Update Flipper's firmware and supplemental data with a press
+  of one button
+  Repair a broken firmware installation
+  Stream Flipper's display and control it remotely
+  Install firmware from a .dfu file
+  Backup and restore settings, progress and pairing data
+  Command line interface
+
+  
+  
+usb:v0483p5740d*
+usb:v0483pDF11d*
+usb:v303Ap40??d*
+  
+
diff --git a/debian/qflipper.install b/debian/qflipper.install
new file mode 100644
index 000..d89af00
--- /dev/null
+++ b/debian/qflipper.install
@@ -0,0 +1 @@
+debian/one.flipperzero.metainfo.xml usr/share/metainfo

-- 
Happy hacking
Petter Reinholdtsen

Bug#1063957: python-pytest-lazy-fixture: autopkgtest regression with pytest 8

[Julian Gilbey]

On Wed, Apr 03, 2024 at 03:58:21PM -0400, Jeremy Bícha wrote:
> I noticed one package affected by this issue, prettytable, has
> switched to a fork, pytest-lazy-fixtures (note the s at the end of the
> name).
> 
> Would someone like to package this for Debian to fix several packages
> failing to build?
> 
> https://github.com/dev-petrov/pytest-lazy-fixtures
> 
> Thank you,
> Jeremy Bícha

Dear all affected by pytest-lazy-fixture: pytest-lazy-fixtures is now
in testing and unstable; in many cases, it can be used as a drop-in
replacement for pytest-lazy-fixture (though not all, it turns out).

I suggest that we soon ask ftpmaster to drop pytest-lazy-fixture from
Debian unstable.

Best wishes,

   Julian

Bug#1071076: inotify-info: baseline ABI violation, builds with -march=native

[Aurelien Jarno]

Source: inotify-info
Version: 0.0.1-1
Severity: serious

Dear maintainer,

inotify-info builds with -march=native, which means the instruction set
it uses depends on the buildd that is used. For instance the i386
package uses AVX instructions. In addition -march=native is not
supported on all architectures.

This is unfortunately not visible in the build log, you might want to
make the build system as verbose as reasonably possible as recommended
by the debian policy.

Regards
Aurelien

Bug#1071075: python-easydev accesses the internet during the build

[Adrian Bunk]

Source: python-easydev
Version: 0.13.2+dfsg1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=python-easydev=all=0.13.2%2Bdfsg1-1=1714380640=0

...
=== FAILURES ===
__ test_isurl __

def test_isurl():
>   assert isurl_reachable("www.google.com") == True
E   AssertionError: assert False == True
E+  where False = isurl_reachable('www.google.com')

test/test_url.py:7: AssertionError
=== short test summary info 
FAILED test/test_url.py::test_isurl - AssertionError: assert False == True
= 1 failed, 56 passed in 2.36s =
...

Bug#1071059: mousepad: segfaults at each launch !

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

control: severity -1 important
control: tag - unreproducible moreinfo

On Mon, 2024-05-13 at 18:28 +0200, Philippe Caillaud wrote:
> Dear Maintainer,
> 
> I use mousepad almost each day for small text editing ; since a few days
> (maybe
> 2 or 3), mousepad
> stopped working : at each run, it crashes (segmentation fault) :
> 
Hey Philippe,

I can't reproduce here, mousepad seems to run just fine.

Some ideas you might try:
- - open a new file from the command line instead of just running mousepad
- - try with a different user
- - try with mousepad --preferences and try to tune the preferences

Also try with gdb with debugging symbols installed maybe?

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmZCaMcACgkQ3rYcyPpX
RFtBuwf9HO5l36+n8GawA4mvDAwah4ui8C4R27Ed7ly1e3GbMMp4a8RoZJlMoWUv
1S6VrbL4kaePF3PvLWeCY66oQ4WJxLGssa9+R1ciX59fjukUP64ToA3uy7pi5qg/
OUj79rmHLbzE8m+uFDd2JQe5xtvSDjTuXnXUdiUcb2dv4BFDoCh/CSpJ8ppFD5Nq
59W1R8fQ0+Ya3GoGy5lPcLypsC/hxoRPWPUdR83W51naNsKOTL/P7R6TJNl+kLFd
BlgblvGtDlGxfwid721KvLaGuoniwBFbXHMTz9/TZ6u3DK0ZuKMGtSde4pfNfiyL
fvmsm3wzzt1Qw6czO7jtWqQftS55Hg==
=PTrV
-END PGP SIGNATURE-

Bug#1070158: qtbase-opensource-src 5.15.2+dfsg-9+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1070158 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: qtbase-opensource-src
Version: 5.15.2+dfsg-9+deb11u1

Explanation: security fixes [CVE-2022-25255 CVE-2023-24607 CVE-2023-32762 
CVE-2023-32763 CVE-2023-33285 CVE-2023-34410 CVE-2023-37369 CVE-2023-38197 
CVE-2023-51714 CVE-2024-25580]

Bug#1064029: mailman3 3.3.8-2~deb12u2 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1064029 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: mailman3
Version: 3.3.8-2~deb12u2

Explanation: depend alternatively on cron-daemon; fix postgresql:// url in 
post-installation script

Bug#1055656: ms-gsl 4.0.0-2+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1055656 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: ms-gsl
Version: 4.0.0-2+deb12u1

Explanation: mark not_null constructors as noexcept

Bug#1071074: python-binary-memcached: please drop outdated python3-m2r build dependency

[Alexandre Detiste]

Source: python-binary-memcached
Version: 0.31.2+dfsg1-1
Severity: normal

Dear Maintainer,

m2r is an obsolete and archived project that
itself depends on "mistune0" oldlibs version of mistune.

Both m2r & mistune0 should be removed some day.

Please remove the extraneous declaration from d/control.

I've sent a PR Upstream to clean up
stale requirements_test.txt

Greetings

tchet@quieter:/tmp/python-binary-memcached$ grep m2r -r
CHANGELOG.md:- Remove setup's.py dependency on m2r
debian/changelog:  * Added python3-m2r to build-depends.
debian/control: python3-m2r,
requirements_test.txt:m2r~=0.2.1
requirements_test.txt:mistune<2 # m2r breaks with newer versions
tchet@quieter:/tmp/python-binary-memcached$ 

Bug#1071073: ITP: pydataverse -- Python module for interacting with Dataverse APIs

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: pydataverse
  Version : 0.3.2
  Upstream Author : Jan Range 
* URL : https://github.com/gdcc/pyDataverse
* License : MIT
  Programming Lang: Python
  Description : Python module for interacting with Dataverse APIs

  pyDataverse provides a comprehensive Python interface for interacting with
  Dataverse's APIs, facilitating the manipulation, validation, import, and
  export of all Dataverse data-types, including Dataverses, Datasets, and
  Datafiles.

  Whether it's for importing large volumes of data into Dataverse,
  testing instances post-deployment, or executing basic API calls, pyDataverse
  streamlines these processes.

  Features include a comprehensive API wrapper covering all Dataverse API
  endpoints, data models for key Dataverse data types, data conversion tools
  for Dataverse's JSON format, easy mass imports/exports through CSV
  templates, utility functions, documented examples, custom exceptions, and a
  test suite. 

I plan to maintain this package as part of the Python team.

Bug#1071072: sweethome3d: New usptream release

[Sylvestre Ledru]

Source: sweethome3d
Severity: wishlist

Dear Maintainer,


Could you please upload version 7.3 ?
release notes:
https://www.sweethome3d.com/blog/2024/04/04/sweet_home_3d_7_3.html

Thanks
S


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

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

-- no debconf information

Bug#1071071: python3-poetry: depends on packaging

[Mark A. Hershberger]

Package: python3-poetry
Version: 1.8.2+dfsg-1
Severity: normal

$ sudo apt install -t testing python3-poetry
...
Setting up python3-poetry (1.8.2+dfsg-1)
...
$ poetry run python

No module named 'packaging.metadata'

$ sudo apt install -t testing python3-packaging
...
Setting up python3-packaging (24.0-1) ...
$ poetry run python
Creating virtualenv devops-fabric-MXLzDq5t-py3.12 in 
/home/mah/.cache/pypoetry/virtualenvs
Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 

-- System Information
Debian Release: 12.5
Kernel Version: Linux gabriel 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
6.1.85-1 (2024-04-11) x86_64 GNU/Linux

Bug#840013: bluez: Please announce supported hardware using AppStream

[Petter Reinholdtsen]

Any hope to have this patch applied to the package?

-- 
Happy hacking
Petter Reinholdtsen

Bug#1070835: update-alternatives: error: alternative path /bin/ed doesn't exist

[Helmut Grohne]

Control: retitle -1 OBS does not correctly implement the bootstrap protocol
Control: reassign -1 src:open-build-service
Control: affects -1 + ed

Hi,

On Fri, May 10, 2024 at 10:48:54AM +0200, Oliver Smith wrote:
> in Debian sid, installing ed fails with:
> 
>   [49/600] installing ed-1.20.2-2
>   update-alternatives: error: alternative path /bin/ed doesn't exist
> 
> It looks like this is related to usr merge, the binary seems to be in
> /usr/bin/ed now: https://packages.debian.org/sid/amd64/ed/filelist
> 
> The error happens in an opensuse build server, trying to build a Debian
> package that depends on ed.

The bootstrap protocol requires that every transitively essential
package has been configured at least once before installing other
packages. ed is such an other package.  Therefore, we may assume that
usrmerge or usr-is-merged (which are a dependency of essential
init-system-helpers) has been configured at least once. OBS has its own
bootstrap strategy that violates this requirement. The bug is to be
found there rather than in ed.

Helmut

Bug#1061179: transition: qtbase-abi-5-15-12

[Sebastian Ramacher]

Control: block -1 by 1060019

On 2024-01-20 13:47:18 +0300, Dmitry Shachnev wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> Control: block -1 by 1060761 1060802
> 
> Dear Release team,
> 
> I have skipped Qt 5.15.11 release and would like to upgrade to 5.15.12
> which was published in December. Qt WebEngine will be upgraded from 5.15.15
> to 5.15.16. The transition is prepared in experimental.

Let's do this one after poppler migrated.

Cheers
-- 
Sebastian Ramacher

Bug#1071065: transition: libsecp256k1

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2024-05-13 19:59:30 +0200, Bastian Germann wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> Control: affects -1 + src:libsecp256k1
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-libsecp256k1.html
> 
> Hi,
> 
> I request a transition slot from libsecp256k1-1 to libsecp256k1-2.
> The auto-generated tracker is okay. All reverse dependencies in sid build 
> with the experimental libsecp256k1.

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1071070: src:nbd: fails to migrate to testing for too long: autopkgtest failure

[Paul Gevers]

Source: nbd
Version: 1:3.25-1
Severity: serious
Control: close -1 1:3.26.1-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:nbd has been trying to migrate for 71 days 
[2]. Hence, I am filing this bug. You added an autopkgtest to your 
package (thank you for that), but it fails. This is blocking migration.


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=nbd



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069447: gpaw: FTBFS on armhf: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" --test-pytest "--test-args=-v -m ci" returned exit code 13

[Paul Gevers]

Control: tags -1 moreinfo

Hi Lucas,

[Please CC me on replies, I'm not subscribed to the bug]

On Sat, 20 Apr 2024 15:09:56 +0200 Lucas Nussbaum  wrote:

During a rebuild of all packages in sid, your package failed to build
on armhf.


Do you have any idea why we don't see the same failure on 
reproducible-builds [1]?


Paul

[1] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gpaw.html


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064003: Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Bastian Blank]

Hi

On Sun, May 12, 2024 at 11:54:42PM +0200, Helmut Grohne wrote:
> On Sun, May 12, 2024 at 07:35:09PM +0200, Bastian Blank wrote:
> > > 1. API expectation of *-$arch-cross packages
> > I asked exactly that in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416#55
> I guess the best description is to be found in man dpkg-cross
> "Conversion process" and even that isn't entirely helpful.

This is now
https://salsa.debian.org/kernel-team/linux/-/merge_requests/1076

Not really tested however.  Until cross-toolchain-base is rebuilt, we
don't have any test subject.

> > > 4. cross-toolchain-base could drop its Build-Conflicts. This may cause
> > >further problems though.
> > >Patch: https://bugs.debian.org/1067370#17
> > 
> > The build will now see multiple architectures of headers.  So it needs
> > to handle this both for native (where build-conflicts can't be used
> > anyway) and cross the same.
> 
> I don't understand what you are trying to say here. c-t-b only builds
> Arch:all packages, so the terms native and cross appear to not apply.
> Then again we also don't know what "further problems" are. I hope
> Matthias can shed some light here.

gcc-13, the native compiler, builds fine with headers in /usr/include
and /usr/include/$multiarch.  gcc-13-cross, the cross compiler, is
reported to not build with this, however I can't verify that right now.

> > On Sun, May 12, 2024 at 01:53:33PM +0200, Helmut Grohne wrote:
> > > 2+3+6+7. linux-libc-dev could be split into linux-libc-dev-common
> > >arch:all m-a:foreign and the symlink farms could be kept in
> > >linux-libc-dev:any m-a:same retaining the size reduction.
> > 
> > This would not actually work.  linux-libc-dev-common would only contain
> > known architectures.  So the current "change config, build
> > linux-libc-dev" will not longer work as well.  This package would then
> > depend on a linux-libc-dev-common without the headers for this
> > architecture.
> 
> I agree that it is not as simple as I pictured it. I was imagining that
> a m-a:same linux-libc-dev could simply contain all the
> architecture-dependent stuff. For many architectures that would
> practically work initially, but there is no bijective mapping between
> kernel architecture names and Debian architecture names, so for
> directories like /usr/lib/linux/uapi/arm is is unclear whether it should
> be part of linux-libc-dev:armel or linux-libc-dev:armhf or
> linux-libc-dev-common.  Even for /usr/lib/linux/uapi/arm64, it is not
> clear whether that should be part of linux-libc-dev:arm64 or
> linux-libc-dev:musl-linux-arm64 or linux-libc-dev-common. You are
> implicitly resolving this to linux-libc-dev-common and conclude that
> headers would then go missing.
> 
> Given this, I fear I concur with your "This would not actually work."

linux-libc-dev is also build-essential.  This kind of rules out any
same-source all-any trickery.  Those packages will not show up at the
same time, so are prone to make the whole toolchain uninstallable.

Bastian

-- 
Vulcans believe peace should not depend on force.
-- Amanda, "Journey to Babel", stardate 3842.3

Bug#1071069: src:prettytable: fails to migrate to testing for too long: FTBFS

[Paul Gevers]

Source: prettytable
Version: 3.6.0-1
Severity: serious
Control: close -1 3.6.0-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1066757

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:prettytable has been trying to migrate for 
72 days [2]. Hence, I am filing this bug. The version in unstable failed 
to build as reported in bug 1066757.


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=prettytable



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070288: pplatex: depends on obsolete pcre3 library

[Sebastian Humenda]

control: forwarded -1 https://github.com/stefanhepp/pplatex/issues/26
thanks


signature.asc
Description: PGP signature

Bug#1071068: ITP: golang-github-bettercap-gatt -- building Bluetooth Low Energy peripherals

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org, 
vil...@debian.org

* Package name: golang-github-bettercap-gatt
  Version : 0.0~git20210514.df6e615
  Upstream Contact: Simone Margaritelli 
* URL : https://github.com/bettercap/gatt
* License : BSD-3-Clause
  Programming Lang: Go
  Description : building Bluetooth Low Energy peripherals

  This package provides a Bluetooth Low Energy GATT implementation.
  Gatt (Generic Attribute Profile) is the protocol used to write BLE
  peripherals (servers) and centrals (clients).
  .
  As a peripheral, you can create services, characteristics, and
  descriptors, advertise, accept connections, and handle requests.
  .
  As a central, you can scan, connect, discover services, and make
  requests.

Bug#1071067: src:sqlmodel: fails to migrate to testing for too long: FTBFS

[Paul Gevers]

Source: sqlmodel
Version: 0.0.8-5
Severity: serious
Control: close -1 0.0.8-6
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1066771

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:sqlmodel has been trying to migrate for 72 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build as reported in bug 1066771.


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=sqlmodel



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071066: gpodder: gPodder segfaults when started with appmenu-gtk-module

[Ben Morris]

Package: gpodder
Version: 3.11.3-2
Severity: important

Dear Maintainer,

Recently, gPodder started crashing on startup. After finding that renaming
the ~/gPodder/ directory didn't help, but running gPodder under a different
user did, I commented out lines in my .config/gtk-3.0/settings.ini to narrow
down the problem until I discovered that removing appmenu-gtk-module from my
gtk-modules line allowed gPodder to start normally.

This crash only started happening fairly recently, and I have not discovered
what change has caused this. I have tried downgrading to the previous version
of appmenu-gtk-module, and this did not resolve the problem. (In any case, I
am reasonably sure that the problam started more recently than that upgrade.)

As such, I think it is quite likely that I'm not reporting this bug on the
correct package. Nevertheless, I'm reporting it on the application where I
noticed it, in the hope that somebody can point me in the right direction.

Steps to reproduce:

# apt install appmenu-gtk3-module
$ GTK3_MODULES=appmenu-gtk-module gpodder

gPodder immediately exits with a segmentation fault, without producing a window.

Note that I originally had "gtk-modules=appmenu-gtk-module" in my
settings.ini, and so had this crash without setting an environment variable.
I include the var for ease of reproduction. It is not necessary to actually
have a global menu; just enabling the module seems to be sufficient to
trigger the segfault.

There is something that I do not understand about gPodder - it appears to
have some support for global menus when the module is not enabled (or
even installed). I do not know how this works.

Additionally, when running without the module, the gPodder menu appears
within the application window, while the Podcasts, Subscriptions, Episodes,
Extra and View menus are correctly displayed as global menus.

I checked some other GTK3 applications on my system, and found one other
strange result: Inkscape also supports global menus with the module disabled,
and also crashes with it enabled.

I believe Inkscape also worked in this configuration in the past, but it's
been a lot longer since I last tried to use it than it has been with gPodder.

However, qalculate-gtk, audacious in "GTK (legacy) mode", qemu, guvcview and
virt-manager all have no global menu support without the module, and work
fine *with* the module, so just disabling the module globally is not a good
workaround.

Ben Morris

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

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

Versions of packages gpodder depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-4+b1
ii  gir1.2-gtk-3.03.24.41-4
ii  python3   3.11.8-1
ii  python3-cairo 1.26.0-1
ii  python3-dbus  1.3.2-5+b2
ii  python3-gi3.48.2-1
ii  python3-gi-cairo  3.48.2-1
ii  python3-mygpoclient   1.9-1
ii  python3-podcastparser 0.6.10-2
ii  python3-requests  2.31.0+dfsg-1

Versions of packages gpodder recommends:
ii  gir1.2-ayatanaappindicator3-0.1  0.5.93+really-1
ii  libgpod4t64 [libgpod4]   0.8.3-19.1+b1
ii  normalize-audio  0.7.7-18
ii  python3-eyed30.9.7-1
ii  python3-html5lib 1.1-6
ii  python3-simplejson   3.19.2-1+b1

Versions of packages gpodder suggests:
pn  gnome-bluetooth-sendto  
pn  mplayer 
ii  yt-dlp  2024.04.09-1

-- no debconf information

Bug#1070891: apt-show-versions: Permission denied on a bad pathname

[Vincent Lefevre]

On 2024-05-13 17:12:57 +0200, Christoph Martin wrote:
> Hi Vincent,
> 
> Am 13.05.24 um 15:34 schrieb Vincent Lefevre:
> 
> > > > I don't know why could cause the error, but the pathname with "//"
> > > > is incorrect.
> > > 
> > > // in the path should not be a problem.
> > 
> > zsh completion cannot handle it, so I was wondering.
> 
> Please try to access the file e.g. 'less 
> /var/lib/apt/lists//debug.mirrors.debian.org_debian-debug_dists_stable-debug_InRelease'

No problems.

> > > Can you do a 'ls -l /var/lib/apt/lists/' to see the permissions?
> > 
> > lrwxrwxrwx 1 root root   25 2024-05-11 22:36:06 
> > _var_local_apt_._Packages -> /var/local/apt/./Packages
> > drwxr-xr-x 2 _apt root 4096 2023-10-07 13:42:54 auxfiles
> > -rw-r--r-- 1 root root52957 2024-05-11 16:15:34 
> > debug.mirrors.debian.org_debian-debug_dists_proposed-updates-debug_InRelease
> > -rw-r--r-- 1 root root   308541 2024-05-08 22:34:42 
> > debug.mirrors.debian.org_debian-debug_dists_proposed-updates-debug_main_binary-amd64_Packages
> > -rw-r--r-- 1 root root49779 2024-02-10 12:17:11 
> > debug.mirrors.debian.org_debian-debug_dists_stable-debug_InRelease
> > -rw-r--r-- 1 root root 14314273 2024-02-10 10:44:17 
> > debug.mirrors.debian.org_debian-debug_dists_stable-debug_main_binary-amd64_Packages
> 
> What is _var_local_apt_._Packages?

Perhaps because on my local repository:

deb [trusted=yes] file:///var/local/apt ./

> Can you access this files content?

Yes, the file can be read.

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

Bug#1071065: transition: libsecp256k1

[Bastian Germann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: affects -1 + src:libsecp256k1
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-libsecp256k1.html

Hi,

I request a transition slot from libsecp256k1-1 to libsecp256k1-2.
The auto-generated tracker is okay. All reverse dependencies in sid build with 
the experimental libsecp256k1.

Bug#998627: linux: please enable the new NTFS3 driver in 5.15

[Felix Zielcke]

Hi,

upstream has now completely removed the old classic NTFS driver.
And ntfs3 has been setup to serve as alias to the old one:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ntfs3?id=74871791ffa9562d43567c5ff2ae93def3f39f65

Are there still concerns to enable it by default? And if so which ones?

Regards
Felix

Bug#1071064: tkgate: please make the build reproducible

[Chris Lamb]

Source: tkgate
Version: 2.1+repack-6
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

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

This is because the binary package ships test output that varies in
a nondeterministic manner. For example:

│ │ │ ├── ./usr/share/doc/tkgate-data/examples/verga/probe1.out
│ │ │ │┄ Ordering differences only
│ │ │ │ @@ -1,9 +1,9 @@
│ │ │ │ -valueof top.i 32'hx @ 0
│ │ │ │  valueof top.a 32'hx @ 0
│ │ │ │ +valueof top.i 32'hx @ 0
│ │ │ │  tell bob top.i 32'h0 @ 0
│ │ │ │  tell bob top.a 32'h0 @ 0
│ │ │ │  tell bob top.i 32'h1 @ 1
│ │ │ │  tell bob top.i 32'h2 @ 2
│ │ │ │  tell bob top.a 32'h2 @ 2
│ │ │ │  tell bob top.i 32'h3 @ 3
│ │ │ │  tell bob top.i 32'h4 @ 4

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2024-05-13 18:07:39.124000324 +0100
--- b/debian/rules  2024-05-13 18:18:23.558129447 +0100
@@ -21,3 +21,4 @@
 
 override_dh_auto_test:
cd test/ && sh runtests.sh
+   find test/ -name *.out | xargs rm -f

Bug#1071063: screenkey: malformed debian/changelog

[Chris Lamb]

Package: screenkey
Version: 1:1.5-4
Severity: serious
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org


Hi,

This might not *strictly* be an RC bug, but the latest upload of
screenkey has the following entry in debian/changelog:

<<<
screenkey (1:1.5-4) unstable; urgency=medium

  * fixed d/watch
  * bumped Standards-Version: 4.7.0
  * removed the stance X-Python-Version

 --
>>>

Note in particular the missing date. This doesn't break dak, otherwise
it would not have been accepted by the archive, but it breaks many
other tools (eg. gbp-buildpackage, etc.) as well as other things. For
example, the package is not reproducible because SOURCE_DATE_EPOCH
cannot be extracted from the debian/changelog.

When building the package you should have seen warnings by, for
instance, dh_installchangelogs, dpkg-gencontrol, dpkg-genchanges,
etc. :)

Regards,

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

Bug#1071062: ITP: golang-github-mgutz-logxi -- 12-factor app logger (library)

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org, 
vil...@debian.org

* Package name: golang-github-mgutz-logxi
  Version : 1
  Upstream Contact: Mario Gutierrez 
* URL : https://github.com/mgutz/logxi
* License : Expat
  Programming Lang: Go
  Description : 12-factor app logger (library)

  Log XI is a structured 12-factor app (http://12factor.net/logs)
  logger built for speed and happy development.
  .
   * Simpler. Sane no-configuration defaults out of the box.
   * Faster. See benchmarks vs logrus and log15.
   * Structured. Key-value pairs are enforced. Logs JSON in production.
   * Configurable. Enable/disable Loggers and levels via env vars.
   * Friendlier. Happy, colorful and developer friendly logger in
 terminal.
   * Helpful. Traces, warnings and errors are emphasized with file, line
 number and callstack.
   * Efficient. Has level guards to avoid cost of building complex
 arguments.

Bug#1071007: sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py

[Axel Beckert]

Control: affects -1 - pycrc
Control: clone -1 -2 -3
Control: reassign -2 pycrc 0.10.0-2
Control: retitle -1 sherlock: Must not ship 
/usr/lib/python3/dist-packages/__init__.py
Control: retitle -2 pycrc: Must not ship 
/usr/lib/python3/dist-packages/__init__.py
Control: reassign -3 lintian 2.117.0
Control: severity -3 wishlist
Control: retitle -3 lintian: Should warn if a package ships 
/usr/lib/python*/dist-packages/__init__.py

Hi Helmut,

Helmut Grohne wrote:
> This bug report has been automatically filed with no human intervention.
> The source code is available at https://salsa.debian.org/helmutg/dumat.

Ok, this explains why you didn't notice that this is actually a
separate bug in each of these packages. :-)

> sherlock has an undeclared file conflict. This may result in an unpack
> error from dpkg.
> 
> The file /usr/lib/python3/dist-packages/__init__.py is contained in the
> packages
>  * pycrc/0.10.0-2 as present in trixie|unstable
>  * sherlock/0.14.3+git20240511.b83f5be-1 as present in unstable

My Python foo isn't that well versed, but as far as I understand
actually no package must ship an __init__.py file at (more or less)
root level (i.e. directly in /usr/lib/python*/dist-packages/ or — since
usrmerge also — /lib/python*/dist-packages/).

Accordingly cloning the bug report for pycrc as it must not ship that
file either.

And cloning it a second time as wishlist bug report against Lintian so
that these cases get caught much earlier. Might be implemented as
extension of python-module-has-overly-generic-name (as the module name
seems the empty string in that case ;-) which so far already catches
cases like e.g. /usr/lib/python3/dist-packages/doc/__init__.py.

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


signature.asc
Description: PGP signature

Bug#1065013: nvidia-graphics-drivers 470.239.06-1 flagged for acceptance

[Adam D. Barratt]

On Wed, 2024-05-08 at 18:22 +0100, Adam D. Barratt wrote:
> On Wed, 2024-05-08 at 19:18 +0200, Andreas Beckmann wrote:
> > On 05/05/2024 20.52, Adam D Barratt wrote:
> > > Package: nvidia-graphics-drivers
> > > Version: 470.239.06-1
> > 
> > > Explanation: upstream security fixes [CVE-2022-42265 CVE-2024-
> > > 0074
> > > CVE-2024-0078]
> > 
> > Can we push these packages to bullseye-updates?
> > The kernel change that recently caused problems for the nvidia
> > modules 
> > in bookworm has now reached bullseye, too: #1070726, but the new 
> > upstream already sitting in bullseye-pu is sufficient to fix that.
> 
> Would wording similar to
> https://lists.debian.org/debian-stable-announce/2024/02/msg2.html
> be accurate / suitable? (With the 12.5 reference changed to the
> relevant DSA number.)

Not sure if you saw the previous mail, but see below for suggested SUA
text.

Regards,

Adam

===
This update addresses problems in three non-free driver packages supporting
nVidia graphics cards.
 
The Linux kernel released in DSA 5681-1 changed an inlined function to
call two GPL-only symbols, making that function inaccessible to non-free
kernel modules.

As a result, the nVidia kernel modules cannot be built via DKMS at
installation time for the updated kernel.

The following packages have been updated to correct the problem:

Source package Fixed version
== =
nvidia-graphics-drivers470.239.06-1
nvidia-graphics-drivers-tesla-470  470.239.06-1~deb11u1
nvidia-settings470.239.06-1
 
If you use the affected packages, we recommend you upgrade to these
versions.
===

Bug#1071059: mousepad: segfaults at each launch !

[Philippe Caillaud]

Package: mousepad
Version: 0.6.2-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I use mousepad almost each day for small text editing ; since a few days (maybe
2 or 3), mousepad
stopped working : at each run, it crashes (segmentation fault) :

$ mousepad --version
Mousepad 0.6.2
[...]
$ mousepad
Erreur de segmentation [= Segmentation fault]
$ echo $?
139
$ gdb mousepad
GNU gdb (Debian 13.2-1+b1) 13.2
[...]
Reading symbols from mousepad...
(No debugging symbols found in mousepad)
(gdb) run
Starting program: /usr/bin/mousepad
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x734006c0 (LWP 106930)]
[New Thread 0x72a006c0 (LWP 106931)]
[New Thread 0x720006c0 (LWP 106932)]
[New Thread 0x716006c0 (LWP 106933)]
[New Thread 0x70c006c0 (LWP 106934)]
[New Thread 0x7fffebe006c0 (LWP 106935)]

Thread 1 "mousepad" received signal SIGSEGV, Segmentation fault.
0x77ea1ec9 in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0
=
NB : "mousepad -h", "mousepad --version", "mousepad --list-encodings" and even
"mousepad --preferences" are working.
Only the normal launch leads to the segfault !


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

Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

Versions of packages mousepad depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b2
ii  libc62.38-10
ii  libglib2.0-0t64  2.80.2-1
ii  libgspell-1-21.12.2-1+b2
ii  libgtk-3-0t643.24.41-4
ii  libmousepad0 0.6.2-1

mousepad recommends no packages.

mousepad suggests no packages.

-- no debconf information

Bug#1071058: mumble-server: prompting due to modified conffiles which were not modified by the user: /etc/mumble/mumble-server.ini

[Andreas Beckmann]

Package: mumble-server
Version: 1.5.517-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed the piuparts
upgrade test because dpkg detected a conffile as being modified and then
prompted the user for an action. As there is no user input, this fails.
But this is not the real problem, the real problem is that this prompt
shows up in the first place, as there was nobody modifying this conffile
at all, the package has just been installed and upgraded...

This is a violation of policy 10.7.3, see
https://www.debian.org/doc/debian-policy/ch-files.html#behavior,
which says "[These scripts handling conffiles] must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens."

https://wiki.debian.org/DpkgConffileHandling should help with figuring
out how to do this properly.

In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

>From the attached log (scroll to the bottom...):

  Setting up mumble-server (1.5.517-2) ...
  
  Configuration file '/etc/mumble/mumble-server.ini'
   ==> File on system created by you or by a script.
   ==> File also in package provided by package maintainer.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** mumble-server.ini (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing 
package mumble-server (--configure):
   end of file on stdin at conffile prompt


cheers,

Andreas


mumble-server_1.5.517-2.log.gz
Description: application/gzip

Bug#1071057: sbws: prompting due to modified conffiles which were not modified by the user: /etc/cron.d/sbws

[Andreas Beckmann]

Package: sbws
Version: 1.9.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed the piuparts
upgrade test because dpkg detected a conffile as being modified and then
prompted the user for an action. As there is no user input, this fails.
But this is not the real problem, the real problem is that this prompt
shows up in the first place, as there was nobody modifying this conffile
at all, the package has just been installed and upgraded...

This is a violation of policy 10.7.3, see
https://www.debian.org/doc/debian-policy/ch-files.html#behavior,
which says "[These scripts handling conffiles] must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens."

https://wiki.debian.org/DpkgConffileHandling should help with figuring
out how to do this properly.

In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

>From the attached log (scroll to the bottom...):

  Setting up sbws (1.9.0-1) ...
  
  Configuration file '/etc/cron.d/sbws'
   ==> Deleted (by you or by a script) since installation.
   ==> Package distributor has shipped an updated version.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** sbws (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package sbws 
(--configure):
   end of file on stdin at conffile prompt


cheers,

Andreas


sbws_1.9.0-1.log.gz
Description: application/gzip

Bug#1065319: notfound 1065319 in 0.5.2-1

[Андрей Спицын]

Hi Jacob,

Sorry for the direct email, but your reply in the mail list did not reach
me. I've found it only via a web site.

Could you check versions in testing and sid. I believe that the 0.5.2
version in bookworm is OK.
Now I use zathura 0.5.6. It has the same problem.


> notfound 1065319 0.5.2-1
> thanks
> I just re-checked and could not reproduce this in bookworm.
> Cheers,
> sur5r



Best Regards,
Andrey

Bug#1071056: RM: itk3/experimental -- RoQA; t64 transition not needed

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Please remove the t64 renamed version of itk3 from experimental, the
t64 transition is not needed for this package.

https://bugs.debian.org/1062462

itk3   | 3.4.2-3.1  | unstable | source
itk3   | 3.4.2-3.1+b1   | unstable | amd64, arm64, armel, armhf, i386, 
mips64el, ppc64el, riscv64, s390x
itk3   | 3.4.2-3.2~exp1 | experimental | source
itk3-dev   | 3.4.2-3.1+b1   | unstable | amd64, arm64, armel, armhf, i386, 
mips64el, ppc64el, riscv64, s390x
itk3-dev   | 3.4.2-3.2~exp1 | experimental | amd64, arm64, armel, armhf, i386, 
mips64el, ppc64el, riscv64, s390x
itk3-doc   | 3.4.2-3.1  | unstable | all
itk3-doc   | 3.4.2-3.2~exp1 | experimental | all
itk3t64| 3.4.2-3.2~exp1 | experimental | amd64, arm64, armel, armhf, i386, 
mips64el, ppc64el, riscv64, s390x

Andreas

Bug#1070977: transition: snappy

[GCS]

On Mon, May 13, 2024 at 2:04 PM Emilio Pozuelo Monfort  wrote:
> Why is there a libsnappy1v5 transitional package?
 Serves several purposes. As noted, upstream soname is _not_ changed,
so I can't let the old library package be present as it would contain
the same named library file conflicting with the one in the new,
normally named library package name. In short, I must do a file move
between packages. Then the old libsnappy1v5 package has a conflict
with the then old libsnappy1 package name. Thus this conflict needs to
be removed.

> Also has upstream been contacted in order to do a proper SONAME bump? 
> Otherwise
> libsnappy1 will have to conflict with libsnappy1v5, and that will make both 
> the
> transition and upgrades harder, as they have to be done in lockstep. If they
> broke the ABI, then a SONAME bump is in order, and that will make it easier 
> for
> us too.
 Yup, in such cases a soname bump is needed. Then upstream is Google
and as I remember years back I had a somewhat similar problem with one
of their library package. If I'm correct, I got a similar answer that
in such cases they just recompile the dependent sources and don't
change the soname.
Then the public source tree is hosted on GitHub [1] without the issues
(report) area enabled. The AUTHORS file contains a general email
address (opensou...@google.com) [2] meaning I'm not sure if I get any
answer or I will get one soon. But I can try it if you insist.

Regards,
Laszlo/GCS
[1] https://github.com/google/snappy
[2] https://github.com/google/snappy/blob/1.2.0/AUTHORS

Bug#1071055: nmu: gauche-gl_0.6-4

[Andreas Beckmann]

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

nmu gauche-gl_0.6-4 . ANY . unstable . -m "Rebuild against libgauche-0.98-0."

not a transition since the affected packages are in sid only


Andreas

Bug#1070986: I already reported for 6.6 and answer was that you should not sign modules!

[Eric Valette]

It has been a month and nobody did care on 6.6. I bet I may be identical 
for 6.7.


NB : I reported other bugs as the localmodconfig options do not include 
many rather basic options (ISO 9660, usb disks, ...).


This one can be fixed by adding the relevant config options...

-- eric

Bug#1070891: apt-show-versions: Permission denied on a bad pathname

[Christoph Martin]

Hi Vincent,

Am 13.05.24 um 15:34 schrieb Vincent Lefevre:


I don't know why could cause the error, but the pathname with "//"
is incorrect.


// in the path should not be a problem.


zsh completion cannot handle it, so I was wondering.


Please try to access the file e.g. 'less 
/var/lib/apt/lists//debug.mirrors.debian.org_debian-debug_dists_stable-debug_InRelease'



Can you do a 'ls -l /var/lib/apt/lists/' to see the permissions?


lrwxrwxrwx 1 root root   25 2024-05-11 22:36:06 _var_local_apt_._Packages 
-> /var/local/apt/./Packages
drwxr-xr-x 2 _apt root 4096 2023-10-07 13:42:54 auxfiles
-rw-r--r-- 1 root root52957 2024-05-11 16:15:34 
debug.mirrors.debian.org_debian-debug_dists_proposed-updates-debug_InRelease
-rw-r--r-- 1 root root   308541 2024-05-08 22:34:42 
debug.mirrors.debian.org_debian-debug_dists_proposed-updates-debug_main_binary-amd64_Packages
-rw-r--r-- 1 root root49779 2024-02-10 12:17:11 
debug.mirrors.debian.org_debian-debug_dists_stable-debug_InRelease
-rw-r--r-- 1 root root 14314273 2024-02-10 10:44:17 
debug.mirrors.debian.org_debian-debug_dists_stable-debug_main_binary-amd64_Packages


What is _var_local_apt_._Packages?

Can you access this files content?

Apart from that, I can't spot a problem.

Christoph


OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[Peter Green]

Package: ftp.debian.org

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

These packages were formerly physical packages, but are now virtual packages.
Unfortunately dak's dependency checks do not take proper account of virtual
packages, which leads dak to incorrectly believe that removing these packages
will cause broken dependencies.

While I am not 100% sure, I belive the presense of these cruft packages is
the cause of superious puipart's regression reports from britney which are
preventing the new version of rust-bindgen from migrating to testing.

Bug#1071053: python3-pynpoint: uninstallable in sid: Depends: python3-h5py (< 3.10) but 3.10.0-1 is to be installed

[Andreas Beckmann]

Package: python3-pynpoint
Version: 0.11.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

  The following packages have unmet dependencies:
   python3-pynpoint : Depends: python3-h5py (< 3.10) but 3.10.0-1 is to be 
installed


Cheers,

Andreas

Bug#1071052: reportbug: proposed version for binNMU should be source package version

[Alexandre Rossi]

Package: reportbug
Version: 13.0.1
Severity: minor

Dear Maintainer,

When filling a binNMU for a package with fancy binary package versionning, it
appears that reportbug uses the binary package version instead of the source
package version.

For instance, when filling a binNMU for src:uwsgi-plugin-php 0.0.15 with
uwsgi-plugin-php version 2.0.22+4+0.0.15+b2 in unstable, reportbug
detects 2.0.22+4+0.0.15+b2 as the version instead of 0.0.15 .

$ reportbug release.debian.org
[...]
Please enter the name of the package: uwsgi-plugin-php
Checking package information...
Your report will be carbon-copied to the package maintainer.
Latest version seems to be 2.0.22+4+0.0.15+b2, is this the proper one 
[Y|n|?]?

reportbug should instead choose the source package version.

Latest version seems to be 0.0.15, is this the proper one [Y|n|?]?
   ^^

Thanks,

Alex

-- Package-specific info:
** Environment settings:
EDITOR="vi"
VISUAL="vi"
REPORTBUGEMAIL="Alexandre Rossi "
EMAIL="Alexandre Rossi "
DEBFULLNAME="Alexandre Rossi"
INTERFACE="text"

** /home/niol/.reportbugrc:
reportbug_version "3.31"
mode standard
ui text

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

Kernel: Linux 6.1.0-21-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)

Versions of packages reportbug depends on:
ii  apt2.9.2
ii  python33.11.8-1
ii  python3-reportbug  13.0.1
ii  sensible-utils 0.0.22

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail
ii  debconf   1.5.86
ii  debsums   3.0.2.1
pn  default-mta | postfix | exim4 | mail-transport-agent  
pn  dlocate   
pn  emacs-bin-common  
ii  file  1:5.45-3
ii  gnupg 2.2.40-3
pn  python3-urwid 
pn  reportbug-gtk 
ii  xdg-utils 1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.9.2
ii  file   1:5.45-3
ii  python33.11.8-1
ii  python3-apt2.9.0
ii  python3-debian 0.1.49
ii  python3-debianbts  4.0.2
ii  python3-requests   2.31.0+dfsg-1
ii  sensible-utils 0.0.22

python3-reportbug suggests no packages.

-- no debconf information

Bug#1070883: src:imsprog: Does not rebuild qt language files

[Михаил Медведев]

Source: imsprog
Severity: important

Hello, Tobias!
I've done some work on the bugs :)

In version v1.3.9:

 * Fixed: There is a spelling error "copyed" in in 99-CH341.rules.
 * Fixed (metadata changed): W: imsprog:
   appstream-metadata-missing-modalias-provide
   usr/lib/udev/rules.d/99-CH341.rules
 * Fixed: As you are upstream, you could wrap README.md at 80 chars per
   line :)
 * Fixed: src:imsprog: Does not rebuild qt language files

 * Don't fixed: P: imsprog source:
   package-uses-old-debhelper-compat-version 12 - I want to maintain
   compatibility for |Jammy| and |Focal| releases.

Please check this package and send me Lintian's warnings.
Regards, Mikhail

Bug#1070891: apt-show-versions: Permission denied on a bad pathname

[Vincent Lefevre]

Hi Christoph,

On 2024-05-13 15:20:28 +0200, Christoph Martin wrote:
> Am 11.05.24 um 11:53 schrieb Vincent Lefevre:
> > Package: apt-show-versions
> > Version: 0.22.15
> > Severity: normal
> > 
> > When running "apt-show-versions -u" in a cron script, I got
> > 
> > Failed to open file 
> > /var/lib/apt/lists//debug.mirrors.debian.org_debian-debug_dists_stable-debug_InRelease
> >  for reading: Permission denied
> > 
> > I don't know why could cause the error, but the pathname with "//"
> > is incorrect.
> 
> // in the path should not be a problem.

zsh completion cannot handle it, so I was wondering.

> Can you do a 'ls -l /var/lib/apt/lists/' to see the permissions?

lrwxrwxrwx 1 root root   25 2024-05-11 22:36:06 _var_local_apt_._Packages 
-> /var/local/apt/./Packages
drwxr-xr-x 2 _apt root 4096 2023-10-07 13:42:54 auxfiles
-rw-r--r-- 1 root root52957 2024-05-11 16:15:34 
debug.mirrors.debian.org_debian-debug_dists_proposed-updates-debug_InRelease
-rw-r--r-- 1 root root   308541 2024-05-08 22:34:42 
debug.mirrors.debian.org_debian-debug_dists_proposed-updates-debug_main_binary-amd64_Packages
-rw-r--r-- 1 root root49779 2024-02-10 12:17:11 
debug.mirrors.debian.org_debian-debug_dists_stable-debug_InRelease
-rw-r--r-- 1 root root 14314273 2024-02-10 10:44:17 
debug.mirrors.debian.org_debian-debug_dists_stable-debug_main_binary-amd64_Packages
-rw-r--r-- 1 root root56601 2024-05-11 16:15:45 
debug.mirrors.debian.org_debian-debug_dists_unstable-debug_InRelease
-rw-r--r-- 1 root root11867 2024-05-11 16:07:07 
debug.mirrors.debian.org_debian-debug_dists_unstable-debug_main_Contents-amd64.lz4
-rw-r--r-- 1 root root 15598917 2024-05-11 16:07:09 
debug.mirrors.debian.org_debian-debug_dists_unstable-debug_main_binary-amd64_Packages
-rw-r--r-- 1 root root12615 2024-05-11 16:07:07 
debug.mirrors.debian.org_debian-debug_dists_unstable-debug_main_i18n_Translation-en
-rw-r--r-- 1 root root   101035 2024-05-11 16:15:38 
ftp.debian.org_debian_dists_experimental_InRelease
-rw-r--r-- 1 root root  6832935 2024-05-11 16:10:22 
ftp.debian.org_debian_dists_experimental_main_Contents-all.lz4
-rw-r--r-- 1 root root  2536358 2024-05-11 16:10:42 
ftp.debian.org_debian_dists_experimental_main_Contents-amd64.lz4
-rw-r--r-- 1 root root  3972604 2024-05-11 16:10:44 
ftp.debian.org_debian_dists_experimental_main_binary-amd64_Packages
-rw-r--r-- 1 root root  2424480 2024-05-11 16:10:15 
ftp.debian.org_debian_dists_experimental_main_i18n_Translation-en
-rw-r--r-- 1 root root  3112151 2024-05-11 16:11:36 
ftp.debian.org_debian_dists_experimental_main_source_Sources
-rw-r--r-- 1 root root55443 2024-05-11 16:15:26 
ftp.debian.org_debian_dists_stable-updates_InRelease
-rw-r--r-- 1 root root  317 2024-02-16 21:02:45 
ftp.debian.org_debian_dists_stable-updates_contrib_Contents-amd64.lz4
-rw-r--r-- 1 root root 1224 2024-02-16 21:01:38 
ftp.debian.org_debian_dists_stable-updates_contrib_binary-amd64_Packages
-rw-r--r-- 1 root root  538 2024-02-16 21:01:38 
ftp.debian.org_debian_dists_stable-updates_contrib_i18n_Translation-en
-rw-r--r-- 1 root root 1251 2024-02-16 21:01:38 
ftp.debian.org_debian_dists_stable-updates_contrib_source_Sources
-rw-r--r-- 1 root root   351371 2023-12-29 15:14:53 
ftp.debian.org_debian_dists_stable-updates_main_Contents-all.lz4
-rw-r--r-- 1 root root   429325 2024-04-23 22:45:52 
ftp.debian.org_debian_dists_stable-updates_main_Contents-amd64.lz4
-rw-r--r-- 1 root root73340 2024-04-23 22:45:52 
ftp.debian.org_debian_dists_stable-updates_main_binary-amd64_Packages
-rw-r--r-- 1 root root90213 2024-04-23 22:45:51 
ftp.debian.org_debian_dists_stable-updates_main_i18n_Translation-en
-rw-r--r-- 1 root root   333130 2024-04-23 22:46:05 
ftp.debian.org_debian_dists_stable-updates_main_source_Sources
-rw-r--r-- 1 root root  361 2024-02-16 21:02:46 
ftp.debian.org_debian_dists_stable-updates_non-free-firmware_Contents-amd64.lz4
-rw-r--r-- 1 root root 1446 2024-02-16 21:01:38 
ftp.debian.org_debian_dists_stable-updates_non-free-firmware_binary-amd64_Packages
-rw-r--r-- 1 root root  696 2024-02-16 21:01:38 
ftp.debian.org_debian_dists_stable-updates_non-free-firmware_i18n_Translation-en
-rw-r--r-- 1 root root12123 2024-02-16 21:01:38 
ftp.debian.org_debian_dists_stable-updates_non-free-firmware_source_Sources
-rw-r--r-- 1 root root27884 2024-02-16 21:02:46 
ftp.debian.org_debian_dists_stable-updates_non-free_Contents-amd64.lz4
-rw-r--r-- 1 root root   101751 2024-02-16 21:01:39 
ftp.debian.org_debian_dists_stable-updates_non-free_binary-amd64_Packages
-rw-r--r-- 1 root root64597 2024-02-16 21:01:39 
ftp.debian.org_debian_dists_stable-updates_non-free_i18n_Translation-en
-rw-r--r-- 1 root root 6231 2024-02-16 21:01:39 
ftp.debian.org_debian_dists_stable-updates_non-free_source_Sources
-rw-r--r-- 1 root root   151082 2024-02-10 12:17:10 
ftp.debian.org_debian_dists_stable_InRelease
-rw-r--r-- 1 root root   166896 2023-05-23 22:01:16 

Bug#1035833: cpptraj: autopkgtest failure everywhere except on amd64

[Andrius Merkys]

On Wed, 10 May 2023 02:29:08 +0530 Kiran S Kunjumon  
wrote:

=== FAILURES
===
TEST: /tmp/autopkgtest-lxc.kz5vbtvg/downtmp/build.qgE/src/test/Test_SPAM

   CPPTRAJ: SPAM Test
../MasterTest.sh: line 495:  3218 Killed  $cpptraj_cmd >> 
$CPPTRAJ_OUTPUT
Error:  cpptraj exited with status 137

   CPPTRAJ: SPAM Pure Solvent Test

   1 out of 2 executions exited with an error.
   2 out of 5 comparisons failed.


Interestingly, the same segmentation faults happen during build, 
although they do not terminate the build process.


Thanks,
Andrius

Bug#1070891: apt-show-versions: Permission denied on a bad pathname

[Christoph Martin]

Hi Vincent,

Am 11.05.24 um 11:53 schrieb Vincent Lefevre:

Package: apt-show-versions
Version: 0.22.15
Severity: normal

When running "apt-show-versions -u" in a cron script, I got

Failed to open file 
/var/lib/apt/lists//debug.mirrors.debian.org_debian-debug_dists_stable-debug_InRelease
 for reading: Permission denied

I don't know why could cause the error, but the pathname with "//"
is incorrect.



// in the path should not be a problem. Can you do a 'ls -l 
/var/lib/apt/lists/' to see the permissions?


Which user does the cronjob run with?

Christoph


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071051: bash-completion: new upstream version

[Christoph Anton Mitterer]

Package: bash-completion
Version: 1:2.13.0-1
Severity: wishlist

Hey.

2.14.0 is out which allegedly fixes the bug[0] that remote scp file
completion was no longer working.

Thanks,
Chris.

[0] https://github.com/scop/bash-completion/issues/1157

Bug#1014539: squirrel3: CVE-2022-30292

[Pierre-Elliott Bécue]

Hello,

Matthias Geiger  wrote on 07/05/2024 at 00:05:36+0200:

> On Thu, 18 Apr 2024 14:40:58 +0200 Matthias Geiger
>  wrote:
>
>>
>> //I have prepared a fix; however this needs the FTBFS in #997441
>> adressed first.
>>
>> Will attach a debdiff once that has happened.
>>
>
> See attachement.
>
> best,

I've uploaded this debdiff in DELAYED/7.

Please reach out if there's any issue.

Bests,
-- 
PEB
diff -Nru squirrel3-3.1/debian/changelog squirrel3-3.1/debian/changelog
--- squirrel3-3.1/debian/changelog	2024-04-29 23:39:09.0 +0200
+++ squirrel3-3.1/debian/changelog	2024-05-13 14:59:34.0 +0200
@@ -1,3 +1,11 @@
+squirrel3 (3.1-8.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherry-pick upstream commit as 03-fix-buffer-overflow.diff
+Closes: #1014539, CVE-2022-30292
+
+ -- Matthias Geiger   Mon, 13 May 2024 14:59:34 +0200
+
 squirrel3 (3.1-8.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru squirrel3-3.1/debian/patches/03-fix-buffer-overflow.diff squirrel3-3.1/debian/patches/03-fix-buffer-overflow.diff
--- squirrel3-3.1/debian/patches/03-fix-buffer-overflow.diff	1970-01-01 01:00:00.0 +0100
+++ squirrel3-3.1/debian/patches/03-fix-buffer-overflow.diff	2024-05-13 14:59:20.0 +0200
@@ -0,0 +1,22 @@
+From a6413aa690e0bdfef648c68693349a7b878fe60d Mon Sep 17 00:00:00 2001
+From: Alberto Demichelis 
+Date: Mon, 2 May 2022 12:04:58 +0200
+Subject: [PATCH] fix in thread.call
+
+---
+ squirrel/sqbaselib.cpp | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/squirrel/sqbaselib.cpp b/squirrel/sqbaselib.cpp
+index 662aeac..e283900 100644
+--- a/squirrel/sqbaselib.cpp
 b/squirrel/sqbaselib.cpp
+@@ -1012,6 +1012,7 @@ static SQInteger thread_call(HSQUIRRELVM v)
+ SQObjectPtr o = stack_get(v,1);
+ if(type(o) == OT_THREAD) {
+ SQInteger nparams = sq_gettop(v);
++sq_reservestack(_thread(o), nparams + 3);
+ _thread(o)->Push(_thread(o)->_roottable);
+ for(SQInteger i = 2; i<(nparams+1); i++)
+ sq_move(_thread(o),v,i);
+
diff -Nru squirrel3-3.1/debian/patches/series squirrel3-3.1/debian/patches/series
--- squirrel3-3.1/debian/patches/series	2024-04-29 23:33:43.0 +0200
+++ squirrel3-3.1/debian/patches/series	2024-05-13 14:59:20.0 +0200
@@ -1,2 +1,3 @@
 01-fix-spelling-errors.patch
 02-sphinx-ext.patch
+03-fix-buffer-overflow.diff


signature.asc
Description: PGP signature

Bug#1071050: kwin-bismuth: Does not work after binary-only upload as typescript transpiled incorrectly with es2022 features

[Petr Gajdůšek]

Package: kwin-bismuth
Version: 3.1.4-4+b1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: petr.gajdu...@egston.com

Dear Maintainer,

After upgrade to 3.1.4-4+b1 kwin-bismuth no more works with following error in
syslog:

kwin_x11[3514]: kwin_scripting: Component failed to load:
(file:///usr/share/kwin/scripts/bismuth/contents/ui/main.qml:5:1: Script
file:///usr/share/kwin/scripts/bismuth/contents/code/index.mjs unavailable
kwin_x11[3514]: import "../code/index.mjs" as Bismuth
kwin_x11[3514]: ^,
file:///usr/share/kwin/scripts/bismuth/contents/code/index.mjs:795:10:
Unexpected token `{'
kwin_x11[3514]:   static {
kwin_x11[3514]:  ^,
file:///usr/share/kwin/scripts/bismuth/contents/code/index.mjs:796:9: Expected
token `('
kwin_x11[3514]: this.id = "MonocleLayout";
kwin_x11[3514]: ^)

The resulting JS oviously uses ES2022 features despite the project's
tsconfig.js has target set to es2016.

After rebuilding the kwin-bismuth package locally on my system (just dpkg-
buildpackage), it works just fine.

Thank you, Petr


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

Kernel: Linux 6.4.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, 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 kwin-bismuth depends on:
ii  libc6 2.38-10
ii  libgcc-s1 14-20240330-1
ii  libkdecorations2-5v5  4:5.27.10-1+b1
ii  libkf5configcore5 5.115.0-2
ii  libkf5configgui5  5.115.0-2
ii  libkf5coreaddons5 5.115.0-2
ii  libkf5globalaccel-bin 5.115.0-2
ii  libkf5globalaccel55.115.0-2
ii  libkf5i18n5   5.115.1-2
ii  libkf5quickaddons55.115.0-3
ii  libqt5core5t645.15.10+dfsg-7.2+b1
ii  libqt5dbus5t645.15.10+dfsg-7.2+b1
ii  libqt5gui5t64 5.15.10+dfsg-7.2+b1
ii  libqt5qml55.15.10+dfsg-2+b2
ii  libqt5quick5  5.15.10+dfsg-2+b2
ii  libqt5widgets5t64 5.15.10+dfsg-7.2+b1
ii  libstdc++614-20240330-1
ii  plasma-workspace  4:5.27.10-3+b1
ii  qml-module-org-kde-kcm5.115.0-3
ii  qml-module-org-kde-kirigami2  5.115.0-2
ii  qml-module-qtquick-controls   5.15.10-2+b2
ii  qml-module-qtquick-layouts5.15.10+dfsg-2+b2
ii  qml-module-qtquick2   5.15.10+dfsg-2+b2

kwin-bismuth recommends no packages.

kwin-bismuth suggests no packages.

-- no debconf information

Bug#1071049: mercurial-evolve: current version of evolve incompatible with current mercurial

[Rémi Letot]

Package: mercurial-evolve
Version: 11.1.1-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: hob...@poukram.net

Dear Maintainer,

using the current mercurial-evolve package (version 11.1.1-1) leads to 
errors with mercurial 6.7: 

hg commit
** Unknown exception encountered with possibly-broken third-party extension 
"evolve" 11.1.1
** which supports versions 6.6 of Mercurial.

>From evolve's repo, it seems that 11.1.2 is needed with mercurial 6.7. 

And 11.1.3 has been available on pypi for one month now, so two birds, 
one stone,... :-)

(I already commented on another bug for that issue, but it seems that 
it didn't automatically reopen the bug, so I create a new one :-)

Thanks

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

Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
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)
LSM: AppArmor: enabled

Versions of packages mercurial-evolve depends on:
ii  libjs-sphinxdoc  7.2.6-7
ii  mercurial6.7.3-1
ii  python3  3.11.8-1
ii  python3-cbor 1.0.0-1.2+b2

mercurial-evolve recommends no packages.

mercurial-evolve suggests no packages.

-- no debconf information

Bug#1071035: FAIL: TestGroup_deadlock

[Reinhard Tartler]

Control: reassign -1 golang-golang-x-sync 0.7.0
Control: affects -1 golang-github-fatih-semgroup

This seems to be related to upgrading golang-golang-x-sync to 0.7.0.

This is how to reproduce is using pristine upstream sources:

siretart@x1:/tmp/docker.io $ git clone https://github.com/fatih/semgroup
Cloning into 'semgroup'...
remote: Enumerating objects: 46, done.
remote: Counting objects: 100% (46/46), done.
remote: Compressing objects: 100% (37/37), done.
remote: Total 46 (delta 23), reused 21 (delta 7), pack-reused 0
Receiving objects: 100% (46/46), 10.49 KiB | 10.49 MiB/s, done.
Resolving deltas: 100% (23/23), done.
siretart@x1:/tmp/docker.io $ cd ./semgroup/
siretart@x1:/tmp/docker.io/semgroup $ go mod edit -require 
golang.org/x/sync@v0.7.0
siretart@x1:/tmp/docker.io/semgroup $ go mod tidy
siretart@x1:/tmp/docker.io/semgroup $ go test -vet=off -v -p 8 
github.com/fatih/semgroup
=== RUN   TestGroup_single_task
--- PASS: TestGroup_single_task (0.00s)
=== RUN   TestGroup_multiple_tasks
--- PASS: TestGroup_multiple_tasks (0.00s)
=== RUN   TestGroup_multiple_tasks_errors
--- PASS: TestGroup_multiple_tasks_errors (0.00s)
=== RUN   TestGroup_deadlock
semgroup_test.go:92: error should be:
1 error(s) occurred:
* couldn't acquire semaphore: context canceled
got:
2 error(s) occurred:
* couldn't acquire semaphore: context canceled
* couldn't acquire semaphore: context canceled
--- FAIL: TestGroup_deadlock (0.00s)
=== RUN   TestGroup_multiple_tasks_errors_Is
--- PASS: TestGroup_multiple_tasks_errors_Is (0.00s)
=== RUN   TestGroup_multiple_tasks_errors_As
--- PASS: TestGroup_multiple_tasks_errors_As (0.00s)
=== RUN   ExampleGroup_parallel
--- PASS: ExampleGroup_parallel (0.00s)
=== RUN   ExampleGroup_withErrors
--- PASS: ExampleGroup_withErrors (0.00s)
FAIL
FAILgithub.com/fatih/semgroup   0.002s
FAIL

Bug#1071048: rust-coreutils: FTBFS on armhf,armel (`timespec` with struct literal syntax due to private fields)

[Kentaro HAYASHI]

Source: rust-coreutils
Severity: serious
Tags: ftbfs
Control: found -1 0.0.26-1

Dear Maintainer,

rust-coreutils fails to build on armhf.

FYI:

https://buildd.debian.org/status/fetch.php?pkg=rust-coreutils=armel=0.0.26-1=1714571498=0
https://buildd.debian.org/status/fetch.php?pkg=rust-coreutils=armhf=0.0.26-1=1714572014=0

Regards,

Bug#1071035: FAIL: TestGroup_deadlock

[Reinhard Tartler]

Control: tag -1 patch

I've filed https://github.com/fatih/semgroup/pull/7 as a workaround.

Anthony, what's your take on this, should we include that patch in the Debian 
Package?

-rt

From bb5f94c0d8e6ddf1f24f673303d73e84c285e1ac Mon Sep 17 00:00:00 2001
From: Reinhard Tartler 
Date: Mon, 13 May 2024 08:31:03 -0400
Subject: [PATCH] chore: bump x/sync to 0.7

Note that this version changes the behavior of semaphore slightly.
After 
https://cs.opensource.google/go/x/sync/+/14be23e5b48bec28285f8a694875175ecacfddb3
the semaphore package will reliably raise errors for both go routines

change the test to test for a substring to be more relaxed in case that
behavior gets reverted
---
 go.mod   | 2 +-
 go.sum   | 4 ++--
 semgroup_test.go | 8 
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/go.mod b/go.mod
index 1a651d6..5926c6b 100644
--- a/go.mod
+++ b/go.mod
@@ -2,4 +2,4 @@ module github.com/fatih/semgroup
 
 go 1.17
 
-require golang.org/x/sync v0.0.0-20210220032951-036812b2e83c

+require golang.org/x/sync v0.7.0
diff --git a/go.sum b/go.sum
index 5c00efd..e8ef4a3 100644
--- a/go.sum
+++ b/go.sum
@@ -1,2 +1,2 @@
-golang.org/x/sync v0.0.0-20210220032951-036812b2e83c 
h1:5KslGYwFpkhGh+Q16bwMP3cOontH8FOep7tGV86Y7SQ=
-golang.org/x/sync v0.0.0-20210220032951-036812b2e83c/go.mod 
h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
+golang.org/x/sync v0.7.0 h1:YsImfSBoP9QPYL0xyKJPq0gcaJdG3rInoqxTWbfQu9M=
+golang.org/x/sync v0.7.0/go.mod h1:Czt+wKu1gCyEFDUtn0jG5QVvpJ6rzVqr5aXyt9drQfk=
diff --git a/semgroup_test.go b/semgroup_test.go
index 255206d..3c90bf6 100644
--- a/semgroup_test.go
+++ b/semgroup_test.go
@@ -4,6 +4,7 @@ import (
"context"
"errors"
"os"
+   "strings"
"sync"
"testing"
 )
@@ -85,11 +86,10 @@ func TestGroup_deadlock(t *testing.T) {
t.Fatalf("g.Wait() should return an error")
}
 
-	wantErr := `1 error(s) occurred:

-* couldn't acquire semaphore: context canceled`
+   wantErr := `couldn't acquire semaphore: context canceled`
 
-	if wantErr != err.Error() {

-   t.Errorf("error should be:\n%s\ngot:\n%s\n", wantErr, 
err.Error())
+   if !strings.Contains(err.Error(), wantErr) {
+   t.Errorf("error should contain:\n%s\ngot:\n%s\n", wantErr, 
err.Error())
}
 }
 

Bug#1071047: lxd: Please update the default URL for the images: remote

[Paride Legovini]

Package: lxd
Version: Please update the default URL for the images: remote
Severity: normal

As of lxd 5.0.2+git20231211.1364ae4-4 the default URL for the images:
remote is:

  https://images.linuxcontainers.org

however that endpoint does not accept the LXD user-agent anymore [1].
The following URL should be used instead:

  https://images.lxd.canonical.com

I am aware of #1058592, but hopefully this can fall into the "small
tweaks" category you still plan to do for the package. 

Thanks!

[1] 
https://discuss.linuxcontainers.org/t/important-notice-for-lxd-users-image-server/18479

--
Paride

Bug#1071046: rust-mimalloc: FTBFS on armhf (E: Build killed with signal TERM after 150 minutes of inactivity)

[Kentaro HAYASHI]

Source: rust-mimalloc 
Severity: serious
Tags: ftbfs
Control: found -1 0.1.29-1+b2

Dear Maintainer,

rust-mimalloc fails to build on armhf.

FYI:

https://buildd.debian.org/status/fetch.php?pkg=rust-mimalloc=armhf=0.1.29-1%2Bb2=1714283560=0

Regards,

Bug#1071045: gauche-c-wrapper: FTBFS against gauche 0.9.14 (0.98)

[Andreas Beckmann]

Source: gauche-c-wrapper
Version: 0.6.1-12
Severity: serious
Tags: ftbfs sid trixie
Justification: fails to build from source (but built successfully in the past)
User: debian...@lists.debian.org
Usertags: piuparts

   dh_auto_build
make -j16
make[1]: Entering directory '/build/gauche-c-wrapper-0.6.1'
cd src; make all
make[2]: Entering directory '/build/gauche-c-wrapper-0.6.1/src'
/usr/bin/gauche-package compile --cppflags="-DGAUCHE_API_0_8_8 -Wdate-time 
-D_FORTIFY_SOURCE=2 -D_GNU_SOURCE" --ldflags="-Wl,-z,relro " 
--libs="/usr/lib/x86_64-linux-gnu/libffi_pic.a " --verbose c-ffi c-ffi.c 
c-ffilib.stub closure_alloc.c
/usr/bin/gauche-package compile --cppflags="-DGAUCHE_API_0_8_8 -Wdate-time 
-D_FORTIFY_SOURCE=2 -D_GNU_SOURCE" --ldflags="-Wl,-z,relro " 
--libs="/usr/lib/x86_64-linux-gnu/libffi_pic.a " --verbose c-lex c-lex.c 
c-lexlib.stub
/usr/bin/gauche-package compile --cppflags="-DGAUCHE_API_0_8_8 -Wdate-time 
-D_FORTIFY_SOURCE=2 -D_GNU_SOURCE" --ldflags="-Wl,-z,relro " 
--libs="/usr/lib/x86_64-linux-gnu/libffi_pic.a  " --verbose c-parser c-parser.c 
c-parserlib.stub
c-lex.c: In function 'Scm_ReadStringLiteral':
c-lex.c:998:1: error: number of arguments doesn't match prototype
  998 | {
  | ^
In file included from /usr/lib/gauche-0.98/0.9.14/include/gauche.h:964,
 from c-lex.h:45,
 from c-lex.c:35:
/usr/lib/gauche-0.98/0.9.14/include/gauche/string.h:243:20: error: prototype 
declaration
  243 | SCM_EXTERN ScmObj  Scm_ReadStringLiteral(ScmPort*, ScmReadContext*,
  |^
In file included from c-ffi.c:31:
c-ffi.c: In function 'ffi_type_of':
c-ffi.c:350:34: error: too few arguments to function 'Scm_InstanceSlotRef'
  350 | return SCM_FFI_TYPE_DATA(Scm_InstanceSlotRef(ctype, 
sa->slotNumber));
  |  ^~~
c-ffi.h:137:42: note: in definition of macro 'SCM_FFI_TYPE'
  137 | #define SCM_FFI_TYPE(obj) ((ScmFFIType*)(obj))
  |  ^~~
c-ffi.c:350:16: note: in expansion of macro 'SCM_FFI_TYPE_DATA'
  350 | return SCM_FFI_TYPE_DATA(Scm_InstanceSlotRef(ctype, 
sa->slotNumber));
  |^
In file included from /usr/lib/gauche-0.98/0.9.14/include/gauche.h:741,
 from c-ffi.h:40:
/usr/lib/gauche-0.98/0.9.14/include/gauche/class.h:624:19: note: declared here
  624 | SCM_EXTERN ScmObj Scm_InstanceSlotRef(ScmObj obj, ScmSmallInt k,
  |   ^~~
*** ERROR: command execution failed: gcc -c -DGAUCHE_API_0_8_8 -Wdate-time 
-D_FORTIFY_SOURCE=2 -D_GNU_SOURCE '-I/usr/lib/gauche-0.98/0.9.14/include' -g 
-O2 -Werror=implicit-function-declaration -ffile-prefix ...
Stack Trace:
___
  0  (report-error e)
  1  (apply gauche-package-compile src (delete-keyword :output args))
at "/usr/share/gauche-0.98/0.9.14/lib/gauche/package/compile.scm":137
  2  (proc (car xs))
  3  (map (lambda (src) (cond ((equal? (path-extension src) OBJEXT ...
at "/usr/share/gauche-0.98/0.9.14/lib/gauche/package/compile.scm":134
  4  (#:G259 (cddr args))
  5  (main args)
gcc -c -DGAUCHE_API_0_8_8 -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE 
'-I/usr/lib/gauche-0.98/0.9.14/include' -g -O2 
-Werror=implicit-function-declaration 
-ffile-prefix-map=/build/gauche-c-wrapper-0.6.1=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fPIC 
-o 'c-lex.o' 'c-lex.c'
make[2]: *** [Makefile:69: c-lex.so] Error 70
make[2]: *** Waiting for unfinished jobs
c-ffi.c: In function 'Scm_FFIPrepClosure':
c-ffi.c:866:5: warning: 'ffi_prep_closure' is deprecated: use 
ffi_prep_closure_loc instead [-Wdeprecated-declarations]
  866 | ffi_status status = ffi_prep_closure(closure, cif, closure_func,
  | ^~
In file included from c-ffi.h:50:
/usr/include/x86_64-linux-gnu/ffi.h:356:1: note: declared here
  356 | ffi_prep_closure (ffi_closure*,
  | ^~~~
*** ERROR: command execution failed: gcc -c -DGAUCHE_API_0_8_8 -Wdate-time 
-D_FORTIFY_SOURCE=2 -D_GNU_SOURCE '-I/usr/lib/gauche-0.98/0.9.14/include' -g 
-O2 -Werror=implicit-function-declaration -ffile-prefix ...
Stack Trace:
___
  0  (report-error e)
  1  (apply gauche-package-compile src (delete-keyword :output args))
at "/usr/share/gauche-0.98/0.9.14/lib/gauche/package/compile.scm":137
  2  (proc (car xs))
  3  (map (lambda (src) (cond ((equal? (path-extension src) OBJEXT ...
at "/usr/share/gauche-0.98/0.9.14/lib/gauche/package/compile.scm":134
  4  (#:G259 (cddr args))
  5  (main args)
gcc -c -DGAUCHE_API_0_8_8 -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE 
'-I/usr/lib/gauche-0.98/0.9.14/include' -g -O2 
-Werror=implicit-function-declaration 
-ffile-prefix-map=/build/gauche-c-wrapper-0.6.1=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security 

Bug#1071044: rust-libmimalloc-sys : FTBFS on armhf (signal: 11, SIGSEGV: invalid memory reference)

[Kentaro HAYASHI]

Source: rust-libmimalloc-sys
Severity: serious
Tags: ftbfs
Control: found -1 0.1.25-1+b2

Dear Maintainer,

rust-libmimalloc-sys fails to build on armhf.

FYI:
https://buildd.debian.org/status/fetch.php?pkg=rust-libmimalloc-sys=armhf=0.1.25-1%2Bb2=1714271391=0

Regards,

Bug#1071039: [Debian-zh-dev] Bug#1071039: iptux FTBFS on 32bit with 64bit time_t

[肖盛文]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/iptux-src/iptux/issues/581

Hi Adrian,

Thanks for your report.



在 2024/5/13 18:49, Adrian Bunk 写道:

Source: iptux
Version: 0.9.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=iptux=0.9.1-1

...
FAILED: src/iptux-core/libiptux-core.so.0.9.1.p/internal_SendFileData.cpp.o
c++ -Isrc/iptux-core/libiptux-core.so.0.9.1.p -Isrc/iptux-core -I../src/iptux-core -Isrc 
-I../src -Isrc/api -I../src/api -I/usr/include/glib-2.0 
-I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/include/sysprof-6 
-I/usr/include/jsoncpp -I/usr/include/sigc++-2.0 
-I/usr/lib/arm-linux-gnueabihf/sigc++-2.0/include -fdiagnostics-color=always 
-D_GLIBCXX_ASSERTIONS=1 -Wall -Winvalid-pch -Wextra -Wpedantic -std=c++14 -Werror=format -g 
-O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD 
-MQ src/iptux-core/libiptux-core.so.0.9.1.p/internal_SendFileData.cpp.o -MF 
src/iptux-core/libiptux-core.so.0.9.1.p/internal_SendFileData.cpp.o.d -o 
src/iptux-core/libiptux-core.so.0.9.1.p/internal_SendFileData.cpp.o -c 
../src/iptux-core/internal/SendFileData.cpp
../src/iptux-core/internal/SendFileData.cpp: In member function ‘void 
iptux::SendFileData::SendDirFiles()’:
../src/iptux-core/internal/SendFileData.cpp:205:16: error: format ‘%lx’ expects 
argument of type ‘long unsigned int’, but argument 8 has type ‘__time64_t’ {aka 
‘long long int’} [-Werror=format=]
   205 |":%s:%.9" PRIx64 ":%lx:%lx=%lx:%lx=%lx:", dirname,
   |^~~~
../src/iptux-core/internal/SendFileData.cpp:205:16: error: format ‘%lx’ expects 
argument of type ‘long unsigned int’, but argument 10 has type ‘__time64_t’ 
{aka ‘long long int’} [-Werror=format=]
   205 |":%s:%.9" PRIx64 ":%lx:%lx=%lx:%lx=%lx:", dirname,
   |^~~~
../src/iptux-core/internal/SendFileData.cpp:243:36: error: format ‘%lx’ expects 
argument of type ‘long unsigned int’, but argument 6 has type ‘__time64_t’ {aka 
‘long long int’} [-Werror=format=]
   243 |":.:0:%lx:%lx=%lx:%lx=%lx:", IPMSG_FILE_RETPARENT,
   |  ~~^
   ||
   |long unsigned int
   |  %llx
../src/iptux-core/internal/SendFileData.cpp:243:44: error: format ‘%lx’ expects 
argument of type ‘long unsigned int’, but argument 8 has type ‘__time64_t’ {aka 
‘long long int’} [-Werror=format=]
   243 |":.:0:%lx:%lx=%lx:%lx=%lx:", IPMSG_FILE_RETPARENT,
   |  ~~^
   ||
   |long unsigned int
   |  %llx
../src/iptux-core/internal/SendFileData.cpp:264:32: warning: cast between 
incompatible function types from ‘int (*)(DIR*)’ to ‘GFunc’ {aka ‘void 
(*)(void*, void*)’} [-Wcast-function-type]
   264 | g_queue_foreach(, GFunc(closedir), NULL);
   |^~~
cc1plus: some warnings being treated as errors
...
FAILED: src/iptux-core/libiptux-core.so.0.9.1.p/internal_TcpData.cpp.o
c++ -Isrc/iptux-core/libiptux-core.so.0.9.1.p -Isrc/iptux-core -I../src/iptux-core -Isrc 
-I../src -Isrc/api -I../src/api -I/usr/include/glib-2.0 
-I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/include/sysprof-6 
-I/usr/include/jsoncpp -I/usr/include/sigc++-2.0 
-I/usr/lib/arm-linux-gnueabihf/sigc++-2.0/include -fdiagnostics-color=always 
-D_GLIBCXX_ASSERTIONS=1 -Wall -Winvalid-pch -Wextra -Wpedantic -std=c++14 -Werror=format -g 
-O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD 
-MQ src/iptux-core/libiptux-core.so.0.9.1.p/internal_TcpData.cpp.o -MF 
src/iptux-core/libiptux-core.so.0.9.1.p/internal_TcpData.cpp.o.d -o 
src/iptux-core/libiptux-core.so.0.9.1.p/internal_TcpData.cpp.o -c 
../src/iptux-core/internal/TcpData.cpp
../src/iptux-core/internal/TcpData.cpp: In member function ‘void 
iptux::TcpData::RecvSublayer(uint32_t)’:
../src/iptux-core/internal/TcpData.cpp:146:35: error: format ‘%lx’ expects 
argument of type ‘long unsigned int’, but argument 7 has type ‘time_t’ {aka 
‘long long int’} [-Werror=format=]
   146 |   snprintf(path, MAX_PATHLEN, "%s" PIC_PATH "/%" PRIx32 "-%" PRIx32 
"-%lx",
   |   
^~~~
   147 |g_get_user_cache_dir(), inAddrToUint32(pal->ipv4()), 
count++,
   148 | 

Bug#1071043: libpsml-dev: unsatisfiable (Build-)Depends: libxmlf90-dev

[Andreas Beckmann]

Package: libpsml-dev
Version: 2.0.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

  The following packages have unmet dependencies:
   libpsml-dev : Depends: libxmlf90-dev but it is not installable


Cheers,

Andreas

Bug#1067815: (no subject)

[wuruilong]

Dear Maintainer,

Upstream has been merged to support loongarch architecture code, the PR 
link is as follows: 
https://gitlab.com/ubports/development/core/click/-/merge_requests/41. 
Please merge the attached patch, or upgrade the software version.


wuruilong

Bug#1071042: nmu: pytorch-cluster_1.6.3-1

[Andreas Beckmann]

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

nmu pytorch-cluster_1.6.3-1 . ANY . unstable . -m "Rebuild against pytorch 2.1"

python3-torch-cluster currently has an unsatisfiable dependency on libtorch2.0


Andreas

Bug#1070977: transition: snappy

[Emilio Pozuelo Monfort]

On 12/05/2024 11:36, László Böszörményi (GCS) wrote:

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

Hi RMs,

Upstream of snappy changed function signatures [1] breaking other
applications with the 1.2.0 release. I've added back the original
function signatures calling the new ones to restore the immediate
problem, to restore the ABI. But then this creates ambiguity in the
Compress method signatures [2] making (only) ceph FTBFS. While it can
be patched to avoid it, a proper transition should be done.
I've renamed back the library name which was done due to the C++11 ABI
change with g++ 5.0 back in 2015.


Why is there a libsnappy1v5 transitional package?

Also has upstream been contacted in order to do a proper SONAME bump? Otherwise 
libsnappy1 will have to conflict with libsnappy1v5, and that will make both the 
transition and upgrades harder, as they have to be done in lockstep. If they 
broke the ABI, then a SONAME bump is in order, and that will make it easier for 
us too.


Cheers,
Emilio

Bug#1069641: right versions

[Andreas Beckmann]

On Mon, 22 Apr 2024 09:31:00 +0200 Alexandre Rossi  wrote:

Hi,

With the right versions, sorry for the noise.


nmu uwsgi-plugin-php_0.0.15  . ANY . unstable . -m "rebuild against new uwsgi.h"
nmu uwsgi-plugin-luajit_0.0.8  . ANY . unstable . -m "rebuild against new 
uwsgi.h"
nmu uwsgi-plugin-mongo_0.0.9  . ANY . unstable . -m "rebuild against new 
uwsgi.h"

binNMUs requests need the source version, not the binary package
version and no +b# suffix
(it's possible the request a specific binNMU version number, but the
default (next number) is fine here)

Andreas

Bug#1071040: O: rtl-wmbus -- software defined receiver for Wireless-M-Bus (EN13757 OMS) with RTL-SDR

[Petter Reinholdtsen]

https://github.com/wmbusmeters/wmbusmeters/issues/460 > show my
last contact with the maintainer, who is also upstream.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1071041: grep: Buggy multi-character collating symbol/equivalent class

[herbert]

Package: grep
Version: 3.8-5
Severity: normal

These three commands should all return patch, but the last one does not
(and is buggy):

$ echo patch | LC_ALL=cs_CZ grep '[[.ch.]]$'
patch
$ echo patch | LC_ALL=cs_CZ grep 't[[=ch=]]$'
patch
$ echo patch | LC_ALL=cs_CZ grep '[[=ch=]]$'
$ 


-- System Information
Debian Release: 12.5
Kernel Version: Linux loth 6.3.0+ #2 SMP PREEMPT_DYNAMIC Thu Jun 15 12:24:54 
HKT 2023 x86_64 GNU/Linux

Bug#1071008: libx52pro0: installs udev rules twice to /usr and /

[Andreas Beckmann]

Followup-For: Bug #1071008

I noticed in piuparts that the package is currently uninstallable,
probably related to this bug.

  Selecting previously unselected package libx52pro0.
  Preparing to unpack .../libx52pro0_0.1.1-3_amd64.deb ...
  Unpacking libx52pro0 (0.1.1-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libx52pro0_0.1.1-3_amd64.deb (--unpack):
   unable to install new version of '/usr/lib/udev/rules.d/99-x52pro.rules': No 
such file or directory
  Errors were encountered while processing:
   /var/cache/apt/archives/libx52pro0_0.1.1-3_amd64.deb

Please verify that the fixed package is installable again ;-)


Andreas

Bug#1071040: O: rtl-wmbus -- software defined receiver for Wireless-M-Bus (EN13757 OMS) with RTL-SDR

[Petter Reinholdtsen]

Package: wnpp
Severity: normal
X-Debbugs-CC: team+pkg...@tracker.debian.org

I used to sponsor the uploader of the rtl-wmbus package, but for several
months now I have not been able to reach him.  This make me suspect he
is no longer around to maintain the package, and I believe someone else
need to take over.  The upload so far only went to experimental.

Its status can be seen in
https://tracker.debian.org/pkg/rtl-wmbus >.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1071039: iptux FTBFS on 32bit with 64bit time_t

[Adrian Bunk]

Source: iptux
Version: 0.9.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=iptux=0.9.1-1

...
FAILED: src/iptux-core/libiptux-core.so.0.9.1.p/internal_SendFileData.cpp.o 
c++ -Isrc/iptux-core/libiptux-core.so.0.9.1.p -Isrc/iptux-core 
-I../src/iptux-core -Isrc -I../src -Isrc/api -I../src/api 
-I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include 
-I/usr/include/sysprof-6 -I/usr/include/jsoncpp -I/usr/include/sigc++-2.0 
-I/usr/lib/arm-linux-gnueabihf/sigc++-2.0/include -fdiagnostics-color=always 
-D_GLIBCXX_ASSERTIONS=1 -Wall -Winvalid-pch -Wextra -Wpedantic -std=c++14 
-Werror=format -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD -MQ 
src/iptux-core/libiptux-core.so.0.9.1.p/internal_SendFileData.cpp.o -MF 
src/iptux-core/libiptux-core.so.0.9.1.p/internal_SendFileData.cpp.o.d -o 
src/iptux-core/libiptux-core.so.0.9.1.p/internal_SendFileData.cpp.o -c 
../src/iptux-core/internal/SendFileData.cpp
../src/iptux-core/internal/SendFileData.cpp: In member function ‘void 
iptux::SendFileData::SendDirFiles()’:
../src/iptux-core/internal/SendFileData.cpp:205:16: error: format ‘%lx’ expects 
argument of type ‘long unsigned int’, but argument 8 has type ‘__time64_t’ {aka 
‘long long int’} [-Werror=format=]
  205 |":%s:%.9" PRIx64 ":%lx:%lx=%lx:%lx=%lx:", dirname,
  |^~~~
../src/iptux-core/internal/SendFileData.cpp:205:16: error: format ‘%lx’ expects 
argument of type ‘long unsigned int’, but argument 10 has type ‘__time64_t’ 
{aka ‘long long int’} [-Werror=format=]
  205 |":%s:%.9" PRIx64 ":%lx:%lx=%lx:%lx=%lx:", dirname,
  |^~~~
../src/iptux-core/internal/SendFileData.cpp:243:36: error: format ‘%lx’ expects 
argument of type ‘long unsigned int’, but argument 6 has type ‘__time64_t’ {aka 
‘long long int’} [-Werror=format=]
  243 |":.:0:%lx:%lx=%lx:%lx=%lx:", IPMSG_FILE_RETPARENT,
  |  ~~^
  ||
  |long unsigned int
  |  %llx
../src/iptux-core/internal/SendFileData.cpp:243:44: error: format ‘%lx’ expects 
argument of type ‘long unsigned int’, but argument 8 has type ‘__time64_t’ {aka 
‘long long int’} [-Werror=format=]
  243 |":.:0:%lx:%lx=%lx:%lx=%lx:", IPMSG_FILE_RETPARENT,
  |  ~~^
  ||
  |long unsigned int
  |  %llx
../src/iptux-core/internal/SendFileData.cpp:264:32: warning: cast between 
incompatible function types from ‘int (*)(DIR*)’ to ‘GFunc’ {aka ‘void 
(*)(void*, void*)’} [-Wcast-function-type]
  264 | g_queue_foreach(, GFunc(closedir), NULL);
  |^~~
cc1plus: some warnings being treated as errors
...
FAILED: src/iptux-core/libiptux-core.so.0.9.1.p/internal_TcpData.cpp.o 
c++ -Isrc/iptux-core/libiptux-core.so.0.9.1.p -Isrc/iptux-core 
-I../src/iptux-core -Isrc -I../src -Isrc/api -I../src/api 
-I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include 
-I/usr/include/sysprof-6 -I/usr/include/jsoncpp -I/usr/include/sigc++-2.0 
-I/usr/lib/arm-linux-gnueabihf/sigc++-2.0/include -fdiagnostics-color=always 
-D_GLIBCXX_ASSERTIONS=1 -Wall -Winvalid-pch -Wextra -Wpedantic -std=c++14 
-Werror=format -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD -MQ 
src/iptux-core/libiptux-core.so.0.9.1.p/internal_TcpData.cpp.o -MF 
src/iptux-core/libiptux-core.so.0.9.1.p/internal_TcpData.cpp.o.d -o 
src/iptux-core/libiptux-core.so.0.9.1.p/internal_TcpData.cpp.o -c 
../src/iptux-core/internal/TcpData.cpp
../src/iptux-core/internal/TcpData.cpp: In member function ‘void 
iptux::TcpData::RecvSublayer(uint32_t)’:
../src/iptux-core/internal/TcpData.cpp:146:35: error: format ‘%lx’ expects 
argument of type ‘long unsigned int’, but argument 7 has type ‘time_t’ {aka 
‘long long int’} [-Werror=format=]
  146 |   snprintf(path, MAX_PATHLEN, "%s" PIC_PATH "/%" PRIx32 "-%" PRIx32 
"-%lx",
  |   
^~~~
  147 |g_get_user_cache_dir(), inAddrToUint32(pal->ipv4()), 
count++,
  148 |time(NULL));
  |~~  
  ||
  |time_t {aka long long int}

Bug#1070824: Acknowledgement (legiond: depends on lenovolegionlinux-dkms which is in contrib)

[Andreas Beckmann]

Furthermore in dkms.conf you should add

# linux/platform_profile.h, wmi_evaluate_method()
BUILD_EXCLUSIVE_CONFIG="CONFIG_ACPI_PLATFORM_PROFILE CONFIG_ACPI_WMI"

to skip building the module on unsupported kernel configurations


Andreas

Bug#1071038: golang-google-api: timeout in test TestBundlerTimeBasedFlushDeadlock

[Reinhard Tartler]

Source: golang-google-api
Version: 0.61.0-4
Severity: serious
Justification: FTBFS

I am unable to build the package (reliably) on my laptop. It turns out that the
test TestBundlerTimeBasedFlushDeadlock times out after 10 minutes:


It seems that the test introduced by 6114940 is hanging/deadlocking for me:

bundler_test.go:402: timed out: context canceled
panic: test timed out after 10m0s
running tests:
TestBundlerTimeBasedFlushDeadlock (9m57s)

goroutine 1205 [running]:
testing.(*M).startAlarm.func1()
/usr/lib/go-1.22/src/testing/testing.go:2366 +0x385
created by time.goFunc
/usr/lib/go-1.22/src/time/sleep.go:177 +0x2d

goroutine 1 [chan receive, 9 minutes]:
testing.(*T).Run(0xcd6340, {0x556943?, 0x0?}, 0x55bf28)
/usr/lib/go-1.22/src/testing/testing.go:1750 +0x3ab
testing.runTests.func1(0xcd6340)
/usr/lib/go-1.22/src/testing/testing.go:2161 +0x37
testing.tRunner(0xcd6340, 0xca6c70)
/usr/lib/go-1.22/src/testing/testing.go:1689 +0xfb
testing.runTests(0xcaa0a8, {0x65bdc0, 0xd, 0xd}, {0x1?, 0x4b8aae?, 
0x6605a0?})
/usr/lib/go-1.22/src/testing/testing.go:2159 +0x445
testing.(*M).Run(0xcb00a0)
/usr/lib/go-1.22/src/testing/testing.go:2027 +0x68b
main.main()
_testmain.go:79 +0x16c

goroutine 7 [semacquire, 9 minutes]:
sync.runtime_Semacquire(0xc0004aff08?)
/usr/lib/go-1.22/src/runtime/sema.go:62 +0x25
sync.(*WaitGroup).Wait(0x5856c8?)
/usr/lib/go-1.22/src/sync/waitgroup.go:116 +0x48
google.golang.org/api/support/bundler.TestBundlerTimeBasedFlushDeadlock(0xc000304000)

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler_test.go:413
 +0x1b2
testing.tRunner(0xc000304000, 0x55bf28)
/usr/lib/go-1.22/src/testing/testing.go:1689 +0xfb
created by testing.(*T).Run in goroutine 1
/usr/lib/go-1.22/src/testing/testing.go:1742 +0x390

goroutine 54 [select (no cases), 9 minutes]:
google.golang.org/api/support/bundler.TestBundlerErrors.func1({0x522040?, 
0xc0001840d8?})

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler_test.go:245
 +0xf
google.golang.org/api/support/bundler.(*Bundler).handle(0xc0001a20b0, 
0xc00018c0b0?)

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler.go:324
 +0x44
created by google.golang.org/api/support/bundler.(*Bundler).enqueueCurBundle in 
goroutine 53

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler.go:179
 +0x148

goroutine 78 [chan receive, 9 minutes]:
google.golang.org/api/support/bundler.TestAddWait.func2({0x522040?, 
0xc000184018?})

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler_test.go:198
 +0x25
google.golang.org/api/support/bundler.(*Bundler).handle(0xc0001320b0, 0x1af?)

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler.go:324
 +0x44
created by google.golang.org/api/support/bundler.(*Bundler).enqueueCurBundle in 
goroutine 77

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler.go:179
 +0x148
FAILgoogle.golang.org/api/support/bundler   600.035s
testing: warning: no tests to run


This is also experienced on ci.debian.org on:
 - amd64: 
https://ci.debian.net/packages/g/golang-google-api/testing/amd64/46591924/
 - ppc6el: 
https://ci.debian.net/packages/g/golang-google-api/testing/ppc64el/46587668/


This test was introduced here: 
https://github.com/googleapis/google-api-go-client/issues/417

Anthony, Shengjing, what's your thought about simply disabling this test for 
now?

-rt

Bug#1071030: postgresql-15: Drop database hang.

[Владимир Ступин]

On Mon, 13 May 2024 10:09:48 +0200
Christoph Berg  wrote:

> Re: Vladimir Stupin
> > Package: postgresql-15
> > Version: 15.6-0+deb12u1
> > 
> > dropdb on any database hangs up. pg_activity shows query DROP DATABASE
> > ; in state ProcSignalBarrier.
> > 
> > I found fix for the trouble at 
> > https://www.postgresql.org/message-id/E1pKAd5-005BKs-Vr%40gemulon.postgresql.org
> > 
> > I use apt-source to check sources to found fix described at link above.
> > Sources was not fixed. Please update package to fix the trouble.
> 
> Hi,
> 
> the fix you link to was included in 15.2 as 
> 267135d01d79c63dfba7fe69dd3b40c125c49a6f.
> How did you determine it wasn't included?

Checked sources secondary. Sorry, you right. Fix already applied.

> Can you pull a backtrace of the hanging process?
> https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD

Here backtrace, that you asked:

Continuing.

Program received signal SIGINT, Interrupt.
0x7feb07d29de3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#0  0x7feb07d29de3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x55759a1305be in WaitEventSetWait ()
#2  0x55759a130908 in WaitLatch ()
#3  0x55759a13c534 in ConditionVariableTimedSleep ()
#4  0x55759a1363c3 in WaitForProcSignalBarrier ()
#5  0x557599f7173c in dropdb ()
#6  0x55759a159700 in standard_ProcessUtility ()
#7  0x7feb076556cd in ?? () from 
/usr/lib/postgresql/15/lib/pg_stat_statements.so
#8  0x55759a1579e1 in ?? ()
#9  0x55759a157af8 in ?? ()
#10 0x55759a15808e in PortalRun ()
#11 0x55759a15432d in ?? ()
#12 0x55759a155069 in PostgresMain ()
#13 0x55759a0d2d81 in ?? ()
#14 0x55759a0d3d55 in PostmasterMain ()
#15 0x557599e3aa5b in main ()
Detaching from program: /usr/lib/postgresql/15/bin/postgres, process 2227776
[Inferior 1 (process 2227776) detached]

May be i need to install some additional packages with debug symbols to get 
more detailed backtrace?

Here postgresql-packages currently installed:

$ dpkg -l | grep postgresql
ii  postgresql-15  15.6-0+deb12u1 amd64 
   The World's Most Advanced Open Source Relational Database
ii  postgresql-15-repack   1.4.8-1+b1 amd64 
   reorganize tables in PostgreSQL databases with minimal locks
ii  postgresql-client-15   15.6-0+deb12u1 amd64 
   front-end programs for PostgreSQL 15
ii  postgresql-client-common   248all   
   manager for multiple PostgreSQL client versions
ii  postgresql-common  248all   
   PostgreSQL database-cluster manager
ii  timescaledb-2-loader-postgresql-15 2.14.1~debian12amd64 
   The loader for TimescaleDB to load individual versions.
ii  timescaledb-2-postgresql-152.14.1~debian12amd64 
   An open-source time-series database based on PostgreSQL, as an extension.

-- 
Владимир Ступин 

Bug#1071037: v4l2loopback-dkms: module fails to build for i386: ERROR: modpost: "__moddi3" undefined!

[Andreas Beckmann]

Package: v4l2loopback-dkms
Version: 0.13.1-1
Severity: serious

DKMS make.log for v4l2loopback-0.13.1 for kernel 6.7.12-686-pae (i686)
Mon May 13 09:57:13 UTC 2024

++ To sign the  module, you must set KBUILD_SIGN_KEY/KBUILD_SIGN_CERT to 
point to the signing key/certificate!
++ For your convenience, we try to read these variables as 
'mok_signing_key' resp. 'mok_certificate' from /etc/dkms/framework.conf

++ If your certificate requires a password, pass it via the KBUILD_SIGN_PIN 
env-var!
++ E.g. using 'export KBUILD_SIGN_PIN; read -s -p "Passphrase for signing 
key : " KBUILD_SIGN_PIN; sudo --preserve-env=KBUILD_SIGN_PIN make sign'

Building v4l2-loopback driver...
make -C /lib/modules/6.7.12-686-pae/build 
M=/var/lib/dkms/v4l2loopback/0.13.1/build KCPPFLAGS="" modules
make[1]: Entering directory '/usr/src/linux-headers-6.7.12-686-pae'
  CC [M]  /var/lib/dkms/v4l2loopback/0.13.1/build/v4l2loopback.o
  MODPOST /var/lib/dkms/v4l2loopback/0.13.1/build/Module.symvers
ERROR: modpost: "__moddi3" 
[/var/lib/dkms/v4l2loopback/0.13.1/build/v4l2loopback.ko] undefined!
make[3]: *** 
[/usr/src/linux-headers-6.7.12-common/scripts/Makefile.modpost:145: 
/var/lib/dkms/v4l2loopback/0.13.1/build/Module.symvers] Error 1
make[2]: *** [/usr/src/linux-headers-6.7.12-common/Makefile:1888: modpost] 
Error 2
make[1]: *** [/usr/src/linux-headers-6.7.12-common/Makefile:246: __sub-make] 
Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.7.12-686-pae'
make: *** [Makefile:53: v4l2loopback.ko] Error 2


This probably affects more 32-bit architectures ...

IIRC gcc generates a __moddi3 function call for
(long long) a % (long long) b
(or a similar operation on long long) on architectures without native
support for long long. The symbol is provided by libgcc_s but for
obvious reasons the kernel cannot be linked agaist that library.

This seems to be a regression from the v4l2loopback-dkms +
linux-headers-* combination in bookworm.

This problem does not appear during the autopkgtest since that is
restricted to amd64 and arm64 (which is probably a copy+paste mistake as
the commit references bbswitch-dkms which is only useful on platforms
with the proprietary nvidia driver and thus restricted to these
architectures).


Andreas