Bug#1067639: ping Bug#1067639: sasl2-bin: terminates with smashed stack

[Thorsten Glaser]

any idea?

Bug#1066045: maven-bundle-plugin: diff for NMU version 3.5.1-2.1

[tony mancill]

On Wed, Mar 27, 2024 at 09:24:34PM -0700, tony mancill wrote:
> Thank you for the patch and the NMU.  Feel free to proceed with a 0-day
> upload if you'd prefer.

Resending - the prior reply was from me, but didn't have the correct
From: header.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small

[Sean Whitton]

Hello,

On Mon 18 Mar 2024 at 10:43am +08, Sean Whitton wrote:

> The vote has concluded.  The result is that the Technical Committee
> recommends that Craig Small  be appointed by the Debian Project
> Leader to the Technical Committee.
>
> Jonathan, over to you.

Quick ping about this.  The appointment holds up some administrative
stuff for us.  Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?

[Sean Whitton]

Hello,

Rob, can you review the implementation in d/rules for Xiyue's patch to
this bug, please?  I'm not sure it's the straightforward way to do it.

Xiyue, I think it would make sense to use emacs-common (<< 1:29.3+2-2),
for the relationships.

Thanks both.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067870: RM: keybinder -- RoQA; depends on gtk2, gtk3 replacement exists

[Esa Peuha]

Package: ftp.debian.org
Control: affects -1 + src:keybinder

It seems that all reverse (build-)dependencies have migrated to
keybinder-3.0 so this can be removed.

Bug#1067582: ping?

[Thorsten Glaser]

this would help a lot with the t64 transition,
as Qt is proving difficult on some architectures

Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment

[Sean Whitton]

Hello dkg,

Please take a look into this test suite failure for your script.

Thanks!

On Tue 26 Mar 2024 at 10:25pm +01, Santiago Vila wrote:

> Package: src:mailscripts
> Version: 28-1
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> During a rebuild of all packages in unstable, your package failed to build:
>
> 
> [...]
>  debian/rules build
> dh build --with elpa --with bash-completion
>dh_update_autotools_config
>dh_autoreconf
>dh_auto_configure
>dh_auto_build
>   make -j2
> make[1]: Entering directory '/<>'
> pod2man --section=1 --date="Debian Project" --center="User Commands" \
>   --utf8 \
>   --name=mdmv \
>   mdmv.1.pod mdmv.1
> pod2man --section=1 --date="Debian Project" --center="User Commands" \
>   --utf8 \
>   --name=mbox2maildir \
>   mbox2maildir.1.pod mbox2maildir.1
> pod2man --section=1 --date="Debian Project" --center="User Commands" \
>   --utf8 \
>   --name=notmuch-slurp-debbug \
>   notmuch-slurp-debbug.1.pod notmuch-slurp-debbug.1
> pod2man --section=1 --date="Debian Project" --center="User Commands" \
>   --utf8 \
>   --name=notmuch-extract-patch \
>   notmuch-extract-patch.1.pod notmuch-extract-patch.1
> pod2man --section=1 --date="Debian Project" --center="User Commands" \
>   --utf8 \
>   --name=maildir-import-patch \
>   maildir-import-patch.1.pod maildir-import-patch.1
> pod2man --section=1 --date="Debian Project" --center="User Commands" \
>   --utf8 \
>   --name=mbox-extract-patch \
>   mbox-extract-patch.1.pod mbox-extract-patch.1
> pod2man --section=1 --date="Debian Project" --center="User Commands" \
>   --utf8 \
>   --name=imap-dl \
>   imap-dl.1.pod imap-dl.1
> pod2man --section=1 --date="Debian Project" --center="User Commands" \
>   --utf8 \
>   --name=email-extract-openpgp-certs \
>   email-extract-openpgp-certs.1.pod email-extract-openpgp-certs.1
> pod2man --section=1 --date="Debian Project" --center="User Commands" \
>   --utf8 \
>   --name=email-print-mime-structure \
>   email-print-mime-structure.1.pod email-print-mime-structure.1
> pod2man --section=1 --date="Debian Project" --center="User Commands" \
>   --utf8 \
>   --name=notmuch-import-patch \
>   notmuch-import-patch.1.pod notmuch-import-patch.1
> pod2man --section=1 --date="Debian Project" --center="User Commands" \
>   --utf8 \
>   --name=gmi2email \
>   gmi2email.1.pod gmi2email.1
> mkdir -p completions/bash
> register-python-argcomplete email-print-mime-structure 
> >completions/bash/email-print-mime-structure.tmp
> mv completions/bash/email-print-mime-structure.tmp 
> completions/bash/email-print-mime-structure
> mkdir -p completions/bash
> register-python-argcomplete imap-dl >completions/bash/imap-dl.tmp
> mv completions/bash/imap-dl.tmp completions/bash/imap-dl
> make[1]: Leaving directory '/<>'
>dh_auto_test
>   make -j2 check
> make[1]: Entering directory '/<>'
> ./tests/email-print-mime-structure.sh
> Testing alternative.eml
> Testing attachment.eml
> Testing encrypted.eml (PGPy)
> /usr/lib/python3/dist-packages/pgpy/constants.py:192: 
> CryptographyDeprecationWarning: IDEA has been deprecated and will be removed 
> in a future release
>   bs = {SymmetricKeyAlgorithm.IDEA: algorithms.IDEA,
> /usr/lib/python3/dist-packages/pgpy/constants.py:194: 
> CryptographyDeprecationWarning: CAST5 has been deprecated and will be removed 
> in a future release
>   SymmetricKeyAlgorithm.CAST5: algorithms.CAST5,
> /usr/lib/python3/dist-packages/pgpy/constants.py:195: 
> CryptographyDeprecationWarning: Blowfish has been deprecated and will be 
> removed in a future release
>   SymmetricKeyAlgorithm.Blowfish: algorithms.Blowfish,
> Testing encrypted.eml (GnuPG PGP/MIME)
> Testing simple.eml
> Testing smime-encrypted.eml (OpenSSL)
> Testing smime-encrypted.eml (GnuPG S/MIME)
> gpgsm: issuer certificate (#/CN=Sample LAMPS Certificate Authority) not found
> Testing smime-signed.eml
> mypy --strict ./email-print-mime-structure
> email-print-mime-structure:51: error: Unused "type: ignore" comment  
> [unused-ignore]
> email-print-mime-structure:53: error: Incompatible types in assignment 
> (expression has type "None", variable has type Module)  [assignment]
> email-print-mime-structure:77: error: Incompatible types in assignment 
> (expression has type "Message | str | list[Message | str] | Any", variable 
> has type "list[Message] | str | bytes | None")  [assignment]
> email-print-mime-structure:109: error: Incompatible types in assignment 
> (expression has type "Message | bytes | Any", variable has type 
> "list[Message] | str | bytes | None")  [assignment]
> email-print-mime-structure:121: error: Incompatible types in assignment 
> (expression has type "Message | bytes | Any", variable has type 
> "list[Message] | str | bytes | None")  [assignment]
> 

Bug#1067839: triton: FTBFS on armel (undefined reference to symbol '__atomic_compare_exchange_4@@LIBATO)

[Petter Reinholdtsen]

I guess the fix is to convince the build to add -latomic to its link
lines when needed.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1067603: contextfree: FTBFS on armhf: test failure with missing codec

[Kentaro HAYASHI]

Hi,

On Wed, 27 Mar 2024 20:58:51 -0700 John Horigan 
wrote:
> That error message indicates that libavcodec60 does not support the
> libx264 codec for encoding H.264 files. libavcodec60 lists
> libx264-164 as a dependency, with no exception for armel or armhf
> systems, so I don't know why the codec won't load.
> 
> Can you run the command
> 
> ffmpeg -codecs
> 
> on an armhf system and report back the output?

I've attached ffmepg -codecs (when ffmpeg was manually installed, not
apt build-dep)

It seems when ffmpeg is not installed, it causes FTBFS.
After installing ffmpeg, build succeeded on armhf.


Surely, it seems that libx264 was installed.

(sid_armhf-dchroot)kenhys@amdahl:~$ dpkg -l |grep
-E "avcodec|x264" ii  libavcodec-dev:armhf 7:6.1.1-3+b1
armhfFFmpeg library with de/encoders for audio/video codecs -
development files ii  libavcodec60:armhf   7:6.1.1-3+b1
  armhfFFmpeg library with de/encoders for
audio/video codecs - runtime files ii  libx264-164:armhf
2:0.164.3108+git31e19f9-1  armhfx264 video coding library
ii  libx264-dev:armhf2:0.164.3108+git31e19f9-1
armhfdevelopment files for libx264




ffmpeg-codecs-on-armhf.txt.gz
Description: application/gzip

Bug#1067603: contextfree: FTBFS on armhf: test failure with missing codec

[John Horigan]

Could this bug be the cause?

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

If libavcodec cannot access libx264.so due to some executable stack
security issue, then it would fail to load the libx264 encoder.

-- john

Bug#1067839: triton: FTBFS on armel (undefined reference to symbol '__atomic_compare_exchange_4@@LIBATO)

[Kentaro HAYASHI]

Control: severity -1 serious

Change severity because of ftbfs.

Bug#1066045: maven-bundle-plugin: diff for NMU version 3.5.1-2.1

[tony mancill]

On Wed, Mar 27, 2024 at 06:18:51PM +0100, Mattia Rizzolo wrote:
> I've prepared an NMU for maven-bundle-plugin (versioned as 3.5.1-2.1) and
> uploaded it to DELAYED/15. Please feel free to tell me if I
> should delay it longer.

Hi Mattia, hi James,

Thank you for the patch and the NMU.  Feel free to proceed with a 0-day
upload if you'd prefer.

I will import the changes into the repo and ACK the NMU with the next
upload.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#1067603: contextfree: FTBFS on armhf: test failure with missing codec

[John Horigan]

That error message indicates that libavcodec60 does not support the libx264
codec for encoding H.264 files. libavcodec60 lists libx264-164 as a
dependency, with no exception for armel or armhf systems, so I don't know
why the codec won't load.

Can you run the command

ffmpeg -codecs

on an armhf system and report back the output?

-- john

On Sun, 24 Mar 2024 21:04:49 +0900 Kentaro HAYASHI  wrote:
> Package: contextfree
> Version: 3.4+dfsg-1.1
> Severity: important
> Tags: ftbfs
> X-Debbugs-Cc: ken...@xdump.org
>
> Dear Maintainer,
>
>
>* What led up to the situation?
>
>contextfree can't build on armel,armhf.
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> apt-get source contextfree
> cd contextfree-3.4+dfsg
> debuild -us -uc
>
>* What was the outcome of this action?
>
> See
>
https://buildd.debian.org/status/fetch.php?pkg=contextfree=armhf=3.4%2Bdfsg-1.1=1711207519=0
>
> input/ziggy_v2.cfdg   pass Reading rules file input/mtree.cfdg
> Restarting as a version 3 design
> 8 rules loaded
> Generating 8bit gray-scale Quicktime movie, variation FFGH...
> Failed to create movie file: codec not found
> make[1]: *** [Makefile:188: test] Error 8
> make[1]: Leaving directory '/home/kenhys/work/contextfree-3.4+dfsg'
> dh_auto_test: error: make -j8 test returned exit code 2
> make: *** [debian/rules:6: build] Error 25
> dpkg-buildpackage: error: debian/rules build subprocess returned exit
> status 2 debuild: fatal error at line 1184:
> dpkg-buildpackage -us -uc -ui failed
>
>* What outcome did you expect instead?
>
> contextfree can build on armel/armhf.
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable')
> Architecture: armhf (armv8l)
>
> Kernel: Linux 6.1.0-18-arm64 (SMP w/8 CPU threads)
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect
>
> Versions of packages contextfree depends on:
> pn  libagg2
> ii  libavcodec60   7:6.1.1-3
> ii  libavformat60  7:6.1.1-3
> ii  libavutil587:6.1.1-3
> ii  libc6  2.37-15.1
> ii  libgcc-s1  14-20240315-1

Bug#1000003:

[Raul Cheleguini]

Dear Christoph (package maintainer) and everyone,

I would like to inform you that we have uploaded a new version
2.2.0-0.1 of the pdfgrep package to unstable as an NMU. This release
includes the switch to pcre2.

It is in deferred uploads (5 day), in case of objection please review it.

Bug#1063371: nmu: golang-github-tinylib-msgp

[Mathias Gibbens]

Control: retitle -1 nmu: golang-github-tinylib-msgp
Control: affects -1 - src:golang-github-go-jose-go-jose

  I've backported a newer version of golang-github-go-jose-go-jose,
which resolves the need for a binNMU of that package.

  A binNMU is still requested for golang-github-tinylib-msgp in
bookworm-backports.

Mathias


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

Bug#1065643: debian-policy: Refer to «dpkg-buildtree clean» for dpkg generated files

[Sean Whitton]

Hello,

On Thu 07 Mar 2024 at 11:22pm +01, Guillem Jover wrote:

> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 4307e89..2fb05cd 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -685,7 +685,7 @@ variables are also available.
>
>  The ``debian/substvars`` file is usually generated and modified
>  dynamically by ``debian/rules`` targets, in which case it must be
> -removed by the ``clean`` target.
> +removed by the ``clean`` target (for example with ``dpkg-buildtree clean``).
>
>  See :manpage:`deb-substvars(5)` for full details about source variable
>  substitutions, including the format of ``debian/substvars``.
> @@ -725,8 +725,9 @@ building packages to record which files are being 
> generated.
>
>  It should not exist in a shipped source package, and so it (and any
>  backup files or temporary files such as ``files.new``)  [#]_ should be
> -removed by the ``clean`` target. It may also be wise to ensure a fresh
> -start by emptying or removing it at the start of the ``binary`` target.
> +removed by the ``clean`` target (for example with ``dpkg-buildtree clean``).
> +It may also be wise to ensure a fresh start by emptying or removing it at the
> +start of the ``binary`` target.
>
>  When ``dpkg-gencontrol`` is run for a binary package, it adds an entry
>  to ``debian/files`` for the ``.deb`` file that will be created when

Instead of "It may also be wise ..." can you use one of the sets of
magic words from Policy 1.1, please?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067159: python-respx: Backport to bookworm

[Yogeswaran Umasankar]

Hi,

In my free time I will give it a try.

Cheers!

Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

[Sean Whitton]

Hello,

On Fri 22 Mar 2024 at 06:46pm +03, Dmitry Shachnev wrote:

> Actually, I would move ${sphinxdoc:Depends} from Recommends to
> Depends, because the documentation is mostly unusable without the
> static files.

I think it's in Recommends because we ship other formats that don't need
it, and to ensure installability on stable, or something similar.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067831: libaio: the t64 package slipped through and is in testing

[Arnaud Rebillout]

On 27/03/2024 7:21 pm, Guillem Jover wrote:

A binNMU would fix that, but given that no one has apparently asked
for that yet, I think instead I'll just add (later today) a compat
symlink only for the udeb for the old SONAME, because the new SONAME is
ABI compatible, but done to avoid stomping on the upstream SONAME in
case they end up merging something else or rejecting the patches, but
in d-i we do not care about backwards compatibility as long as it is
ABI compatible, then no binNMU will be needed anymore.


Thanks very much for your explanations and for the prompt upload.

I'll pick that up on Kali's side today.

Best,

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

[Sean Whitton]

Hello,

On Sat 23 Mar 2024 at 05:08pm +01, Holger Wansing wrote:

> While working on adapting the parts/7doc script (from Debian Webmaster
> Team's 'cron' repo), I realized that this is not going to work out of the
> box: while the concept of the symlinks mentioned above is working fine,
> when the debian-policy document is installed on a machine as usual
> (means it recides in the same path as in the binary deb package, aka
> /usr/share/doc/debian-policy/policy.html), we have the docs for the website
> on the debian.org website machine in another path. That is in
> /srv/www.debian.org/www/doc/debian-policy/.
>
> That means the (relative) symlinks will not resolve!
> Therefore I think the best solution here is, to change the relative
> symlinks into absolute ones, on the debian.org website machine.
>
> I have worked out the needed changes for cron/parts/7doc to deal with all
> this (it works fine here locally). The debian-policy package could stay
> unchanged.
> I attach the patch here just for reference; will apply it, as soon as
> sphinx-rtd-theme-common gets installed on wolkenstein
> (working on a bugreport to DSA to get this done).
>
> Closing #1066967 against sphinx-common/dh_sphinxdoc now.
> Thanks python people for your help!

Many thanks all for working on this, especially you Holger for this
scripting work.  So, we're waiting in DSA and then on your script
changes, and it'll work again.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067869: ITP: golang-github-joshuarubin-lifecycle -- manage goroutines in golang applications (library)

[Maytham Alsudany]

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Control: block 1067867 by -1

* Package name: golang-github-joshuarubin-lifecycle
  Version : 1.1.4
  Upstream Contact: https://github.com/joshuarubin/lifecycle/issues
* URL : https://github.com/joshuarubin/lifecycle
* License : Expat
  Programming Lang: Go
  Description : manage goroutines in golang applications (library)

 lifecycle helps manage goroutines at the application level. context.Context
 has been great for propagating cancellation signals, but not for getting any
 feedback about when goroutines actually finish. This package works with
 context.Context to ensure that applications don't quit before their goroutines
 do.
 .
 The semantics work similarly to the go (lifecycle.Go) and defer
 (lifecycle.Defer) keywords as well as sync.WaitGroup.Wait (lifecycle.Wait).
 Additionally, there are lifecycle.GoErr and lifecycle.DeferErr which only
 differ in that they take funcs that return errors.
 .
 lifecycle.Wait will block until one of the following happens:
   - all funcs registered with Go complete successfully then all funcs 
registered
 with Defer complete successfully
   - a func registered with Go returns an error, immediately canceling ctx and
 triggering Defer funcs to run. Once all Go and Defer funcs complete, Wait
 will return the error
   - a signal (by default SIGINT and SIGTERM, but configurable with
 WithSignals) is received, immediately canceling ctx and triggering Defer
 funcs to run. Once all Go and Defer funcs complete, Wait will return
 ErrSignal
   - a func registered with Go or Defer panics. the panic will be propagated to
 the goroutine that Wait runs in. there is no attempt, in case of a panic,
 to manage the state within the lifecycle package.

Dependency of golang-github-joshuarubin-go-sway.

This package will be maintained within the Debian Go Packaging Team.
I will need a DD to sponsor and upload this package.

--
Kind regards,
Maytham Alsudany



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

Bug#895570: devscripts: wrap-and-sort should default to -ast

[Otto Kekäläinen]

The research done in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895570#50 looks good.

Do we have now agreement to default to -ast or -astb for packages that have
Debhelper 14+?

Bug#1067868: ITP: golang-github-joshuarubin-go-sway -- Sway client for Go (library)

[Maytham Alsudany]

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Control: block 1067865 by -1

* Package name: golang-github-joshuarubin-go-sway
  Version : 1.2.0
  Upstream Contact: https://github.com/joshuarubin/go-sway/issues
* URL : https://github.com/joshuarubin/go-sway
* License : Expat
  Programming Lang: Go
  Description : Sway client for Go (library)

 This package simplifies working with the sway IPC from Go. It was highly
 influenced by https://github.com/i3/go-i3.
 .
 While the i3 and sway IPCs share much in common, they are not identical. This
 package provides the complete sway api.

Dependency of nwg-bar.

This package will be maintained within the Debian Go Packaging Team.
I will need a DD to sponsor and upload this package.

--
Kind regards,
Maytham Alsudany




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

Bug#1067867: ITP: golang-github-joshuarubin-go-sway -- Sway client for Go (library)

[Maytham Alsudany]

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Control: block 1067865 by -1

* Package name: golang-github-joshuarubin-go-sway
  Version : 1.2.0
  Upstream Contact: https://github.com/joshuarubin/go-sway/issues
* URL : https://github.com/joshuarubin/go-sway
* License : Expat
  Programming Lang: Go
  Description : Sway client for Go (library)

 This package simplifies working with the sway IPC from Go. It was highly
 influenced by https://github.com/i3/go-i3.
 .
 While the i3 and sway IPCs share much in common, they are not identical. This
 package provides the complete sway api.

Dependency of nwg-bar.

This package will be maintained within the Debian Go Packaging Team.
I will need a DD to sponsor and upload this package.

--
Kind regards,
Maytham Alsudany



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

Bug#1067853: kanshi(1) refers to kanshictl(1), but no kanshictl is not shipped (neither manpage or executable)

[Amin Bandali]

Hi,

For the record, the absence of kanshictl was previously raised in
https://bugs.debian.org/1026463 but self-closed with a comment about
varlink possibly not being in the best shape for inclusion in Debian.

I'm personally not decided for or against packaging varlink in Debian
at this point.  I think I might try following up with kanshi and/or
varlink upstream to inquire more about the situation.  I'll look into
either packaging varlink and adding kanshictl, or otherwise amending
man kanshi(1) to drop references to kanshictl(1) to avoid confusion.

Also FWIW, per https://todo.sr.ht/~emersion/kanshi/104 upstream kanshi
didn't seem interested in exploring other options in place of varlink.

Bug#1067866: ITP: golang-github-dlasky-gotk3-layershell -- gotk3 addon module that provides gtk_layer_shell compatibiility (library)

[Maytham Alsudany]

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-dlasky-gotk3-layershell
  Version : 0.0~git20230801.b0c42cd
  Upstream Contact: https://github.com/dlasky/gotk3-layershell/issues
* URL : https://github.com/dlasky/gotk3-layershell
* License : Expat
  Programming Lang: Go
  Description : gotk3 addon module that provides gtk_layer_shell 
compatibiility (library)

 gotk3-layershell is a simple golang library to provide bindings for the
 excellent Gtk Layer Shell library which can be consumed in the also excellent
 gotk3 Gtk library. This allows for GTK windows in Linux window managers like
 swaywm that utilize the Layer Shell protocol in wayland to be positioned
 relative to the viewport including pinning and layer depth control.

Dependency of nwg-bar.

This package will be maintained within the Debian Go Packaging Team.
I will need a DD to sponsor and upload this package.

--
Kind regards,
Maytham Alsudany



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

Bug#1067865: ITP: nwg-bar -- GTK3-based button bar for wlroots-based compositors

[Maytham Alsudany]

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Control: block -1 by 1067864

* Package name: nwg-bar
  Version : 0.1.6
  Upstream Contact: https://github.com/nwg-piotr/nwg-bar/issues
* URL : https://github.com/nwg-piotr/nwg-bar
* License : Expat
  Programming Lang: Go
  Description : GTK3-based button bar for wlroots-based compositors

 nwg-bar is a GTK3-based button bar for wlroots-based compositors like sway,
 based on a user-defined JSON template and fully customizable using CSS.
 .
 The nwg-bar command creates a button bar on the basis of a JSON template placed
 in the ~/.config/nwg-bar/ folder. By default the command displays a horizontal
 bar in the center of the screen. Use command line arguments to change the
 placement.
 .
 This application is a part of the nwg-shell project.

This package will be maintained within the Debian Go Packaging Team.
I will need a DD to sponsor and upload this package.

--
Kind regards,
Maytham Alsudany



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

Bug#1007632: xsettings-kde: please consider upgrading to 3.0 source format

[Bastian Germann]

I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru xsettings-kde-0.9/debian/changelog xsettings-kde-0.9/debian/changelog
--- xsettings-kde-0.9/debian/changelog  2024-03-27 23:57:07.0 +
+++ xsettings-kde-0.9/debian/changelog  2024-03-27 23:51:52.0 +
@@ -1,3 +1,11 @@
+xsettings-kde (0.9-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Convert to source format 3.0 (Closes: #1007632)
+  * Move from obsolete pkg-config to pkgconf
+
+ -- Bastian Germann   Wed, 27 Mar 2024 23:51:52 +
+
 xsettings-kde (0.9-2) unstable; urgency=low
 
   * [e89ec72] Add autostart file
diff -Nru xsettings-kde-0.9/debian/control xsettings-kde-0.9/debian/control
--- xsettings-kde-0.9/debian/control2024-03-27 23:57:07.0 +
+++ xsettings-kde-0.9/debian/control2024-03-27 23:51:37.0 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Guido Günther 
 Build-Depends: cdbs, debhelper (>= 7), libfontconfig1-dev, libglib2.0-dev,
- libx11-dev, pkg-config, cdbs, quilt
+ libx11-dev, pkgconf, cdbs
 Standards-Version: 3.8.4
 
 Package: xsettings-kde
diff -Nru xsettings-kde-0.9/debian/rules xsettings-kde-0.9/debian/rules
--- xsettings-kde-0.9/debian/rules  2024-03-27 23:57:07.0 +
+++ xsettings-kde-0.9/debian/rules  2024-03-27 23:51:06.0 +
@@ -2,4 +2,3 @@
 
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/makefile.mk
-include /usr/share/cdbs/1/rules/patchsys-quilt.mk
diff -Nru xsettings-kde-0.9/debian/source/format 
xsettings-kde-0.9/debian/source/format
--- xsettings-kde-0.9/debian/source/format  1970-01-01 00:00:00.0 
+
+++ xsettings-kde-0.9/debian/source/format  2024-03-27 23:51:52.0 
+
@@ -0,0 +1 @@
+3.0 (quilt)

Bug#1067864: ITP: golang-github-allan-simon-go-singleinstance -- Make sure you have only one instance of a software in Go (library)

[Maytham Alsudany]

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-allan-simon-go-singleinstance
  Version : 1.0.0
  Upstream Contact: Allan Simon 
* URL : https://github.com/allan-simon/go-singleinstance
* License : Expat
  Programming Lang: Go
  Description : Make sure you have only one instance of a software in Go 
(library)

 Cross plateform library to have only one instance of a software (based on
 python's tendo).

Dependency of nwg-bar.

This package will be maintained within the Debian Go Packaging Team.
I will need a DD to sponsor and upload this package.

--
Kind regards,
Maytham Alsudany




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

Bug#1067863: xserver-xorg-video-trident: please consider upgrading to 3.0 source format

[Bastian Germann]

Source: xserver-xorg-video-trident
Version: 1:1.4.0-1
Severity: wishlist

This package is among the few that still use source format 1.0.
Please upgrade it to source format 3.0, as (1) this format has many
advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ;
(2) this contributes to standardization of packaging practices.

Bug#1067862: xserver-xorg-video-mach64: please consider upgrading to 3.0 source format

[Bastian Germann]

Source: xserver-xorg-video-mach64
Version: 6.9.7-1
Severity: wishlist

This package is among the few that still use source format 1.0.
Please upgrade it to source format 3.0, as (1) this format has many
advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ;
(2) this contributes to standardization of packaging practices.

Bug#1067861: xserver-xorg-video-geode: please consider upgrading to 3.0 source format

[Bastian Germann]

Source: xserver-xorg-video-geode
Version: 2.11.21-2
Severity: wishlist

This package is among the few that still use source format 1.0.
Please upgrade it to source format 3.0, as (1) this format has many
advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ;
(2) this contributes to standardization of packaging practices.

Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

[Thorsten Glaser]

Hi Wookey,

>OK, got those. but that's just binaries. It was the source changes I
>was looking for (or did I misunderstand and you didn't actually make
>any of those?),

Yes, I did not make any source changes. These were the last binaries
from before the t64 transition (I downloaded the .deb files unchanged)
with just control.tar.xz/control changed to allow installation given
the relevant libraries were already rebuilt for t64.

> but actually having an openjdk binaries is very useful
>too to satisfy the self-dependency without more faff.

Yes, that was their purpose.

>I'm no java expert so if anything breaks or it gets more complicated
>than 'get the right build-deps in (with care for t64-libs) somehow' I
>will indeed be asking questions :-)

Right. I’m no expert either, though :/

>> What was the actual problem with uploading the images you built? Just
>> not having any corresponding source? Or something more complicated?
>
>Answering my own question: There have been a couple of new openjdk-17
>uploads (latest is: 17_17.0.11~7ea-1) so Thorsten's bootstrap build
>(17.0.10+7-1) is out of date.

Yes, exactly: dak lacked the 17.0.10+7.orig.tar.* because sid already
moved to 17.0.11~7ea.orig.tar.*

>So I now have all the pieces (on armhf, not checked armel yet but
>hopefully it matches)

Depends, but 'apt install /tmp/*.deb' will tell you ;-)

>The build failed:
>
>An exception has occurred in the compiler (17.0.10). Please file a bug against 
>the Java compiler via the Java bug reporting page (https://bugreport.java.com) 
>after checking the Bug Database (https://bugs.java.com) for duplicates. 
>Include your program, the following diagnostic, and the parameters passed to 
>the Java compiler in your report. Thank you.
>java.io.UncheckedIOException: java.nio.file.FileSystemException: .: Value too 
>large for defined data type
>
>Don't worry about this. It's a an issue to do with building for 32 bit
>inside qemu on a 64-bit machine. I'll stop doing that and use real
>hardware :-/

Ouch. I was just wondering which filesystem you used, but yes,
there’s that known combined qemu/kernel/libc issue which cbmuser
is also constantly running into. I think switching to… sgixfs I
think? also makes it work, but I’m not sure.

https://sourceware.org/bugzilla/show_bug.cgi?id=23960#c73
sgixfs and btrfs, yeah, ext4 is problematic. But apparently,
LFS should fix this but Java is again special in that it’s
still problematic there.

Were you using qemu-user? qemu-system has its own kernel and
“should” be fine, modulo the usual qemu issues. Real hardware
is better (for many architectures even necessary).

Good luck,
//mirabilos
-- 
 exceptions: a truly awful implementation of quite a nice idea.
 just about the worst way you could do something like that, afaic.
 it's like anti-design.   that too… may I quote you on that?
 sure, tho i doubt anyone will listen ;)

Bug#1003923: soundkonverter: reproducible-builds: BuildId differences triggered by RPATH

[James Addison]

Followup-For: Bug #1003923
Control: forwarded -1 
https://salsa.debian.org/qt-kde-team/extras/soundkonverter/-/merge_requests/2

Dear Maintainer,

Please find a Debian Salsa merge request, added by this message as the
forwarded URL for this bug, that applies the patch from this bugreport and
confirms that it reduces buildpath variance for soundkonverter.

Two commits in the merge request are particularly relevant:

  * 099c4dcc4d038727e57b380e219d5512059a9615 - enables build-path variance
testing, _without_ the patch applied; the 'reprotest' pipeline fails.

  * c5d0d82ff446333768b201e729773064c5fe33de - after a few false starts,
correctly applies the patch; the 'reprotest' pipeline succeeds.

The other commits included in the merge request are me gradually and sometimes
mistakenly working towards those checkpoints.

Thank you,
James

Bug#1066033: RFS: galvani/0.34-1 [ITP] -- reads data from a device with graphical plots and evaluation

[Jeremy Sowden]

On 2024-03-27, at 10:48:45 +0100, Dr. Burkard Lutz wrote:
> Am Dienstag, dem 26.03.2024 um 17:03 + schrieb Jeremy Sowden:
> > [...]
> > 
> > The following should suffice:
> > 
> >   export DH_VERBOSE = 1
> >   export DEB_BUILD_MAINT_OPTIONS = hardening=+all
> >   export DEB_LDFLAGS_MAINT_APPEND = -lstdc++fs
> > 
> >   %:
> >   dh $@ --with autoreconf
> > 
> 
> So, this is exactly what I had initially.
> 
> > Running the build one can see:
> > 
> >   g++ [...] -D_FORTIFY_SOURCE=2 [...]
> > 
> > so the right argument is being passed to the compiler. 
> >  There is a list
> > of the functions that are fortified here:
> > 
> >  
> > https://www.gnu.org/software/libc/manual/html_node/Source-Fortification.html
> > 
> > Does the software use any of these?  If not, this is a false
> > positive.
> > 
> > J.
> 
> Galvani only uses "open" for file operations and "read" to read from
> usb devices.
> 
> I'm a bit confused now. The output of "blhc galvani_0.34-1_amd64.build"
> is empty, but "hardening-check -vR /usr/bin/galvani" gives:
> 
> /usr/bin/galvani:
>  Position Independent Executable: yes
>  Stack protected: yes
>  Fortify Source functions: no, only unprotected functions found!
>   unprotected: read
>   unprotected: memcpy
>   unprotected: readlink
>   unprotected: vsnprintf
>   unprotected: memset
>   unprotected: memmove
>   unprotected: realpath
>   unprotected: getcwd
>  Read-only relocations: yes
>  Immediate binding: yes
>  Stack clash protection: unknown, no -fstack-clash-protection
> instructions found
>  Control flow integrity: no, not found!
> --
> followed by a long list.

I've take a closer look and I don't think you have anything to worry
about.  Lintian's complaint relates to five unfortified function symbols
in the galvani binary:

getcwd
read
vsnprintf
realpath
readlink

hardening-check(1) lists an additional three.  Of the eight, the galvani
source itself only includes one of them: read(2).  The other are
presumably being pulled in via inline functions or templates from header
files or similar mechanisms.  Furthermore, the hardening-check(1) man-
page explains that:

When an executable was built such that the fortified versions of the
glibc functions are not useful (e.g. use is verified as safe at
compile time, or use cannot be verified at runtime), this check will
lead to false alarms.

There is one read(2) call (in mess.cxx):

std::string Multimeter::readfrom_dmm ()
{
std::string mwert, extra_str;
std::string error_str;
char buffer[1024];
std::string poll;

if (scpi) 
{
dmm_polling = true;
poll = "MEAS?"; 
}
else poll = "D";

if (usb)
{
if (dmm_polling) writeto_dmm (poll);
int result = read(usb_port, buffer, 1024);

and it is straightforward for the compiler to verify that it will not
overrun the buffer.

I believe your original rules file was fine.  The correct hardening
flags were being passed.  The fact that there were unfortified function
symbols in the resulting binary was down to the tool-chain and not
anything you were doing wrong.

J.


signature.asc
Description: PGP signature

Bug#1064128: Reopen - not fixed upstream

[Kyle Robbertze]

reopen -1
found -1
forwarded -1 https://github.com/savonet/liquidsoap/issues/3750
thanks

So it looks like the fix was reverted upstream before 2.2.4 was 
released. This has not been fixed...


--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄ https://wiki.debian.org/KyleRobbertze

Bug#1066718: ctn: diff for NMU version 3.2.0~dfsg-7.1

[Andrey Rakhmatullin]

Control: tags 1066718 + patch
Control: tags 1066718 + pending

Dear maintainer,

I've prepared an NMU for ctn (versioned as 3.2.0~dfsg-7.1) and
uploaded it to unstable.

Regards.


-- 
WBR, wRAR
diff -Nru ctn-3.2.0~dfsg/debian/changelog ctn-3.2.0~dfsg/debian/changelog
--- ctn-3.2.0~dfsg/debian/changelog	2020-11-16 17:45:24.0 +0500
+++ ctn-3.2.0~dfsg/debian/changelog	2024-03-27 23:50:34.0 +0500
@@ -1,3 +1,10 @@
+ctn (3.2.0~dfsg-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with -Werror=implicit-function-declaration (Closes: #1066718).
+
+ -- Andrey Rakhmatullin   Wed, 27 Mar 2024 23:50:34 +0500
+
 ctn (3.2.0~dfsg-7) unstable; urgency=medium
 
   [ Jelmer Vernooij ]
diff -Nru ctn-3.2.0~dfsg/debian/patches/fix-implicit-function-declaration.patch ctn-3.2.0~dfsg/debian/patches/fix-implicit-function-declaration.patch
--- ctn-3.2.0~dfsg/debian/patches/fix-implicit-function-declaration.patch	1970-01-01 05:00:00.0 +0500
+++ ctn-3.2.0~dfsg/debian/patches/fix-implicit-function-declaration.patch	2024-03-27 23:50:34.0 +0500
@@ -0,0 +1,727 @@
+Description: Add missing header includes.
+Author: Andrey Rakhmatullin 
+Bug-Debian: https://bugs.debian.org/1066718
+Last-Update: 2024-03-27
+
+Index: ctn-3.2.0~dfsg/facilities/manage/control.c
+===
+--- ctn-3.2.0~dfsg.orig/facilities/manage/control.c
 ctn-3.2.0~dfsg/facilities/manage/control.c
+@@ -64,6 +64,8 @@ static char rcsid[] = "$Revision: 1.32 $
+ #include 
+ #include 
+ #include 
++#include 
++#include 
+ #ifdef _MSC_VER
+ #include 
+ #include 
+@@ -78,6 +80,7 @@ static char rcsid[] = "$Revision: 1.32 $
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #endif
+ 
+Index: ctn-3.2.0~dfsg/facilities/database/database.c
+===
+--- ctn-3.2.0~dfsg.orig/facilities/database/database.c
 ctn-3.2.0~dfsg/facilities/database/database.c
+@@ -83,6 +83,8 @@
+ /*lint +e652 */
+ #include 
+ #include 
++#include 
++#include 
+ #include "dicom.h"
+ #include "condition.h"
+ #include "hunk_man.h"
+Index: ctn-3.2.0~dfsg/facilities/objects/dcm.c
+===
+--- ctn-3.2.0~dfsg.orig/facilities/objects/dcm.c
 ctn-3.2.0~dfsg/facilities/objects/dcm.c
+@@ -96,6 +96,10 @@
+ static char rcsid[] = "$Revision: 1.170 $ $RCSfile: dcm.c,v $";
+ 
+ 
++#define _XOPEN_SOURCE
++#include 
++#include 
++
+ #include "ctn_os.h"
+ 
+ #include "dicom.h"
+Index: ctn-3.2.0~dfsg/facilities/fis/fisinsert.c
+===
+--- ctn-3.2.0~dfsg.orig/facilities/fis/fisinsert.c
 ctn-3.2.0~dfsg/facilities/fis/fisinsert.c
+@@ -50,6 +50,7 @@ static char rcsid[] = "$Revision: 1.11 $
+ 
+ #include 
+ #include 
++#include 
+ 
+ #include "dicom.h"
+ #include "condition.h"
+Index: ctn-3.2.0~dfsg/facilities/gq/gq.c
+===
+--- ctn-3.2.0~dfsg.orig/facilities/gq/gq.c
 ctn-3.2.0~dfsg/facilities/gq/gq.c
+@@ -56,6 +56,7 @@ static char rcsid[] = "$Revision: 1.20 $
+ #include	
+ #include	
+ #include	
++#include	
+ 
+ #if defined(SHARED_MEMORY) && defined(SEMAPHORE)
+ #include	
+Index: ctn-3.2.0~dfsg/facilities/hap/hapbuildinterp.c
+===
+--- ctn-3.2.0~dfsg.orig/facilities/hap/hapbuildinterp.c
 ctn-3.2.0~dfsg/facilities/hap/hapbuildinterp.c
+@@ -62,6 +62,7 @@ static char rcsid[] = "$Revision: 1.13 $
+ #include "hap.h"
+ #include "dicom_sq.h"
+ #include "dicom_uids.h"
++#include "condition.h"
+ 
+ #define HAP_X_VARIABLE_EVENT	HAP_I_VARIABLE_EVENT
+ 
+Index: ctn-3.2.0~dfsg/facilities/hap/hapbuildpatient.c
+===
+--- ctn-3.2.0~dfsg.orig/facilities/hap/hapbuildpatient.c
 ctn-3.2.0~dfsg/facilities/hap/hapbuildpatient.c
+@@ -61,6 +61,7 @@ static char rcsid[] = "$Revision: 1.16 $
+ #include "hap.h"
+ #include "dicom_sq.h"
+ #include "dicom_uids.h"
++#include "condition.h"
+ 
+ #define HAP_X_VARIABLE_EVENT	HAP_P_VARIABLE_EVENT
+ 
+Index: ctn-3.2.0~dfsg/facilities/hap/hapbuildresults.c
+===
+--- ctn-3.2.0~dfsg.orig/facilities/hap/hapbuildresults.c
 ctn-3.2.0~dfsg/facilities/hap/hapbuildresults.c
+@@ -61,6 +61,7 @@ static char rcsid[] = "$Revision: 1.7 $
+ #include "hap.h"
+ #include "dicom_sq.h"
+ #include "dicom_uids.h"
++#include "condition.h"
+ 
+ #define HAP_X_VARIABLE_EVENT	HAP_R_VARIABLE_EVENT
+ 
+Index: ctn-3.2.0~dfsg/facilities/hap/hapbuildstudy.c
+===
+--- ctn-3.2.0~dfsg.orig/facilities/hap/hapbuildstudy.c
 ctn-3.2.0~dfsg/facilities/hap/hapbuildstudy.c
+@@ -61,6 +61,7 @@ static char rcsid[] = "$Revision: 1.18 $
+ #include "hap.h"
+ #include "dicom_uids.h"
+ #include "dicom_sq.h"
++#include 

Bug#1066203: recode: FTBFS: error.c:197:43: error: implicit declaration of function ‘strcmp’ [-Werror=implicit-function-declaration]

[Reuben Thomas]

On Wed, 27 Mar 2024 at 20:25, Santiago Vila  wrote:

>
> When I had already a bunch of them, I realized there is a macro
> STDC_HEADERS which is not properly detected.


Ah, I suspect the configure code is too old. Regenerating configure etc.
(autoreconf) might help.

-#if STDC_HEADERS
> +#if STDC_HEADERS || 1
>

But this is a good test to see if you've identified the problem.

-- 
https://rrt.sc3d.org

Bug#1066203: recode: FTBFS: error.c:197:43: error: implicit declaration of function ‘strcmp’ [-Werror=implicit-function-declaration]

[Santiago Vila]

I saw this go past, and it seemed that the solution was indeed just to #include 
; are you saying it's more complicated than that?


It depends on how much good we want the fix to be.

I started to add such includes every time the C compiler suggested it.

When I had already a bunch of them, I realized there is a macro
STDC_HEADERS which is not properly detected. That seems the proper solution.

So, I tried to override such variable but didn't find the way.

Now my current idea is to change the code in this way wherever needed:

-#if STDC_HEADERS
+#if STDC_HEADERS || 1

Will tell you how it goes. That would be the easy fix.

For a more proper fix, I'd like to know why STDC_HEADERS is not properly 
detected,
but I don't know enough autoconf to debug that.

Thanks.

Bug#1067821: bookworm-pu: package nvidia-graphics-drivers/535.161.08-1~deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2024-03-27 at 09:51 +0100, Andreas Beckmann wrote:
> In order to receive further upstream support (i.e. CVE fixes), we
> need
> to switch src:nvidia-graphics-drivers from the 525 series (EoL
> 12/2023)
> to the 535 series, a new LTSB branch sufficient for the lifetime of
> bookworm. (The first 535 beta appeared during deep freeze of
> bookworm.)
> This driver supports a superset of the GPUs supported by the 525
> drivers, no GPUs have been dropped.
> 
[...]
>   I'm currently doing interoperability tests with
>   src:nvidia-open-gpu-kernel-modules. (These two source packages
>   need to be updated together due to the strict firmware
>   dependency.) An upload to bookworm will only happen after the
>   package is in sid.

Please go ahead, bearing in mind that the window for 12.6 closes over
the coming weekend.

Regards,

Adam

Bug#1067843: bookworm-pu: package nvidia-open-gpu-kernel-modules/535.161.08-1~deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2024-03-27 at 14:43 +0100, Andreas Beckmann wrote:
> We need to update src:nvidia-open-gpu-kernel-modules to a new
> upstream
> version to stay in sync with src:nvidia-graphics-drivers (for a
> matching
> firmware-nvidia-gsp upstream version) and to fix some CVEs.
[...]
>   [ ] the issue is verified as fixed in unstable
>   I'm currently doing interoperability tests with
>   src:nvidia-graphics-drivers. (These two source packages
>   need to be updated together due to the strict firmware
>   dependency.) An upload to bookworm will only happen after the
>   package is in sid.

Please go ahead, bearing in mind that the window for 12.6 closes over
the coming weekend.

Regards,

Adam

Bug#1067854: elpa-magit: emacs-pgtk 29.2+1-2 emits deprecation warnings when using magit

[Xiyue Deng]

Daniel Kahn Gillmor  writes:

> Package: elpa-magit
> Version: 3.3.0-3
> Severity: normal
> X-Debbugs-Cc: d...@fifthhorseman.net
>
> Dear Maintainer,
>
> I'm using emacs-pgtk 29.2+1-2, with magit.
>
> I opened a revision controlled file in magit, and got the following
> warnings in my *Messages* buffer:
>
> ⛔ Warning (comp): magit-utils.el:571:33: Warning: ‘crm-default-separator’ is 
> an obsolete variable (as of 29.1); use ‘crm-separator’ instead.
> ⛔ Warning (comp): magit-section.el:369:8: Warning: the function ‘linum-mode’ 
> is not known to be defined.
> ⛔ Warning (comp): magit-git.el:257:2: Warning: custom-declare-variable 
> `magit-list-refs-sortby' docstring has wrong usage of unescaped single quotes 
> (use \= or different quoting)
> ⛔ Warning (comp): magit-process.el:803:2: Warning: docstring has wrong usage 
> of unescaped single quotes (use \= or different quoting)
> ⛔ Warning (comp): git-commit.el:741:25: Warning: ‘point-at-bol’ is an 
> obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ 
> instead.
> ⛔ Warning (comp): magit-log.el:456:12: Warning: the function 
> ‘magit--any-wip-mode-enabled-p’ is not known to be defined.
> ⛔ Warning (comp): magit-status.el:312:2: Warning: docstring has wrong usage 
> of unescaped single quotes (use \= or different quoting)
>
> It would be great if magit didn't produce warnings unless there was an
> actual warning i should be paying attention to.
>
>--dkg
>

It would be good that upstream will take care of them, which should
happen over time.

Meanwhile, this should happen only once when the source files are native
compiled the first time.  You may also wish to set
`native-comp-async-report-warnings-errors' to `nil' or `silent' to
suppress the popups if you'd like.

-- 
Xiyue Deng

Bug#1066365: timidity: diff for NMU version 2.14.0-8.2

[Andrey Rakhmatullin]

Control: tags 1066365 + patch
Control: tags 1066365 + pending

Dear maintainer,

I've prepared an NMU for timidity (versioned as 2.14.0-8.2) and
uploaded it to unstable.

Regards.


-- 
WBR, wRAR
diff -Nru timidity-2.14.0/debian/changelog timidity-2.14.0/debian/changelog
--- timidity-2.14.0/debian/changelog	2023-04-07 23:22:10.0 +0500
+++ timidity-2.14.0/debian/changelog	2024-03-27 23:21:21.0 +0500
@@ -1,3 +1,10 @@
+timidity (2.14.0-8.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with -Werror=implicit-function-declaration (Closes: #1066365).
+
+ -- Andrey Rakhmatullin   Wed, 27 Mar 2024 23:21:21 +0500
+
 timidity (2.14.0-8.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru timidity-2.14.0/debian/patches/fix-implicit-function-declaration.patch timidity-2.14.0/debian/patches/fix-implicit-function-declaration.patch
--- timidity-2.14.0/debian/patches/fix-implicit-function-declaration.patch	1970-01-01 05:00:00.0 +0500
+++ timidity-2.14.0/debian/patches/fix-implicit-function-declaration.patch	2024-03-27 23:21:21.0 +0500
@@ -0,0 +1,30 @@
+Description: Add missing header includes, don't call a non-existent function.
+Author: Andrey Rakhmatullin 
+Bug-Debian: https://bugs.debian.org/1066365
+Last-Update: 2024-03-27
+
+Index: timidity-2.14.0/interface/xaw_i.c
+===
+--- timidity-2.14.0.orig/interface/xaw_i.c
 timidity-2.14.0/interface/xaw_i.c
+@@ -57,6 +57,7 @@
+ #include "arc.h"
+ 
+ #include 
++#include 
+ #include 
+ #include 
+ 
+Index: timidity-2.14.0/interface/xskin_c.c
+===
+--- timidity-2.14.0.orig/interface/xskin_c.c
 timidity-2.14.0/interface/xskin_c.c
+@@ -547,7 +547,7 @@ static void ctl_event(CtlEvent *e)
+ case CTLE_LYRIC:
+   ctl_lyric((int)e->v1);
+   break;
+-#ifdef SUPPORT_SOUNDSPEC
++#if 0
+ case CTLE_SPEANA:
+   ctl_speana_data((double *)e->v1, (int)e->v2);
+ break;
diff -Nru timidity-2.14.0/debian/patches/series timidity-2.14.0/debian/patches/series
--- timidity-2.14.0/debian/patches/series	2023-04-07 23:22:10.0 +0500
+++ timidity-2.14.0/debian/patches/series	2024-03-27 23:21:21.0 +0500
@@ -13,3 +13,4 @@
 0013-readmidi-Fix-division-by-zero.patch
 0014-resample-Fix-out-of-bound-access-in-resamplers.patch
 0015-timidity-no_date.patch
+fix-implicit-function-declaration.patch


signature.asc
Description: PGP signature

Bug#1067860: dh-debputy: conffiles are not registered

[Sven Joachim]

Package: dh-debputy
Version: 0.1.22
Severity: important

Retrying xterm with dh-debputy (see
https://salsa.debian.org/joachim-guest/xterm/-/tree/debputy?ref_type=heads)
I noticed that no conffiles are registered, although xterm ships various
files in /etc:

,
| $ debdiff /var/cache/apt/archives/xterm_390-1+b1_amd64.deb 
xterm_390-1+debputy1_amd64.deb
| [The following lists of changes regard files as different if they have
| different names, permissions or owners.]
|
| Files in first .deb but not in second
| -
| -rw-r--r--  root/root   /usr/share/doc/xterm/changelog.Debian.amd64.gz
| -rw-r--r--  root/root   DEBIAN/conffiles
|
| Control files: lines which differ (wdiff format)
| 
| Installed-Size: [-2452-] {+2450+}
| [-Source: xterm (390-1)-]
| Version: [-390-1+b1-] {+390-1+debputy1+}
`

This seems to have regressed since my previous attempt with debputy
0.1.9 (see #1057001).


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

Versions of packages dh-debputy depends on:
ii  debhelper 13.15.2
ii  man-db2.12.0-3+b1
ii  perl  5.38.2-3.2
ii  python3   3.11.8-1
ii  python3-colored   2.2.3-1
ii  python3-colorlog  6.8.2-1
ii  python3-debian0.1.49
ii  python3-ruamel.yaml   0.17.21-1
ii  strip-nondeterminism  1.13.1-1

Versions of packages dh-debputy recommends:
ii  python3-argcomplete  3.1.4-1

Versions of packages dh-debputy suggests:
ii  hunspell-en-us  1:2020.12.07-2
pn  python3-hunspell
pn  python3-lsprotocol  
pn  python3-pygls   

-- no debconf information

Bug#1067859: RFS: python-redmine/2.4.0-2 -- Python library for the Redmine RESTful API (Python 3)

[Akash Doppalapudi]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-redmine":

 * Package name : python-redmine
   Version  : 2.4.0-2
   Upstream contact : Max Tepkeev 
 * URL  : https://github.com/maxtepkeev/python-redmine
 * License  : Apache-2.0
 * Vcs  : https://salsa.debian.org/debian/python-redmine
   Section  : python

The source builds the following binary packages:

  python3-redminelib - Python library for the Redmine RESTful API 
(Python 3)


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


  https://mentors.debian.net/package/python-redmine/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-redmine/python-redmine_2.4.0-2.dsc


Changes since the last upload:

 python-redmine (2.4.0-2) unstable; urgency=medium
 .
   * d/control:
 - Replace Build-Depends: python3-nose with python3-pytest (Closes: 
#1018572)

 - Replace Build-Depends: python3-cov with python3-pytest-cov
 - Add Testsuite: autopkgtest-pkg-pybuild
   * Remove d/tests/control and use autopkgtest-pkg-pybuild instead

Regards,
--
  Akash Doppalapudi


OpenPGP_0xBCBCAE31ECE05007.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#987227: php-defaults: Consider changing php sapi dependency order

[Joe Cooper]

Is there some way to get some movement on making this change?

mod_php has been discouraged for well over a decade by the PHP project
developers. It has security implications (applications run as www-data
instead of a less privileged user), it has a performance and memory-usage
cost, and increased attack surface, even if the user isn't using it to run
PHP applications (it is loaded by default by configuration in
/etc/apache2/mods-enabled/php8.2.load when installed). There's no reason to
ever prefer mod_php, so the default here is guiding users in a bad
direction on multiple fronts (security, performance, and memory usage).

Installing mod_php also prevents configuring http2 in Apache, because it
depends on mpm_prefork.

Upstream recommends FPM and strongly discourages mod_php, so the package
should prefer FPM. Merely changing the order of dependencies to put fpm
first, would resolve this problem.

Is there anything blocking this change, or has it just not gotten the
attention of the right folks?

On Mon, 19 Apr 2021 15:43:32 -0600 Jesse Rhodes  wrote:
> Source: php-defaults
> Severity: wishlist
> X-Debbugs-Cc: je...@sney.ca
>
> Dear Maintainer,
>
> The top-level versioned php metapackage (php7.4 at the time of writing)
has the following Depends field:
>
> Depends: libapache2-mod-php7.4 | php7.4-fpm | php7.4-cgi, php7.4-common
>
> Thus, a user who runs 'apt install php' will get libapache2-mod-php7.4,
along with apache2 itself.
>
> Apache upstream considers prefork to be specific to "sites requiring
stability or compatibility with older software"[1]. And in the modern era,
best practices for hosting websites with dynamic content include using
either a threaded MPM in apache, or a different httpd such as nginx.
>
> Because of this, it seems that libapache2-mod-php is no longer a sane
default when installing php. It makes sense to keep it available, both for
the legacy reasons cited above and for environments like a low traffic
application that requires apache features, but it should not be the first
choice of sapi to install.
>
> Please consider making this change.
>
> Thanks,
>
> Jesse (sney)
>
> [1] https://httpd.apache.org/docs/2.4/en/mpm.html
>
> -- System Information:
> Debian Release: bullseye/sid
> APT prefers testing
> APT policy: (990, 'testing'), (500, 'testing-security'), (500,
'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
>

Bug#1067858: reset SuperSpeed USB device number 2 using xhci_hcd

[Pierre Tomon]

Source: linux-signed-amd64
Version: 6.7.9+2
Severity: normal
X-Debbugs-CC: pierretom...@ik.me

Dear Maintainer,

Since kernel 6.7.7-1 to 6.7.9+2 (amd64), I got this message when turning on the 
external drive.
The device is accessible after about 1 minute, then I can mount it and access 
data.
Does not happen on kernel 6.6.15+2 and prior versions.

SATA/USB controller: Bus 006 Device 003: ID 174c:5106 ASMedia Technology Inc. 
ASM1051 SATA 3Gb/s bridge
SATA controler: ASMedia Technology Inc. ASM1061/ASM1062 Serial ATA Controller 
(rev 01)

# dmesg
[   89.821220] usb 6-1: new SuperSpeed USB device number 2 using xhci_hcd
[   98.669813] usb 6-1: New USB device found, idVendor=174c, idProduct=5106, 
bcdDevice= 0.01
[   98.669829] usb 6-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[   98.669836] usb 6-1: Product: AS2105
[   98.669842] usb 6-1: Manufacturer: ASMedia
[   98.669847] usb 6-1: SerialNumber: 
[   98.702925] usb-storage 6-1:1.0: USB Mass Storage device detected
[   98.703186] scsi host10: usb-storage 6-1:1.0
[   98.703323] usbcore: registered new interface driver usb-storage
[   98.712000] usbcore: registered new interface driver uas
[   99.729263] scsi 10:0:0:0: Direct-Access ST3000DM 001-1CH166   CC29 
PQ: 0 ANSI: 0
[   99.729842] sd 10:0:0:0: Attached scsi generic sg3 type 0
[   99.730034] sd 10:0:0:0: [sdc] Very big device. Trying to use READ 
CAPACITY(16).
[  130.381128] usb 6-1: reset SuperSpeed USB device number 2 using xhci_hcd
[  130.401814] sd 10:0:0:0: [sdc] 5860533168 512-byte logical blocks: (3.00 
TB/2.73 TiB)
[  130.402173] sd 10:0:0:0: [sdc] Write Protect is off
[  130.402181] sd 10:0:0:0: [sdc] Mode Sense: 23 00 00 00
[  130.402486] sd 10:0:0:0: [sdc] No Caching mode page found
[  130.402493] sd 10:0:0:0: [sdc] Assuming drive cache: write through
[  130.403339] sd 10:0:0:0: [sdc] Very big device. Trying to use READ 
CAPACITY(16).
[  161.100747] usb 6-1: reset SuperSpeed USB device number 2 using xhci_hcd
[  161.395030]  sdc: sdc1 sdc2
[  161.395511] sd 10:0:0:0: [sdc] Attached SCSI disk

Bug#1067857: cross-toolchain-base: linux-libc-dev is not installed automatic

[YunQiang Su]

Package: cross-toolchain-base

We does state that libc6-dev-arm64-cross depends on
linux-libc-dev-arm64-cross, while

  apt install libc6-dev-arm64-cross

won't install linux-libc-dev-arm64-cross automatically.

Any ideas?

-- 
YunQiang Su

Bug#1067856: nmu: castxml_0.6.3-1

[Andrey Rakhmatullin]

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

nmu castxml_0.6.3-1 . amd64 arm64 armel armhf i386 ppc64el riscv64 s390x .
unstable . -m "Rebuild for time_t"

All but mips64el. https://packages.debian.org/sid/castxml

Looking at https://release.debian.org/transitions/html/auto-llvm-
toolchain-17.html there may be other leftovers but I haven't looked at them
individually.

Bug#1067855: seahorse: Segfault when uploading keys to keyserver

[Julian Groß]

Package: seahorse
Version: 43.0-1
Severity: normal

Dear Maintainer,

trying to upload keys to a keyserver via Seahorse causes a segmentation fault. 
The upload itself appears to succeed, as the keys end up on the keyserver 
anyway.

Here is the relevant backtrace:
```backtrace
#0  0x555d0d75 in on_export_message_complete (object=, 
result=0x55c03620, user_data=) at 
../pgp/seahorse-hkp-source.c:796
#1  0x77cb0ee3 in g_task_return_now (task=task@entry=0x55c03620 
[GTask]) at ../../../gio/gtask.c:1371
#2  0x77cb1b83 in g_task_return (type=, 
task=0x55c03620 [GTask]) at ../../../gio/gtask.c:1440
#3  g_task_return (task=0x55c03620 [GTask], type=) at 
../../../gio/gtask.c:1397
#4  0x76f9b23a in send_and_read_splice_ready_cb (session=0x55c11f90 
[SoupSession], result=0x55c3aa70, task=0x55c03620 [GTask]) at 
../libsoup/soup-session.c:3290
#5  0x77cb0ee3 in g_task_return_now (task=task@entry=0x55c3aa70 
[GTask]) at ../../../gio/gtask.c:1371
#6  0x77cb1b83 in g_task_return (type=, 
task=0x55c3aa70 [GTask]) at ../../../gio/gtask.c:1440
#7  g_task_return (task=0x55c3aa70 [GTask], type=) at 
../../../gio/gtask.c:1397
#8  0x76f9587d in send_and_splice_ready_cb (ostream=, 
result=, task=0x55c3aa70 [GTask]) at 
../libsoup/soup-session.c:3432
#9  0x77cb0ee3 in g_task_return_now (task=task@entry=0x55fa1070 
[GTask]) at ../../../gio/gtask.c:1371
#10 0x77cb1b83 in g_task_return (type=, 
task=0x55fa1070 [GTask]) at ../../../gio/gtask.c:1440
#11 g_task_return (task=0x55fa1070 [GTask], type=) at 
../../../gio/gtask.c:1397
#12 0x77c9145b in async_ready_splice_callback_wrapper 
(source_object=0x55bf94e0 [GMemoryOutputStream], res=0x55fad8a0, 
_data=0x55fa1070) at ../../../gio/goutputstream.c:1719
#13 0x77cb0ee3 in g_task_return_now (task=task@entry=0x55fad8a0 
[GTask]) at ../../../gio/gtask.c:1371
#14 0x77cb1b83 in g_task_return (type=, 
task=0x55fad8a0 [GTask]) at ../../../gio/gtask.c:1440
#15 g_task_return (task=0x55fad8a0 [GTask], type=) at 
../../../gio/gtask.c:1397
#16 0x77c8dacc in real_splice_async_complete_cb (task=0x55fad8a0 
[GTask]) at ../../../gio/goutputstream.c:2694
#17 0x77cb0ee3 in g_task_return_now (task=task@entry=0x5596db90 
[GTask]) at ../../../gio/gtask.c:1371
#18 0x77cb1b83 in g_task_return (type=, 
task=0x5596db90 [GTask]) at ../../../gio/gtask.c:1440
#19 g_task_return (task=0x5596db90 [GTask], type=) at 
../../../gio/gtask.c:1397
#20 0x77c8da44 in async_ready_close_callback_wrapper 
(source_object=0x55bf94e0 [GMemoryOutputStream], res=0x55927a30, 
user_data=0x5596db90) at ../../../gio/goutputstream.c:1950
#21 0x77cb0ee3 in g_task_return_now (task=task@entry=0x55927a30 
[GTask]) at ../../../gio/gtask.c:1371
#22 0x77cb0f1d in complete_in_idle_cb (task=0x55927a30) at 
../../../gio/gtask.c:1385
#23 0x77ea00d9 in g_main_dispatch 
(context=context@entry=0x5569af00) at ../../../glib/gmain.c:3476
#24 0x77ea3317 in g_main_context_dispatch_unlocked 
(context=0x5569af00) at ../../../glib/gmain.c:4284
#25 g_main_context_iterate_unlocked (context=context@entry=0x5569af00, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/gmain.c:4349
#26 0x77ea3930 in g_main_context_iteration 
(context=context@entry=0x5569af00, may_block=may_block@entry=1) at 
../../../glib/gmain.c:4414
#27 0x77ce0b7d in g_application_run 
(application=application@entry=0x55696060 [SeahorseApplication], 
argc=argc@entry=1, argv=argv@entry=0x7fffdf48) at 
../../../gio/gapplication.c:2577
#28 0x5558169b in _vala_main (args_length1=1, args=0x7fffdf48) at 
src/seahorse.p/main.c:76
#29 main (argc=1, argv=0x7fffdf48) at src/seahorse.p/main.c:87
```

Greetings
Julian Groß

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

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

Versions of packages seahorse depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b1
ii  gcr  3.41.2-1
ii  gnome-keyring42.1-1+b2
ii  gnupg2.2.40-1.1
ii  libc62.37-15
ii  libgck-1-0   3.41.2-1
ii  libgcr-base-3-1  3.41.2-1
ii  libgcr-ui-3-13.41.2-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  

Bug#1067854: elpa-magit: emacs-pgtk 29.2+1-2 emits deprecation warnings when using magit

[Daniel Kahn Gillmor]

Package: elpa-magit
Version: 3.3.0-3
Severity: normal
X-Debbugs-Cc: d...@fifthhorseman.net

Dear Maintainer,

I'm using emacs-pgtk 29.2+1-2, with magit.

I opened a revision controlled file in magit, and got the following
warnings in my *Messages* buffer:

⛔ Warning (comp): magit-utils.el:571:33: Warning: ‘crm-default-separator’ is an 
obsolete variable (as of 29.1); use ‘crm-separator’ instead.
⛔ Warning (comp): magit-section.el:369:8: Warning: the function ‘linum-mode’ is 
not known to be defined.
⛔ Warning (comp): magit-git.el:257:2: Warning: custom-declare-variable 
`magit-list-refs-sortby' docstring has wrong usage of unescaped single quotes 
(use \= or different quoting)
⛔ Warning (comp): magit-process.el:803:2: Warning: docstring has wrong usage of 
unescaped single quotes (use \= or different quoting)
⛔ Warning (comp): git-commit.el:741:25: Warning: ‘point-at-bol’ is an obsolete 
function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead.
⛔ Warning (comp): magit-log.el:456:12: Warning: the function 
‘magit--any-wip-mode-enabled-p’ is not known to be defined.
⛔ Warning (comp): magit-status.el:312:2: Warning: docstring has wrong usage of 
unescaped single quotes (use \= or different quoting)

It would be great if magit didn't produce warnings unless there was an
actual warning i should be paying attention to.

   --dkg

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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages elpa-magit depends on:
ii  dh-elpa-helper  2.0.17
ii  elpa-dash   2.19.1+git20220608.1.0ac1ecf+dfsg-1
ii  elpa-git-commit 3.3.0-3
ii  elpa-magit-section  3.3.0-3
ii  elpa-with-editor3.3.0-1
ii  emacsen-common  3.0.5
ii  git 1:2.43.0-1

elpa-magit recommends no packages.

elpa-magit suggests no packages.

-- no debconf information

Bug#1067853: kanshi(1) refers to kanshictl(1), but no kanshictl is not shipped (neither manpage or executable)

[Daniel Kahn Gillmor]

Package: kanshi
Version: 1.5.1-1
Severity: minor
X-Debbugs-Cc: d...@fifthhorseman.net

Dear Maintainer,

Reading the manual page for kanshi(1), i note that it has a SEE ALSO
reference to kanshictl(1).  no such manual page or binary is shipped.

Looking at the upstream source, it appears to only be built if meson
can find libvarlink, but maybe libvarlink isn't available in debian?

At any rate, it seems that the only thing kanshictl can do as of today
is to ask the kanshi daemon to reload, which presumably can be done
other ways too.  So this probably isn't such a big deal.  I haven't
tried to get kanshictl to build, for what it's worth.

But if kanshictl is not going to ship in debian, then maybe the
reference should be removed from the kanshi(1) manpage as well, to
avoid other people having to chase down the same confusion i did.

Thanks for maintaining kanshi in debian!

  --dkg


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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kanshi depends on:
ii  libc6   2.37-15
ii  libwayland-client0  1.22.0-2.1+b1

kanshi recommends no packages.

kanshi suggests no packages.

-- no debconf information

Bug#1067852: nmu: gdal_3.8.4+dfsg-3

[Bas Couwenberg]

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

nmu gdal_3.8.4+dfsg-3 . ANY . unstable . -m "Rebuild with libfyba0t64"

gdal needs to be built with libfyba-dev (>= 4.1.1-11) to pick up the 
libfyba0t64 dependency correctly.

Bug#1067098: mpl-sphinx-theme: please make the build reproducible

[Andreas Tille]

Control: tags -1 pending
thanks

Hi Vagrant,

sorry about your work was lost.  I confirm the new upstream
version in Git contains the patch.  Unfortunately it needs
new dependencies.  If it might help you I could upload your
NMU again.

Kind regards
Andreas.


-- 
https://fam-tille.de

Bug#1066045: maven-bundle-plugin: produces nondeterministic ordering in MANIFEST.MF headers

[James Addison]

Followup-For: Bug #1066045
Control: forwarded -1 
https://salsa.debian.org/java-team/maven-bundle-plugin/-/merge_requests/1
Control: tags -1 pending

This change has recently been uploaded to DELAYED/15 by Mattia from the
Reproducible Builds team after I requested that; in addition I'm providing the
same change as a merge request on Salsa (adding this as the forwarded-to URL
for reference, although in this case the change itself is a backport from
upstream).

Bug#1066045: maven-bundle-plugin: diff for NMU version 3.5.1-2.1

[Mattia Rizzolo]

Control: tags 1066045 + pending


Dear maintainer,

I've prepared an NMU for maven-bundle-plugin (versioned as 3.5.1-2.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
diffstat for maven-bundle-plugin-3.5.1 maven-bundle-plugin-3.5.1

 changelog  |9 ++
 patches/0002-FELIX-6602-sort-resources-and-exported-packages.patch |   33 ++
 patches/series |1 
 3 files changed, 43 insertions(+)

diff -Nru maven-bundle-plugin-3.5.1/debian/changelog maven-bundle-plugin-3.5.1/debian/changelog
--- maven-bundle-plugin-3.5.1/debian/changelog	2018-09-05 11:48:32.0 +0200
+++ maven-bundle-plugin-3.5.1/debian/changelog	2024-03-27 18:13:06.0 +0100
@@ -1,3 +1,12 @@
+maven-bundle-plugin (3.5.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch from upstream to fix nondeterministic ordering in MANIFEST.MF
+headers.  Closes: #1066045
+Thanks to James Addison  for bringing up the patch.
+
+ -- Mattia Rizzolo   Wed, 27 Mar 2024 18:13:06 +0100
+
 maven-bundle-plugin (3.5.1-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru maven-bundle-plugin-3.5.1/debian/patches/0002-FELIX-6602-sort-resources-and-exported-packages.patch maven-bundle-plugin-3.5.1/debian/patches/0002-FELIX-6602-sort-resources-and-exported-packages.patch
--- maven-bundle-plugin-3.5.1/debian/patches/0002-FELIX-6602-sort-resources-and-exported-packages.patch	1970-01-01 01:00:00.0 +0100
+++ maven-bundle-plugin-3.5.1/debian/patches/0002-FELIX-6602-sort-resources-and-exported-packages.patch	2024-03-27 18:11:20.0 +0100
@@ -0,0 +1,33 @@
+From d885d99a6a16660f655a4fd18e8a1a39beef0a15 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Herv=C3=A9=20Boutemy?= 
+Date: Sat, 25 Mar 2023 00:18:11 +0100
+Subject: [PATCH] FELIX-6602 sort resources and exported packages
+
+---
+ .../java/org/apache/felix/bundleplugin/BundlePlugin.java | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/src/main/java/org/apache/felix/bundleplugin/BundlePlugin.java
 b/src/main/java/org/apache/felix/bundleplugin/BundlePlugin.java
+@@ -1938,6 +1938,7 @@ public class BundlePlugin extends AbstractMojo
+ scanner.scan();
+ 
+ String[] paths = scanner.getIncludedFiles();
++Arrays.sort( paths );
+ for ( int i = 0; i < paths.length; i++ )
+ {
+ packages.put( analyzer.getPackageRef( getPackageName( paths[i] ) ) );
+@@ -2076,7 +2077,9 @@ public class BundlePlugin extends AbstractMojo
+ scanner.addDefaultExcludes();
+ scanner.scan();
+ 
+-List includedFiles = Arrays.asList( scanner.getIncludedFiles() );
++String[] f = scanner.getIncludedFiles();
++Arrays.sort( f );
++List includedFiles = Arrays.asList( f );
+ 
+ for ( Iterator j = includedFiles.iterator(); j.hasNext(); )
+ {
+-- 
+2.43.0
+
diff -Nru maven-bundle-plugin-3.5.1/debian/patches/series maven-bundle-plugin-3.5.1/debian/patches/series
--- maven-bundle-plugin-3.5.1/debian/patches/series	2018-07-30 14:16:51.0 +0200
+++ maven-bundle-plugin-3.5.1/debian/patches/series	2024-03-27 18:11:24.0 +0100
@@ -4,3 +4,4 @@
 maven-archiver3-869361.patch
 maven3-compatibility.patch
 0001-Port-to-current-maven-dependency-tree.patch
+0002-FELIX-6602-sort-resources-and-exported-packages.patch


signature.asc
Description: PGP signature

Bug#1066794: consider retrying git binnmus.

[Peter Green]

git failed to build when binnmu'd for the time64 transition and also
in lucas's test build a few days earlier. This was filed as bug 1066794.

Andrey Rakhmatullin responded to the bug report saying he was unable to
reproduce the failure. Michael Hudson replied with a post suggesting
that the failure may be related to libcgi-pm-perl, though he did not
make it clear which version of libcgi-pm-perl he was testing with.

Andrey noted that the version of libcgi-pm-perl in his local tests was
newer than the version used in the failed builds.

Ubuntu temporally disabled tests in git, but have since re-enabled
them, and the package built successfully on all Ubuntu architectures.

I would suggest therefore that it makes sense to retry the binnmus
as there is a good chance that whatever caused the issue has since
been fixed.

Bug#1067851: linux-image-6.1.0-18-amd64 fails to recognize the tpm2.0 on my x240

[Falk Hackenberger]

Package: src:linux
Version: 6.1.76-1
Severity: normal
X-Debbugs-Cc: deb...@spam.huckley.de

Dear Maintainer,

On a x240 where tpm is setup to TPM 2.0 through PTT the linux kernel do not
recognize
the tpm2.0 chip.

dmesg |grep -i tpm
[0.018294] ACPI: SSDT 0xDCED4000 0005D0 (v01 LENOVO Tpm2Tabl
1000 INTL 20120711)
[0.018302] ACPI: TPM2 0xDCED2000 34 (v03 LENOVO TP-GI
2490 PTEC 0002)
[0.018353] ACPI: Reserving TPM2 table memory at [mem 0xdced2000-0xdced2033]
[3.981911] tpm tpm0: Operation Timed out
[5.981909] tpm tpm0: Operation Timed out
[5.981922] tpm_crb: probe of MSFT0101:00 failed with error -62
[6.029335] ima: No TPM chip found, activating TPM-bypass!



-- Package-specific info:
** Version:
Linux version 6.1.0-18-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01)

** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-18-amd64 
root=UUID=83505fae-ef75-447f-a279-b403f727ca65 ro rootflags=subvol=@rootfs 
quiet rd.auto=1

** Not tainted

** Kernel log:
[   32.105588] RAPL PMU: API unit is 2^-32 Joules, 4 fixed counters, 655360 ms 
ovfl timer
[   32.105592] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[   32.105594] RAPL PMU: hw unit of domain package 2^-14 Joules
[   32.105596] RAPL PMU: hw unit of domain dram 2^-14 Joules
[   32.105597] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
[   32.153700] at24 9-0050: supply vcc not found, using dummy regulator
[   32.160631] at24 9-0050: 256 byte spd EEPROM, read-only
[   32.265001] usb 2-8: Found UVC 1.00 device Integrated Camera (5986:0268)
[   32.281755] snd_hda_intel :00:03.0: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   32.303103] iTCO_vendor_support: vendor-support=0
[   32.319396] input: Integrated Camera: Integrated C as 
/devices/pci:00/:00:14.0/usb2/2-8/2-8:1.0/input/input10
[   32.326719] usbcore: registered new interface driver uvcvideo
[   32.335812] iTCO_wdt iTCO_wdt.1.auto: Found a Lynx Point_LP TCO device 
(Version=2, TCOBASE=0x1860)
[   32.335932] iTCO_wdt iTCO_wdt.1.auto: initialized. heartbeat=30 sec 
(nowayout=0)
[   32.364483] input: HDA Intel HDMI HDMI/DP,pcm=3 as 
/devices/pci:00/:00:03.0/sound/card0/input11
[   32.364546] input: HDA Intel HDMI HDMI/DP,pcm=7 as 
/devices/pci:00/:00:03.0/sound/card0/input12
[   32.364600] input: HDA Intel HDMI HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.0/sound/card0/input13
[   32.386190] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3232: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   32.386199] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   32.386203] snd_hda_codec_realtek hdaudioC1D0:hp_outs=2 
(0x16/0x15/0x0/0x0/0x0)
[   32.386206] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0
[   32.386208] snd_hda_codec_realtek hdaudioC1D0:inputs:
[   32.386210] snd_hda_codec_realtek hdaudioC1D0:  Dock Mic=0x19
[   32.386213] snd_hda_codec_realtek hdaudioC1D0:  Mic=0x1a
[   32.386215] snd_hda_codec_realtek hdaudioC1D0:  Internal Mic=0x12
[   32.409373] e1000e :00:19.0 :00:19.0 (uninitialized): registered PHC 
clock
[   32.441799] intel_rapl_common: Found RAPL domain package
[   32.441806] intel_rapl_common: Found RAPL domain core
[   32.441808] intel_rapl_common: Found RAPL domain uncore
[   32.441809] intel_rapl_common: Found RAPL domain dram
[   32.475170] e1000e :00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 
28:d2:44:b0:2c:20
[   32.475177] e1000e :00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[   32.475219] e1000e :00:19.0 eth0: MAC: 11, PHY: 12, PBA No: 1000FF-0FF
[   32.480324] EXT4-fs (sda2): mounted filesystem with ordered data mode. Quota 
mode: none.
[   32.491030] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1b.0/sound/card1/input14
[   32.491106] input: HDA Intel PCH Dock Mic as 
/devices/pci:00/:00:1b.0/sound/card1/input15
[   32.500600] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1b.0/sound/card1/input16
[   32.500688] input: HDA Intel PCH Dock Headphone as 
/devices/pci:00/:00:1b.0/sound/card1/input17
[   32.500747] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1b.0/sound/card1/input18
[   32.526050] e1000e :00:19.0 enp0s25: renamed from eth0
[   32.579625] rtl8192ee: Using firmware rtlwifi/rtl8192eefw.bin
[   32.585520] Bluetooth: Core ver 2.22
[   32.585545] NET: Registered PF_BLUETOOTH protocol family
[   32.585546] Bluetooth: HCI device and connection manager initialized
[   32.585551] Bluetooth: HCI socket layer initialized
[   32.585553] Bluetooth: L2CAP socket layer initialized
[   32.585562] Bluetooth: SCO socket layer initialized
[   32.585699] rtl8192ee :03:00.0: firmware: direct-loading firmware 
rtlwifi/rtl8192eefw.bin
[   32.593913] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[   

Bug#1003922: recastnavigation: reproducible-builds: BuildId differences triggered by RPATH

[James Addison]

Followup-For: Bug #1003922
Control: tags -1 pending

Bug#1067850: src:kget: possible Salsa-CI reprotest misconfiguration.

[James Addison]

Source: kget
Severity: wishlist
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath

Dear Maintainer,

The Salsa CI configuration for kget sets customized[1] command-line options for
'reprotest'[2], a utility used to find package reproducibility problems.

Unfortunately, I think that the configured SALSA_CI_REPROTEST_ARGS arguments
may be incorrect; the provided arguments _appear_ intended to disable
build-path variance, but I believe that they unintentionally disable _all_
forms of reprotest variance testing.  Please refer to this Reproducible Builds
mailing list thread for more information:

  
https://lists.reproducible-builds.org/pipermail/rb-general/2024-February/003247.html


I'd recommend removing the SALSA_CI_REPROTEST_ARGS line entirely -- which
in isolation could cause Salsa-CI reprotest to fail, due to a build-path
bug reported in #1003914 -- but also then applying the patch from that
bugreport to confirm and solve the problem.

If that is undesirable, then as an alternative I could suggest configuring:

  SALSA_CI_REPROTEST_ARGS: '--variations=all,-build_path'

(please note that there are _two_ changes in this line; the insertion of 'all'
and adjustment of 'build-path' to 'build_path')

...to enable all forms of variation, with the exception of buildpath.

Thank you,
James

[1] - 
https://salsa.debian.org/qt-kde-team/kde/kget/-/blob/c3b261bd0d740cdd89c8d06e05eb238cb746fe3d/debian/salsa-ci.yml#L7

[2] - https://salsa.debian.org/reproducible-builds/reprotest

Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

[Wookey]

On 2024-03-27 15:27 +, Wookey wrote:
> On 2024-03-26 22:28 +, Thorsten Glaser wrote:
> 
> > I hacked that, and I tried to do armel and armhf as well but
> > dak stopped me, whereas mini-dak was not as strict.
> 
> What was the actual problem with uploading the images you built? Just
> not having any corresponding source? Or something more complicated?

Answering my own question: There have been a couple of new openjdk-17
uploads (latest is: 17_17.0.11~7ea-1) so Thorsten's bootstrap build 
(17.0.10+7-1) is out of
date.

But it does a great job of filling the self-dependency so I can build the 
current version.
So I now have all the pieces (on armhf, not checked armel yet but hopefully it 
matches)

Building now...


Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#1067849: util-linux: CVE-2024-28085: wall: escape sequence injection

[Salvatore Bonaccorso]

Source: util-linux
Version: 2.39.3-11
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2.38.1-5 
Control: found -1 2.36.1-8+deb11u1
Control: found -1 2.36.1-8
Control: found -1 2.33.1-0.1

Hi,

The following vulnerability was published for util-linux.

CVE-2024-28085[0]:
| escape sequence injection in wall


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-28085
https://www.cve.org/CVERecord?id=CVE-2024-28085
[1] https://www.openwall.com/lists/oss-security/2024/03/27/5
[2] https://people.rit.edu/sjf5462/6831711781/wall_2_27_2024.txt
[3] https://github.com/skyler-ferrante/CVE-2024-28085

Regards,
Salvatore

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

Kernel: Linux 6.1.0-18-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Bug#1067848: libmed-dev: Missing include file for the Fortran wrapping

[Sci Dev]

Package: libmed-dev
Version: 4.1.0+repack-3+b4
Severity: important
X-Debbugs-Cc: sci-...@hotmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation? I wanted to use the MED library to compile a 
Fortran software which relies on it.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? I built my Fortran program which contains a source file 
which includes "med.hf".
   * What was the outcome of this action? It failed because "med.hf" requires 
another file which is missing from the package, "med_parameter.hf".
   * What outcome did you expect instead? The missing include file, 
"med_parameter.hf", is available in MED sources and should be included in the 
Debian package.

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


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

Kernel: Linux 5.15.90.1-microsoft-standard-WSL2 (SMP w/16 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libmed-dev depends on:
pn  libmed11  

libmed-dev recommends no packages.

libmed-dev suggests no packages.

Bug#1067847: RFS: image-analyzer/3.2.6-1 [ITP] -- Mirage Image Analyzer

[Matteo Bini]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "image-analyzer":

 * Package name : image-analyzer
   Version  : 3.2.6-1
   Upstream contact : Rok Mandeljc 
 * URL  : https://cdemu.sourceforge.io/
 * License  : CC0-1.0, GPL-2+
   Section  : utils

The source builds the following binary packages:

  image-analyzer - Mirage Image Analyzer

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

  https://mentors.debian.net/package/image-analyzer/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/i/image-analyzer/image-analyzer_3.2.6-1.dsc

Changes for the initial release:

 image-analyzer (3.2.6-1) unstable; urgency=low
 .
   * Initial release, closes: #983454.

Regards,

-- 
Matteo Bini

Bug#1001870: meshlab: reproducible-builds: BuildId differences triggered by RPATH

[James Addison]

Source: meshlab
Followup-For: Bug #1001870
Control: tags -1 pending

Bug#1067760: libc6: Curious behavior of inet_pton() on IPv4 mapped numbers

[Alessandro Vesely]

On Tue 26/Mar/2024 20:14:27 +0100 Aurelien Jarno wrote:

On 2024-03-26 12:53, Alessandro Vesely wrote:

Package: libc6
Version: 2.36-9+deb12u4
Severity: normal
Tags: ipv6

Dear Maintainer,

I compiled the example program given in the  inet_pton(3) man page, and obtain
the following:

$ ./a.out i6 0:0:0::5:6:7:8
:::5:6:7:8
$ ./a.out i6 0:0:0::5.6.7.8
Not in presentation format
$ ./a.out i6 0:0:0:0:0::5.6.7.8
:::5.6.7.8


Could you please tell me what do you find curious and what do you expect
instead? Thanks.



Yeah, sorry about that.  I counted one word per tag, irrespective of it being 
hex or decimal.  So, for the last case I though heck, 10 tag is 160-bit.  I was 
so persuaded that, when Bastian told me the 8-word "0:0:0::5.6.7.8" is not 
valid I went to RFC 4291 and when I read there that the 10-tag IP 
0:0:0:0:0:0:13.1.68.3 is valid, I started filling an errata against it.  I 
copied the following passage with the idea of correcting it by removing a 
couple of "x"s.


   3. An alternative form that is sometimes more convenient when dealing
  with a mixed environment of IPv4 and IPv6 nodes is
  x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
  the six high-order 16-bit pieces of the address, and the 'd's are
  the decimal values of the four low-order 8-bit pieces of the
  address (standard IPv4 representation).

Only at that point I read the text carefully and realized how mistaken I was. 
I aborted the errata submission, of course.  But for the bug report, which I 
had already sent, I can only apologize.



Best
Ale

Bug#1067838: [Pkg-sssd-devel] Bug#1067838: Please provide a trivial working example

[Simon Josefsson]

Thanks -- alas I think this is the same as this one:

https://bugs.launchpad.net/ubuntu/+source/resolv-wrapper/+bug/2015570

Rebuild the binary package and installing it should make things work
again.  Could you try that?

I'm not sure how to express this dependency, it seems some behaviour of
glibc is changing that libresolv_wrapper depends on and rebuilding
libresolv_wrapper against the new libc make things work again.  If
someone can debug and come up with a patch, that would be appreciated.

/Simon

Christoph Biedl  writes:

> Package: libresolv-wrapper
> Version: 1.1.8-2+b1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
>
> Greetings,
>
> while looking for a way to overload hostname resolution as non-root
> (part of a test suite and/or autopkgtest), I came across your package.
> However, *nothing* works, not even in the stable releases.
>
> Assuming this is rather a "you're holding it wrong" than a grave bug in
> libresolv-wrapper, I guess usage is not as easy as it seems. So can
> you please provide an as-simple-as-possible example, in the tradition
> of "Hello, world"?
>
> It could be like
>
> echo "A server1.example.com 192.0.2.1" >/tmp/hosts
> LD_PRELOAD=libresolv_wrapper.so \
> RESOLV_WRAPPER_HOSTS=/tmp/hosts \
> $MAGIC
>
> where the output signalizes the hostname server1.example.com was indeed
> resolved into the given IP address.
>
> These are the things I've tried without success:
>
> * getent hosts server1.example.com
> * host server1.example.com
> * wget -O /dev/null http://server1.example.com/
> * the actual application, using a gnutls linkage
>
> According to strace, libresolv_wrapper.so is loaded but there is no
> access to the mocked hosts file.
>
> According to ltrace, none of the RESOLV_WRAPPER_* variables are checked
> via getenv.
>
> Not a big surpise then: Setting RESOLV_WRAPPER_DEBUGLEVEL had no effect
> either.
>
> Using , the above checks work except
> for the second one. However, this project is not in Debian.
>
> Christoph
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.6.22 (SMP w/8 CPU threads)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages libresolv-wrapper depends on:
> ii  libc6  2.37-15.1
>
> libresolv-wrapper recommends no packages.
>
> libresolv-wrapper suggests no packages.
>
> -- no debconf information
>
> ___
> Pkg-sssd-devel mailing list
> pkg-sssd-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-sssd-devel
>


signature.asc
Description: PGP signature

Bug#1067846: nmu: librist_0.2.10+dfsg-1

[Andrey Rakhmatullin]

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

nmu librist_0.2.10+dfsg-1 . armel armhf . unstable . -m "Rebuild for time_t"

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

Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

[Wookey]

On 2024-03-26 22:28 +, Thorsten Glaser wrote:

> I hacked that, and I tried to do armel and armhf as well but
> dak stopped me, whereas mini-dak was not as strict.

What was the actual problem with uploading the images you built? Just
not having any corresponding source? Or something more complicated?

It seems to me you've done all the hard work - we just need to work
out how to get those packages into the archive.  Maybe that needs a
rebuild with corresponding source? Although if we already have the
source just making a new changes file with all the right piece in
should be enough, should it not?

or am I missing something?

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#1067845: adduser: Reserving uid/gid from the uid/gid pools

[Yair Yarom]

Package: adduser
Version: 3.134
Severity: wishlist
Tags: patch

Dear Maintainer,

The UID_POOL (and GID_POOL) files contains UIDs that should be used for given
name. It would be helpful to reserve the UIDs for the future, so that the order
of adding users to the system won't affect the usability of the UIDs/names.

I.e. if a UID is in the pool, it won't be used unless for the specific name in
the pool.

Attached is a patch that accompilshes this. The RESERVE_UID_POOL and
RESERVE_GID_POOL configurations can be used to enable/disable this feature.

This could also be used to solve bug 248500.

Thanks,
Yair.


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

Kernel: Linux 6.6.20-aufs-1 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=en_IL.UTF-8, LC_CTYPE=en_IL.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages adduser depends on:
ii  passwd  1:4.13+dfsg1-1+b1

adduser recommends no packages.

Versions of packages adduser suggests:
ii  cron3.0pl1-162
ii  liblocale-gettext-perl  1.07-5
ii  perl5.36.0-7+deb12u1
ii  quota   4.06-1+b2

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

-- no debconf information
--- a/AdduserCommon.pm
+++ b/AdduserCommon.pm
@@ -132,7 +132,7 @@
 if ($type eq "uid") {
 ($name, $id, $comment, $home, $shell) = split (/:/);
 if (!$name || $name !~ /^([_a-zA-Z0-9-]+)$/ ||
-!$id || $id !~ /^(\d+)$/) {
+!defined($id) || $id !~ /^(\d+)$/) {
 warnf gtx("Couldn't parse `%s', line %d.\n"),$pool_file,$.;
 next;
 }
@@ -145,7 +145,7 @@
 } elsif ($type eq "gid") {
 ($name, $id) = split (/:/);
 if (!$name || $name !~ /^([_a-zA-Z0-9-]+)$/ ||
-!$id || $id !~ /^(\d+)$/) {
+!defined($id) || $id !~ /^(\d+)$/) {
 warnf gtx("Couldn't parse `%s', line %d.\n"),$pool_file,$.;
 next;
 }
@@ -314,6 +314,8 @@
 add_extra_groups => 0,
 uid_pool => "",
 gid_pool => "",
+reserve_uid_pool => 1,
+reserve_gid_pool => 1,
 );
 
 # Initialize to the set of known variables.
--- a/adduser
+++ b/adduser
@@ -123,6 +123,8 @@
 my $perm = undef;
 my %uid_pool;
 my %gid_pool;
+my %reserved_uid_pool;
+my %reserved_gid_pool;
 
 our @names;
 
@@ -260,9 +262,15 @@
 # read the uid and gid pool
 if ($config{"uid_pool"}) {
 read_pool ($config{"uid_pool"}, "uid", \%uid_pool);
+if ($config{"reserve_uid_pool"}) {
+%reserved_uid_pool = map {$uid_pool{$_}{id} => $_} keys %uid_pool;
+}
 }
 if ($config{"gid_pool"}) {
 read_pool ($config{"gid_pool"}, "gid", \%gid_pool);
+if ($config{"reserve_gid_pool"}) {
+%reserved_gid_pool = map {$gid_pool{$_}{id} => $_} keys %gid_pool;
+}
 }
 
 ($new_name) if defined $new_name;
@@ -1128,7 +1136,7 @@
 
 my $t = $min;
 while ($t <= $max) {
-   return $t if (!defined(getpwuid($t)));
+   return $t if (!exists($reserved_uid_pool{$t}) and 
!defined(getpwuid($t)));
$t++;
 }
 return -1; # nothing available
@@ -1151,7 +1159,7 @@
 
 my $t = $min;
 while ($t <= $max) {
-   return $t if (!defined(getgrgid($t)));
+   return $t if (!exists($reserved_gid_pool{$t}) and 
!defined(getgrgid($t)));
$t++;
 }
 return -1; # nothing available
@@ -1175,7 +1183,8 @@
 
 my $t = $min;
 while ($t <= $max) {
-   return $t if (!defined(getgrgid($t)) && !defined(getpwuid($t)));
+   return $t if (!exists($reserved_uid_pool{$t}) && 
!exists($reserved_gid_pool{$t}) &&
+ !defined(getgrgid($t)) && !defined(getpwuid($t)));
$t++;
 }
 return -1; # nothing available

Bug#1064726: Should I upload 0ad involved in wxwidgets3.2 migration?

[Sebastian Ramacher]

On 2024-03-27 15:51:22 +0100, Ludovic Rousseau wrote:
> Hello Debian Release team,
> 
> 0ad has a FTBFS bug #1064726.
> I have a new version with the fix ready for upload.
> 
> But when trying to upload I get:
> -
> $ dupload --to debian-ssh *_source.changes --no
> dupload note: no announcement will be sent.
> Checking OpenPGP signatures before upload..signatures are ok
> Checking Debian transitions...
> 
> Warning: Source package 0ad is part of ongoing transitions:
> 
>   
>   
>   
> 
> If the upload does not solve issues caused by these transitions, then it
> might disrupt them by adding delays or entangling them. For more information,
> please read:
> 
>   
> 
> Note: If you are aware of this and do not want to be warned, you can disable
> this hook from the configuration file, skip it with --skip-hooks or set the
> one-off environment variable DUPLOAD_SKIP_HOOKS, or alternatively you can
> reply to the following prompt.
> 
> Continue anyway? (yes/NO)
> -
> 
> I see 0ad listed in 
> https://release.debian.org/transitions/html/auto-wxwidgets3.2.html
> Of course the rebuild failed because the FTBFS fix is not yet in unstable.
> 
> Should I upload a new version of 0ad to help the wxwidgets3.2 migration?

Yes, please. The upload is necessary to rebuild 0ad for these
transitions.

Cheers

> Should I wait for 0ad to be removed from testing (planned in 5 days)?
> 
> Please Cc: me on reply.
> 
> Thanks
> 
> -- 
> Dr. Ludovic Rousseau
> 

-- 
Sebastian Ramacher

Bug#1066115: mpg321: diff for NMU version 0.3.2-3.2

[Andreas Metzler]

Control: tags 1066115 + pending

Dear maintainer,

I've prepared an NMU for mpg321 (versioned as 0.3.2-3.2) and
uploaded it to DELAYED/00.

Kind regards
Andreas
diff -Nru mpg321-0.3.2/debian/changelog mpg321-0.3.2/debian/changelog
--- mpg321-0.3.2/debian/changelog	2020-07-23 17:22:42.0 +0200
+++ mpg321-0.3.2/debian/changelog	2024-03-27 15:40:50.0 +0100
@@ -1,3 +1,11 @@
+mpg321 (0.3.2-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * 14_ftbfs_implicit.diff: Fix build error with
+-Wno-error=implicit-function-declaration. Closes: #1066115
+
+ -- Andreas Metzler   Wed, 27 Mar 2024 15:40:50 +0100
+
 mpg321 (0.3.2-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru mpg321-0.3.2/debian/patches/ftbfs_implicit.diff mpg321-0.3.2/debian/patches/ftbfs_implicit.diff
--- mpg321-0.3.2/debian/patches/ftbfs_implicit.diff	1970-01-01 01:00:00.0 +0100
+++ mpg321-0.3.2/debian/patches/ftbfs_implicit.diff	2024-03-27 15:39:14.0 +0100
@@ -0,0 +1,34 @@
+Description: Fix build error with -Wno-error=implicit-function-declaration
+Author: Andreas Metzler 
+Origin: vendor
+Forwarded: no
+Last-Update: 2024-03-27
+Bug-Debian: https://bugs.debian.org/1066115
+
+
+--- mpg321-0.3.2.orig/mpg321.h
 mpg321-0.3.2/mpg321.h
+@@ -242,7 +242,7 @@ typedef struct {
+ } fft_state;
+ 
+ typedef short int sound_sample;
+-//void fft_perform(const sound_sample *input, double *output, fft_state *state);
++void fft_perform(const sound_sample *input, double *output, fft_state *state);
+ 
+ fft_state *fft_init(void);
+ 
+@@ -290,6 +290,14 @@ output_frame *Output_Queue;
+ /* Shared total decoded frames */
+ decoded_frames *Decoded_Frames;
+ 
++int init_alsa_volume_control(char *name);
++int calc_http_length(buffer *buf);
++long mpg321_alsa_get_volume();
++void mpg321_alsa_set_volume(long value);
++void do_basicauth();
++ao_device *open_ao_playdevice_buffer(struct mad_header const *header);
++int check_default_play_device_buffer();
++
+ #if defined(__GNU_LIBRARY__) && !defined(_SEM_SEMUN_UNDEFINED)
+ /* */
+ #else
diff -Nru mpg321-0.3.2/debian/patches/series mpg321-0.3.2/debian/patches/series
--- mpg321-0.3.2/debian/patches/series	2019-03-13 15:57:59.0 +0100
+++ mpg321-0.3.2/debian/patches/series	2024-03-27 15:37:21.0 +0100
@@ -1 +1,2 @@
 handle_illegal_bitrate_value.patch
+ftbfs_implicit.diff

Bug#1017429:

[pbrochart]

Hi,

Rebuilding the package with iwlib solved the issue for me (USB wireless
device).
You can download it here:

https://nebulus.tuxfamily.org/debian/bookworm/mate-applets/

Bug#1017429:

[pbrochart]

Hi,

Rebuilding the package with iwlib solved the issue for me (USB wireless
device).
You can download it here:

https://nebulus.tuxfamily.org/debian/bookworm/mate-applets/

Bug#1017429: mate-applets: net-speed applet does not show anything

[pbrochart]

Hi,

Rebuilding the package with iwlib solved the issue for me (USB wireless
device).
You can download it here:

https://nebulus.tuxfamily.org/debian/bookworm/mate-applets/

Bug#1017429:

[pbrochart]

Hi,

Rebuilding the package with iwlib solved the issue for me (USB wireless
device).
You can download it here:

https://nebulus.tuxfamily.org/debian/bookworm/mate-applets/

Bug#1017429:

[pbrochart]

Hi,

Rebuilding the package with iwlib solved the issue for me (USB wireless
device).
You can download it here:

https://nebulus.tuxfamily.org/debian/bookworm/mate-applets/

Bug#1017429:

[pbrochart]

Hi,

Rebuilding the package with iwlib solved the issue for me (USB wireless
device).
You can download it here:

https://nebulus.tuxfamily.org/debian/bookworm/mate-applets/

Bug#1017429:

[pbrochart]

Hi,

Rebuilding the package with iwlib solved the issue for me (USB wireless
device).
You can download it here:

https://nebulus.tuxfamily.org/debian/bookworm/mate-applets/

Bug#1017429:

[pbrochart]

Hi,

Rebuilding the package with iwlib solved the issue for me (USB wireless
device).
You can download it here:

https://nebulus.tuxfamily.org/debian/bookworm/mate-applets/

Bug#1017429:

[pbrochart]

Hi,

Rebuilding the package with iwlib solved the issue for me (USB wireless
device).
You can download it here:

https://nebulus.tuxfamily.org/debian/bookworm/mate-applets/

Bug#1017429:

[pbrochart]

Hi,

Rebuilding the package with iwlib solved the issue for me (USB wireless
device).
You can download it here:

https://nebulus.tuxfamily.org/debian/bookworm/mate-applets/

Bug#1017429:

[pbrochart]

Hi,

Rebuilding the package with iwlib solved the issue for me (USB wireless
device).
You can download it here:

https://nebulus.tuxfamily.org/debian/bookworm/mate-applets/

Bug#1017429:

[pbrochart]

Hi,

Rebuilding the package with iwlib solved the issue for me (USB wireless
device).
You can download it here:

https://nebulus.tuxfamily.org/debian/bookworm/mate-applets/

Bug#1017429:

[pbrochart]

Hi,

Rebuilding the package with iwlib solved the issue for me (USB wireless
device).
You can download it here:

https://nebulus.tuxfamily.org/debian/bookworm/mate-applets/

Bug#1017429:

[pbrochart]

Hi,

Rebuilding the package with iwlib solved the issue for me (USB wireless
device).
You can download it here:

https://nebulus.tuxfamily.org/debian/bookworm/mate-applets/

Bug#1017429:

[pbrochart]

Hi,

Rebuilding the package with iwlib solved the issue for me (USB wireless
device).
You can download it here:

https://nebulus.tuxfamily.org/debian/bookworm/mate-applets/

Bug#1017429:

[pbrochart]

Hi,

Rebuilding the package with iwlib solved the issue for me (USB wireless
device).
You can download it here:

https://nebulus.tuxfamily.org/debian/bookworm/mate-applets/

Bug#1067844: c-evo-dh: Depends on dead-upstream mpg321 instead of mpg123

[Andreas Metzler]

Source: c-evo-dh
Version: 1.11-1
Severity: normal
X-Debbugs-Cc: ametz...@bebt.de
User: ametz...@debian.org
Usertags: mpg321-removal

Hello,

this package depends on mpg321. mpg321 is dead upstream (last change
2012, about 12 years ago), it was initially created because of license
issues with mpg123, however mpg123 moved to Debian main in 2006.

Please consider moving to another player, e.g. mpg123. mpg123 mpg123
license nowadays is LGPL-2.1, while mpg321 uses GPL-2+. Since LGPL-2.1
can be relicensed to GPL-2+ there should not be any problemds on that
side.

cu Andreas

Bug#1064726: Should I upload 0ad involved in wxwidgets3.2 migration?

[Ludovic Rousseau]

Hello Debian Release team,

0ad has a FTBFS bug #1064726.
I have a new version with the fix ready for upload.

But when trying to upload I get:
-
$ dupload --to debian-ssh *_source.changes --no
dupload note: no announcement will be sent.
Checking OpenPGP signatures before upload..signatures are ok
Checking Debian transitions...

Warning: Source package 0ad is part of ongoing transitions:

  
  
  

If the upload does not solve issues caused by these transitions, then it
might disrupt them by adding delays or entangling them. For more information,
please read:

  

Note: If you are aware of this and do not want to be warned, you can disable
this hook from the configuration file, skip it with --skip-hooks or set the
one-off environment variable DUPLOAD_SKIP_HOOKS, or alternatively you can
reply to the following prompt.

Continue anyway? (yes/NO)
-

I see 0ad listed in 
https://release.debian.org/transitions/html/auto-wxwidgets3.2.html
Of course the rebuild failed because the FTBFS fix is not yet in unstable.

Should I upload a new version of 0ad to help the wxwidgets3.2 migration?
Should I wait for 0ad to be removed from testing (planned in 5 days)?

Please Cc: me on reply.

Thanks

--
Dr. Ludovic Rousseau

Bug#1017429: mate-applets: net-speed applet does not show anything

[pbrochart]

Hi,

Rebuilding the package with iwlib solved the issue for me (USB wireless
device).
You can download it here:

https://nebulus.tuxfamily.org/debian/bookworm/mate-applets/

Bug#1060666: github example is too unstable

[João Pedro Nóbrega Fernandes]

I've tested the github repository you cited and wasn't able to reproduce it
at all. Tested versions said to be working and the code still was really
unstable even using docker compose.

I believe this code you used wasn't the best example as I found its
Makefile really unstable with many versions of podman compose and even
Docker.

So I think this is not a issue with the version in Debian stable

Bug#849741: (no subject)

[Henrik Christian Grove]

Control: submitter -1 !

Bug#943315: ITP: vst3sdk -- professional audio plugin development kit

[Andrius Merkys]

Hello,

I had some luck in packaging vst3sdk. I pushed my packaging attempts 
(just the debian/ directory) to my personal repository on salsa [1]. The 
package builds and installs VST3 plugins, debian/copyright is as well 
almost finished.


I had some difficulties in constructing the multiple upstream tarball 
(MUT). uscan does not seem to be able to handle debian/watch correctly, 
thus I first have to change upstream version to 0 in debian/changelog, 
run 'uscan --download', revert the upstream version in debian/changelog 
and run it again. From downloaded tarballs the MUT is built by 
debian/get-orig-source. I plan to import the constructed MUT into the 
same git repository [1] to simplify its usage, but I will probably 
exclude doc/ subdirectory due to multiple source-is-missing problems.


[1] https://salsa.debian.org/merkys/vst3sdk

Andrius

Bug#1064035: [regression 5.10.y] linux-doc builds: Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.

[Greg Kroah-Hartman]

On Tue, Mar 05, 2024 at 07:46:59AM +, Greg Kroah-Hartman wrote:
> On Mon, Mar 04, 2024 at 10:41:50PM +0100, Salvatore Bonaccorso wrote:
> > Hi,
> > 
> > On Mon, Mar 04, 2024 at 01:05:09PM -0700, Jonathan Corbet wrote:
> > > Salvatore Bonaccorso  writes:
> > > 
> > > > Ok. In the sprit of the stable series rules we might try the later and
> > > > if it's not feasible pick the first variant?
> > > 
> > > Well, "the spirit of the stable series" is one of Greg's titles, and he
> > > said either was good...:)
> > 
> > here we go. Please let me know if you need anything changed in the
> > commit message to describe the situation better.
> > 
> > Greg, in the Fixes tag I added the 5.10.y commit as the issue is
> > specific to the 5.10.y series. Is this the correct form to note this?
> 
> Looks good, I'll queue this up after the next round of releases goes
> out, thanks for the patch!

Now finally queued up, sorry for the delay.

greg k-h

Bug#1067843: bookworm-pu: package nvidia-open-gpu-kernel-modules/535.161.08-1~deb12u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
We need to update src:nvidia-open-gpu-kernel-modules to a new upstream
version to stay in sync with src:nvidia-graphics-drivers (for a matching
firmware-nvidia-gsp upstream version) and to fix some CVEs.

[ Impact ]
A graphics driver with some open CVEs.

[ Tests ]
Only installability and module buildability have been tested, everything
else would require nvidia hardware.

[ Risks ]
Upgrading the nvidia driver stack in stable to new upstream releases has
already been done in the past.

[ Checklist ]
  [*] *all* changes are documented in the d/changelog
  The changelog entries for the uploads to sid and bookworm are
  still missing.
  [.] I reviewed all changes and I approve them
  The upstream changes are exceed any reasonably reviewable size.
  [.] attach debdiff against the package in (old)stable
  Only for debian/*
  [ ] the issue is verified as fixed in unstable
  I'm currently doing interoperability tests with
  src:nvidia-graphics-drivers. (These two source packages
  need to be updated together due to the strict firmware
  dependency.) An upload to bookworm will only happen after the
  package is in sid.

[ Changes ]
The full upstream diffstat summary is
1766 files changed, 321746 insertions(+), 112788 deletions(-)
and thus I treat this as "unreviewed blob".
(Parts of this are firmware blobs as hexdump in C source const char[]
format.)

 debian/.gitignore  |   1 +
 debian/bug-control.mk  |   8 +-
 debian/changelog   | 114 +++--
 debian/control |   5 +-
 debian/copyright   |   4 +-
 debian/patches/hmm.patch   |  17 +++
 ...-minimum-supported-kernel-version-to-3.10.patch |   4 +-
 ...-remove-empty-lines-from-uts_release-outp.patch |   6 +-
 debian/patches/module/0034-fix-typos.patch |  48 +
 debian/patches/module/bashisms.patch   |   2 +-
 debian/patches/module/cc_version_check-gcc5.patch  |   2 +-
 .../module/conftest-prefer-arch-headers.patch  |   2 +-
 debian/patches/module/conftest-verbose.patch   |  14 +--
 debian/patches/module/ppc64el.patch|  19 
 debian/patches/module/series.in|   2 +-
 debian/patches/module/use-kbuild-compiler.patch|   2 +-
 debian/patches/module/use-kbuild-flags.patch   |   2 +-
 debian/patches/series  |   1 +
 debian/patches/typos.patch |  20 ++--
 debian/rules   |   9 +-
 debian/rules.defs  |   2 +-
 debian/source/lintian-overrides|   3 -
 debian/sync.sh |   1 +

There are only minor packaging changes, these have been synced from
src:nvidia-graphics-drivers.

[ Other info ]
This is a rebuild of the package from sid with no further changes.


Andreas


nvidia-open-gpu-kernel-modules_535.diff.xz
Description: application/xz

Bug#1054514: [PATCH 1/1] drm/qxl: fixes qxl_fence_wait

[Maxime Ripard]

Hi,

On Wed, Mar 20, 2024 at 04:25:48PM +0100, Linux regression tracking (Thorsten 
Leemhuis) wrote:
> On 08.03.24 02:08, Alex Constantino wrote:
> > Fix OOM scenario by doing multiple notifications to the OOM handler through
> > a busy wait logic.
> > Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
> > result in a '[TTM] Buffer eviction failed' exception whenever it reached a
> > timeout.
> > 
> > Fixes: 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait")
> > Link: 
> > https://lore.kernel.org/regressions/fb0fda6a-3750-4e1b-893f-97a3e402b...@leemhuis.info
> > Reported-by: Timo Lindfors 
> > Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054514
> > Signed-off-by: Alex Constantino 
> > ---
> >  drivers/gpu/drm/qxl/qxl_release.c | 20 ++--
> >  1 file changed, 14 insertions(+), 6 deletions(-)
> 
> Hey Dave and Gerd as well as Thomas, Maarten and Maxime (the latter two
> I just added to the CC), it seems to me this regression fix did not
> maybe any progress since it was posted. Did I miss something, is it just
> "we are busy with the merge window", or is there some other a reason?
> Just wondering, I just saw someone on a Fedora IRC channel complaining
> about the regression, that's why I'm asking. Would be really good to
> finally get this resolved...

I've ping'd Gerd last week about it, but he couldn't remember the
details of why that patch was warranted in the first place.

If it works, I'd prefer to revert the original patch that we know used
to work instead of coming up with some less proven logic, which seems to
be quite different to what it used to be.

Alex, could you try reverting 5a838e5d5825c85556011478abde708251cc0776
and letting us know the result?

Thanks!
Maxime


signature.asc
Description: PGP signature

Bug#872587: Document the Protected field

[Simon McVittie]

On Wed, 27 Mar 2024 at 14:43:40 +0200, Martin-Éric Racine wrote:
> ke 27. maalisk. 2024 klo 14.00 Andrey Rakhmatullin (w...@debian.org) 
> kirjoitti:
> > "Essential: yes" are always installed. Tools and dependencies assume they
> > are installed.  Bootstrapping tools install them implicitly. Package
> > management tools refuse to remove them.
> >
> > "Protected: yes" are nothing like that. Package management tools refuse to
> > remove them and that's all.

Another way to look at this is that if a Protected package is already
installed, then package management behaves as though it's Essential,
but if a Protected package is merely available from a configured apt
source, then nothing special happens.

> Protected: yes|no
> This field prevents a package from getting auto-removed by dpkg
> without using one of the force options.

True so far...

> It is intended for custom
> local packages not meant for upload to the Debian repository.

... but this isn't the whole story. Protected: yes is also appropriate
for non-local packages that are required for system boot, or for package
management. The design principle is that if it would be hard to recover
from removing a package once it has been installed, then it's Protected.

An example of Protected: yes on boot packages is that the init metapackage
is Protected: yes, to make sure you don't accidentally remove the init
system and make the system unbootable (which is hard to recover from
because before you can install a new init system, you need to be able to
boot). It might also make sense for bootloaders like grub to be Protected:
yes, although currently they are not.

An example of Protected: yes on package management packages is that it
would be appropriate to put Protected: yes on apt (although in fact apt
is hard-coded to behave that way even without Protected: yes), to avoid
accidentally getting into a situation where you have removed apt
(which is hard to recover from because now there's no package manager,
and no easy-to-validate trust chain to check that a manually-downloaded
apt_*.deb is authentic).

smcv

Bug#1067842: transition: octave-9

[Sébastien Villemot]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: debian-oct...@lists.debian.org
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

Please schedule a transition for the latest major upstream version of Octave,
version 9. All the arch:any Octave addons need to be rebuild.

Octave 9 has already been uploaded to experimental.

A rebuild of all the packages affected by the transition has been performed.
Several problems were fixed, and to the best of our knowledge, all packages are
ready. We stand ready to upload and NMU as needed if other issues arise.

Thanks,

Ben file:

title = "octave-9";
is_affected = .depends ~ "octave-abi-58" | .depends ~ "octave-abi-59";
is_good = .depends ~ "octave-abi-59";
is_bad = .depends ~ "octave-abi-58";

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

Bug#1067841: libopenshot-audio: FTBFS on armel (error: static assertion failed)

[Kentaro HAYASHI]

Source: libopenshot-audio
Severity: important
Tags: ftbfs
X-Debbugs-Cc: ken...@xdump.org

Dear Maintainer,

libopenshot-audio fails to build on armel.

FYI: See
https://buildd.debian.org/status/fetch.php?pkg=libopenshot-audio=armel=0.3.2%2Bdfsg1-2.1=1709160782=0


  
/home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/JuceLibraryCode/modules/juce_core/threads/juce_ThreadLocalValue.h:51:5:
  required from here
/home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/JuceLibraryCode/modules/juce_core/memory/juce_Atomic.h:58:43:
error: static assertion failed : This class can only be used for
lock-free types
/home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/JuceLibraryCode/modules/juce_core/memory/juce_Atomic.h:58:43:
note: 'std::atomic::ObjectHolder*>::is_always_lock_free'
evaluates to false
/home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/JuceLibraryCode/modules/juce_core/memory/juce_Atomic.h:
In instantiation of 'juce::Atomic::~Atomic() [with Type =
unsigned int]':
/home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/JuceLibraryCode/modules/juce_core/time/juce_Time.cpp:180:27:
  required from here
/home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/JuceLibraryCode/modules/juce_core/memory/juce_Atomic.h:58:43:
error: static assertion failed : This class can only be used for
lock-free types
/home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/JuceLibraryCode/modules/juce_core/memory/juce_Atomic.h:58:43:
note: 'std::atomic::is_always_lock_free' evaluates to
false make[3]: *** [CMakeFiles/openshot-audio.dir/build.make:121:
CMakeFiles/openshot-audio.dir/JuceLibraryCode/include_juce_core.cpp.o]
Error 1 make[3]: Leaving directory
'/home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/debian/build' make[2]:
*** [CMakeFiles/Makefile2:107: CMakeFiles/openshot-audio.dir/all] Error
2 make[2]: *** Waiting for unfinished jobs
/home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/JuceLibraryCode/modules/juce_dsp/processors/juce_Oversampling.h:139:
warning: The following parameter of
juce::dsp::Oversampling::addOversamplingStage(FilterType type, float
normalisedTransitionWidthUp, float stopbandAmplitudedBUp, float
normalisedTransitionWidthDown, float stopbandAmplitudedBDown) is not
documented: parameter 'type'
/home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/JuceLibraryCode/modules/juce_dsp/frequency/juce_Windowing.h:84:
warning: The following param eter of
juce::dsp::WindowingFunction::fillWindowingTables(FloatType *samples,
size_t size, WindowingMethod type, bool normalise=true, FloatT ype
beta=0) is not documented: parameter 'type' make[3]: Leaving directory
'/home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/debian/build'


Regards,

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: armel (armv8l)

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