date:20240325

Source: frameworkintegration
Version: 5.115.0-1
Severity: serious

B-D on libqt5widgets5 needs to be updated to libqt5widgets5t64 so that the
package can be rebuilt again.


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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#1060795: severity of 1060795 is grave

2024-03-25 Thread Julien Cristau

severity 1060795 grave
thanks

Not sure how this was allowed to get into testing, but surely this
qualifies as RC...

Cheers,
Julien

Bug#1067658: Update source link to package recent software version

2024-03-25 Thread Narcis Garcia


Package: wondershaper
Version: 1.1a-10.1
Severity: normal
Justification: Source homepage not updated, then software not updated

Dear Maintainer:
Due to obsolete source link, this package is not being updated to 
current project's version: 1.4.1


"Wonder Shaper is a script that allows the user to limit the bandwidth 
of one or more network adapters. It does so by using iproute's tc 
command, but greatly simplifies its operation. Wonder Shaper was first 
released by Bert Hubert in 2002, but the original version lacked a 
command-line interface, from on version 1.2 this feature was added. From 
version 1.3, the HTB queuing is used instead of CBQ, allowing better 
bandwidth management on high speed (above ten megabits) links. In 
version 1.4 an improved ingress shaping method was implemented and the 
ability to limit either down or up (both is still possible too)"


https://github.com/magnific0/wondershaper/
Debian source link should be updated, to get the latest package's changes

+ Please update your e-mail address on package details.

--
Regards,
Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't
masked enough at this tracker archive. Public archive administrator
should fix this against automated addresses collectors.

Bug#1067659: nmu: libfixbuf_2.4.1+ds-2

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: libfix...@packages.debian.org
Control: affects -1 + src:libfixbuf
User: release.debian@packages.debian.org
Usertags: binnmu

nmu libfixbuf_2.4.1+ds-2 . riscv64 . unstable . -m "Rebuild with
libglib2.0-0t64"

https://packages.debian.org/sid/libfixbuf-tools

Bug#1067660: wireplumber: Wireplumber 0.5.0 breaks asahi-audio 1.x

2024-03-25 Thread Thomas Renard

Package: wireplumber
Version: 0.4.17-1+b1
Severity: normal

Dear Maintainer,

According to the new api in wireplumber asahi-audio 1.x breaks. The asahi
developer tries to fix this upstream in asahi-audio during this week but 
because of the
api change asahi-audio 2.x will break with wireplumber <0.5.0.

So there is/will be a direct dependency:

wireplumber 0.4.x compatible to asahi-audio 1.x
wireplumber >= 0.5.0 comaptible to asahi-audio 2.x

Source; fedora-asahi-dev channel on matrix 24.03.2024, @chadmed around 01.24.
https://matrix.to/#/#asahi-devel:fedoraproject.org

Please consider this

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 6.6.0-asahi-00915-ge3707768193f (SMP w/10 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wireplumber depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-4
ii  dbus-x11 [dbus-session-bus]   1.14.10-4
ii  init-system-helpers   1.66
ii  libc6 2.37-15
ii  libglib2.0-0t64 [libglib2.0-0]2.78.4-3
ii  libpipewire-0.3-0 1.0.3-1
ii  libwireplumber-0.4-0  0.4.17-1+b1
ii  pipewire  1.0.3-1

Versions of packages wireplumber recommends:
ii  pipewire-pulse  1.0.3-1

Versions of packages wireplumber suggests:
ii  libspa-0.2-bluetooth  1.0.3-1
pn  libspa-0.2-libcamera  
pn  wireplumber-doc   

-- no debconf information

Bug#1067661: condor: unable to install condor on armhf in Ubuntu

2024-03-25 Thread Vladimir Petko

Package: condor
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Dear Maintainer,

The package d/control file hardcodes dependencies to libssl, libscitokens0 and
libvomsapi1v5 that were renamed to t64 suffix due to the time_t transition. I
have applied a proposed fix[1] to generate the library name in
override_dh_gencontrol and validated that the package builds and installs in
sid chroot.

In Ubuntu, the attached patch was applied to achieve the following:

  * Don't hard-code dependency on a shared library (LP: #2058880).


Thanks for considering the patch.

[1] https://lists.ubuntu.com/archives/ubuntu-devel/2024-March/042948.html


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

Kernel: Linux 6.5.0-25-generic (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru condor-23.4.0+dfsg/debian/control condor-23.4.0+dfsg/debian/control
--- condor-23.4.0+dfsg/debian/control   2024-03-23 09:07:04.0 +1300
+++ condor-23.4.0+dfsg/debian/control   2024-03-25 15:56:46.0 +1300
@@ -25,6 +24,7 @@
libpcre2-dev,
libpq-dev,
libscitokens-dev,
+   libssl-dev,
libsqlite3-dev,
libsystemd-dev,
libvirt-dev,
@@ -59,12 +59,10 @@
  libkrb5-3,
  libkrb5support0,
  libmunge2,
- libssl3t64,
- libscitokens0,
- libvomsapi1v5,
  net-tools,
  libjs-bootstrap,
  libjs-jquery,
+ ${lib:Depends},
  ${misc:Depends},
  ${perl:Depends},
  ${python3:Depends},
diff -Nru condor-23.4.0+dfsg/debian/rules condor-23.4.0+dfsg/debian/rules
--- condor-23.4.0+dfsg/debian/rules 2024-03-23 09:07:04.0 +1300
+++ condor-23.4.0+dfsg/debian/rules 2024-03-25 15:56:46.0 +1300
@@ -132,3 +132,10 @@
 
 override_dh_auto_test:
 
+override_dh_gencontrol:
+   dh_gencontrol -- \
+   -Vlib:Depends="$(foreach package, libscitokens libssl, \
+   $(shell dpkg-query -W -f '$${Depends}' $(package)-dev \
+   | sed -E 
's/.*($(package)[[:alnum:].-]+).*/\1,/' )) \
+   $(shell dpkg-query -W -f '$${Depends}' voms-dev \
+   | sed -E 
's/.*(libvomsapi[[:alnum:].-]+).*/\1,/' )"

Bug#1067662: a2jmidid doesn't handle midi interfaces with two or more identical port names correctly and fails to expose them

2024-03-25 Thread Reinaert Albrecht

Package: aj2midid
Version: 9-3

This issue has been solved in 2019 in a2jmidid:
https://github.com/jackaudio/a2jmidid/pull/5

It's been described in various places:
https://linuxmusicians.com/viewtopic.php?t=24822

Could you please include this in the packages? It basically boils down to
this four letter change in port.c:
  119c119
  <   "%s [%d] (%s): [%d] %s",
  ---
  >   "%s [%d] (%s): %s",

I'm filing this bug since the Ubuntu maintainer asked me to file it here.

Bug#1067630: fixed in emacs 1:29.3+1-1

2024-03-25 Thread Sean Whitton

Hello,

On Mon 25 Mar 2024 at 10:21am +07, Max Nikulin wrote:

> On Mon, 25 Mar 2024 01:13:54 + Debian FTP Masters wrote:
>> Source: emacs
>> Source-Version: 1:29.3+1-1
>> Done: Rob Browning
>
> Should this issue be reopened or be cloned to backport fixes to Emacs-28 in
> Debian stable?

Neither are necessary.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067651: mapserver fails to build on armhf in Ubuntu due to implicit declaration of strlcpy

2024-03-25 Thread Sebastiaan Couwenberg


On 3/25/24 9:25 AM, Vladimir Petko wrote:

  strlcpy and strlcat were introduced in glibc 2.38[1]. At the moment
Ubuntu noble has 2.39  and Debian unstable  - 2.37.


Can you try the attached patch which patches CMakeLists.txt to add the 
definition when strlcat/strlcpy are found on Linux?


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
Description: Add -D_BSD_SOURCE for strlcat/strlcpy privided by glibc >= 2.38.
Author: Bas Couwenberg 
Bug-Debian: https://bugs.debian.org/1067651

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -121,6 +121,10 @@ check_function_exists("strlcpy"  HAVE_ST
 check_function_exists("strlen"  HAVE_STRLEN)
 check_function_exists("strncasecmp"  HAVE_STRNCASECMP)
 
+IF((HAVE_STRLCAT OR HAVE_STRLCPY) AND CMAKE_SYSTEM_NAME MATCHES "Linux")
+add_definition(-D_BSD_SOURCE)
+ENDIF
+
 check_symbol_exists(vsnprintf stdio.h HAVE_VSNPRINTF)
 IF(NOT HAVE_VSNPRINTF)
 check_function_exists("vsnprintf"  HAVE_VSNPRINTF)

Bug#1067660: wireplumber: Wireplumber 0.5.0 breaks asahi-audio 1.x

2024-03-25 Thread Dylan Aïssi

Control: reassign -1 asahi-audio
Control: notfound -1 0.4.17-1
Control: found -1 1.7-1
Control: affects -1 wireplumber

Hello,
Thanks for this bug report, I reassign it to asahi-audio since the versioned
dependency is on it and not on wireplumber.

Le lun. 25 mars 2024 à 09:45, Thomas Renard  a écrit :
>
> According to the new api in wireplumber asahi-audio 1.x breaks. The asahi
> developer tries to fix this upstream in asahi-audio during this week but 
> because of the
> api change asahi-audio 2.x will break with wireplumber <0.5.0.
>
> So there is/will be a direct dependency:
>
> wireplumber 0.4.x compatible to asahi-audio 1.x
> wireplumber >= 0.5.0 comaptible to asahi-audio 2.x
>
> Source; fedora-asahi-dev channel on matrix 24.03.2024, @chadmed around 01.24.
> https://matrix.to/#/#asahi-devel:fedoraproject.org
>
> Please consider this

I don't plan to upload wireplumber 0.5.0 to unstable soon because it's
kind of blocked
by waybar which is not yet compatible with it, it's fixed in git
upstream but no release
and also because of the t64 transition. So, since asahi-audio seems to
want to fix this
bug this week, we should have a new compatible version of asahi-audio
in due course.

Best,
Dylan

Bug#1066025: dh_installsystemd doesn't process user services in /usr/lib/systemd/user/

2024-03-25 Thread Sergey Ponomarev

Hi Niels,

I upgraded to Ubuntu 24.04 and now have debhelper 13.14.1ubuntu1.
Once executed the debuild nothing was generated.
When executed the dh_installsystemduser manually also nothing was generated.
>From it's sources I found that it looks for some dependency and I added to
the /debian/control:

Depends: ${misc:Depends}

Now this helped and two install/uninstall scripts were generated
/debian/sshtunnel.postinst.debhelper
/debian/sshtunnel.postrm.debhelper

I manually included the scripts to /debian/postinst and /debian/postrm and
built the deb.
It was installed successfully but didn't start the service.
I started manually. During uninstall it has not been stopped. There is no
prerm script that will do that.

So the issues are:
1. The debhelper did not execute the dh_installsystemduser. I guess I must
add it manually to /debian/rules
2. The generated scripts do not start the service after installation.
3. Missing prerm script to stop the service.
4. Surprising need for for ${misc:Depends}

So far I will anyway continue to use the manual scripts because I wish to
support old distros.
Anyway I wanted to have good and proper "official" scripts to install the
user service.

You can play with my simple package here:
http://github.com/yurt-page/sshtunnel

It can be a good sample and test ground.

Best regards and thank you for your work,
Sergey

On Sat, Mar 16, 2024 at 7:50 PM Niels Thykier  wrote:

> Control: tags -1 moreinfo
>
> Niels Thykier:
> > Sergey Ponomarev:
> >> debhelper package version: 13.11.6ubuntu1
> >> Ubuntu 23.10 Mantic
> >>
> >> Is there any plan for support of user services?
> >> The user service is complicated by itself because it differs by commands
> >> from system services.
> >> That's why I also asked to make a review of mine scripts to have at
> least
> >> one right example of this.
> >>
> >>
> >> [...]
> >
> > User services are handled by `dh_installsystemduser` (not
> > `dh_installsystemd`) and that command used `/usr/lib` since the
> > beginning as far as I can tell. That command was added in 10.9.1 and
> > should be in the default sequence.
> >
> > Best regards,
> > Niels
> >
> >
>
> Hi Sergey,
>
> I hope the above solved your issues.  If so, I will close this bug as
> resolved. :)
>
> Best regards,
> Niels
>
>

Bug#1067651: mapserver fails to build on armhf in Ubuntu due to implicit declaration of strlcpy

2024-03-25 Thread Vladimir Petko

Hi,

Thank you!!!

I've made a small change to the patch: used -D_DEFAULT_SOURCE[1] to
avoid the deprecation warning. I have tested noble and sid build with
the attached patch.

Best Regards,
 Vladimir.
[1] https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html

On Mon, Mar 25, 2024 at 9:57 PM Sebastiaan Couwenberg
 wrote:
>
> On 3/25/24 9:25 AM, Vladimir Petko wrote:
> >   strlcpy and strlcat were introduced in glibc 2.38[1]. At the moment
> > Ubuntu noble has 2.39  and Debian unstable  - 2.37.
>
> Can you try the attached patch which patches CMakeLists.txt to add the
> definition when strlcat/strlcpy are found on Linux?
>
> Kind Regards,
>
> Bas
>
> --
>   GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
Description: Add -D_BSD_SOURCE for strlcat/strlcpy privided by glibc >= 2.38.
Author: Bas Couwenberg 
Bug-Debian: https://bugs.debian.org/1067651

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -121,6 +121,10 @@ check_function_exists("strlcpy"  HAVE_ST
 check_function_exists("strlen"  HAVE_STRLEN)
 check_function_exists("strncasecmp"  HAVE_STRNCASECMP)

+IF((HAVE_STRLCAT OR HAVE_STRLCPY) AND CMAKE_SYSTEM_NAME MATCHES "Linux")
+add_definitions(-D_DEFAULT_SOURCE)
+ENDIF()
+
 check_symbol_exists(vsnprintf stdio.h HAVE_VSNPRINTF)
 IF(NOT HAVE_VSNPRINTF)
 check_function_exists("vsnprintf"  HAVE_VSNPRINTF)

Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

2024-03-25 Thread Alberto Bertogli


On Sun, Mar 24, 2024 at 06:00:51PM +, Chris Lamb wrote:

Alberto Bertogli wrote:


I'll try to get a debian install to boot for armhf, but it'll take me a
bit because it's not straightforward (to put it mildly :).


Oh, yeah. :/ Perhaps qemu might be better option here. There might
even be pre-built disk images flying around.


Sorry, yes that's what I meant! To install it under qemu!

Unfortunately, I haven't been able to get it to work.

I managed to get bookworm installed, and then extracted the 
kernel+initrd from inside the virtual disk (as apparently that's 
needed), but the kernel won't boot due to: `Unhandled fault: synchronous 
abort (translation table walk)`.


At this point I'm not really keen on debugging whatever that armhf 
kernel issue is :(


If you know of a functional official image that I can use to try to 
reproduce the problem, or recently-tested steps I can follow to get a 
working qemu install, please let me know.


Thanks,
Alberto

Bug#1051774: PySNMP / asyncio bugfix

2024-03-25 Thread Adam Cecile


Hello guys

Any news regarding this bugfix ?

Regards, Adam.

Bug#1067651: mapserver fails to build on armhf in Ubuntu due to implicit declaration of strlcpy

2024-03-25 Thread Sebastiaan Couwenberg


Control: tags -1 pending

On 3/25/24 10:20 AM, Vladimir Petko wrote:

I've made a small change to the patch: used -D_DEFAULT_SOURCE[1] to
avoid the deprecation warning. I have tested noble and sid build with
the attached patch.


Thanks for you patch improvements. I've managed to test my original 
patch and yours with glibc 2.38 from Debian experimental. I'll forward 
it upstream and include it in the next upload.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1067663: org-mode: Org mode 9.6.23 that fixes several critical

2024-03-25 Thread David Bremner

Package: org-mode
Version: 9.6.10+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: debian-emac...@lists.debian.org, Debian Security Team 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

In https://list.orgmode.org/87o7b3eczr@bzg.fr/T/#t, Ihor Radchenko writes


I just released Org mode 9.6.23 that fixes several critical
vulnerabilities. The release is coordinated with emergency Emacs 29.3
release
(https://lists.gnu.org/archive/html/info-gnu/2024-03/msg5.html).

Please upgrade your Org mode *and* Emacs ASAP.

The vulnerabilities involve arbitrary Elisp and LaTeX evaluation when
previewing attachments in Emacs or when opening third-party Org files.


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

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

Versions of packages org-mode depends on:
ii  elpa-org  9.6.10+dfsg-1

org-mode recommends no packages.

org-mode suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmYBSjMACgkQA0U5G1Wq
FSHjuA/+PbZdJex2gariys1U8zA9ExAUW0TKE2Pt/k/bngZt9+B7JGm1bNqSMkBm
mPN+6uIEZdmmasNCqHzNwlxPyezWnL1ik4n3lfz1fkXMSf7YWExcL/rnBvsc6aqi
yzTB0IPP2+1Jx0BV3ysiX62eRlLXiv3NlJQuKHyOwVCjOUDJUdN25YgZQ7b4Q2/S
4lC6O1wkmJqyV/PopvHIeFTo76l8Cg612ZGFrdniXkWB4zUSl2MdfsduimFO4xfp
/izY1u7nCT+bdsKT6OdvKqV5bStEukiklo/A2V9KTWrAQ2xeNwgE0gtP6MYzVfZ+
f7of4+SCqt0dZMwLiuZse+XA82nPnDqSdiT5A5EGRQ8am5BQ9d0weOoaQMho3vym
bUQO0rdU0MCrZR3MxCH4YPKm1ge1wPS7zLL48/+6PFhlHHkmQ1t98EzCbJ+gEgJW
Qm/wnT0ctJRmp2uqGDpRLeI0t+YU/kyfaaHS/rB7XSkQN6vBmJKnClGmgFnhVphR
hrQVVpJjD0SeZSv9uOUI17HfPz9v3pIKLCMs4R2+WTddxf6bdXytFmlOWBlcvEpE
0ocIW00D68jDWx0Bq1PItEJ11V9GbcqrigtBHfEocYVnL4hB3x5lkaGkMF5P2gOn
4OL3eC+UqJoEpr53PiD5fdbo7WkeI3NCdDBqb/GDn9Kj4HQyZqY=
=aTCW
-END PGP SIGNATURE-

Bug#1067630: fixed in emacs 1:29.3+1-1

2024-03-25 Thread Max Nikulin


On 25/03/2024 15:47, Sean Whitton wrote:

On Mon 25 Mar 2024 at 10:21am +07, Max Nikulin wrote:


On Mon, 25 Mar 2024 01:13:54 + Debian FTP Masters wrote:

Source: emacs
Source-Version: 1:29.3+1-1
Done: Rob Browning


Should this issue be reopened or be cloned to backport fixes to Emacs-28 in
Debian stable?


Neither are necessary.


Do you mean that somebody is working on backporting changes to 28.2 in 
bookworm already? This bug is closed. Have I missed other ones for 
elpa-org in unstable and for emacs in stable?

Bug#1063140: mpg123: NMU diff for 64-bit time_t transition

2024-03-25 Thread Sebastian Ramacher

Hi Thomas

On 2024-03-23 15:24:58 +0100, Thomas Orgis wrote:
> Hi Sebastian,
> 
> 
> Am Sat, 23 Mar 2024 10:40:43 +0100
> schrieb Sebastian Ramacher : 
> 
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_decode_frame_32@Base 
> > 1.13.7
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_feedseek_32@Base 
> > 1.13.7
> > +#MISSING: 1.32.5-1+b1# 
> > (arch-bits=32|arch=!x32)mpg123_framebyframe_decode_32@Base 1.13.7
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_framelength_32@Base 
> > 1.23.8
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_framepos_32@Base 
> > 1.14.0
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_index_32@Base 1.13.7
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_length_32@Base 1.13.7
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_open_32@Base 1.13.7
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_open_fd_32@Base 
> > 1.13.7
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_open_fixed_32@Base 
> > 1.26.0
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_open_handle_32@Base 
> > 1.13.7
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_position_32@Base 
> > 1.13.7
> > +#MISSING: 1.32.5-1+b1# 
> > (arch-bits=32|arch=!x32)mpg123_replace_reader_32@Base 1.13.7
> > +#MISSING: 1.32.5-1+b1# 
> > (arch-bits=32|arch=!x32)mpg123_replace_reader_handle_32@Base 1.13.7
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_seek_32@Base 1.13.7
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_seek_frame_32@Base 
> > 1.13.7
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_set_filesize_32@Base 
> > 1.13.7
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_set_index_32@Base 
> > 1.13.7
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_tell_32@Base 1.13.7
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_tell_stream_32@Base 
> > 1.13.7
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_tellframe_32@Base 
> > 1.13.7
> > +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_timeframe_32@Base 
> > 1.13.7
> > +#MISSING: 1.32.5-1+b1# 
> > (arch-bits=32|arch=!x32)syn123_resample_intotal_32@Base 1.26.2
> > +#MISSING: 1.32.5-1+b1# 
> > (arch-bits=32|arch=!x32)syn123_resample_total_32@Base 1.26.2
> > Do you know what's happenig here?
> 
> This looks just like the list of wrapper functions offered for
> applications that do not enable LFS (_FILE_OFFSET_BITS unset or 32).
> 
> Steve mentioned this:
> 
> > (you can't enable 64-bit time_t compatibility to use the other
> > libraries it calls, without also turning on LFS).
> 
> So I take it you build mpg123 with enforced LFS so that the build does
> not detect ambiguity in off_t and hence doesn't offer 32 bit wrappers.

On all 32 bit architectures except i386 we are now building with
-D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64. Both gcc and dpkg now set
both flags. So unless the build system of a package forcibly unsets
_FILE_OFFSET_BITS and _TIME_BITS, all Debian release architectures
(except i386) now build with with 64 bit time_t and off_t.

i386 stays unchanged for historic reasons.

> I recently took pains to make the actual library code independent of
> LFS choice, using explicit 64 bit API. But If you build with
> -D_FILE_OFFSET_BITS=64 enforced, mpg123's configure will _not_ set
> 
>   lfs_sensitive=yes
>   AC_DEFINE(LFS_SENSITIVE, 1, [ System redefines off_t when defining 
> _FILE_OFFSET_BITS to 64. ])
> 
> as defining the offset bits to 64 doesn't change the size of off_t, so
> it looks like a pure 64 bit offset system. But this doesn't control the
> symbols, only usage of libmpg123 API by the mpg123 application.
> 
> That happens in src/libmpg123/lfs_wrap.c:
> 
> off_t attribute_align_arg mpg123_tell(mpg123_handle *mh)
> {
> int64_t pos = mpg123_tell64(mh);
> OFF_RETURN(pos, mh)
> }
> 
> #if SIZEOF_OFF_T == 4
> 
> int attribute_align_arg mpg123_open_32(mpg123_handle *mh, const char *path)
> {
> return mpg123_open(mh, path);
> }
> 
> #endif
> 
> #if defined(LFS_LARGEFILE_64) || (SIZEOF_OFF_T == 8)
> 
> #ifdef LFS_LARGEFILE_64
> #define OFF64 off64_t
> #else
> #define OFF64 off_t
> #endif
> 
> OFF64 attribute_align_arg mpg123_tell_64(mpg123_handle *mh)
> {
> return mpg123_tell64(mh);
> }
> 
> #endif
> 
> So, there is the new portable mpg123_tell64 which works with int64_t,
> always. There is a 'native' off_t wrapper over this with no suffix. If 
> the 'native' off_t is 32 bits, an _32 alias to that is added. If
> the 'native' off_t is 64 bits, or if off64_t is available, a _64 alias
> is created with _64 suffix.
> 
> The changed Debian build seems to trigger the case of 'native 64 bit
> off_t'. Is that really an issue if you rebuild all software with that
> setting? It should only ever use the _64 symbols. Should we explicitly
> add 32 bit wrappers that nobody needs?

It is not necessary if we are renaming the binary packages instead. So
we'd implement Steve's origin

Bug#1067531: fix ftbfs with 64bit time_t

2024-03-25 Thread Mike Gabriel


Control: closed -1
Control: fixed -1 0.2.1-9

Hi Matthias,

On  Sa 23 Mär 2024 09:14:49 CET, Matthias Klose wrote:


Package: src:lomiri
Version: 0.2.1-7
Severity: serious
Tags: sid trixie ftbfs patch

fix ftbfs with 64bit time_t, patch at

http://launchpadlibrarian.net/720782511/lomiri_0.2.1-7build3_0.2.1-7ubuntu1.diff.gz


This has been fixed in 0.2.1-9. Please sync lomiri to Ubuntu to make  
patching unnecessary.


Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpT1_gIhjVm7.pgp
Description: Digitale PGP-Signatur

Bug#1067664: FTBFS: dh_installdocs: error: Requested unknown package libspf2-2 via --link-doc

2024-03-25 Thread Andreas Metzler

Source: libspf2
Version: 1.2.10-8.1
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

Even with fixing the -Werror=implicit-function-declaration build error
libspf2 also fails to build (dpkg-buildpackage -b) at dh_installdocs
with:

mv debian/spfquery/usr/sbin/spfd debian/spfquery/usr/sbin/spfd.libspf2
dh_installdocs -a --link-doc=libspf2-2
dh_installdocs: error: Requested unknown package libspf2-2 via --link-doc, 
expected one of: libspf2-2t64 libspf2-dev spfquery libmail-spf-xs-perl
make: *** [debian/rules:68: binary-arch] Error 25

I think this will also be fixed by the change in #1067204 but filing for
completeness sake.

I inted to fix this by NMU.

cu Andreas

Bug#1067665: cvise 2.10.0-1 still build-depends on python-pytest-flake8 (broken with recent flake8)

2024-03-25 Thread Olivier Gayot

Package: cvise
Version: 2.10.0-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Dear Maintainer,

In version 2.10.0, upstream dropped the dependency on pytest-flake8
because it is no longer maintained [1] and broken with modern flake8.

However, in 2.10.0-1 in Debian, the build dependency on
python3-pytest-flake8 is still present, albeit unused during the build
process.

This is preventing removal of python-pytest-flake8. 

In Ubuntu, the attached patch was applied to achieve the following:

  * Drop dependency on python-pytest-flake8 (broken with modern flake8) which
was already dropped upstream in cvise 2.10 and is now unused (LP: #2058917)


Thanks for considering the patch.


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

Kernel: Linux 6.8.0-11-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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
diff -Nru cvise-2.10.0/debian/control cvise-2.10.0/debian/control
--- cvise-2.10.0/debian/control 2024-03-12 16:49:12.0 +0100
+++ cvise-2.10.0/debian/control 2024-03-25 10:45:07.0 +0100
@@ -13,7 +13,6 @@
   python3-pebble,
   python3-psutil,
   python3-pytest ,
-  python3-pytest-flake8 ,
   llvm-18-dev, libclang-18-dev, clang-18, clang-format-18,
 #  clang-tools-18, clang-tidy-18, clangd-18,
   unifdef,

Bug#1063140: mpg123: NMU diff for 64-bit time_t transition

2024-03-25 Thread Thomas Orgis

Hi Sebastian,

thanks for not escalating on the anger that has shown through the end
of my last reply. It really seems to be an endless stream of pain that
results from once having put off_t into public API. This is the message
I have to any developer: Do not put types into your API that could
depend on compile-time settings! (Even, and especially, if the libc
does that and you _think_ it could be handled.)

At least it is clear to me now that time_t is only a minor detail.

You are switching system ABI in enabling LFS and 64 bit time_t. This is
a decision that Debian made and also, you are planning to make this
transition in-place, instead of calling it a new arch.

From my point of view, then, the mpg123 build works as designed: It
sees a system with fixed 64 bit off_t and drops any 32 bit off_t
support from the ABI. Since you do this switch on upgrade of existing
systems, you need to handle that in the packaging system, either via
versioning or the suffix you designed. Fine, then. But there is a
consideration for user-compiled code in the system.

The important breakage here is not that the _32 suffix symbols are
missing. It is rather that the non-suffixed ABI suddenly changed.
If a user program that just was built without _FILE_OFFSET_BITS being
set for the old library is started using the replaced libmpg123 binary,
it finds the mpg123_tell() symbol, but suddenly faces memory corruption
as that function now writes 64 bits instead of 32 bits to the return
address.

A clean transition, IMHO, would mean that you have to change sonames so
that it is clear that the new libraries have a different ABI. Silently
breaking user binaries is a bothersome issue to me. Breaking them with
'library not found' errors is obvious. Subtle errors and crashes
through memory corruption are not.

I'd rather have that situation avoided.

One solution would be to have a library mode that drops both

mpg123_tell()
mpg123_tell_32()

and only retains mpg123_tell_64() as well as the recently added actual
mpg123_tell64() using int64 instead of off_t. If _FILE_OFFSET_BITS is
defined system-wide (in gcc internal headers / spec file), new builds
will pick up mpg123_tell_64() and not notice any missing symbols.

With this, you only have the missing symbols for clear errors at least.

On the other hand, providing the wrappers for 32 bit is a possible
option. The code is there … but … thinking … no. It doesn't help.
Having a 32 bit mpg123_tell() in a system defaulting to 64 bit off_t is
really confusing.

Can you do a scan over all depending packages and ensure that they only
use _64 suffixed symbols (where there is a pair like mpg123_tell() and
mpg123_tell_64())?

Even if you change the package name for the transition, I'd like to
ensure that the new library does cause controlled failure due to linker
errors instead of subtle runtime breakage.

Would you be willing to add something along

./configure --disable-suffixless-abi

to your builds once I implement that? This would double the count of
dropped symbols, but avoid the subtle runtime ABI breakage.


Alrighty then,

Thomas

PS: Please observe my comments about --with-cpu on ARM, bug #1067562.

Bug#1067666: FTBFS: error: implicit declaration of function ‘inet_pton’

Source: sipgrep
Version: 2.1.0-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=sipgrep&arch=amd64&ver=2.2.0-1&stamp=1711359605&raw=0

transport_hep.c: In function ‘send_hepv3’:
transport_hep.c:80:5: error: implicit declaration of function ‘inet_pton’
[-Werror=implicit-function-declaration]
   80 | inet_pton (AF_INET, rcinfo->src_ip, &src_ip4.data);
  | ^


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1067667: FTBFS: Imported target "Qt::CorePrivate" includes non-existent path

Source: qbittorrent
Version: 4.6.4-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=qbittorrent&arch=amd64&ver=4.6.4-1&stamp=1711350555&raw=0

-- Configuring done (1.6s)
CMake Error in src/base/CMakeLists.txt:
  Imported target "Qt::CorePrivate" includes non-existent path

"/usr/include/x86_64-linux-gnu/qt6/QtCore/6.4.2"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.



CMake Error in src/base/CMakeLists.txt:
  Imported target "Qt::CorePrivate" includes non-existent path

"/usr/include/x86_64-linux-gnu/qt6/QtCore/6.4.2"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1067668: FTBFS: error: Cannot find (any matches for) "ReadMe"

Source: licenserecon
Version: 1.9
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=licenserecon&arch=amd64&ver=1.9&stamp=1711339889&raw=0

   dh_installdocs -a
dh_installdocs: error: Cannot find (any matches for) "ReadMe" (tried in .,
debian/tmp)


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1067669: FTBFS on 32-bit: test possible_underflow ... FAILED

Source: rust-uutils-term-grid
Version: 0.6.0-1
Severity: serious
Tags: ftbfs

test uutils_ls::columns_width_30 ... ok
test possible_underflow ... FAILED

failures:

 possible_underflow stdout 
thread 'possible_underflow' panicked at 'attempt to multiply with overflow',
/usr/src/rustc-1.70.0/library/core/src/num/mod.rs:371:5


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1067671: unable to run "make pot" due to missing english/template/debian/legal.wml

2024-03-25 Thread Wenbin Lv

Package: www.debian.org

Hi,

I noticed some .pot files are out of date when translating the web pages,
but can't update them by running "make pot" under english/po. The errors
are:

../../english/po/wmlxgettext.pl legal
../../english/template/debian/legal.wml
../../english/template/debian/legal_tags.wml > ../../english/po/legal.pot
Unable to open ../../english/template/debian/legal.wml
make[1]: *** [Makefile:140: ../../english/po/legal.pot] Error 2
make[1]: Leaving directory '/home/lwb/sources/webwml/english/po'
make: *** [Makefile:184: pot] Error 2

This file was deleted in commit 4e6f84e3b617a3ef6f7fb3c7b7d4e75ef302968c.

Thanks,
Wenbin Lv

Bug#1067670: ITP: tclsyslog -- Tcl interface to the standard syslog service

2024-03-25 Thread Massimo Manghi

Package: wnpp
Severity: wishlist
Owner: Massimo Manghi 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: tclsyslog
  Version : 1.1
  Upstream Contact: Alexandros Stergiakis 
* URL : https://tcl-syslog.sourceforge.net/
* License : GPL
  Programming Lang: C,Tcl
  Description : Tcl interface to the standard syslog service

Server applications need to generate activity log messages and for this
purpose the standard syslog facility is the natural choice. Tcl is
a scripting language which from its inception was designed with
a solid capability of handling asynchronous communications, a feature
that made a language of choice for the development of server side
applications. I need a sponsor for this package.

Bug#1067096: ITP: galvani -- reads data from a device with graphical plots and evaluation

2024-03-25 Thread Dr. Burkard Lutz

Am Freitag, dem 22.03.2024 um 18:51 -0700 schrieb Dima Kogan:
> > You wrote: "- Each release of "galvani" should have a git tag".
> > Does
> > that mean, that every file in the release should have a tag
> > "v_0.34"
> > or similar?
> 
> Tags apply to the whole repository, not to individual files.
> 
Ok, thank you.

> I'm still confused, though. Are you the author of this software? Is
> there version control somewhere? You're packaging version 0.34; is
> there
> a version 0.33? Where is it? What are the differences between the
> two?
> What about version 0.35? Is it going to be developed? Where are those
> commits going to go?
> 
All versions are on my local computer. I started with version 0.10.
Whenever I added new functions or fixed several bugs, I increased the
version number.

> I'm guessing your development happens in some non-public place, and
> this
> is the first public releaes. Is there a non-public version control?
> or a
> non-public place to download this software? If so, can that version
> control (or the release tarballs) be made public as well?
> 
The actual version ("0.34") is the first which contains all desired
functions, and after extensive testing I hope that there are only minor
bugs left. Therfore I decided to make an attempt for publishing it on
debian.
Should I rename it to "0.10"?
Now you can see the project under the following address:
https://gitlab.com/b.lutz1/galvani
I changed the group name to "galvani" but the path to the project
remained the same.

> I think there are some (mostly older) Debian packages where upstream
> develops behind closed doors, and releases a tarball to the public
> periodically. It's unideal, but you can do that too, if that's what
> you
> want.
> 
I saw that you are a member of debian-science-team. Did you have some
time so far to have a look at my project? Do you think debian-science-
team could be interested in that project?

> Whatever we're doing, there has to be a clear idea of where upstream
> lives.
> 
> Sorry to be a pain, you're just trying to do something nonstandard,
> and
> I don't know what specifically to suggest, yet.

I'm looking for a sponsor to publish the project on debian. Can you
perhaps help me in that issue?

Regards

-- 
Dr. Burkard Lutz
Hellmut-von-Gerlachstr. 35
34121 Kassel

Bug#1067672: openvas-scanner: Use distro-wide _FORTIFY_SOURCE instead of hard-coded from upstream

2024-03-25 Thread Florent 'Skia' Jacquet

Source: openvas-scanner
Severity: normal
Tags: patch
X-Debbugs-Cc: florent.jacq...@canonical.com

Hi,

We had a recent FTBFS in Ubuntu due to upstream hardcoding the FORTIFY_SOURCE 
flag in its build-system. Would you consider the following patch enabling 
distro-wide hardening, instead of upstream's?

Thanks



-- System Information:
Debian Release: trixie/sid
  APT prefers noble
  APT policy: (500, 'noble'), (500, 'mantic'), (500, 'jammy'), (400, 
'noble-proposed')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.0-11-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=sh: 0: getcwd() failed: 
No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
From: Florent 'Skia' Jacquet 
Date: Fri, 22 Mar 2024 17:19:59 +0100
Subject: Don't redefine FORTIFY_SOURCE
Bug-Ubuntu: 
https://bugs.launchpad.net/ubuntu/+source/openvas-scanner/+bug/2058758

Index: openvas-scanner-22.7.9/CMakeLists.txt
===
--- openvas-scanner-22.7.9.orig/CMakeLists.txt
+++ openvas-scanner-22.7.9/CMakeLists.txt
@@ -208,7 +208,7 @@ if (ENABLE_COVERAGE)
   set (COVERAGE_FLAGS "--coverage")
 endif (ENABLE_COVERAGE)
 
-set (HARDENING_FLAGS"-Wformat -Wformat-security 
-D_FORTIFY_SOURCE=2 -fstack-protector")
+set (HARDENING_FLAGS"-Wformat -Wformat-security -fstack-protector")
 set (LINKER_HARDENING_FLAGS "-Wl,-z,relro -Wl,-z,now")
 # The "-D_FILE_OFFSET_BITS=64 -DLARGEFILE_SOURCE=1" is necessary for GPGME!
 set (GPGME_C_FLAGS  "-D_FILE_OFFSET_BITS=64 -DLARGEFILE_SOURCE=1")
Index: openvas-scanner-22.7.9/debian/rules
===
--- openvas-scanner-22.7.9.orig/debian/rules
+++ openvas-scanner-22.7.9/debian/rules
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+
 DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 
 %:

Bug#1067630: fixed in emacs 1:29.3+1-1

2024-03-25 Thread Sean Whitton

Hello,

On Mon 25 Mar 2024 at 04:58pm +07, Max Nikulin wrote:

> On 25/03/2024 15:47, Sean Whitton wrote:
>> On Mon 25 Mar 2024 at 10:21am +07, Max Nikulin wrote:
>>
>>> On Mon, 25 Mar 2024 01:13:54 + Debian FTP Masters wrote:
 Source: emacs
 Source-Version: 1:29.3+1-1
 Done: Rob Browning
>>>
>>> Should this issue be reopened or be cloned to backport fixes to Emacs-28 in
>>> Debian stable?
>> Neither are necessary.
>
> Do you mean that somebody is working on backporting changes to 28.2 in
> bookworm already? This bug is closed. Have I missed other ones for elpa-org in
> unstable and for emacs in stable?

No, I just mean that the bug metadata is correct.  Closed does not mean
resolved in all suites.

-- 
Sean Whitton

Bug#991520: checkrestart: "lsof: WARNING: can't stat() fuse.gvfsd-fuse file system..."

Control: found -1 0.88.1

On 2021-07-26 14:33:38 +0200, Vincent Lefevre wrote:
> When running checkrestart, I get the following warnings from lsof:
> 
> lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/118/gvfs
>   Output information may be incomplete.
> lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
>   Output information may be incomplete.
> 
> or only the second one.

This is still reproducible. Actually, now

lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
  Output information may be incomplete.
lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc
  Output information may be incomplete.

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

Bug#1067673: caja: The Caja Open With... environment menu does not show the Geany text editor (sh and desktop files)

2024-03-25 Thread Imi


Package: caja
Version: 1.26.1-1+deb12u1
Severity: normal

Dear Maintainer,

* The Open With... menu only thinks it is hidden for sh and desktop files.
* The expectation is that if I select Geany in the file properties, then
a) appear in the Open With.. menu (I can select it)
b) two mouse clicks on the file will also cause Geany to open the file: at
least, the sh scripts.
* Another weird thing is that if I set two applications for files (sh or
desktop) in the file properties -and this is the default anyway- it works
"foolproof".

If it is set in ~/.config/ in the mimeapps.list file (shortcut),

[Default Applications]
application/x-desktop=libreoffice-writer.desktop
application/x-shellscript=libreoffice-writer.desktop

[Added Associations]
application/x-shellscript=geany.desktop;libreoffice-writer.desktop;
text/x-shellscript=geany.desktop;
text/x-desktop=geany.desktop;
application/x-desktop=libreoffice-writer.desktop;geany.desktop;

what happens is that in the Open With... menu, Open With: Geany appears, 
but if

I double-click on the file, LibreOffice Writer opens it.
This is when I select LibreOffice as the default association! When I select
Geany as the default application, LibreOffice appears as the menu to 
open with,

and when I double-click Geany, the file opens. This is some kind of reverse
operation.
Now, let's ignore the desktop settings in the example, because on that, if I
double-click, I'm launching the application...

* The Open With... menu only thinks it is hidden for sh and desktop files.
However, it is definitely expected to work here.

* The things I have done:

1) I edited the geany.desktop file in /usr/share/applications/ and added 
four

new settings at the end of MimeTypes=:

text/x-shellscript;text/x-desktop;application/x-shellscript;application/x-desktop;

2)
a) I have checked the contents of the mimeinfo.cache file
(/usr/share/applications/), and I see that it contains the correct settings:

application/x-shellscript=geany.desktop;vim.desktop;
application/x-desktop=geany.desktop;
text/x-shellscript=geany.desktop

b) I put this in,

text/x-desktop=geany.desktop;

then I ran it.

sudo update-desktop-database

The contents of the file have been updated.

And I ran it.

sudo update-mime-database /usr/share/mime

3) And I copied the geany.desktop file from /usr/share/applications/ to
~/.local/share/applications/.

None of the solutions helped...

* MATE and System

*inxi -Szxxx*
System:
Kernel: 6.7.10-3-liquorix-amd64 arch: x86_64 bits: 64 compiler: gcc
v: 12.2.0 Desktop: MATE v: 1.26.0 info: mate-panel wm: marco v: 1.26.1 vt:
7
dm: LightDM v: 1.26.0 Distro: Debian GNU/Linux 12 (bookworm)

file -b --mime-type install.sh
text/x-shellscript

xdg-mime query filetype install.sh
application/x-shellscript

file -b --mime-type geany.desktop
text/plain

xdg-mime query filetype geany.desktop
application/x-desktop


-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: amd64 (x86_64)

Kernel: Linux 6.7.10-3-liquorix-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=hu_HU.UTF-8, LC_CTYPE=hu_HU.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 caja depends on:
ii caja-common 1.26.1-1+deb12u1
ii desktop-file-utils 0.26-1
ii gvfs 1.50.3-1
ii libatk1.0-0 2.46.0-5
ii libc6 2.36-9+deb12u4
ii libcairo-gobject2 1.16.0-7
ii libcairo2 1.16.0-7
ii libcaja-extension1 1.26.1-1+deb12u1
ii libexempi8 2.6.3-1
ii libexif12 0.6.24-1+b1
ii libgail-3-0 3.24.38-2~deb12u1
ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii libglib2.0-0 2.74.6-2
ii libglib2.0-bin 2.74.6-2
ii libglib2.0-data 2.74.6-2
ii libgtk-3-0 3.24.38-2~deb12u1
ii libice6 2:1.0.10-1
ii libmate-desktop-2-17 1.26.0-2
ii libnotify4 0.8.1-1
ii libpango-1.0-0 1.50.12+ds-1
ii libpangocairo-1.0-0 1.50.12+ds-1
ii libselinux1 3.4-1+b6
ii libsm6 2:1.2.3-1
ii libx11-6 2:1.8.4-2+deb12u2
ii libxml2 2.9.14+dfsg-1.3~deb12u1
ii mate-desktop 1.26.0-2
ii shared-mime-info 2.2-1

Versions of packages caja recommends:
ii gvfs-backends 1.50.3-1
ii gvfs-fuse 1.50.3-1

Versions of packages caja suggests:
ii engrampa 1.26.0-1+deb12u2
pn gstreamer1.0-tools 
pn meld 

-- no debconf information

Bug#1067517: found bug in checkdisk

2024-03-25 Thread Florian Goth

Hi everyone,

further debugging allowed me to find the root cause.

I think there is a bug in line 1356 of the function checkdisk in subroutines:

$(stat -c %G /dev/$device) = "disk"


According to the manuals I found 
(https://man7.org/linux/man-pages/man1/stat.1.html)


stat -c %G

returns the group of the owner, but nothing related to a device type.


Therefore reintroducing the old way of determining hard drives fixes this issue.





(SFB1170, Project Z03, part-time system administration)
Interested in Research Software? https://de-rse.org/chapter/wue/
http://z03.physik.uni-wuerzburg.de  (uni network)

Theoretische Physik 1
Institut für theoretische Physik und Astrophysik
Am Hubland, 97074 Würzburg
GERMANY

Bug#1059030: closed by Safir Secerovic (Fixed in version 1.0-1)

2024-03-25 Thread Joshua AE Lee


This still seems to be an issue ion stable

On 3/25/24 08:12, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the goverlay package:

#1059030: goverlay missing dependency libglu1-mesa

It has been closed by Safir Secerovic .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Safir Secerovic 
 by
replying to this email.

Bug#1067674: library package (arch any) depending on a "common" package with too strict version constraint

2024-03-25 Thread Matthias Klose


Package: src:folks
Version: 0.15.9-1
Severity: important
Tags: patch

This is a bad packaging practice which happens way to often within all 
the GTK/Gnome packaging (cloning for mutter as well).  The scenario goes 
as follows:


 - upload a new package

 - build fails on "all", not building the "common" package.

 - build succeeds on other architectures, in most cases
   because the packagers don't run the tests, or ignore test
   results.

 - the packages then are not installable anymore until the
   uploads are in sync, blocking any other builds depending
   on these packages.  This can take a long, if the uploader
   goes to vacation, or a new package build takes ages (yes,
   LLVM had that issue as well, and LLVM builds take days).

proposed patch attached. Note that (>= ${source:Version}) has the same 
problem, and doesn't help either. Feel free to use some other version 
constraint than the upstream version.


diff -Nru folks-0.15.9/debian/control folks-0.15.9/debian/control
--- folks-0.15.9/debian/control 2024-03-23 12:41:20.0 +0100
+++ folks-0.15.9/debian/control 2024-03-24 22:06:08.0 +0100
@@ -31,7 +31,7 @@

 Package: libfolks26
 Architecture: any
-Depends: folks-common (= ${source:Version}),
+Depends: folks-common (>= ${upstream:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
 Recommends: libfolks-eds26
diff -Nru folks-0.15.9/debian/rules folks-0.15.9/debian/rules
--- folks-0.15.9/debian/rules   2024-03-23 12:41:20.0 +0100
+++ folks-0.15.9/debian/rules   2024-03-24 22:06:08.0 +0100
@@ -35,3 +35,8 @@
dh_auto_test --no-parallel -- --timeout-multiplier 3

 override_dh_gnome_clean:
+
+
+override_dh_gencontrol:
+   dh_gencontrol -- \
+	  -Vupstream:Version=$(shell dpkg-parsechangelog -S Version | sed 
's/-[^-]*$$//')

Bug#1067676: gpick: build-dependency on libglib2.0-0 is unsatisfiable on armel/armhf

2024-03-25 Thread Simon McVittie

Source: gpick
Version: 0.2.6-1
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

gpick Build-Depends on:

debhelper-compat (= 13),
cmake,
libcairo2 (>=1.6),<---
libglib2.0-0 (>=2.16),<---
libgtk-3-dev,
liblua5.4-dev (>= 5.4),
libboost-dev,
libexpat1-dev,
lemon,
flex,
ragel,
gettext,
libboost-test-dev,
libboost-system-dev,
libboost-filesystem-dev

The build-dependency on libglib2.0-0 is no longer satisfiable in unstable
due to the 64-bit time_t transition. It should be replaced with
libglib2.0-dev (>= 2.16), or just libglib2.0-dev.

Similarly, the build-dependency on libcairo2 should be replaced with
libcairo2-dev.

Thanks,
smcv

Bug#1067677: clutter-gst-3.0: build-dependency on libglib2.0-0 is unsatisfiable on armel/armhf

2024-03-25 Thread Simon McVittie

Source: clutter-gst-3.0
Version: 3.0.27-3
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

The build-dependency on libglib2.0-0 is no longer satisfiable in unstable
due to the 64-bit time_t transition. It should be replaced with
libglib2.0-dev (>= 2.18), or just libglib2.0-dev.

Alternatively, clutter-gst-3.0 could be removed (#1018112), but that
would require also removing cheese (#1018115) and pinpoint (#1018133),
as well as breaking a Recommends in mugshot.

smcv

Bug#1061264: ocrmypdf: Uses deprecated/to be removed pypdf2 in autopkgtest

2024-03-25 Thread Scott Kitterman

On Sun, 21 Jan 2024 13:14:34 -0500 Scott Kitterman  
wrote:
> Source: ocrmypdf
> Version: 15.2.0+dfsg1-1
> Severity: wishlist
> 
> I've recently adopted pypdf and pypdf2 into the Debian Python Team in 
response to an RFA for both packages.  As these are somewhat security 
sensitive packages (among my first acts after adopting the packages was to 
upload proposed updates for both to address minor security issues in Bookworm 
in the next point release - same bug in both), I do not think we should 
release pypdf2 in Trixie and have filed an RC bug to that effect.
> 
> ocrmypdf uses the package in debian/tests/control.  Please update to use
> python3-pypdf insteadm.

Pypdf2 has been removed from testing, so this is now serious.

Scott K

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

Bug#1067678: mugshot: Recommends unmaintained clutter-1.0 and related libraries

2024-03-25 Thread Simon McVittie

Package: mugshot
Version: 0.4.3-1
Severity: important
Tags: bookworm sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs clutter
Control: block 996690 by -1

This package Recommends gir1.2-gtkclutter-1.0, which is no longer
maintained upstream (and has been effectively unmaintained for a while),
and gir1.2-cheese-3.0, which is also effectively unmaintained.

When clutter-gtk and cheese are removed from Debian (see #1018115,
#1018113, etc.), this will become release-critical due to this rule:

In addition, the packages in main
* must not require or recommend a package outside of main for
  compilation or execution (thus, the package must not declare
  a Pre-Depends, Depends, **Recommends**, Build-Depends,
  Build-Depends-Indep, or Build-Depends-Arch relationship on a
  non-main package unless that package is only listed as a non-default
  alternative for a package in main),

— Debian Policy §2.2.1 "The main archive area"

The webcam integration doesn't seem to be very reliable anyway:
https://github.com/bluesabre/mugshot/issues/5

Please consider disabling this feature.

Thanks,
smcv

Bug#619648: cron.daily doesn't execute scheduled scripts

2024-03-25 Thread Lin Qigang


# copy paste error XP
Control: tags 1053873 - moreinfo
Control: tags 619648 + moreinfo

I'm sorry, I just realized that the only thing that does not work is 
user-crontabs. I was assuming they'd be managed by anacron as well but 
apparently they are not. That explains why @daily did not work as 
expected, my machine was booting up well after midnight.


If I understand, you are using 'crontab -e' to schedule tasks. The 
personal crontab explains that these tasks are run by cron, and it 
mentions the manual pages for crontab(5) and cron(8). When opening 
/etc/anacrontab, it explains that this is the configuration file for 
anacron, and it mentions the manual pages for anacrontab(5) and anacron(8).


I did spent a lot of time reading the docs and the config files of cron 
and anacron and only found this information on stackoverflow. Do you 
think other bugreports here are related to my misunderstanding? If yes, 
do you think we should explicitly document this "limitation"?


While it is not explicitly mentioned in /etc/anacrontab that only 
@monthly is supported, it is documented in the manual page for 
anacrontab(5). I do not think it needs to be documented further.


As for other bug reports, #920181 [1] is similar to the confusion you 
have encountered with @daily, which has some good suggestions. However, 
this bug report #619648 does not look to be the same as the problems you 
have described. If your issue is not fixed, please file a separate bug 
report with more information so that it can be properly addressed.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920181

--
Lance Lin
GPG Fingerprint: 4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7


OpenPGP_0x903649294C33F9B7.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067363: polymake: FTBFS: dpkg-shlibdeps: error: no dependency information found for /lib/x86_64-linux-gnu/libflint.so.19 (used by debian/libpolymake4.11/usr/lib/libpolymake.so.4.11)

2024-03-25 Thread David Bremner



Control: reassign -1 flint

Lucas Nussbaum  writes:

> Source: polymake
> Version: 4.11-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240319 ftbfs-trixie
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>

I'm fairly sure this is actually a bug in flint.

Bug#1067679: libvte-2.91-0: backspace character (code 8) output at the end of a line goes 2 columns backward

Package: libvte-2.91-0
Version: 0.75.92-1
Severity: normal

A backspace character (code 8) output at the end of a physical line
goes 2 columns backward.

For instance, in a 80-column libvte-based terminal (such as
GNOME Terminal or Sakura), I get

$ for i in $(seq 4 $(tput cols)) ; do printf "." ; done ; printf "ab \bc\n"
.ac

Xterm does not have such an issue:

$ for i in $(seq 4 $(tput cols)) ; do printf "." ; done ; printf "ab \bc\n"
.abc

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

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

Versions of packages libvte-2.91-0 depends on:
ii  libatk1.0-0t64   2.51.90-4
ii  libc62.37-15.1
ii  libcairo-gobject21.18.0-1+local1
ii  libcairo21.18.0-1+local1
ii  libfribidi0  1.0.13-3+b1
ii  libgcc-s114-20240315-1
ii  libglib2.0-0t64  2.78.4-6
ii  libgnutls30t64   3.8.3-1.1+b1
ii  libgtk-3-0t643.24.41-3
ii  libicu72 72.1-4+b1
ii  liblz4-1 1.9.4-1+b2
hi  libpango-1.0-0   1.51.0+ds-4
hi  libpangocairo-1.0-0  1.51.0+ds-4
ii  libpcre2-8-0 10.42-4+b1
ii  libstdc++6   14-20240315-1
ii  libsystemd0  255.4-1+b1
ii  libvte-2.91-common   0.75.92-1

libvte-2.91-0 recommends no packages.

libvte-2.91-0 suggests no packages.

-- no debconf information

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

Bug#1059030: closed by Safir Secerovic (Fixed in version 1.0-1)

2024-03-25 Thread Tobias Frost

Control: fixed -1 1.0-1

Bug#1067363: polymake: FTBFS: dpkg-shlibdeps: error: no dependency information found for /lib/x86_64-linux-gnu/libflint.so.19 (used by debian/libpolymake4.11/usr/lib/libpolymake.so.4.11)

2024-03-25 Thread Torrance, Douglas


Control: forcemerge 1067226 -1

On Mon, 25 Mar 2024 10:42:24 -0300 David Bremner  wrote:


Control: reassign -1 flint

Lucas Nussbaum  writes:

> Source: polymake
> Version: 4.11-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240319 ftbfs-trixie
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>

I'm fairly sure this is actually a bug in flint.


Indeed!  It's #1067226 -- merging.


signature.asc
Description: PGP signature

Bug#1059030: closed by Safir Secerovic (Fixed in version 1.0-1)

2024-03-25 Thread Tobias Frost

Control: fixed -1 1
0.9.1-2

correction: this  has been fixed even in 0.9.1-2 already

Bug#1065105: (no subject)

2024-03-25 Thread bugsnmd


  Hi,

This bug remains an issue for me, anything I can do to try and 
investigate it / any possible fixes?


I've tried a few things as discussed in this forum: 
https://forums.debian.net/viewtopic.php?p=795786#p795786


Cheers

Nick

Bug#1059030: closed by Safir Secerovic (Fixed in version 1.0-1)

2024-03-25 Thread Tobias Frost

Control: fixed -1 0.9.1-2

correction: this  has been fixed even in 0.9.1-2 already

Bug#1067680: [RFP]: floorp -- powerful firefox fork with more customization and features

2024-03-25 Thread Justin Thompson

Package: wnpp
Severity: wishlist
Information about package: Described as "A Browser build for keeping the
Open, Private and Sustainable Web alive. Based on Mozilla Firefox; "Floorp
is built on Firefox and was built in Japan and is a new browser with
excellent privacy & flexibility." Software is affilated only with Ablaze
organization.
Available from: https://github.com/Floorp-Projects/Floorp (Github and
official website both point Debian and derivative users to get the PPA. A
tarball is available on the Github Releases page as well)
License: Uses Mozilla Public License, v. 2.0. Further information about the
software's license can be seen on
https://github.com/Floorp-Projects/Floorp/blob/3ac256fb89a13234104fc5bf0fab31447c5973c3/toolkit/content/license.html

Bug#1065105:

2024-03-25 Thread Jesse Rhodes

HI Nick,

Thanks for your bug report.

As the forum thread suggests, this is most likely not a bug in the
plasma desktop. If your bios is fully up to date, you might want to
try with the newer kernel from bookworm-backports [1][2] in case it
has better support for your laptop. Usually kernel and bios updates
are the best approach for fixing issues like this.

Unfortunately, they also sometimes go a long time without a
resolution, especially if the device was only sold as being compatible
with Windows.

For more troubleshooting follow-up, try asking in #debian on the OFTC
IRC network. If you're unfamiliar with IRC there is more information
at https://wiki.debian.org/IRC.

sney

[1] https://packages.debian.org/bookworm-backports/linux-image-amd64
[2] https://backports.debian.org/Instructions/

Bug#1067681: ITP: python-tktooltip -- simple yet fully customisable tooltip/pop-up implementation

2024-03-25 Thread Georges Khaznadar

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-tktooltip
  Version : 3.0.0
  Upstream Contact: gnikit 
* URL : https://pypi.org/project/tkinter-tooltip/
* License : Expat
  Programming Lang: Python3
  Description : simple yet fully customisable tooltip/pop-up implementation

 Tktooltip is a simple yet fully customisable tooltip/pop-up
 implementation for tkinter widgets. It is capable of fully
 integrating with custom tkinter themes both light and dark ones.
 .
 Features
 
 .
  - normal tooltips
  - show tooltip with s seconds delay
  - tooltip tracks mouse cursor
  - tooltip displays strings and string returning functions
  - fully customisable, tooltip inherits underlying theme style
---

this package is a dependency for some education packages which I aim to publish
shortly. Those are coming from project Primtux (https://primtux.fr/), which is
a collection of educational small applications for primary education.

I shall maintain the package in salsa.d.o, under the umbrella of python-team.

Bug#1066110: tracker-extract: regular crash

2024-03-25 Thread Alban Browaeys

On Thu, 21 Mar 2024 20:51:23 +0100 Patrice Duroux
 wrote:
> So did a forcemerge 1066898 1066110 be a better way to proceed?
> 


Yes, that would be fine too as far as I know (I am not a Debian
Developer).
I believe it will then close this bug report too.

By the way I think your question implies that this bug is fixed by
3.7.0-1, isn't it?

Cheers,
Alban

> Le jeu. 21 mars 2024 à 10:40, Alban Browaeys
>  a écrit :
> >
> > On Thu, 14 Mar 2024 22:04:33 +0100 intrigeri 
> > wrote:
> > > Hi,
> > >
> > > I see a similar crash every 2-4 seconds on my sid system since
some
> > recent
> > > upgrade.
> > >
> > > This looks like
> > > https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/312.
> > >
> >
> >
> > Looks like
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066898
> >
> > > I lack time to do this myself but it could be interesting to
check if
> > > the upstream fix resolves this for you:
> > >
> >
https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/516/diffs
> > > … which I understand will be included in 3.7 stable.
> > >
> >
> >
> > Should be fixed by 3.7.0-1 which is available in unstable since a
day.
> > Could you upgrade and clos this bug report if fixed?
> >
> > Regards,
> > Alban
> 
>

Bug#423207: bash builtins should not kill script when they get SIGPIPE

2024-03-25 Thread Gioele Barabucci


Control: tags -1 wontfix

In https://lists.gnu.org/archive/html/bug-bash/2024-03/msg00201.html the 
bash maintainer stated that this behavior is intended and reflects the 
current consensus among POSIX shell implementations.


See also https://www.austingroupbugs.net/view.php?id=789

Regards,

--
Gioele Barabucci

Bug#456943: (no subject)

On 2016-07-14 14:22:15 -0700, Vincent Lefevre wrote:
> On 2016-07-14 09:02:48 +0200, Walter Doekes wrote:
> > Leon Meier wrote:
> > > As of today, the test case [...] still fails in (u)xterm.
> > > Any resolution in sight?
> > 
> > I tried to reproduce, and indeed, it fails on xterm (without the 'ne' grep
> > option), but not in gnome-terminal.
> > 
> > Does that mean that this is an xterm bug again and not a grep bug?
> 
> It is GNOME Terminal that is buggy, so that the grep bug is not
> visible.

A solution for "grep" would be to add a space+backspace before the
escape sequence.

Testcase:

for i in `seq 5` ; do printf "%0$(($(tput cols)+i-5))dab \bc\n" ; done | \
  GREP_COLORS="mt=41;97:ne" grep --color c

This works fine in Xterm, giving on a 80-column terminal:

abc
0abc
00abc
000abc
abc

where only the "c" has the red background.

However, this triggers the bug in GNOME Terminal (and other
libvte-based terminals):

abc
0ac 
00abc
000abc
abc

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

Bug#1067649: Verification page is not accessible from the homepage

2024-03-25 Thread Tassia Camoes Araujo

Hi Thomas,

On 2024-03-25 02:39, Thomas Lange wrote:
> I don't think we need the link on the startpage, but maybe on the
> /distrib page where we provide other ISO downloads.
>
I agree that not every user need to verify downloads.

> But in the end I try to remember whenever I have verified an ISO by
> myself.
>
I do that on a regular basis for educational purposes, as I see the
value of being able to verify authenticity of our images with our own
hands.

> I can't remember and I guess I never did it. Maybe I
> check that I'm using https://www.debian.org. That's all I need to
> trust.
>
It is not only a matter of trusting the website, but the network, and
even the local filesystem. It happened to me once to have to re-flash a
batch of 20 USBs, because I had not verified if the file I had at hands
was the good one. I can imagine that for media vendors it is also of
crucial importance, to make sure they are redistributing the authentic
image.

So here I adapt my original request: please add the link to /verify at
the /distrib page; and if possible, also consider renaming the link of
"other downloads", since the content of the target is not only about
other downloads. For a minimal change, I'd say "other download options",
but I'd prefer "other ways of getting debian" ("Getting Debian" is the
title of the /distrib page, so it will be less confusing when the user
lands on the target).

Thanks for considering!

Tassia.

Bug#1067682: ITP: fracatux -- small application to teach fractions, at primary level

2024-03-25 Thread Georges Khaznadar

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: fracatux
  Version : 1.5.2
  Upstream Contact: Arnaud Champollion 
* URL : https://forge.aeif.fr/achampollion/fracatux
* License : GPL-2+
  Programming Lang: Python3
  Description : small application to teach fractions, at primary level

 Fracatux is part of the project Primtux (https://primtux.fr), which aims
 to provide simple and effective programs for teaching in primary schools.
 .
 Fracatux is a free/libre program to display fractions as bars, and to
 perform various operations with them. It permits, among other things,
 to make evident equalities of fractions, addition of fractions with the
 same denominator, and correspondences between fractional, decimal and
 scientific representations. A scale line (decimal or fractional) allows
 one to compare those fractions from ordinal point of view.

The package will be maintained on salsa.debian.org, under the debian
subdirectory.

Bug#1067683: FTBFS: error: implicit declaration of function ‘getmode’

Source: freebsd-buildutils
Version: 10.3~svn296373-7.1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=freebsd-
buildutils&arch=amd64&ver=10.3%7Esvn296373-7.1%2Bb1&stamp=1710975960&raw=0

create.c:233:12: error: implicit declaration of function ‘MD5File’
[-Werror=implicit-function-declaration]

compare.c:254:16: error: implicit declaration of function ‘MD5File’
[-Werror=implicit-function-declaration]

spec.c:234:18: error: implicit declaration of function ‘getmode’; did you mean
‘setmode’? [-Werror=implicit-function-declaration]

verify.c:123:9: error: implicit declaration of function ‘compare’
[-Werror=implicit-function-declaration]



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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1067684: ITP: goda -- Go Dependency Analysis toolkit

2024-03-25 Thread Anthony Fok

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: goda
  Version : 0.5.7-1
  Upstream Author : Egon Elbre
* URL : https://github.com/loov/goda
* License : Expat
  Programming Lang: Go
  Description : Go Dependency Analysis toolkit

 Goda is a Go dependency analysis toolkit. It contains tools to figure
 out what your program is using.
 .
 Cool things it can do:
 .
   # All of the commands should be run in the cloned repository.
   git clone https://github.com/loov/goda && cd goda
 .
   # draw a graph of packages in github.com/loov/goda
   goda graph "github.com/loov/goda/..." | dot -Tsvg -o graph.svg
 .
   # draw a dependency graph of github.com/loov/goda and dependencies
   goda graph -cluster -short "github.com/loov/goda:all" | dot -Tsvg -o 
graph.svg
 .
   # list direct dependencies of github.com/loov/goda
   goda list "github.com/loov/goda/...:import"
 .
   # list dependency graph that reaches flag package, including std
   goda graph -std "reach(github.com/loov/goda/...:all, flag)" | dot -Tsvg -o 
graph.svg
 .
   # list packages shared by github.com/loov/goda/pkgset and 
github.com/loov/goda/cut
   goda list "shared(github.com/loov/goda/pkgset:all, 
github.com/loov/goda/cut:all)"
 .
   # list packages that are only imported for tests
   goda list "github.com/loov/goda/...:+test:all - github.com/loov/goda/...:all"
 .
   # list packages that are imported with `purego` tag
   goda list -std "purego=1(github.com/loov/goda/...:all)"
 .
   # list packages that are imported for windows and not linux
   goda list "goos=windows(github.com/loov/goda/...:all) - 
goos=linux(github.com/loov/goda/...:all)"
 .
   # list how much memory each symbol in the final binary is taking
   goda weight -h $GOPATH/bin/goda
 .
   # show the impact of cutting a package
   goda cut ./...:all
 .
   # print dependency tree of all sub-packages
   goda tree ./...:all
 .
   # print stats while building a go program
   go build -a --toolexec "goda exec" .
 .
   # list dependency graph in same format as "go mod graph"
   goda graph -type edges -f '{{.ID}}{{if .Module}}{{with 
.Module.Version}}@{{.}}{{end}}{{end}}' ./...:all
 .
 How it differs from go list or go mod
 .
 go list and go mod are tightly integrated with Go and can answer simple
 queries with compatibility. They also serves as good building blocks for
 other tools.
 .
 goda is intended for more complicated queries and analysis. Some of the
 features can be reproduced by format flags and scripts. However, this
 library aims to make even complicated analysis fast.
 .
 Also, goda can be used together with go list and go mod.


Reasons for packaging:

- Recommended by Dominik Honnef, upstream author of golang-honnef-go-tools,
  when he removed cmd/rdeps which, like dh-make-golang, also used
  golang.org/x/tools/refactor/importgraph

- Potential solution to fix and improve "dh-make-golang estimate"

Bug#1032670: allegro4.4: CVE-2021-36489

2024-03-25 Thread Andreas Rönnquist

On Sun, 24 Mar 2024 21:46:40 +0100 Moritz Muehlenhoff 
wrote:
- 8< -
> 
> I never tried to reproduce these, but reproducability of a given PoC
> made against a current version not working with an older version
> doesn't mean the old version isn't affected. From a quick glance the
> equivalent of the checks added in 5 are also needed in 4.4, e.g.
> rle_tga_read8() lacks a check for w overstepping c.
> 
> Given that all these image files are typically read from a trusted
> location/source shipped by a given game it's not a big deal, but I'd
> suggest to keep the bug open until 4.4 has been fully phased out or
> the fixes backported.
> 

Yeah, I believe that upstream isn't interested either in 4.4, but focus
pretty much fully on 5.x now - and my interest is basically on 5.x.
Previously my interest in 4.4 was because of alex4, but since that
package has turned out to be non-free and moved there, my interest in
it has waned, and consequently, in allegro4.4 too.

I believe a big part of Tobias Hansens interest in Allegro 4 was due to
Aseprite, which have turned to a license that cannot be packaged in
Debian (but I don't want to claim that I 100% know Tobias reasoning).

If anyone really wants to have allegro 4.4 still in Debian, my
suggestion would be to step up and help out with the package (but since
I believe upstream has no interest in it, I don't know how doable it
is).

I am considering removing myself from the allegro 4.4 package, but
still keep working on the 5.x one. There I soon have a upload coming, I
am just waiting for [1] to get solved (Fixing multiarch stuff for cmake
package config).

Of course, removing 4.4 would mean removal of quite some small nice
little games, but sometimes you just have to endure the negative.

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

1: https://github.com/liballeg/allegro5/pull/1543

Bug#1067685: packages are not installable

2024-03-25 Thread Matthias Klose


Package: src:speech-dispatcher-contrib
Version: 0.12.0~rc1-1
Severit: important

the packages are not installable, having an upper dependency on the 
speech-dispatcher packages:


speech-dispatcher-baratinoo/amd64 has unsatisfiable dependency
speech-dispatcher-ivona/amd64 has unsatisfiable dependency
speech-dispatcher-kali/amd64 has unsatisfiable dependency
speech-dispatcher-pico/amd64 has unsatisfiable dependency
speech-dispatcher-voxin/amd64 has unsatisfiable dependency

Bug#1067686: ghdl 4.0 available, builds on s390x

2024-03-25 Thread Matthias Klose


Package: src:ghdl
Version: 3.0.0+dfsg2-1

ghdl 4.0 is available, also builds on s390x:
https://launchpad.net/ubuntu/+source/ghdl/4.0.0+dfsg-0ubuntu2

Bug#1067124: Ping

2024-03-25 Thread Daniel Leidert

Hi,

I would like to send a ping. If this was fixed, I could upload the
pdns-recursor to Buster LTS. Your help is appreciated.

Regards, Daniel


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

Bug#1067413: RFP: keydb -- persistent key-value database with network interface

2024-03-25 Thread Guillem Jover

Hi!

On Fri, 2024-03-22 at 12:35:47 +, Chris Lamb wrote:
> > I'm CCing Chris, who might perhaps be interested in replacing Redis with
> > KeyDB as its spiritual successor and taking this on? Or if not, at least
> > to perhaps potentially coordinate some kind of transition, even though
> > we've had issues migrating persistent DBs from newer Redis to KeyDB, so
> > that might be tricky or not feasible at all.
> 
> Thanks for including me here. I had not yet looked into potential
> Redis replacements nor the exact and precise details of the new
> license etc. and this activity around KeyDB feels like a good start.
> I thought I'd let the dust settle for a bit before making any
> decisions — perhaps the change even gets reversed (!), and no doubt
> there might be new alternatives that will fork the code immediately
> prior to the license change.

Yeah, fair enough.

> My personal and professional usage of Redis has dropped off in the
> past few years, so it would make more sense for me to help out in a
> team maintainership role, at least with respect to KeyDB.

Ack.

> However, I'd be interested in coordinating around some kind of
> Redis→KeyDB/something transition if need be.

For KeyDB, that would also depend on whether KeyDB adds Redis 7 support
or not I guess.

  https://github.com/Snapchat/KeyDB/issues/420

and if that does not materialize, a potential migration path via:

  https://github.com/Snapchat/KeyDB/issues/527#issuecomment-1370606311

In our, case we migrated from Redis 6 to KeyDB, so the above did not
really affect us.

> (Incidentally, why did your work switch to KeyDB?)

We did this several years ago, AFAIR mainly for its active-active
replication mode for our HA setup. The multi-threading was a nice
improvement too. And I cannot recall exactly, but I think at that
time Redis Inc was already going into a weird licensing path with
its other adjacent projects, so we might have taken that too as a
nice side effect to get away from.

Thanks,
Guillem

Bug#1067687: lcov: Missing runtime dependency on libtimedate-perl

2024-03-25 Thread Dave Jones

Source: lcov
Version: 1.15-1
Severity: important

Dear Maintainer,

While libtimedate-perl is included as a build dependency, it's missing 
from the runtime dependencies. However, the genhtml binary relies upon 
Date/Parse.pm which is provided by libtimedate-perl, hence it needs to 
be in the runtime dependencies too.

I suspect many users haven't noticed this as libtimedate-perl is pulled 
in by many other things too, but on a minimal cloud image this results 
in the following output when attempting to run genhtml:

   $ genhtml -o /tmp/i3-coverage/ i3.info
   Can't locate Date/Parse.pm in @INC (you may need to install the 
   Date::Parse module) (@INC contains: /etc/perl 
   /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 
   /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 
   /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base 
   /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 
   /usr/local/lib/site_perl) at /usr/bin/genhtml line 89.

Bug#1067689: apt complains that repository tags changed although they never changed

2024-03-25 Thread Stefan Smorra

Package: apt
Version: 2.6.1 (amd64)
Severity: normal

First I want to say that my system is nothing special. I don't have any fancy
settings and most things are at default.

A few days ago I ran 'apt update' and it said something like this (error #1,
This is not the only error. Please keep reading.):

"File has unexpected size (32 != 1104). Mirror sync in progress?"

Someone has the same error here
https://askubuntu.com/questions/1147254/apt-update-fails-at-chrome-stable-main-file-has-unexpected-size-1103-1104

Normally this is not a problem because you can wait until the server works
again.

So I waited until the next day and tried again. But I got another error which
looks like this (error #2):

user1@user1-laptop1:/media/user1/SMO-STICK$ sudo apt update
Get:1 http://security.debian.org/debian-security bookworm-security InRelease
[48.0 kB]
Hit:2 http://deb.debian.org/debian bookworm InRelease
Hit:3 http://deb.debian.org/debian bookworm-updates InRelease
Hit:4 https://download.virtualbox.org/virtualbox/debian bookworm InRelease
E: Repository 'http://security.debian.org/debian-security bookworm-security
InRelease' changed its 'Label' value from 'Debian' to 'Debian-Security'
N: Repository 'http://security.debian.org/debian-security bookworm-security
InRelease' changed its 'Version' value from '12-updates' to '12'
N: Repository 'http://security.debian.org/debian-security bookworm-security
InRelease' changed its 'Suite' value from 'stable-updates' to 'stable-security'
E: Repository 'http://security.debian.org/debian-security bookworm-security
InRelease' changed its 'Codename' value from 'bookworm-updates' to
'bookworm-security'
N: This must be accepted explicitly before updates for this repository can be
applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this repository?
[y/N]

However if you look into waybackmachine you can see that these tags (Label,
Version, ...) never changed.

This error didn't go away even after waiting multiple days.

I suppose that error #2 is a result of error #1. Error #1 seems to have changed
the tags to wrong values.

Someone had the same problem in 2022 here
https://lists.debian.org/debian-user/2022/12/msg00412.html

This person also has the issue with the debian-security repository. It seems to
be a rare issue (bug).

So the actual bug is that apt wants me to confirm changed tags which actually
never changed.

I now confirmed the message with 'y' and everything seems to work. I am only
reporting this so it will get fixed and other users won't experience it.

Best regards
Stefan

Bug#456943: (no subject)

On 2024-03-25 15:49:52 +0100, Vincent Lefevre wrote:
> A solution for "grep" would be to add a space+backspace before the
> escape sequence.

An additional note: One of the following is needed:

* Detect the end of line (this may be tricky) and split the coloring
  into 2 parts (each one with space + backspace + escape sequence)
  at this point. If this detection is incorrect, then the background
  problem would still be visible, but with no major drawbacks.

* Split the coloring so that each matching character gets a space +
  backspace + escape sequence. I think that this is acceptable since
  this trick should be used only when the output is a tty (i.e. it
  is not redirected to a file / not piped to a pager or something
  else).

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

Bug#1067690: (no subject)

2024-03-25 Thread Dan Bungert

Source: pygame-sdl2
Version: 8.1.3-1
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: daniel.bung...@canonical.com

Dear Maintainer,

pygame-sdl2 will FTBFS with the current incarnation of cython3.  Switching to
cython3-legacy produces a passing build.  Confirmed building with this change
on sid and Ubuntu noble.

--- a/debian/control
+++ b/debian/control
@@ -6,7 +6,7 @@
 Uploaders:
  Markus Koschany 
 Build-Depends:
- cython3,
+ cython3-legacy,
  debhelper-compat (= 13),
  dh-sequence-python3,
  libsdl2-dev,

-Dan

Bug#1066025: dh_installsystemd doesn't process user services in /usr/lib/systemd/user/

2024-03-25 Thread Niels Thykier


Sergey Ponomarev:

Hi Niels,

I upgraded to Ubuntu 24.04 and now have debhelper 13.14.1ubuntu1.



Hi,

In case you are using Ubuntu, you should be filing the bug against 
Ubuntu for future reference. Notably, Ubuntu has patched debhelper and 
even monkey-patch(ed?) debhelper in their official builds on top that.
Therefore, they have to screen incoming bug reports first to ensure the 
bug is not introduced by their patches.



Once executed the debuild nothing was generated.
When executed the dh_installsystemduser manually also nothing was generated.
 From it's sources I found that it looks for some dependency and I added to
the /debian/control:

 Depends: ${misc:Depends}

Now this helped and two install/uninstall scripts were generated
/debian/sshtunnel.postinst.debhelper
/debian/sshtunnel.postrm.debhelper

I manually included the scripts to /debian/postinst and /debian/postrm and
built the deb.



If you had to "manually" include those snippets into the deb in a clean 
build, then I think there is something seriously wrong with the 
packaging. Normally, `dh_installdeb` would do that for you if the 
commands are run in the correct sequence.


Now, you mention you ran it manually. So it is possible you did that 
manually after building the deb, in which case you would see this 
behavior. This would also fit that your `debian/rules` likes quite 
standard without any room for mistakes of this kind when I checked it.




It was installed successfully but didn't start the service.
I started manually. During uninstall it has not been stopped. There is no
prerm script that will do that.



No, this feature is first added in compat 14 apparently (which is not 
stable yet). Sadly, this is not documented in the upgrade checklist for 
reasons I do not understand. The commit that introduced the feature 
recorded it in the wrong place and the remark seems to be completely gone.


I will follow up on this part.


So the issues are:
1. The debhelper did not execute the dh_installsystemduser. I guess I must
add it manually to /debian/rules


Either that or you could use the proper debhelper-compat level.  That is 
compat 12 or later would do. The package you linked to used compat 11 as 
I recall.


Remember to check the debhelper compat upgrade checklist before you 
update the compat level.


It is in `man 7 debhelper-compat-upgrade-checklist` or `man 7 debhelper` 
(depending on the debhelper version).



2. The generated scripts do not start the service after installation.
3. Missing prerm script to stop the service.


As mentioned above, this is compat 14 stuff.


4. Surprising need for for ${misc:Depends}



There is no such need in the Debian version of debhelper for 
dh_installsystemduser to generate the snippets. However, 
dh_installsystemduser must either install the services files *or* be run 
after they are installed at the correct location.
  My best guess is that you ran dh_installsystemduser to "early" the 
first time, then the files were in place, followed by you tweaking 
debian/control and then running dh_installsystemduser without clean 
first. That is basically the one way I can make sense of what happened.


That said, you ought have that dependency anyway for other reasons (at 
least up to compat 14, where it will be applied automatically).



So far I will anyway continue to use the manual scripts because I wish to
support old distros.
Anyway I wanted to have good and proper "official" scripts to install the
user service.

You can play with my simple package here:
http://github.com/yurt-page/sshtunnel

It can be a good sample and test ground.

Best regards and thank you for your work,
Sergey

[...]


From my PoV, I will acknowledge that the compat checklist is missing 
the remark that `dh_installsystemduser` changes behavior in compat 14 by 
adding start+stop snippets for user services.


For the other parts, I am not seeing anything that I can be sure is a 
bug in debhelper vs. issues caused by ad-hoc debugging / something else. 
At least not in Debian's version of debhelper.


Best regards,
Niels

PS: I suspect your `debian/dirs` file is (mostly?) redundant, since your 
`Makefile` does the `mkdir -p` necessary.

Bug#1067688: firefox-esr: Cannot copy address bar link to other windows in Wayland

2024-03-25 Thread Huey Chen

Package: firefox-esr
Version: 115.9.1esr-1
Severity: normal
X-Debbugs-Cc: hueyche...@outlook.com

Dear Maintainer,
If anyone tries to copy the address bar in the top of Firefox, it will only 
copy within Firefox and not other windows. This happens in Wayland.
I want to copy and paste the link in the address bar to another window, but 
nothing is even copied. Text is copied everywhere in Firefox except the address 
bar.


-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils  5.17
ii  fontconfig   2.15.0-1.1
ii  libasound2t641.2.11-1+b1
ii  libatk1.0-0t64   2.51.90-4
ii  libc62.37-15.1
ii  libcairo-gobject21.18.0-3
ii  libcairo21.18.0-3
ii  libdbus-1-3  1.14.10-4+b1
ii  libdbus-glib-1-2 0.112-3+b2
ii  libevent-2.1-7t642.1.12-stable-8.1+b1
ii  libffi8  3.4.6-1
ii  libfontconfig1   2.15.0-1.1
ii  libfreetype6 2.13.2+dfsg-1+b2
ii  libgcc-s114-20240315-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b2
ii  libglib2.0-0t64  2.78.4-6
ii  libgtk-3-0t643.24.41-3
ii  libnspr4 2:4.35-1.1+b1
ii  libnss3  2:3.99-1
ii  libpango-1.0-0   1.52.1+ds-1
ii  libstdc++6   14-20240315-1
ii  libvpx8  1.13.1-2
ii  libx11-6 2:1.8.7-1
ii  libx11-xcb1  2:1.8.7-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.4-1
ii  libxtst6 2:1.2.3-1.1
ii  procps   2:4.0.4-4
ii  zlib1g   1:1.3.dfsg-3.1

Versions of packages firefox-esr recommends:
ii  libavcodec60  7:6.1.1-3

Versions of packages firefox-esr suggests:
pn  fonts-lmodern   
pn  fonts-stix | otf-stix   
ii  libcanberra0t64 [libcanberra0]  0.30-12.2
ii  libgssapi-krb5-21.20.1-6
pn  pulseaudio  

-- no debconf information

Bug#1067691: FTBFS: double free or corruption

Source: spek
Version: 0.8.5+dfsg-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=spek&arch=armel&ver=0.8.5%2Bdfsg-3%2Bb3&stamp=1711383117&raw=0

fft const
double free or corruption (!prev)
/bin/bash: line 6: 27223 Aborted ${dir}$tst
FAIL: test


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1067692: gcc-arm-none-eabi: inttypes.h fails to define PRIi64 on GCC 13.2.1 with newlib

2024-03-25 Thread Jonathan Neuschäfer

Package: gcc-arm-none-eabi
Version: 15:13.2.rel1-2
Severity: normal

After upgrading to Debian trixie (currently "testing") and thus GCC
13.2.1, inttypes.h doesn't define the 64-bit format specifiers such as
PRIi64 anymore, as demonstrated and explained by the following program:

// $ arm-none-eabi-gcc --version
// arm-none-eabi-gcc (15:13.2.rel1-2) 13.2.1 20231009
//
// $ arm-none-eabi-gcc -c test.c
// test.c: In function 'main':
// test.c:21:31: error: expected ')' before 'PRIi64'
//21 | printf("the answer: %" PRIi64 "\n", i);
//   |   ~   ^~~
//   |   )
// test.c:18:1: note: 'PRIi64' is defined in header ''; did you 
forget to '#include '?
//17 | #include 
//   +++ |+#include 
//18 |

#include 
#include 
#include 

int main(void) {
int64_t i = 42;
printf("the answer: %" PRIi64 "\n", i);
return 0;
}

//
// /usr/include/newlib/machine/_default_types.h correctly defines 
___int64_t_defined,
// (indentation for emphasis mine, in all code excerpts):
//
// #ifdef __INT64_TYPE__
//  typedef __INT64_TYPE__ __int64_t;
//  #ifdef __UINT64_TYPE__
//   typedef __UINT64_TYPE__ __uint64_t;
//  #else
//   typedef unsigned __INT64_TYPE__ __uint64_t;
//  #endif
//  #define ___int64_t_defined 1
// #elif __EXP(LONG_MAX) > 0x7fff
//  typedef signed long __int64_t;
//  typedef unsigned long __uint64_t;
//  #define ___int64_t_defined 1
//  ...
//
//
// Next, __int64_t_defined would be set in /usr/include/newlib/sys/_stdint.h:
//
// #ifdef ___int64_t_defined
//  #ifndef _INT64_T_DECLARED
//   typedef __int64_t int64_t ;
//   #define _INT64_T_DECLARED
//  #endif
//  #ifndef _UINT64_T_DECLARED
//   typedef __uint64_t uint64_t ;
//   #define _UINT64_T_DECLARED
//  #endif
//  #define __int64_t_defined 1
// #endif /* ___int64_t_defined */
//
//
// sys/_stdint.h would be included via , but that doesn't happen
// because GCC picks the wrong stdint.h, from 
/usr/lib/gcc/arm-none-eabi/13.2.1/include/stdint.h.
//
// Finally, PRIi64 and similar macros are not defined in
// /usr/include/newlib/inttypes.h, because __int64_t_defined wasn't defined:
//
// #if __int64_t_defined
//  #define PRId64  __PRI64(d)
//  #define PRIi64  __PRI64(i)
//  #define PRIo64  __PRI64(o)
//  #define PRIu64  __PRI64(u)
//  #define PRIx64  __PRI64(x)
//  #define PRIX64  __PRI64(X)
//
//  #define SCNd64  __SCN64(d)
//  #define SCNi64  __SCN64(i)
//  #define SCNo64  __SCN64(o)
//  #define SCNu64  __SCN64(u)
//  #define SCNx64  __SCN64(x)
// #endif
//
//
// As a workaround, #include  before #include  fixes 
the issue.


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

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

Versions of packages gcc-arm-none-eabi depends on:
ii  binutils-arm-none-eabi  2.41.90.20240115-1+23
ii  libc6   2.37-15
ii  libgcc-s1   14-20240201-3
ii  libgmp102:6.3.0+dfsg-2+b1
ii  libisl230.26-3+b2
ii  libmpc3 1.3.1-1+b2
ii  libmpfr64.2.1-1+b1
ii  libstdc++6  14-20240201-3
ii  zlib1g  1:1.3.dfsg-3+b1

Versions of packages gcc-arm-none-eabi recommends:
ii  libnewlib-arm-none-eabi  4.4.0.20231231-2

gcc-arm-none-eabi suggests no packages.

-- no debconf information

Bug#1067693: open-vm-tools version 12.4.0 has been released - please rebase

2024-03-25 Thread John Wolfe Jr

Package: open-vm-tools
Version: 2:12.4.0

open-vm-tools 12.4.0 was released on March 21, 2024.

There are no new features in the open-vm-tools 12.4.0 release. This is
primarily a maintenance release that addresses a single critical
problem:

For complete details, see:
https://github.com/vmware/open-vm-tools/releases/tag/stable-12.4.0

Release Notes are available at:
https://github.com/vmware/open-vm-tools/blob/stable-12.4.0/ReleaseNotes.md

The granular changes that have gone into the 12.4.0 release are in the
ChangeLog at: 
https://github.com/vmware/open-vm-tools/blob/stable-12.4.0/open-vm-tools/ChangeLog

Please rebase open-vm-tools to release 12.4.0 on supported Debian
releases as appropriate.

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

Bug#1067694: Update Build-Depends for the time64 library renames

Source: glogg
Version: 1.1.4-1.1
Severity: serious

The package explicitly Build-Depends: libqt5dbus5, this needs to be changed to
libqt5dbus5t64 if it's needed at all.


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1057548: closed by Debian FTP Masters (reply to Noah Meyerhans ) (Bug#1057548: fixed in cloud-init 24.1.1-1)

2024-03-25 Thread Santiago Vila


found 1057548 24.1.1-1
retitle 1057548 cloud-init: FTBFS: missing Build-Depends on passwd
tags 1057548 + patch
thanks

Hello.

I don't quite understand why this bug was closed with this changelog entry:

   * New upstream version 24.1 (Closes: #1057548)

I did not ask for a new upstream version to be packaged, and the upload
did not really fix the bug. I assume you just misdiagnosed it.

The build log contains this line:

RuntimeError: Unable to lock user account 'foo_user'. No tools available.   
Tried: ['passwd', 'usermod'].

and in fact such line disappears when passwd is present in the chroot.

The problem is that passwd is no longer build-essential in trixie/sid, so if 
it's
required for building, it needs to be added to Build-Depends.

To reproduce, please try using debootstrap from trixie/sid, which finally stops
installing a few of required-but-not-build-essential packages.

Trivial patch attached.

Thanks.--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Build-Depends:
  debhelper-compat (= 13),
  dh-python,
  iproute2,
+ passwd,
  po-debconf,
  procps ,
  pylint,

Bug#1066983: monopd: Fails to start monopd.service

2024-03-25 Thread Sylvain Rochet

Hi Markus,

On Mon, Mar 25, 2024 at 02:36:59AM +0100, Markus Koschany wrote:
> Sylvain Rochet wrote:
> > Actually, the main problem is /lib/systemd/system/monopd.socket which 
> > set Accept=yes while monopd needs Accept=no (which is the default value).
> 
> I wonder if monopd needs a systemd socket file at all and if we should 
> disable the service after the installation. We have been using this 
> setting since the introduction of systemd. If monopd runs with 
> Accept=no then we also don't need a service template file. At some 
> point I also noticed the same warning as Shriram
> 
> "monopd.socket is a disabled or a static unit not running, not 
> starting it."  and then followed [1] and added the required template 
> file.

Yeah, socket activation is not really useful for public servers 
services, it is mostly used for local services that can be spawned on 
the fly later. Furthermore, socket activation breaks monopd metaserver 
registration because the daemon must be running to register, so better 
only ship the service file. I let you decide whether the service should 
be disabled or enabled by default (but unless something recently 
changed, daemon usually runs by default on Debian. I admit having lost 
track :D).

> I have been running monopd for the past decade and I also suspect the 
> daemon is affected by some bugs which might be remotely exploitable.

What makes you think that?

My daemon is running attached to gdb so I can easily catch and trace any 
issue that would kill the process. So far it's been over 10 years 
without a single issue, some process lived for several years between 
systems reboot.

I am not saying it is bug free because nothing is bug free, but if it is 
remotely exploitable and actively exploited, I would be aware of it on 
my running instance.

> Since users usually don't need the monopd server anyway, if they want 
> to play a game, they should make a conscious decision to start it if 
> they want to use it locally. For a simple internet game, the daemon is 
> not required.

Installing the server package isn't already a conscious decision?

Kind regards,
Sylvain

signature.asc
Description: Digital signature

Bug#1067695: nmu: boost1.83_1.83.0-2.1

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: boost1...@packages.debian.org
Control: affects -1 + src:boost1.83
User: release.debian@packages.debian.org
Usertags: binnmu

nmu boost1.83_1.83.0-2.1 . ANY . unstable . -m "Rebuild for time_t"

For https://release.debian.org/transitions/html/auto-openmpi.html

Bug#1067697: Update Build-Depends for the time64 library renames

Source: xca
Version: 2.5.0-1
Severity: serious

The package explicitly Build-Depends: libqt5sql5, libqt5help5, this needs to be
changed to the new names if it's needed at all.


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

2024-03-25 Thread Julian Gilbey

Hi all,

[NB: sent to d-science, d-python, d-devel and the RFP bug; reply-to
set to d-science and the RFP bug only]

An update on Apache Arrow, and in particular the Python library
PyArrow.  For those who don't know:

  Apache Arrow is a development platform for in-memory analytics. It
  contains a set of technologies that enable big data systems to
  process and move data fast. It specifies a standardized
  language-independent columnar memory format for flat and
  hierarchical data, organized for efficient analytic operations on
  modern hardware.

  The project is developing a multi-language collection of libraries
  for solving systems problems related to in-memory analytical data
  processing. This includes such topics as:

  * Zero-copy shared memory and RPC-based data movement

  * Reading and writing file formats (like CSV, Apache ORC, and Apache
Parquet)

  * In-memory analytics and query processing

  (from: https://arrow.apache.org/docs/index.html)

Pandas has announced that Pandas 3.x will depend on PyArrow
in a critical way (it will back the "string" datatype), and it is due
to be released imminently.

So this is a plea for anyone looking for something really helpful to
do: it would be great to have a group of developers finally package
this!  There was some initial work done (see the RFP bug report for
details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021),
but that is fairly old now.  As Apache Arrow supports numerous
languages, it may well benefit from having a group of developers with
different areas of expertise to build it.  (Or perhaps it would make
more sense to split the upstream source into a collection of different
Debian source packages for the different supported languages.  I don't
know.)  Unfortunately I don't have the capacity to devote any time to
it myself.

Thanks in advance for anyone who can step forward for this!

Best wishes,

   Julian

Bug#1066025: dh_installsystemd doesn't process user services in /usr/lib/systemd/user/

2024-03-25 Thread Sergey Ponomarev

Thank you, Neils,

> Ubuntu has patched debhelper

Sounds weird. I thought you guys had some communication with each other.

I changed the compact to 13 and indeed the scripts were generated and
included into the resulting package.
When changed to 14 scripts remains the same, no prerm script and nothing
about starting/stopping.

But when changed to 15 then the build failed:

dh_missing: warning: root/.ssh/sshtunnel.config.sh exists in debian/tmp but
is not installed to anywhere
dh_missing: error: missing files, aborting
The following debhelper tools have reported what they installed
(with files per package)
 * dh_installdocs: sshtunnel (0)

The debuild created /debian/tmp/ folder and copied all files there.
Previously it copied files to /debian/sshtunnel


I pushed the compact 14 version to a separate branch:
https://github.com/yurt-page/sshtunnel/tree/1.3.x

I'll use the old compact level for now because I want to support old
releases.
I wish to send the ssh tunnel script to the OpenSSH client itself and am
not sure what to do: require the compact 14 or again add scripts manually.

Thank you for the quick response.


On Mon, Mar 25, 2024 at 7:25 PM Niels Thykier  wrote:

> Sergey Ponomarev:
> > Hi Niels,
> >
> > I upgraded to Ubuntu 24.04 and now have debhelper 13.14.1ubuntu1.
>
>
> Hi,
>
> In case you are using Ubuntu, you should be filing the bug against
> Ubuntu for future reference. Notably, Ubuntu has patched debhelper and
> even monkey-patch(ed?) debhelper in their official builds on top that.
> Therefore, they have to screen incoming bug reports first to ensure the
> bug is not introduced by their patches.
>
> > Once executed the debuild nothing was generated.
> > When executed the dh_installsystemduser manually also nothing was
> generated.
> >  From it's sources I found that it looks for some dependency and I added
> to
> > the /debian/control:
> >
> >  Depends: ${misc:Depends}
> >
> > Now this helped and two install/uninstall scripts were generated
> > /debian/sshtunnel.postinst.debhelper
> > /debian/sshtunnel.postrm.debhelper
> >
> > I manually included the scripts to /debian/postinst and /debian/postrm
> and
> > built the deb.
>
>
> If you had to "manually" include those snippets into the deb in a clean
> build, then I think there is something seriously wrong with the
> packaging. Normally, `dh_installdeb` would do that for you if the
> commands are run in the correct sequence.
>
> Now, you mention you ran it manually. So it is possible you did that
> manually after building the deb, in which case you would see this
> behavior. This would also fit that your `debian/rules` likes quite
> standard without any room for mistakes of this kind when I checked it.
>
>
> > It was installed successfully but didn't start the service.
> > I started manually. During uninstall it has not been stopped. There is no
> > prerm script that will do that.
> >
>
> No, this feature is first added in compat 14 apparently (which is not
> stable yet). Sadly, this is not documented in the upgrade checklist for
> reasons I do not understand. The commit that introduced the feature
> recorded it in the wrong place and the remark seems to be completely gone.
>
> I will follow up on this part.
>
> > So the issues are:
> > 1. The debhelper did not execute the dh_installsystemduser. I guess I
> must
> > add it manually to /debian/rules
>
> Either that or you could use the proper debhelper-compat level.  That is
> compat 12 or later would do. The package you linked to used compat 11 as
> I recall.
>
> Remember to check the debhelper compat upgrade checklist before you
> update the compat level.
>
> It is in `man 7 debhelper-compat-upgrade-checklist` or `man 7 debhelper`
> (depending on the debhelper version).
>
> > 2. The generated scripts do not start the service after installation.
> > 3. Missing prerm script to stop the service.
>
> As mentioned above, this is compat 14 stuff.
>
> > 4. Surprising need for for ${misc:Depends}
> >
>
> There is no such need in the Debian version of debhelper for
> dh_installsystemduser to generate the snippets. However,
> dh_installsystemduser must either install the services files *or* be run
> after they are installed at the correct location.
>My best guess is that you ran dh_installsystemduser to "early" the
> first time, then the files were in place, followed by you tweaking
> debian/control and then running dh_installsystemduser without clean
> first. That is basically the one way I can make sense of what happened.
>
> That said, you ought have that dependency anyway for other reasons (at
> least up to compat 14, where it will be applied automatically).
>
> > So far I will anyway continue to use the manual scripts because I wish to
> > support old distros.
> > Anyway I wanted to have good and proper "official" scripts to install the
> > user service.
> >
> > You can play with my simple package here:
> > http://github.com/yurt-page/sshtunnel
> >
> > It can be a good s

Bug#1067698: RFS: persist-el/0.6+dfsg-1 [Team] -- persist variables between Emacs Sessions

2024-03-25 Thread Xiyue Deng

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "persist-el":

 * Package name : persist-el
   Version  : 0.6+dfsg-1
   Upstream contact : Phillip Lord 
 * URL  : https://elpa.gnu.org/packages/persist.html
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/emacsen-team/persist-el
   Section  : editors

The source builds the following binary packages:

  elpa-persist - persist variables between Emacs Sessions

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

  https://mentors.debian.net/package/persist-el/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/persist-el/persist-el_0.6+dfsg-1.dsc

Changes since the last upload:

 persist-el (0.6+dfsg-1) unstable; urgency=medium
 .
   * Team upload.
 .
   [ Debian Janitor ]
   * Remove constraints unnecessary since buster (oldstable):
 + elpa-persist: Drop versioned constraint on emacs in Recommends.
 .
   [ Xiyue Deng ]
   * New upstream release.
   * Re-export upstream signing key without extra signatures.
   * Update standards version to 4.6.2, no changes needed.

Regards,
-- 
Xiyue Deng

Bug#1067699: libllvm18:i386 contains files, also in libllvm18:amd64

2024-03-25 Thread Torsten Wohlfarth

Package: libllvm18
Version: 1:18.1.2-1
Severity: important
X-Debbugs-Cc: t...@siduction.org

Dear Maintainer,

libLLVM.so.1:i386 contains

/usr/lib/llvm-18/lib/libLLVM.so.1
/usr/lib/llvm-18/lib/libLLVM.so.18.1

which are also in libllvm18:amd64


That shouldn't be happen, since it makes installing of libllvm18:i386 on amd64
systems impossible.


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

Kernel: Linux 6.8.1-1-siduction-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libllvm18 depends on:
ii  libc6   2.37-15.1
ii  libedit23.1-20230828-1
ii  libffi8 3.4.6-1
ii  libgcc-s1   14-20240315-1
ii  libstdc++6  14-20240315-1
ii  libtinfo6   6.4+20240113-1
ii  libxml2 2.9.14+dfsg-1.3+b2
ii  libz3-4 4.8.12-3.1+b2
ii  libzstd11.5.5+dfsg2-2
ii  zlib1g  1:1.3.dfsg-3.1

libllvm18 recommends no packages.

libllvm18 suggests no packages.

Bug#1065056: bookworm-pu: package php-composer-class-map-generator/1.0.0-2+deb12u1

Control: tags -1 + confirmed

On Thu, 2024-02-29 at 11:10 +0100, David Prévot wrote:
> [1/9 for bookworm]
> 
> This is a follow up from composer/DSA-5632-1.
> 
> In order to fix a Debian-specific issue related to CVE-2024-24821, we
> agreed with the security team to push related dependencies via the
> next point release.

All 9 of them. :-/

Please go ahead.

Regards,

Adam

Bug#1065057: bookworm-pu: package php-composer-xdebug-handler/3.0.3-2+deb12u1

Control: tags -1 + confirmed

On Thu, 2024-02-29 at 11:18 +0100, David Prévot wrote:
> This is a follow up from composer/DSA-5632-1.
> 
> In order to fix a Debian-specific issue related to CVE-2024-24821, we
> agreed with the security team to push related dependencies via the
> next
> point release.

+  * Track debian/bookworm-security

Even though this update isn't going to the security archive?

Please go ahead.

Regards,

Adam

Bug#1067700: nmu: nfs-utils_1:2.6.4-3

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: nfs-ut...@packages.debian.org
Control: affects -1 + src:nfs-utils
User: release.debian@packages.debian.org
Usertags: binnmu

nmu nfs-utils_1:2.6.4-3 . ANY . unstable . -m "Rebuild for time_t"

Bug#1067701: FTBFS: _TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64

Source: erlang
Version: 1:25.3.2.10+dfsg-1
Severity: serious
Tags: ftbfs


https://buildd.debian.org/status/fetch.php?pkg=erlang&arch=armhf&ver=1%3A25.3.2.10%2Bdfsg-1&stamp=1711383511&raw=0

arm-linux-gnueabihf-gcc -Werror=undef -Werror=implicit -Werror=return-type
-fno-strict-aliasing -fno-common -g -O2 -fno-strict-aliasing
-I/<>/erts/arm-unknown-linux-gnueabihf  -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64  -D_GNU_SOURCE  -DHAVE_CONFIG_H -Wall -Wstrict-
prototypes -Wpointer-arith -Wmissing-prototypes -Wdeclaration-after-statement
-DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS
-D_POSIX_THREAD_SAFE_FUNCTIONS   -Iarm-unknown-linux-gnueabihf/opt/emu -Ibeam
-Isys/unix -Isys/common -Iarm-unknown-linux-gnueabihf -Ipcre -Iryu
-Iopenssl/include -I../include -I../include/arm-unknown-linux-gnueabihf
-I../include/internal -I../include/internal/arm-unknown-linux-gnueabihf -c
sys/unix/sys_time.c -o obj/arm-unknown-linux-gnueabihf/opt/emu/sys_time.o
In file included from /usr/include/features.h:393,
 from /usr/include/arm-linux-gnueabihf/bits/libc-header-
start.h:33,
 from /usr/include/stdlib.h:26,
 from sys/unix/sys_time.c:35:
/usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed
only with _FILE_OFFSET_BITS=64"
   26 | #   error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
  | ^


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1065058: bookworm-pu: package php-symfony-contracts/2.5.2-1+deb12u1

Control: tags -1 + confirmed

On Thu, 2024-02-29 at 11:31 +0100, David Prévot wrote:
> This is a follow up from composer/DSA-5632-1, #1065056 and #1065057.
> 
> In order to fix a Debian-specific issue related to CVE-2024-24821, we
> agreed with the security team to push related dependencies via the
> next
> point release.

Please go ahead.

Regards,

Adam

Bug#1007066: dh-buildinfo: please consider upgrading to 3.0 source format

2024-03-25 Thread Bastian Germann


I am uploading a NMU to DELAYED/10 in order to fix this.
Please find the debdiff attached.diff -Nru dh-buildinfo-0.11+nmu2/.dh-buildinfo.prcs_aux 
dh-buildinfo-0.11+nmu3/.dh-buildinfo.prcs_aux
--- dh-buildinfo-0.11+nmu2/.dh-buildinfo.prcs_aux   2006-12-17 
15:38:14.0 +
+++ dh-buildinfo-0.11+nmu3/.dh-buildinfo.prcs_aux   1970-01-01 
00:00:00.0 +
@@ -1,21 +0,0 @@
-;; This file is automatically generated, editing may cause PRCS to do
-;; REALLY bad things.
-(Created-By-Prcs-Version 1 3 3)
-(debian/rules 1400 1139951704 6_rules 1.5)
-(debian/copyright 267 1057481110 4_copyright 1.1)
-(stats/lib/buildinfo-nb-files.gnuplot 232 1063198995 17_buildinfo- 1.2)
-(debian/compat 2 1057480823 5_compat 1.1)
-(stats/bin/check-buildinfo 1342 1166365617 10_check-buil 1.10)
-(stats/bin/fetch-buildinfo 2227 1063746792 13_fetch-buil 1.8)
-(private/upload 325 1063197804 12_upload 1.3)
-(stats/check-buildinfo 779 1060110460 10_check-buil 1.2)
-(stats/bin/buildinfo-packagetable 6206 1166369620 14_buildinfo- 1.2.1.17)
-(dh_buildinfo 7809 1073568157 2_dh_buildin 1.7)
-(debian/changelog 2925 1139952038 7_changelog 1.15)
-(stats/buildinfo-nb.gnuplot 221 1060032012 11_buildinfo- 1.1)
-(stats/lib/buildinfo-nb.gnuplot 221 1063198978 11_buildinfo- 1.2)
-(BuildDeps.pm 4814 1003610400 0_BuildDeps. 1.1)
-(dpkg-checkbuilddeps 4005 1003445118 1_dpkg-check 1.1)
-(buildinfo.html 26038 1063741835 9_buildinfo. 1.23)
-(debian/control 895 1073567609 8_control 1.6)
-(Makefile.PL 174 1139951911 3_Makefile.P 1.3)
diff -Nru dh-buildinfo-0.11+nmu2/debian/changelog 
dh-buildinfo-0.11+nmu3/debian/changelog
--- dh-buildinfo-0.11+nmu2/debian/changelog 2018-01-10 21:28:27.0 
+
+++ dh-buildinfo-0.11+nmu3/debian/changelog 2024-03-25 18:37:09.0 
+
@@ -1,3 +1,12 @@
+dh-buildinfo (0.11+nmu3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/copyright: Convert to machine-readable format.
+  * Convert to source format 3.0 (Closes: #1007066).
+  * Drop versioned B-D on build-essential.
+
+ -- Bastian Germann   Mon, 25 Mar 2024 18:37:09 +
+
 dh-buildinfo (0.11+nmu2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru dh-buildinfo-0.11+nmu2/debian/control 
dh-buildinfo-0.11+nmu3/debian/control
--- dh-buildinfo-0.11+nmu2/debian/control   2018-01-10 21:00:16.0 
+
+++ dh-buildinfo-0.11+nmu3/debian/control   2024-03-25 18:37:09.0 
+
@@ -1,7 +1,7 @@
 Source: dh-buildinfo
 Section: devel
 Priority: optional
-Build-Depends-Indep: perl, build-essential (>= 7)
+Build-Depends-Indep: perl
 Build-Depends: debhelper (>= 9)
 Maintainer: Yann Dirson 
 Rules-Requires-Root: no
diff -Nru dh-buildinfo-0.11+nmu2/debian/copyright 
dh-buildinfo-0.11+nmu3/debian/copyright
--- dh-buildinfo-0.11+nmu2/debian/copyright 2003-07-06 08:45:10.0 
+
+++ dh-buildinfo-0.11+nmu3/debian/copyright 2024-03-25 18:37:02.0 
+
@@ -1,5 +1,10 @@
-This is the debian package for dh-buildinfo.  It was initially created
-by Yann Dirson  using dh-make-perl.
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment:
+ This is the debian package for dh-buildinfo.  It was initially created
+ by Yann Dirson  using dh-make-perl.
 
-This package is covered by the GNU General Public Licence, version 2.
-On Debian systems, you'll find it in /usr/share/common-licenses/GPL-2
+Files: *
+Copyright: 2001 Yann Dirson 
+License: GPL-2
+ This package is covered by the GNU General Public Licence, version 2.
+ On Debian systems, you'll find it in /usr/share/common-licenses/GPL-2
diff -Nru dh-buildinfo-0.11+nmu2/debian/source/format 
dh-buildinfo-0.11+nmu3/debian/source/format
--- dh-buildinfo-0.11+nmu2/debian/source/format 1970-01-01 00:00:00.0 
+
+++ dh-buildinfo-0.11+nmu3/debian/source/format 2024-03-25 18:37:09.0 
+
@@ -0,0 +1 @@
+3.0 (native)

Bug#1065059: bookworm-pu: package symfony/5.4.23+dfsg-1+deb12u2

Control: tags -1 + confirmed

On Thu, 2024-02-29 at 11:54 +0100, David Prévot wrote:
> Hi,
> 
> Le Thu, Feb 29, 2024 at 11:40:25AM +0100, David Prévot a écrit :
> >   [x] attach debdiff against the package in (old)stable
> 
> Now it’s true.

Please go ahead.

Regards,

Adam

Bug#1065060: bookworm-pu: package php-proxy-manager/2.11.1+1.0.14-1+deb12u1

Control: tags -1 + confirmed

On Thu, 2024-02-29 at 11:50 +0100, David Prévot wrote:
> This is a follow up from composer/DSA-5632-1.
> 
> In order to fix a Debian-specific issue related to CVE-2024-24821, we
> agreed with the security team to push related dependencies via the
> next
> point release.

Please go ahead.

Regards,

Adam

Bug#1065062: bookworm-pu: package php-zend-code/4.8.0-1+deb12u1

Control: tags -1 + confirmed

On Thu, 2024-02-29 at 11:58 +0100, David Prévot wrote:
> This is a follow up from composer/DSA-5632-1.
> 
> In order to fix a Debian-specific issue related to CVE-2024-24821, we
> agreed with the security team to push related dependencies via the
> next
> point release.

Please go ahead.

Regards,

Adam

Bug#1065065: bookworm-pu: package php-doctrine-annotations/2.0.1-1+deb12u1

Control: tags -1 + confirmed

On Thu, 2024-02-29 at 12:05 +0100, David Prévot wrote:
> This is a follow up from composer/DSA-5632-1.
> 
> In order to fix a Debian-specific issue related to CVE-2024-24821, we
> agreed with the security team to push related dependencies via the
> next
> point release.

Please go ahead.

Regards,

Adam

Bug#1065067: bookworm-pu: package php-doctrine-lexer/2.1.0-2+deb12u1

Control: tags -1 + confirmed

On Thu, 2024-02-29 at 12:08 +0100, David Prévot wrote:
> This is a follow up from composer/DSA-5632-1.
> 
> In order to fix a Debian-specific issue related to CVE-2024-24821, we
> agreed with the security team to push related dependencies via the
> next
> point release.

Again the branch name probably wants adjusting.

Please go ahead.

Regards,

Adam

Bug#1065068: bookworm-pu: package php-doctrine-deprecations/1.0.0-2+deb12u1