Bug#1042336: moment-timezone.js: FTBFS: cp: cannot stat '/usr/share/zoneinfo/posix/*': No such file or directory

[Daniel Swarbrick]

On Wed, 26 Jul 2023 22:08:15 +0200 Lucas Nussbaum  wrote:
> Relevant part (hopefully):
> > mkdir -p temp/zic/2023c temp/zdump/2023c
> > cp -RL /usr/share/zoneinfo/posix/* temp/zic/2023c/
> > cp: cannot stat '/usr/share/zoneinfo/posix/*': No such file or 
directory

> > make[1]: *** [debian/rules:51: data/unpacked/2023c.json] Error 1

This appears to have broken due to a change in the tzdata package which 
landed in both Debian and Ubuntu[1].


The Ubuntu moment-timezone.js package was adapted[2] to accommodate this 
change, but the Debian package was not.


[1]: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2008076
[2]: 
https://git.launchpad.net/ubuntu/+source/moment-timezone.js/commit/debian?h=applied/ubuntu/lunar




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051474: libreoffice: Please add embeded code copies to embeded-code-copies on security tracker debian.tar.xz/tarballs

[Rene Engelhard]

severity 1051474 important

thanks

Hi,

Am 08.09.23 um 19:19 schrieb Bastien Roucariès:

Source: libreoffice
Severity: serious
Tags: security
Justification: Document embdeded code copy + copyright
X-Debbugs-Cc: Debian Security Team 


Since when is that serious? It isn't. There have been no complains from 
anyone in the security team in any of the last security updates?


(None of which affected any of the internal copies used,)

The policy says "should". And it it it followed.

The most stuff isn't used as internal code copies, only the unavoidable 
ones is. And TTBOMK the security team DOES know it.


> Could you document that you embded a few tar ball under the security 
tracker ?


You mean I should send MRs to it?

>Moreover you do not document where you downloaded these file a comment 
under

copyright will be helpful (README.source say how to retrieve it not the link to
get).


The fetch it manually and put it there.  (Which normally would be done 
from upstreams build systeem for ALL tarballs, even those not used..)


(It basically always is https://dev-www.libreoffice.org/src/ (which 
mirrors stuff they got from the website):


Makefile:        $(call 
fetch_Download_item_unchecked,https://download.documentfoundation.org/libreoffice/src/$(shell 
echo $(gb_LO_VER) | sed -e 
"s/\([0-9]*\.[0-9]*\.[0-9]*\).*/\1/"),libreoffice-$(i)-$(gb_LO_VER).tar.xz))



Regards,


Rene

Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Russ Allbery]

Hideki Yamane  writes:
> Russ Allbery  wrote:

>> Licenses will be included in common-licenses if they meet all of the
>> following criteria:

>  How about just pointing SPDX licenses URL for whole license text and
>  lists DFSG-free licenses from that? (but yes, we should adjust short
>  name of licenses for DEP-5 and SPDX for it).

Can we do this legally?  If we can, it certainly has substantial merits,
but I'm not sure that this satisfies the requirement in a lot of licenses
to distribute a copy of the license along with the work.  Some licenses
may allow that to be provided as a URL, but I don't think they all do
(which makes sense since people may receive Debian on physical media and
not have Internet access).

-- 
Russ Allbery (r...@debian.org)  

Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Enrico Zini]

On Sat, Sep 09, 2023 at 08:35:27PM -0700, Russ Allbery wrote:

> Licenses will be included in common-licenses if they meet all of the
> following criteria:
> 
> * The license is DFSG-free.
> * Exactly the same license wording is used by all works covered by it.
> * The license applies to at least 100 source packages in Debian.
> * The license text is longer than 25 lines.

I like this. I'd say that even if a license is shorter than 25 lines I'd
appreciate to be able to link to it instead of copypasting it.

I like to be able to fill the license field with a value, after checking
that the upstream license didn't diverge from what it looks like. I'd
love to use SPDX IDs there, for example. In an ideal world, I'd like to
autofill debian/copyright with SPDX IDs from upstream metadata. Having a
link to a file goes closer to having a declarative license ID.

In general the less bytes I have to maintain in debian/* the happier I
am, and as a personal aesthetic sense I feel like the less bytes we all
have to maintain in debian/* the less is our collective maintenance
burden.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 

Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Jonas Smedegaard]

Quoting Russ Allbery (2023-09-10 05:35:27)
> In order to structure the discussion and prod people into thinking about
> the implications, I will make the following straw man proposal.  This is
> what I would do if the decision was entirely up to me:
> 
> Licenses will be included in common-licenses if they meet all of the
> following criteria:
> 
> * The license is DFSG-free.
> * Exactly the same license wording is used by all works covered by it.
> * The license applies to at least 100 source packages in Debian.
> * The license text is longer than 25 lines.

I fully support the above proposed criteria, and appreciate your
initiative to have this conversation.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1051585: onnx failing autopkgtest blocks migration

[Mattias Ellert]

Source: onnx
Version: 1.13.1-1
Severity: serious
Control: affects -1 +src:pytorch
Control: affects -1 +src:pytorch-cuda
Control: affects -1 +src:open3d
Control: affects -1 +src:pytorch-vision
Control: affects -1 +src:baler
Control: affects -1 +src:pytorch-scatter
Control: affects -1 +src:pytorch-audio
Control: affects -1 +src:skorch
Control: affects -1 +src:invesalius
Control: affects -1 +src:tpot
Control: affects -1 +src:pytorch-ignite
Control: affects -1 +src:pytorch-sparse
Control: affects -1 +src:pytorch-text

The failing autopkgtest blocks migration for onnx and packages that
depend on it,

Mattias



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

Bug#1051562: fis-gtm: uploader email adres maybe invalid

[Andreas Tille]

Hi Amul,

I did not had any problems to reach you under this e-mail address.
Please confirm it is valid and also confirm you are working on packaging
the latest upstream release.

Kind regards
Andreas.

Am Sat, Sep 09, 2023 at 10:20:40PM +0200 schrieb Ben Tris:
> Package: fis-gtm
> Severity: minor
> X-Debbugs-Cc: benatt...@gezapig.nl, m...@qa.debian.org
> 
> Dear Maintainer,
> 
> The email under uploader Amul Shah is now
>  this is not found in qa.
> I could not find more info.
> 
> 
> -- System Information:
> Debian Release: 12.1
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
> 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.1.0-11-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 fis-gtm depends on:
> pn  fis-gtm-7.0  
> 
> fis-gtm recommends no packages.
> 
> fis-gtm suggests no packages.
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#1046011: ldapvi: Fails to build source after successful build

[Nilesh Patra]

Control: tags -1 patch

Hi Rhonda,

This happens because configure is saved to configure.save and then
moved back again in the "dh_clean" step. In the next build, dh_auto_clean
calls "make distclean" that removes the configure file.

make distclean is not called in the first build because there is no GNUMakefile
in the first build, but it is generated as a part of the first build's process.

IMHO, the easier solution would be either of these:
* Change dh_clean to dh_auto_clean
* Patch GNUMakefile.in to *not* remove configure.

I've attached a patch for the first solution. Please consider applying if you
find this OK.

Best,
Nilesh
diff --git a/debian/rules b/debian/rules
index e052b44..4354209 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,10 +7,11 @@ override_dh_auto_configure:
 	dh_auto_configure -- --with-libcrypto=none
 	cd manual && $(MAKE) manual.html
 
-override_dh_clean:
+override_dh_auto_clean:
 	-rm manual/manual.html
+	-rm -f *.o ldapvi
 	cp -a configure configure.save
-	dh_clean
+	dh_auto_clean
 	mv configure.save configure
 
 override_dh_auto_install:


signature.asc
Description: PGP signature

Bug#1051584: /usr/lib/llvm-15/bin/llvm-config: multiarch issues, with llvm-config-15

[Witold Baryluk]

Package: llvm-15
Version: 1:15.0.7-8
Severity: normal
File: /usr/lib/llvm-15/bin/llvm-config
X-Debbugs-Cc: witold.bary...@gmail.com

Dear Maintainer,

I am trying to cross compile Mesa for armhf, on arm64 box.

I installed llvm-15, libllvm15:arm64 and libllvm15:armhf

So I do have libLLVM.so now for armhf, but I am unable to convince the
llvm-config-15 to output proper paths with --ldflags.

[7/1106] Linking target src/amd/vulkan/libvulkan_radeon.so
FAILED: src/amd/vulkan/libvulkan_radeon.so 
/usr/bin/arm-linux-gnueabihf-g++-12  -o src/amd/vulkan/libvulkan_radeon.so  
-Wl,--build-id=sha1 -Wl,-Bsymbolic -Wl,--gc-sections -Wl,--version-script 
/home/witold_baryluk/mesa-git/src/vulkan/vulkan.sym -L/usr/lib/llvm-15/lib 
-lLLVM-15 -pthread ... -Wl,--end-group
/usr/lib/llvm-15/lib/libLLVM-15.so: file not recognized: file format not 
recognized
collect2: error: ld returned 1 exit status



So, that is not using correct -L here.

Canonical way would be to use llvm-config-15 (Which Meson used by Mesa is
using to find all the flags), but it does not understand multiarch.

$ CC=arm-linux-gnueabihf-gcc-12 CXX=arm-linux-gnueabihf-g++-12 
PKG_CONFIG=arm-linux-gnueabihf-pkg-config llvm-config-15 --ldflags
-L/usr/lib/llvm-15/lib
$


(libLLVM15.so there is a symlink which eventually leads to 
/usr/lib/arm64-linux-gnu/libLLVM15.so.1)

I checked source code of llvm-config and there is nothing in it to make
it smart, one just needs to compile two versions of LLVM and llvm-config,
but installing arm64 and armhf versions of llvm-config is not possible.

I am not able install llvm15:armhf and llvm15:arm64 simulataniously
either, as they conflict and provide same binaries.

This is not great, as the pkg-config provided by Debian is multi-arch
aware, and can provide correct paths.

The same issue happens on amd64, when cross-compiling mesa to i386. It
happens to work there, due to some other flags passed do the compiler,
and compiler sees both versions of libLLVM.so (amd64 and i386), and picks
i386 one, becase the other cannot be used. But that is more of an accident,
than working properly.

Bug#1051583: ITP: node-fast-json-patch -- Node.js implementation of JSON-Patch

[Yadd]

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

* Package name: node-fast-json-patch
  Version : 3.1.1
  Upstream Contact: Joachim Wester 
* URL : https://github.com/Starcounter-Jack/JSON-Patch
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js implementation of JSON-Patch

node-fast-json-patch is a leaner and meaner implementation of JSON-Patch.
Small footprint. High performance. It can:
 * apply patches (arrays) and single operations on JS object
 * validate a sequence of patches
 * observe for changes and generate patches when a change is detected
 * compare two objects to obtain the difference

node-fast-json-patch is a dependency of node-vega-embed, needed for
node-jupyterlab.

Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Russ Allbery]

Hello everyone,

I come seeking your opinions.  Please cc 885...@bugs.debian.org on replies
so that we can accumulate this discussion in a Debian Policy bug.

One of the responsibilities of the Policy Editors is to determine which
licenses should be included in /usr/share/common-licenses, and thus do not
have to be reproduced in the copyright file of every package that use
them.  We have never had a clear criteria for this.  We need one, so that
we can advertise a clear and transparent policy for inclusion without
having the conversation from first principles for each new license.

I was the one who made the last few decisions, and I based the decision
largely on the number of binary packages in Debian using the license.
When I was doing this, I set a fairly high threshold (more packages than
the least popular package currently in /usr/share/common-licenses, which
historically has been GFDL-1.3 although it now appears to be MPL-1.1).  No
one was entirely satisfied with that criteria, including me.

I have the following questions:

1. What criteria (besides the obvious one of being a DFSG-free license)
   should we apply when deciding what licenses to include?  Number of
   packages?  Length?  How positive we feel towards the license?  Some
   combination of these things?  Please be specific.

2. If we use number of packages as a criteria, what should the threshold
   be?  I have appended to the bottom of this message the current output
   of my ad-hoc license-count tool run against the current archive so that
   you have a feeling for how many packages use various licenses.

3. If we use number of packages, should that be source packages or binary
   packages?  Source packages represent maintainer effort; binary packages
   represent disk clutter.

4. Should there be a length cutoff for licenses, such that we do not
   include in /usr/share/common-licenses any license shorter than some
   number of lines or bytes?  The justification would be that telling
   people to go look elsewhere for the license has some inherent overhead
   and annoyance when they discover that the license is all of ten lines
   and could have just been included in the copyright file.

5. Should we exclude licenses that contain text that all or most users of
   the license customize when they use it?  For example, the existing
   /usr/share/common-licenses/BSD contains the clause:

  3. Neither the name of the University nor the names of its
 contributors may be used to endorse or promote products derived
 from this software without specific prior written permission.

   which users of this specific license usually change to instead include
   the name of their organization, or their name, or something else.  Full
   disclosure: it will be very hard to convince me that licenses used this
   way should be included in common-licenses, since I believe it is
   technically incorrect to omit a license and point to the
   common-licenses version when the provisions of the common-licenses
   version are different in detail due to naming different people or
   requiring or prohibiting mentioning of different names as endorsements.

Here are various concerns that people have had in this area in the past.
I'm neither indicating agreement nor disagreement with any of these
points, only listing them to provoke thought about some of the things
people have raised before.

* Including long legal texts in debian/copyright, particularly if one
  wants to format them for copyright-format, is tedious and annoying and
  doesn't benefit our users in any significant way, and therefore we
  should include as many licenses as possible in common-licenses to spare
  people that work.

* common-licenses consumes disk space on every installed Debian system of
  any size, and therefore should be kept small to avoid wasting system
  resources.

* Every appproved DFSG license should be included in common-licenses so
  that it serves as a repository of licenses the project has approved.

* Including a license in common-licenses implies that the project approves
  of that license, and therefore licenses such as the LaTeX Project Public
  License 1.0, which requires renaming derived works, should not be
  included even though DFSG #4 grudgingly allows for this type of license
  term.

* All licenses explicitly mentioned in the Debian Free Software Guidelines
  should be present in common-licenses (as justification for including the
  BSD license even though the current text is specific to the Regents of
  the University of California).

In order to structure the discussion and prod people into thinking about
the implications, I will make the following straw man proposal.  This is
what I would do if the decision was entirely up to me:

Licenses will be included in common-licenses if they meet all of the
following criteria:

* The license is DFSG-free.
* Exactly the same license wording is used by all works covered by it.
* The 

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Luca Boccassi  writes:

> Sure, updated as suggested.

I have a bunch of minor wording fixes that I'd want to make at this before
merging, but that should be straightforward to do.  Before I invest the
time in that, I want to check the opinions of everyone else following
along and see if the semantics of Luca's change have general approval.

Could folks take a look at this patch and see if the basic gist of it is
something that they would second (or, for that matter, is something they
would object to)?  I think I would second it (with wording adjustments),
with one caveat mentioned below.  The whole thing is at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945269#295

Luca, am I right that service directories are specific to, well, services?
If so, what would you think of moving them to Policy 9.3 alongside the
other discussion of systemd units?  They feel out of place here, since
packages that do not use services cannot use this functionality, and
there's already a statement in the tmpfiles.d section pointing to them as
more appropriate for services.

> +Packages might need additional files or directories to implement their
> +functionality. Directories that are located under ``/var/`` or
> +``/etc/``, and files that are located under ``/var/``, should not be
> +created manually via maintainer scripts, but instead be declaratively
> +defined via the `tmpfiles.d
> +`_
> +interface.  Files and directories under ephemeral filesystems such as
> +``/tmp/`` may also be created and managed via ``tmpfiles.d`` snippets.

I understand the empty directory part, but I don't believe "files that are
located under /var" is correct unless you specifically mean *empty* files
(and even then, I'm not clear on precisely when this would be needed).
For example, /var/lib/gnubg/gnubg_ts0.bd is created by the gnubg package
maintainer script, and I can see no possible way that action could (or
should) be handled by the tmpfiles.d mechanism.

What am I missing?

-- 
Russ Allbery (r...@debian.org)  

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Russ Allbery]

Russ Allbery  writes:

> -If a service unit is not present, ``systemd`` uses dependency information
> -contained within the init scripts and symlinks in ``/etc/rcn.d`` to decide
> -which scripts to run and in which order.  The ``sysv-rc`` runlevel system
> -for ``sysvinit`` uses the same symlinks in ``/etc/rcn.d`` to decide which
> -scripts to run and in which order at boot time and when the init state (or
> -"runlevel") is changed.  See the ``README.runlevels`` file shipped with
> -``sysv-rc`` for implementation details.  Other alternatives might exist.
> +``systemd`` uses dependency and ordering information contained within the
> ++enabled unit files to decide which services to run and in which order.
> +The ``sysv-rc`` runlevel system for ``sysvinit`` uses the same symlinks in
> +``/etc/rcn.d`` to decide which scripts to run and in which order at boot
> +time and when the init state (or "runlevel") is changed.  See the
> +``README.runlevels`` file shipped with ``sysv-rc`` for implementation
> +details.  Other alternatives might exist.

And of course I have to post the diff to see the bugs.  The part that says
"uses the same symlinks" should now say "uses symlinks".

-- 
Russ Allbery (r...@debian.org)  

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Russ Allbery]

Package: debian-policy
Version: 4.6.2.0
Severity: important
X-Debbugs-Cc: r...@debian.org

As part of reviewing #1039102, I took a detailed look at Policy 9.3
on system services and realized that it is largely obsolete and is
not followed by most Debian packages that provide system services.
Specifically:

* There is no real documentation of systemd units except in the
  introduction, and most of the section describes init scripts as
  if they were the only way to start a service.

* All packages are told they must use update-rc.d, but systemd units
  no longer use update-rc.d.  They instead use deb-systemd-helper in
  ways that are not documented in Policy and I believe are maintained
  primarily in debhelper.

* All packages are told they should use invoke-rc.d, but systemd units
  no longer use invoke-rc.d.  They instead use deb-systemd-invoke,
  which also supports the policy-rc.d interface.

* The policy-rc.d interface is undocumented.

This part of Policy is also a bit of a mess of deleted sections due to
a desire to avoid section renumbering.

I started a rewrite of this section, but quickly ran into the question
of how to document the correct invocations of deb-systemd-helper and
deb-systemd-invoke.  After thinking about this for a while, the
conclusion I reached was that documenting this in Policy is both extra
make-work that we do not have the resources to keep up with, and serves
no real purpose for nearly every reader of Debian.  debhelper is already
maintaining the correct code to set up systemd services in close
cooperation with the systemd and init-system-helpers maintainers, that
code contains temporary workarounds and other fixes that Policy is not
going to keep up with, and it's hard to justify duplicating that work in
a Policy statement.

I therefore would like to propose a first: I think Policy should simply
say that any package that provides a system service should use debhelper
and rely on dh_installsystemd to put the appropriate commands in its
maintainer scripts.  (We can then discuss whether we should do the same
for init scripts and dh_installinit, although its stanzas are simpler.)

Previously we have tried to avoid doing this, and have maintained the
principle that debhelper is simply an *implementation* of Policy, and it
still falls to Policy to describe what debhelper should do.  However, I
think it is now abundantly obvious that debhelper has considerably more
development resources available to it than Policy has writers, debhelper
developers are quite rightfully not waiting for things to be added to
Policy before they can be implemented, and essentially every Debian
package that does anything non-trivial uses debhelper now.  I also don't
see any truly useful purpose served by dumping a wad of shell code into
Policy that essentially no one will use because it's what debhelper would
add for them.

I have some other questions about the rewrite of these sections (such as
how hard we should try to retain section numbering), but I think we should
resolve this question first, since it has dramatic effects on what text
we should write.


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

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

debian-policy depends on no packages.

Versions of packages debian-policy recommends:
ii  libjs-sphinxdoc  5.3.0-7

Versions of packages debian-policy suggests:
pn  doc-base  

-- no debconf information

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Russ Allbery]

Luca Boccassi  writes:

> systemd upstream will drop support for the transitional sysv generator
> in the near future. The transition is long finished, it's been at least
> a decade, and it's time for the tail of packages still shipping only
> init scripts but not units to be updated.

> Tentatively this should happen within Trixie's development cycle. Of
> course it's free software and generators are not that difficult to
> maintain, so if someone wanted to lift the sysv generator out of the
> systemd repository and adapt it to be a standalone binary there's
> nothing stopping them. But I wouldn't want the systemd package to depend
> on such a backward compat tool, so packages needing this hyptothetical
> package should depend explicitly on it. This is just mentioned for
> completeness, it's been at least a decade and writing a unit file is
> beyond trivial so there shouldn't be any issue adding the few remaining
> ones.

The mass bug filing happened, and although there were some objections on
debian-devel, I don't think any of them were blocking.  Specifically, I
did not see anyone present a concrete plan for how to keep the systemd
unit generator or some equivalent alive, and given that systemd upstream
is dropping support for this feature, I believe that's the only way for
this change to not be effective mandatory.

Therefore, I think the time is ripe to proceed with this Policy change.

I took a detailed look at this part of Policy today, and the whole system
service section needs serious work.  I believe the instructions it
currently provides for constructing package maintainer scripts won't
actually work with a current Debian system, and most Debian packages are
technically violating the current Policy because it hasn't been updated
for how systemd units work today.  I started on overhauling that section,
but it became clear that this is going to be a larger project with some
potentially controversial decisions, so I'm going to open a new bug about
that so that we don't block this change on that work.

I made the following changes to your last diff:

* Move the "should" about integrating with service management to the
  parent section.

* Explicitly say that systemd is the default init system and service
  manager (it feels like we should say this somewhere, and I don't think
  we already do).

* Add an explicit exception for packages intended only to support
  alternate init systems.  (As an obvious example, sysvinit isn't going to
  ship a systemd unit, nor should it.)

* Delete the paragraph suggesting that packages without systemd units
  should write an init script, since this will no longer accomplish the
  goal of getting that system service to work with systemd and therefore
  no longer seems to serve a purpose.

Here is what I came up with.  I think it is ready for seconds or
objections.

-- 
Russ Allbery (r...@debian.org)  

>From 474a9f4c74bc2c3a1d162de33e377a3585e641af Mon Sep 17 00:00:00 2001
From: Russ Allbery 
Date: Sat, 9 Sep 2023 18:39:16 -0700
Subject: [PATCH] systemd unit files are now a must

systemd is dropping support for the generator that allows it to
automatically create units for init scripts. As a result, all
packages that want to integrate with systemd service management
must start shipping systemd units.

State that arranging for services to be automatically started or
stopped is a should, but if the package wishes to do that, a
systemd service unit is a must unless the package is only intended
for use with alternate init systems. Avoid saying that systemd uses
/etc/rcn.d links to determine service ordering.
---
 policy/ch-opersys.rst | 35 ---
 1 file changed, 20 insertions(+), 15 deletions(-)

diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 207b3c0..bee16f2 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -323,20 +323,25 @@ which try to write to a home directory will fail to build.
 Starting system services
 
 
+Debian packages that provide system services should arrange for those
+services to be automatically started and stopped by the init system or
+service manager.  This section describes how that is done.
+
 .. _s-services-intro:
 
 Introduction
 
 
-Packages that include system services should include ``systemd`` service
-units to start or stop those services.  See :manpage:`systemd.service(5)`
-for details on the syntax of a service unit file.  In the common case that
-a package includes a single system service, the service unit should have
-the same name as the package plus the ``.service`` extension.
+The default init system and service manager in Debian is ``systemd``.
+Packages that wish to automatically start and stop system services must
+include ``systemd`` service units to do so, unless the service is only
+intended for use on systems running alternate init systems.  See
+:manpage:`systemd.service(5)` for 

Bug#1051581: munin examples/systemd-fastcgi/munin-html.service issue

[axet]

Package: munin
Version: 2.0.73-1
Severity: normal

Dear Maintainer,

Mumin examples/systemd-fastcgi/munin-html.service has to use different user:

www-data/www-data. Currently munin/munin

Please patch the file with:

[Service]
User=www-data
Group=www-data

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

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

Versions of packages munin depends on:
ii  cron [cron-daemon]   3.0pl1-162
ii  debconf [debconf-2.0]1.5.82
ii  fonts-dejavu-core2.37-6
ii  init-system-helpers  1.65.2
ii  libdate-manip-perl   6.91-1
pn  libdigest-md5-perl   
ii  libfile-copy-recursive-perl  0.45-4
ii  libhtml-template-perl2.97-2
ii  libio-socket-inet6-perl  2.73-1
ii  liblog-log4perl-perl 1.57-1
ii  librrds-perl 1.7.2-4+b8
pn  libstorable-perl 
ii  liburi-perl  5.17-1
hi  munin-common 2.0.73-1
ii  netbase  6.4
ii  perl [libtime-hires-perl]5.36.0-7
ii  rrdtool  1.7.2-4+b8
ii  systemd-sysv 252.12-1~deb12u1

Versions of packages munin recommends:
ii  libcgi-fast-perl  1:2.15-1
ii  munin-doc 2.0.73-1
ii  munin-node2.0.73-1

Versions of packages munin suggests:
ii  elinks [www-browser]0.13.2-1+b4
ii  firefox-esr [www-browser]   102.13.0esr-1~deb12u1
pn  libapache2-mod-fcgid
ii  libnet-ssleay-perl  1.92-2+b1
ii  links [www-browser] 2.28-1+b2
ii  lynx [www-browser]  2.9.0dev.12-1
ii  nginx [httpd]   1.22.1-9
ii  opera-stable [www-browser]  102.0.4880.40
ii  w3m [www-browser]   0.5.3+git20230121-2

-- debconf information:
  munin/postrm_remove_rrd_files: false

-- debsums errors found:
debsums: changed file 
/usr/share/doc/munin/examples/systemd-fastcgi/munin-html.service (from munin 
package)

Bug#1051580: bookworm-pu: package gtk+3.0/3.24.38-2~deb12u1

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: gtk+...@packages.debian.org
Control: affects -1 + src:gtk+3.0

[ Reason ]
New upstream bugfix release. I started looking at cherry-picking these
changes to bookworm, but then decided that taking the new upstream
release in its entirety would be lower-risk.

[ Impact ]
Assorted bug fixes from upstream, some of them fixing known regressions
in 3.24.37, none of them with Debian bug numbers that I have been able
to correlate.

[ Tests ]
A prerelease (equivalent except for the changelog and version number) is
available in https://people.debian.org/~smcv/12.2/pool/main/g/gtk+3.0/,
and I have been using it for a couple of weeks on two bookworm GNOME
machines (a gaming desktop and my partner's laptop) with no obvious
regressions.

The same changes have been in testing and unstable since July.
Subsequent changes in unstable (enabling the libcloudproviders feature)
are intentionally not included.

[ Risks ]
Upstream considers GTK 3 to be a legacy version, so QA on GTK 3 changes
is not always as thorough as we would like. If there are regressions they
are likely to be of a magnitude similar to the bugs fixed here, and on
balance I think we are better off with these changes than without them.

All changes are narrowly-targeted bug fixes, except for the changes in
gtk/inspector/, which are only active when a special debugging UI is
enabled (by running apps with GTK_DEBUG=interactive, or enabling a dconf
setting and then using Ctrl+Shift+D/Ctrl+Shift+I shortcuts). The changes
in gtk/inspector/ are not really something I would normally say is stable
point release material, but they seem harmless enough, and don't seem worth
reverting.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  (filtered to exclude translations, deleted patches, and
  Windows-/macOS-only code)
  [x] the issue is verified as fixed in unstable

[ Changes ]
d/control.in, d/gbp.conf: Track the bookworm branch.

d/control: Automatically regenerated from d/control.in.
I don't know why this made Jeremy disappear from the Uploaders (possibly
because his name was variously spelled with/without the accent on the
í?) but this doesn't really matter for stable.

gdk/gdkgl.c:
- Fix application crash with "Couldn't find current GLX or EGL context"
  under unknown circumstances (gtk#5711 upstream, regression in 3.24.37)

gdk/gdkpixbuf-drawable.c (code change involving cairo_surface_mark_dirty):
- Fix a gnome-flashback crash when taking screenshots
  (gtk#5691, regression in 3.24.37)

gdk/gdkpixbuf-drawable.c (the rest), gtk/gtktext*.c, gtk/gtktreeview*.c:
- Documentation fixes

gdk/wayland/gdkdisplay-wayland.c:
- Fix application crash when running under Wayland with the
  cursor-theme-size GSetting set to 0 (gtk#5700)

gdk/wayland/gdkscreen-wayland.c:
- Ensure apps launched under Wayland after setting
  org.gtk.Settings.Modules will load the desired modules at startup
  (gtk!5733)

gdk/wayland/gdkwindow-wayland.c:
- Don't crash in Wayland environments that don't implement
  xdg_activation_v1, such as Enlightenment (Closes: #1043000)

gtk/gtkapplication-dbus.c:
- Fix a crash in gtk_application_set_screensaver_active() during
  app exit (gtk#5775)
  - this is an incomplete solution, and a post-3.24.38 follow-up
is needed to resolve #1051220, but I want to get that tested in
testing/unstable before backporting it

gtk/gtkfilechooserwidget.c, gtk/gtkfilesystemmodel.c, gtk/gtkpathbar.c:
- Silence GFileInfo warnings if used with a backported version of GLib
  (gtk!5645)

gtk/inspector:
- Show more information in the "inspector" debugging interface: Pango
  backend, input method module (gtk!5706, gtk#4512)

gtk/theme/Adwaita:
- Use a light colour for the caret in dark themes, making it much
  easier to see in some apps, in particular Evince (evince#1842)

testsuite/reftests/meson.build:
- testsuite: Disable some reftests that are not reliable

po/, po-properties/ (excluded from diff): Translation updates.

[ Other info ]
There are various other fixes queued up on upstream's gtk-3-24 branch
for release in 3.24.39, but no sign of an upstream release for them
so far. I want to give those changes some testing in testing/unstable
before proposing some or all of them for a stable update - I hope the
stable release managers won't mind reviewing a few smaller updates,
rather than one very large update?

The changes queued post-3.24.38 in gtk-3-24 do not include anything that
is obviously fixing a regression in the changes proposed here.

There *is* a change queued in gtk-3-24 fixing a regression in *3.24.37*
(#1051220), wich in theory already affects bookworm, although in practice
it is accidentally mitigated by 

Bug#1038389: dch bookworm patch

[Marcus Hanisch]

Hi all!

I also noticed that `dch` still uses bullseye as latest stable when 
using `dch --bpo`.


I had a quick look into it and came up with this patch:


--- /usr/bin/dch    2023-04-05 12:40:28.0 +0200
+++ /root/dch_bookworm    2023-09-10 01:07:09.625694923 +0200
@@ -163,7 +163,7 @@
  distribution name
   --bpo
  Increment the Debian release number for a backports upload
- to "bullseye-backports"
+ to "bookworm-backports"
   --stable
  Increment the Debian release number for a stable upload.
   -l, --local 
@@ -507,7 +507,7 @@
 if (defined $opt_D) {
 if ($vendor eq 'Debian') {
 unless ($opt_D
-    =~ 
/^(experimental|unstable|sid|UNRELEASED|((old){0,2}stable|testing|wheezy|jessie|stretch|buster|bullseye)(-proposed-updates|-security)?|proposed-updates)$/
+    =~ 
/^(experimental|unstable|sid|UNRELEASED|((old){0,2}stable|testing|wheezy|jessie|stretch|buster|bullseye|bookworm)(-proposed-updates|-security)?|proposed-updates)$/

 ) {
 my $deb_info = get_debian_distro_info();
 my ($oldstable_backports, $stable_backports) = ("", "");
@@ -530,9 +530,9 @@
   if $oldstable_backports;
 warn "$progname warning: Recognised distributions are: \n"
   . "experimental, unstable, testing, stable, 
oldstable, oldoldstable,\n"
-  . 
"{bullseye,buster,stretch,jessie,wheezy}-proposed-updates,\n"
+  . 
"{bookworm,bullseye,buster,stretch,jessie,wheezy}-proposed-updates,\n"
   . 
"{testing,stable,oldstable,oldoldstable}-proposed-updates,\n"

-  . "{bullseye,buster,stretch,jessie,wheezy}-security,\n"
+  . 
"{bookworm,bullseye,buster,stretch,jessie,wheezy}-security,\n"
   . 
"{testing,stable,oldstable,oldoldstable}}-security$oldstable_backports$stable_backports 
and UNRELEASED.\n"

   . "Using your request anyway.\n";
 $warnings++ if not $opt_force_dist;
@@ -673,7 +673,7 @@
 11, 'bullseye', 12, 'bookworm', 13, 'trixie'
 );
 my $lts_dist    = '9';
-my $latest_dist = '11';
+my $latest_dist = '12';
 # dist guessed from backports, SRU, security uploads...
 my $guessed_dist = '';
 my $CHANGES  = '';

I


Best greetings!


Marcus Hanisch

Bug#1051579: nomacs: segmentation fault in std::__atomic_base

[Vincent Lefevre]

Package: nomacs
Version: 3.17.2282+dfsg-2
Severity: important

I got a segmentation fault when doing "View -> Close Tab" then
a double click on a directory.

The latest messages:

[...]
[INFO] "/home/vinc17/photos-tmp/DCIM/chamonix/20230620_175745.jpg" does not 
exist - according to a fast check
[INFO] "/home/vinc17/private/appart/photo-porte.jpg" does not exist - according 
to a fast check
[WARNING] fromIccProfile: failed minimal tag size sanity
[INFO] [Basic Loader] "/home/vinc17/wd/images/normal.jpg" loaded in 4 ms
[INFO] [Basic Loader] "/home/vinc17/wd/images/gps-tracks/aubepin028.jpg" loaded 
in 4 ms
Error: XMP Toolkit error 203: Duplicate property or field node
Warning: Failed to decode XMP metadata.
[INFO] [Basic Loader] "/home/vinc17/wd/linux/joooj/stat/year2022.cpuload.png" 
loaded in 2 ms
[INFO] [Basic Loader] "/home/vinc17/wd/linux/joooj/stat/year2018.mail-e.png" 
loaded in 2 ms
[INFO] [Basic Loader] "/home/vinc17/wd/linux/joooj/stat/year2018.mail-n.png" 
loaded in 3 ms
[INFO] [Basic Loader] "/home/vinc17/wd/linux/joooj/stat/20210616.mail-n.png" 
loaded in 4 ms
[INFO] list updated in 75 ms
[INFO] [DkImageLoader] 10215 containers created in 222 ms
[INFO] [DkImageLoader] after sorting:  316 ms
[INFO] [Basic Loader] "/home/vinc17/photos-tmp/DCIM/20230825_112623.jpg" loaded 
in 78 ms
zsh: segmentation fault (core dumped)  nomacs .

According to gdb:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  std::__atomic_base::load (__m=std::memory_order_acquire, 
this=0xe4457b82fe3d7e0a) at /usr/include/c++/13/bits/atomic_base.h:835

warning: Source file is more recent than executable.
835 __glibcxx_assert(__b != memory_order_acq_rel);
[Current thread is 1 (Thread 0x7f3cfdb03cc0 (LWP 487325))]

I've attached the full backtrace.

This is reproducible:

1. Run "nomacs .".
2. Menu View -> Close Tab.
3. Double click on an arbitrary directory (this doesn't seem to matter).

Now, I get an additional warning:

[...]
[INFO] [Basic Loader] "/home/vinc17/wd/linux/joooj/stat/year2022.cpuload.png" 
loaded in 3 ms
[INFO] [Basic Loader] "/home/vinc17/wd/linux/joooj/stat/year2018.mail-e.png" 
loaded in 3 ms
[INFO] [Basic Loader] "/home/vinc17/wd/linux/joooj/stat/year2018.mail-n.png" 
loaded in 3 ms
[INFO] [Basic Loader] "/home/vinc17/wd/linux/joooj/stat/20210616.mail-n.png" 
loaded in 4 ms
[INFO] list updated in 68 ms
[WARNING] danger zone: viewport is queried before its initialization
[INFO] [DkImageLoader] 10215 containers created in 222 ms
[INFO] [DkImageLoader] after sorting:  323 ms
zsh: segmentation fault (core dumped)  nomacs .

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

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

Versions of packages nomacs depends on:
ii  libc6  2.37-8
ii  libexiv2-270.27.6-1
ii  libgcc-s1  13.2.0-3
ii  libopencv-core406  4.6.0+dfsg-13+b1
ii  libopencv-imgproc406   4.6.0+dfsg-13+b1
ii  libqt5concurrent5  5.15.10+dfsg-3
ii  libqt5core5a   5.15.10+dfsg-3
ii  libqt5gui5 5.15.10+dfsg-3
ii  libqt5network5 5.15.10+dfsg-3
ii  libqt5printsupport55.15.10+dfsg-3
ii  libqt5svg5 5.15.10-2
ii  libqt5widgets5 5.15.10+dfsg-3
ii  libquazip5-1   0.9.1-3
ii  libraw23   0.21.1-7
ii  libstdc++6 13.2.0-3
ii  libtiff6   4.5.1+git230720-1
ii  qt5-image-formats-plugins  5.15.10-2

Versions of packages nomacs recommends:
ii  nomacs-l10n  3.17.2282+dfsg-2

nomacs suggests no packages.

-- no debconf information

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

Thread 18 (Thread 0x7f3cb850d6c0 (LWP 487354)):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, 
abstime=0x7f3cb850cc90, op=137, expected=0, futex_word=0x7f3cd4010fa4) at 
./nptl/futex-internal.c:57
sc_cancel_oldtype = 0
__arg6 = 
__arg3 = 
_a5 = 
_a2 = 
sc_ret = 
__arg4 = 
__arg1 = 
_a6 = 
_a3 = 
resultvar = 
__arg5 = 
__arg2 = 
_a4 = 
_a1 = 
#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7f3cd4010fa4, 
expected=expected@entry=0, clockid=clockid@entry=1, 
abstime=abstime@entry=0x7f3cb850cc90, private=private@entry=0, 

Bug#1051578: bookworm-pu: package gtk4/4.8.3+ds-2+deb12u1

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: g...@packages.debian.org
Control: affects -1 + src:gtk4

[ Reason ]
User request in #1043261

[ Impact ]
Parts of the left sidebar in the file chooser dialog (File -> Open,
File -> Save As) are truncated if the window is narrow or the sidebar
contains items with a long name, especially if the accessibility option
for larger-than-default font size is turned on.

[ Tests ]
A prerelease (equivalent except for the changelog and version number) is
available in https://people.debian.org/~smcv/12.2/pool/main/g/gtk4/, and I
have been using it for a couple of weeks on two bookworm GNOME machines
(a gaming desktop and my partner's laptop) with no obvious regressions.

I was able to reproduce something resembling the bug report on bookworm,
and I confirm that this change avoided it.

The same change was in 4.9.3 in experimental and 4.10.x in testing/unstable.

[ Risks ]
I would say this is low risk: it's a targeted fix backported from
upstream, and all it does is to set the ellipsize property on more rows.

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

[ Changes ]
debian/patches/placessidebar-Make-all-rows-ellipsize.patch,
gtk/gtksidebarrow.c, gtk/ui/gtksidebarrow.ui:
Fix #1043261

debian/patches/gdk-x11-Reset-all-scroll-valuators-on-enter.patch:
Metadata changes only, no functional change

d/control.in, d/control, d/gbp.conf, d/watch:
Branch-related trivialities because this is the first bookworm update
for gtk4

[ Other info ]
There are various other fixes queued up on upstream's gtk-4-8 branch,
but I don't think they are going to do a 4.8.4 release with those fixes
included, or any particular QA of their own. We cannot directly test
4.8.x changes in testing/unstable any more, because testing/unstable
have been updated to the 4.10.x and then 4.12.x branches already.

If I find the time to assess impact vs risk for the rest of the gtk-4-8
changes, I'll propose another bookworm update with some or all of them -
but that doesn't seem likely to happen any time soon, and I hope that
reviewing more than one update won't increase the stable release team's
workload too much when compared with a single large cumulative update?

Thanks,
smcv
diffstat for gtk4-4.8.3+ds gtk4-4.8.3+ds

 debian/changelog |   11 ++
 debian/control   |2 
 debian/control.in|2 
 debian/gbp.conf  |2 
 debian/patches/gdk-x11-Reset-all-scroll-valuators-on-enter.patch |3 
 debian/patches/placessidebar-Make-all-rows-ellipsize.patch   |   46 ++
 debian/patches/series|3 
 debian/watch |2 
 gtk/gtksidebarrow.c  |5 -
 gtk/ui/gtksidebarrow.ui  |1 
 10 files changed, 67 insertions(+), 10 deletions(-)

diff -Nru gtk4-4.8.3+ds/debian/changelog gtk4-4.8.3+ds/debian/changelog
--- gtk4-4.8.3+ds/debian/changelog	2023-02-04 15:14:39.0 +
+++ gtk4-4.8.3+ds/debian/changelog	2023-09-09 20:32:02.0 +0100
@@ -1,3 +1,14 @@
+gtk4 (4.8.3+ds-2+deb12u1) bookworm; urgency=medium
+
+  * d/p/placessidebar-Make-all-rows-ellipsize.patch:
+Add patch from upstream gtk-4-8 branch to fix truncation in places
+sidebar with large text accessibility setting (Closes: #1043261)
+  * d/patches: Mark patch for #1029972 as also applied for 4.8.4
+  * d/watch: Only watch for versions 4.8.x for bookworm
+  * d/gbp.conf, d/control.in: Switch packaging branch to debian/bookworm
+
+ -- Simon McVittie   Sat, 09 Sep 2023 20:32:02 +0100
+
 gtk4 (4.8.3+ds-2) unstable; urgency=medium
 
   [ Jeremy Bicha ]
diff -Nru gtk4-4.8.3+ds/debian/control gtk4-4.8.3+ds/debian/control
--- gtk4-4.8.3+ds/debian/control	2023-02-04 15:14:39.0 +
+++ gtk4-4.8.3+ds/debian/control	2023-09-09 20:32:02.0 +0100
@@ -79,7 +79,7 @@
 Rules-Requires-Root: no
 Standards-Version: 4.6.2
 Vcs-Browser: https://salsa.debian.org/gnome-team/gtk4
-Vcs-Git: https://salsa.debian.org/gnome-team/gtk4.git
+Vcs-Git: https://salsa.debian.org/gnome-team/gtk4.git -b debian/bookworm
 Homepage: https://www.gtk.org/
 
 Package: libgtk-4-1
diff -Nru gtk4-4.8.3+ds/debian/control.in gtk4-4.8.3+ds/debian/control.in
--- gtk4-4.8.3+ds/debian/control.in	2023-02-04 15:14:39.0 +
+++ gtk4-4.8.3+ds/debian/control.in	2023-09-09 20:32:02.0 +0100
@@ -79,7 +79,7 @@
 Rules-Requires-Root: no
 Standards-Version: 4.6.2
 Vcs-Browser: https://salsa.debian.org/gnome-team/gtk4
-Vcs-Git: 

Bug#1051577: iproute2: obsolete conffiles

[gregor herrmann]

Package: iproute2
Version: 6.5.0-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

After upgrading to 6.5.0-1 adequate shows:

adequate found packaging bugs
- -

iproute2: obsolete-conffile /etc/iproute2/rt_tables.d/README
iproute2: obsolete-conffile /etc/iproute2/rt_protos.d/README
iproute2: obsolete-conffile /etc/iproute2/rt_protos
iproute2: obsolete-conffile /etc/iproute2/rt_dsfield
iproute2: obsolete-conffile /etc/iproute2/nl_protos
iproute2: obsolete-conffile /etc/iproute2/ematch_map
iproute2: obsolete-conffile /etc/iproute2/bpf_pinning

Cf. dpkg-maintscript-helper(1) and dh_installdeb(1) / package.maintscript
/ rm_conffile.

Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmT898hfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZ76hAAvpluUC3obOOsJfmXhh48GqVoLEt/7wg2B7WR73f21nGSTMUP+nzDSE8W
JwkGRIP8aT6eiHfh8zHj83Ey0r4IZ9g/OlMzyqCq7jDRzPo3fmy6Z3tJePGFO5Qg
nYmZwQA9DA+ANUi0A9BqNvgofguXh9KxIk5k2Gd2M8P5OBPvcXuVBuXtARwPljVw
7wA+niYFUyjkL1rgj1eBdiwzzldyUJiGC4/cve2fkmQyXqtocTqWjQTEXa1zYRGn
zRsCCyRdD0lJl/DqKTHspPyM/BAbWJbVnUPZ0Kn0LJAcvaUuOH+U4UAJTCshzaNM
XzuAHx39Hh90SbRYvikASBPJX3s1jhOBTuJkH6qWjgtgQfSyElvujHqzOwUr73xX
K5Ew9wDBAEbC5JDs4pLZGBQLUWmocQdAKRikPkScSqTpU+s/RIgwzg7uGsVK2tSo
dO7zN6Q08NusJT6T4c7AYgSEHiLsH0rIHA7jY/x9roZ+X57Hg36YRGLdIL5UG74k
1dIgRZh4CpJZdmD28x5lW5Zk2oKE+x3GDhiZKuhoKJBSfH4CbNbHc3n4PkAIlBAD
i2oxEkO20DwuJTiVmsQvDmYRWLOaSvA6Ffi02H78LQ3+QCFjXdKLIsm5Ex3wD7Me
p+tSaEI4OE3VeaFY5xXnr20PIVe/7cf7TUAseyLB59vQk17tSIk=
=dToJ
-END PGP SIGNATURE-

Bug#1051553: ITP: lib25519 -- X25519/Ed25519 microlibrary

[Simon Josefsson]

Jan Mojzis  writes:

> * Package name: lix25519
^ lib25519 I guess?

Otherwise looks good to me.

> I'm using this library and I'm going to maintain using 
> https://salsa.debian.org/
> I need sponsor for the first upload (I'm DM).

I would be happy to help review, co-maintain and upload this package.

/Simon


signature.asc
Description: PGP signature

Bug#1024367: In 4.9.1, the example uses not recommended install -s

[gregor herrmann]

On Sat, 09 Sep 2023 15:16:10 -0700, Russ Allbery wrote:

> I'm therefore going to propose fixing this bug with the following patch,
> which is more aggressive than you propose.
> 
> I think this is informative rather than normative and therefore
> technically doesn't require seconds, but I'll give this some time for
> other people to take a look and talk me out of deleting this section if
> they wish.

Looks good to me.

Cheers,
gregor 


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1050322: Partial versus complete replacement of a package by another

[Russ Allbery]

julien.pu...@gmail.com writes:

> Oh. I think I had two problems:
> (1) thinking "Replaces" meant "replaces" ;
> (2) thinking d/control controlled packages.

> Let me try to see if I'm getting at something:

> (*) Replaces doesn't really mean "can be used in place of"
> -- that would be expressed with Breaks+Provides.

> (*) Replaces shouldn't come without Breaks, but doesn't imply it
> so we have to put in both (why?).

Yes, this is a good question.  I recently was confused about this myself
despite having worked on Debian and maintained Policy and, at times,
Lintian for years, which implies that we don't do a very good job of
documenting the ins and outs of this.

https://lists.debian.org/debian-devel/2023/06/msg00354.html is the best
explanation of this that I've seen.  The short summary is that the one
case where Breaks is not required is if the package with Replaces also
depends on a new version of the package that it is replacing.  This
prevents the scenario described in the footnote.

The other thing that's worth noting is that sometimes you want Breaks and
sometimes you want Conflicts, and both Breaks and Conflicts are useful
without Replaces for other reasons, so none of them can really imply any
of the others.

I also saw your other bug (#1050221) about promoting that footnote to the
main text.  That's a partial fix, but I think we should include some
portion of Helmut's explanation directly in Policy as well.  (We sort of
say this, but we're not nearly as explicit about it as we could be, and we
don't use normative language.)

> (*) In 7.6.1's example, what happens if the system has foo 1.2-2 and
> the user tries to install foo-data 1.2-3? Do we end up with foo 1.2-2
> and foo-data 1.2-3 unpacked and apt/dpkg complaining it can't configure
> them or does it refuse with a clear error message?

It refuses to begin the operation because foo-data 1.2-3 breaks foo 1.2-2
and foo 1.2-2 is currently configured.  foo 1.2-2 has to be unconfigured
first before the installation of foo-data 1.2-3 can procede.  (This is
documented in Policy 7.3 where Breaks is discussed.)

What normally happens is that users use apt rather than dpkg directly.  I
believe apt will force an upgrade of foo because it sees that it is broken
by foo-data and will not allow installation of foo-data without either
upgrading or removing foo.  (dpkg does not do this because dpkg in general
operates on only the packages it's told to operate on and doesn't expand
the scope of one invocation to change other packages.)

-- 
Russ Allbery (r...@debian.org)  

Bug#1034356: gnome-shell: Frozen UI and massive log flodding

[Simon McVittie]

On Sun, 27 Aug 2023 at 10:56:20 +0200, H.-Dirk Schmitt wrote:
> Am Sonntag, dem 20.08.2023 um 12:17 +0100 schrieb Simon McVittie:
> > Please could you try installing the libgjs0g from here:
> > 
> > and then do whatever is necessary to reproduce the issue?
> 
> I have installed the update on my machine and will distribute the
> update to other maintained machines. 
> 
> I don't know a simple reproduction of the problem. Sometimes it appears
> shortly after login – sometimes it take days. 

You've now been testing this for about 2 weeks. Have you seen this bug's
symptoms again?

If it had not been fixed successfully, would you expect to have seen at
least one instance of it by now?

Are there any messages like this:

Apr 13 14:50:39 schroeder gnome-shell[6317]: Attempting to call back into JSAPI 
during the sweeping phase of GC. This is most likely caused by not destroying a 
Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be 
caused by using the destroy(), dispose(), or remove() vfuncs. Because it would 
crash the application, it has been blocked and the JS callback not invoked.

in the system log on any of the affected machines, but *without* the UI
freeze and log flooding?

Thanks,
smcv

Bug#1051576: bookworm-pu: package gjs/1.74.2-1+deb12u1

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: g...@packages.debian.org
Control: affects -1 + src:gjs

[ Reason ]
#1034356

[ Impact ]
If there is a particular category of programming error (something
not disconnecting all of its signal/idle/timeout handlers when it
should, for example #1049947 which seems most likely to be a bug in
gnome-shell-extension-vertical-overview) then the failure mode is an
infinite loop of assertion messages/stack traces, flooding the log and
(in the case of GNOME Shell) freezing the UI. With the change proposed
in this update, it should instead log O(1) assertion messages and stack
traces, then continue normally, avoiding the infinite loop.

[ Tests ]
A prerelease (equivalent except for the changelog and version number) is
available in https://people.debian.org/~smcv/12.2/pool/main/g/gjs/, and I
have been using it for a couple of weeks on two bookworm GNOME machines
(a gaming desktop and my partner's laptop) with no obvious regressions.

The submitter of #1034356/#1049947 has been testing the same prerelease
for 2 weeks, but they do not know how to reproduce the bug on-demand,
so it is not immediately clear whether it has been fixed. I sent a
reminder today asking them to report their test results.

The same change has been in unstable since 17 August with no obvious
regressions, and should be released in upstream 1.78.0 soon.

[ Risks ]
I would say this is low risk: it's a targeted fix backported from
upstream, changing the order of some operations so that on a programming
error, callbacks reliably return a zero-filled value (usually 0 or NULL)
instead of whatever happens to be in uninitialized memory.

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

[ Changes ]
All changes are for #1034356.
diffstat for gjs-1.74.2 gjs-1.74.2

 debian/changelog  |   12 +
 debian/patches/function-Always-initialize-callback-return-value.patch |   66 ++
 debian/patches/series |1 
 gi/function.cpp   |   18 +-
 4 files changed, 87 insertions(+), 10 deletions(-)

diff -Nru gjs-1.74.2/debian/changelog gjs-1.74.2/debian/changelog
--- gjs-1.74.2/debian/changelog	2023-02-21 12:13:29.0 +
+++ gjs-1.74.2/debian/changelog	2023-09-09 20:29:21.0 +0100
@@ -1,3 +1,15 @@
+gjs (1.74.2-1+deb12u1) bookworm; urgency=medium
+
+  * d/p/function-Always-initialize-callback-return-value.patch:
+Add patch backported from upstream 1.77.1 avoiding infinite loops
+of idle callbacks if an idle handler is called during GC. The most
+common reason for this is if a GNOME Shell extension incorrectly does
+not disconnect all of its signal/idle/timeout handlers. This change
+mitigates the infinite loop and associated log flooding, but does not
+fix the extension behaviour. (Closes: #1034356)
+
+ -- Simon McVittie   Sat, 09 Sep 2023 20:29:21 +0100
+
 gjs (1.74.2-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru gjs-1.74.2/debian/patches/function-Always-initialize-callback-return-value.patch gjs-1.74.2/debian/patches/function-Always-initialize-callback-return-value.patch
--- gjs-1.74.2/debian/patches/function-Always-initialize-callback-return-value.patch	1970-01-01 01:00:00.0 +0100
+++ gjs-1.74.2/debian/patches/function-Always-initialize-callback-return-value.patch	2023-09-09 20:29:21.0 +0100
@@ -0,0 +1,66 @@
+From: Sebastian Keller 
+Date: Thu, 16 Mar 2023 22:35:49 +0100
+Subject: function: Always initialize callback return value
+
+When callback_closure() exits early, for example due to being called
+during GC, the return value would not be initialized. This value is
+often non-zero. If the callback is a source func of an idle or a timeout
+this would then get interpreted as G_SOURCE_CONTINUE and the same would
+repeat in the next iteration. If this happens fast enough, this results
+in the entire process being seemingly frozen while spamming the log with
+error messages.
+
+To fix this always initialize the return value to 0 or a comparable
+neutral value.
+
+Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1868
+Bug-Debian: https://bugs.debian.org/1034356
+Forwarded: https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/832
+Applied-upstream: 1.77.1, commit:c925d91e5d018f38b0f66d0ac592274d4b007efb
+---
+ gi/function.cpp | 18 --
+ 1 file changed, 8 insertions(+), 10 deletions(-)
+
+diff --git a/gi/function.cpp b/gi/function.cpp
+index 08a0ea2..2fe4b2c 100644
+--- a/gi/function.cpp
 b/gi/function.cpp
+@@ -287,6 +287,14 @@ void GjsCallbackTrampoline::warn_about_illegal_js_callback(const char* when,
+ void 

Bug#1051247: muse-el: Choose living upstream for muse-el and merge updates

[David Bremner]

Manphiz  writes:

>
> Hi sten,
>
> When trying to pick a new upstream to rebase, I found that pulling
> either upstream repo will result in an incompatible git history versus
> the current debian/master branch on salsa.  I wonder how I should handle
> this?  Is it OK to force push to master?  Will it affect existing
> annotated tags?

Please don't force push the public history. There are various ways to
"fake merge" that are preferable.

Bug#1031403: debian-policy: missing quotes in sh script example in file policy/ap-pkg-diversions

[Russ Allbery]

Control: tags -1 pending

Max-Julian Pogner  writes:

> consulting the debian policy manual whether it contains suggestions how
> to best implement diversions (see `man dpkg-divert`), i noticed syntax
> errors in the provided shell script example snippets.

> a patch fixing these typos is attached.

Thanks, applied for the next Policy release.

-- 
Russ Allbery (r...@debian.org)  

Bug#1051575: brotli: please package new upstream release

[Andres Salomon]

Package: brotli
Version: 1.0.9-2
Severity: wishlist

Chromium fails to build against the version of brotli that's in Debian, 
as it started requiring BrotliDecoderAttachDictionary 
(). 
I can revert that for now, but it would be great to get an updated 
broli in Debian.


Brotli 1.1.0 was released last week. Please consider packaging it.

Thanks,
Andres

Bug#1024367: In 4.9.1, the example uses not recommended install -s

[Russ Allbery]

Enrico Zini  writes:

> Hello, and thank you for maintaining the Policy!

> Policy paragraph 4.9.1 has an example debian/rules which contains these
> lines:

>INSTALL_PROGRAM = $(INSTALL) -p-o root -g root  -m  755

>ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
>INSTALL_PROGRAM += -s
>endif

> However, paragraph 10.1 recommends against it:

>It is not recommended to strip binaries by passing the "-s" flag to
>"install", because this fails to remove .comment and .note sections,
>and also prevents the automatic creation of dbgsym binary packages by
>tools like "dh_strip".

> I would personally prefer if the example built on debhelper. If the
> intention is to show what are the expectations at a lower level then
> I wish the example had a comment saying "This snippet serves to explain
> what are the expectations as a lower level. You usually want to use
> debhelper instead"

I looked at this snippet and I think it has worse problems than the use of
install -s.  For example, it predates the existence of dpkg-buildflags,
which would also handle noopt.  I'm also dubious that it serves any useful
purpose given that nearly every package should just use debhelper.  The
typical current Debian packager seems more likely to be confused by this
fragment than aided by it.

I'm therefore going to propose fixing this bug with the following patch,
which is more aggressive than you propose.

I think this is informative rather than normative and therefore
technically doesn't require seconds, but I'll give this some time for
other people to take a look and talk me out of deleting this section if
they wish.

-- 
Russ Allbery (r...@debian.org)  

>From 409bbd815a946a7bb7b1eea8cab8198c494dd7d4 Mon Sep 17 00:00:00 2001
From: Russ Allbery 
Date: Sat, 9 Sep 2023 15:10:21 -0700
Subject: [PATCH] Remove old Makefile DEB_BUILD_OPTIONS example

The correct way to implement most DEB_BUILD_OPTIONS these days is
to just use debhelper. The detailed Makefile fragment was probably
more confusing than helpful, given that it predates dpkg-buildflags,
uses install -s (which Policy elsewhere recommends against), and
manually does other work debhelper would automate. Replace it with
a note that packaging helper frameworks do much of this work.
---
 policy/ch-source.rst | 35 +++
 1 file changed, 3 insertions(+), 32 deletions(-)

diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index 4307e89..b6f2c86 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -588,38 +588,9 @@ The meaning of the following tags has been standardized:
 
 Unknown flags must be ignored by ``debian/rules``.
 
-The following makefile snippet is an example of how one may implement
-the build options; you will probably have to massage this example in
-order to make it work for your package.
-
-.. code-block:: Makefile
-
-CFLAGS = -Wall -g
-INSTALL = install
-INSTALL_FILE= $(INSTALL) -p-o root -g root  -m  644
-INSTALL_PROGRAM = $(INSTALL) -p-o root -g root  -m  755
-INSTALL_SCRIPT  = $(INSTALL) -p-o root -g root  -m  755
-INSTALL_DIR = $(INSTALL) -p -d -o root -g root  -m  755
-
-ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
-CFLAGS += -O0
-else
-CFLAGS += -O2
-endif
-ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
-INSTALL_PROGRAM += -s
-endif
-ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
-NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
-MAKEFLAGS += -j$(NUMJOBS)
-endif
-
-build:
-# ...
-ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-# Code to run the package test suite.
-endif
-
+Packaging helper frameworks such as debhelper will automatically support
+many of these options without any further work required by the package
+maintainer.
 
 .. _s-debianrules-gainrootapi:
 
-- 
2.40.1

Bug#1051471: btrfsd: cron job for calling btrfsd

[Matthias Klumpp]

Hi Martin!

Am Fr., 8. Sept. 2023 um 15:24 Uhr schrieb Martin :
> [...]
> would you consider to include a cron job into the package in order to
> make btrfsd installable on systems without Systemd? Of course a change
> regarding package dedepencies would also be required.

Sure, that should actually be extremely low-maintenance, there isn't
any hard dependency the daemon has on systemd - with one exception: It
uses libsystemd to write to the journal if that's available, and I
would like to keep that feature. It will however already fall back to
syslog in case sd-journal isn't available, and libsystemd is inert on
systems without systemd.

> I have seen btrfsd in mailing list "debian-devel-changes" but could not
> find it on my Devuan system.
>
> If yes, I would aim to provide a merge request.

This could go upstream, I think.
I do not know if there is a no-overhead way to ship both the cron job
and systemd timer in the same package with recompilation. But if
that's not possible, I think at the very least we could provide a
configuration option upstream to select one or the other, so
derivatives that don't use systemd could switch to the cron version by
simply recompiling the package (by checking dpkg vendor strings).

What do you think? Unfortunately I know little how to make both
systems interoperate and avoid having the timer and cron job calling
the service, so patches would be very welcome.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1051542: texlive-extra-utils: a5toa4 fails to generate pdf: No such file or directory

[Preuße]

On 09.09.2023 15:23, Christian Weiske wrote:

Hi Christian,


Using a5toa4 fails in a very simple case:


cweiske:~> a5toa4 a5.pdf
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian) 
(preloaded format=pdflatex)
  restricted \write18 enabled.
entering extended mode
/usr/share/texlive/texmf-dist/scripts/pfarrei/pfarrei.tlu:114: 
pfarrei.xt9z35/a5.pdf: No such file or directory


The temp directory does not contain the pdf file:


$ ls -l1 pfarrei.xt9z35/
insgesamt 16
-rw-r--r-- 1 cweiske cweiske8  9. Sep 15:21 a5.aux
-rw-r--r-- 1 cweiske cweiske 7062  9. Sep 15:21 a5.log
-rw-r--r-- 1 cweiske cweiske   45  9. Sep 15:21 a5.tex


It seems the tool does not copy my pdf file to the temporary directory.



Seems to be a long standing issue [1]. Are you willing to contact the 
upstream author of the pfarrei package? I don't really have the time to 
care about upstream issues.


Hilmar

[1] https://golatex.de/viewtopic.php?t=24521
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#949258: debian-policy: Support negated architecture specifications in debian/control Architecture field

[Russ Allbery]

Samuel Thibault  writes:

> I didn't find a previous discussion on this: it would be useful to
> support negated architecture specifications in the debian/control
> Architecture field, so that we can e.g. write:

> Architecture: !s390 !s390x
> (for xorg stuff)

> Architecture: !hppa !hurd-any !kfreebsd-any
> (for java stuff)

> and even things like

> Architecture: linux-any kfreebsd-any !hppa !m68k-any

> which would be understood as [ (linux-any or kfreebsd-any) and not hppa
> and not m68k-any ]. I.e. if no positive specification is set, an "any"
> positive specification is assumed.

> That would help to remove quite a few entries of
> https://buildd.debian.org/quinn-diff/experimental/Packages-arch-specific
> and avoid packages with some java bits to have to hardcode the list of
> ports on which java jni bindings packages should be built.

> I guess support would be needed in dpkg, lintian, etc.

Hi Samuel,

I agree that this would be useful.  This has come up frequently over the
years, and back when I was maintaining architecture-specific packages, the
lack of this feature was often annoying.

But (as may be obvious from the long delay in even getting a response),
Policy can't drive the implementation of this change and therefore
probably isn't a good place to start with the request.  I think it would
need to start with dpkg and ftp-master (for DAK).  I'm therefore probably
going to have to close this bug against Policy as unactionable since I
don't know of any efforts towards implementing this support, and Policy
would only be able to change once the support is available.

If I misunderstood the current state, please do let me know.

-- 
Russ Allbery (r...@debian.org)  

Bug#1029211: debian-policy: Add mention of the new non-free-firmware archive area

[Russ Allbery]

Gunnar Wolf  writes:

> It has been four months since the General Resolution 2022/vote_003 was
> voted¹, but it has not yet been completely adopted. The archive area was
> created and at least a package was uploaded to it in October, but it has
> not seen further movement. Two days ago, a call to action for moving
> packages was sent by Cyril Brulebois², and I just sent a mail checking
> for other places where it should be included³.

> ¹ https://www.debian.org/vote/2022/vote_003
> ² https://lists.debian.org/debian-boot/2023/01/msg00150.html
> ³ https://lists.debian.org/debian-project/2023/01/msg00018.html

> To my surprise, the non-free-firmware archive area has not yet been
> discussed for inclusion in the Policy.

> I am (now!) aware there is a clear process to get changes included in
> the Policy, but this is the first time I do this, so please excuse me
> for jumping all the way to "State D: Wording proposed" (of course, my
> words can be checked and improved, particularly given I'm not a native
> English speaker).

> ⁴ https://www.debian.org/doc/debian-policy/ap-process.html

> I am suggesting the following patch, which I'm attaching to this bug
> report, and also uploaded them to my fork of debian-policy in Salsa:

> 
> https://salsa.debian.org/gwolf/policy/-/commit/79c58a40065c01f56850f86e883d8fa482c7cca0

Thank you!  I also second this change, and have merged it for the next
version of Policy, including the fixes suggested by James Addison.  I
numbered the footnotes in chapter two so that both non-free and
non-free-firmware could reference the same footnote.

An editorial note: Gunnar's patch introduced non-free-firmware after main
and before contrib and non-free, and after some consideration I kept that
order because I think it reflects the high likelihood that the typical
user will encounter the non-free-firmware archive area given the results
of the GR.  That does mean that the contrib and non-free sections have
been renumbered to 2.2.3 and 2.2.4, which resurrects a section 2.2.4 that
previously was for non-US back when we had cryptography restrictions.  I
don't think this will cause any actual problems (and one of my long-term
wishlist items is for Policy to rely less on section numbering, which is
inherently unstable, and switch to some sort of persistent ID), but it
seemed worth mentioning.

-- 
Russ Allbery (r...@debian.org)  

Bug#1051574: icebreaker: uploader email address maybe invalid

[Ben Tris]

Source: icebreaker
Version: 2.2.0-1
Severity: minor
X-Debbugs-Cc: benatt...@gezapig.nl, m...@qa.debian.org

Dear Maintainer,

The email under uploader Andreas Gnau is now
 this is not found in qa.
I could not find more info.


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

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

Bug#1051573: bambootracker: FTBFS with RtAudio 6

[IOhannes m zmoelnig]

Source: bambootracker
Version: 0.6.1-1
Severity: serious
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

bambootracker ftbfs with RtAudio 6 (currently found in experimental).

```
g++ -c -pipe -g -O2 
-ffile-prefix-map=/build/bambootracker-CzYJbF/bambootracker-0.6.1=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 
-std=gnu++1y -pthread -pthread -Wall -Wextra -Wall -Wextra -Werror -pedantic 
-pedantic-errors -D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS -D__LINUX_ALSA__ 
-D__LINUX_PULSE__ -D__UNIX_JACK__ -D_REENTRANT -DQT_NO_DEBUG -DQT_WIDGETS_LIB 
-DQT_GUI_LIB -DQT_CORE_LIB -I. -Iinstrument -Imodule 
-I../submodules/emu2149/src -I/usr/include/rtaudio -I/usr/include/rtmidi 
-I/usr/include/x86_64-linux-gnu/qt5 
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets 
-I/usr/include/x86_64-linux-gnu/qt5/QtGui 
-I/usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I. 
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o audio_stream_rtaudio.o 
audio/audio_stream_rtaudio.cpp
audio/audio_stream_rtaudio.cpp: In member function ‘virtual bool 
AudioStreamRtAudio::initialize(uint32_t, uint32_t, uint32_t, const QString&, 
const QString&, QString*)’:
audio/audio_stream_rtaudio.cpp:82:16: error: ‘RtAudioError’ does not name a 
type; did you mean ‘RtAudioErrorType’?
   82 | catch (RtAudioError& error) {
  |^~~~
  |RtAudioErrorType
audio/audio_stream_rtaudio.cpp:83:17: error: ‘error’ was not declared in this 
scope; did you mean ‘perror’?
   83 | error.printMessage();
  | ^
  | perror
make: *** [Makefile:4064: audio_stream_rtaudio.o] Error 1
```

Attached is a patch that fixes the FTBFS (but is otherwise untested).
No debdiff this time, sorry.

cheers.
Description: Fix FTBFS with RtAudio6
 Replace try/catch with check for return code
Author: IOhannes m zmölnig
Origin: Debian
Forwarded: no
Last-Update: 2023-09-09
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: bambootracker-0.6.1/BambooTracker/audio/audio_stream_rtaudio.cpp
===
--- bambootracker-0.6.1.orig/BambooTracker/audio/audio_stream_rtaudio.cpp
+++ bambootracker-0.6.1/BambooTracker/audio/audio_stream_rtaudio.cpp
@@ -73,16 +73,15 @@ bool AudioStreamRtAudio::initialize(uint
 
unsigned int bufferSize = rate * duration / 1000;
bool isSuccessed = false;
-   try {
-   audio->openStream(, nullptr, RTAUDIO_SINT16, rate, 
, callback, this, );
if (errDetail) *errDetail = "";
-   isSuccessed = true;
-   rate = audio->getStreamSampleRate();// Match to real rate 
(for ALSA)
-   }
-   catch (RtAudioError& error) {
-   error.printMessage();
-   if (errDetail) *errDetail = 
QString::fromStdString(error.getMessage());
-   }
+   if (audio->openStream(, nullptr, RTAUDIO_SINT16, rate, 
, callback, this, )) {
+   std::string err = audio->getErrorText();
+   std::cerr << err << std::endl;
+   if (errDetail) *errDetail = QString::fromStdString(err);
+   } else {
+   isSuccessed = true;
+   rate = audio->getStreamSampleRate();// Match to 
real rate (for ALSA)
+   }
 
AudioStream::initialize(rate, duration, intrRate, backend, device);
return isSuccessed;

Bug#1051314: fonts-recommended: recognise noto-core as alternative to dejavu-core

[Gunnar Hjalmarsson]

Adam Borowski wrote:

On Wed, Sep 06, 2023 at 07:22:36AM +0100, Justin B Rye wrote:

Various major desktops now default to fonts-noto-core instead of
fonts-dejavu-core.   During a conversation with a
fontconfig-config maintainer on debian-l10n-english about the
knock-on effects
("https://lists.debian.org/debian-l10n-english/2023/09/msg1.html;)
I noticed that the dependency chains ensuring that fonts-noto-core
is actually installed at all are surprisingly weak.


After our conversation I made two installs for test purposes:

1. Debian 12 with GNOME
   Result: fonts-noto-core was not included by default.

2. Debian trixie with GNOME
   Result: fonts-noto-core was included by default.

I suspect that the change can be explained by this commit:
https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/5aa10dde


Alas, noto has the downside of making font pickers next to useless,
as it declares every single of languages it supports as a separate
font family. So instead off just "Noto Sans" "Noto Mono" "Noto
Slightly Serifed", you have "Noto Western Klingon" "Noto Eastern
Klingon" and so on, making the list of available fonts one big noto
fest.


If you assume that users often want to change much, I can understand 
that you see that as a disadvantage. OTOH, a user who wants to do it 
differently can uninstall fonts-noto-core and with that get a 
significantly shorter list.


Myself is involved in changing the default selection of fonts and font 
configuration for Ubuntu. In that context we focus on offering the users 
a sensible default, which most users are comfortable with, and the way 
Noto provides different fonts for different scripts and purposes is an 
advantage to achieve that. Ubuntu is about to prefer Noto for most 
scripts, but to the extent exceptions proves to be motivated, that can 
be handled relatively easy via font configuration. Something that would 
have been harder with DejaVu Sans as the preferred font.



I have no firm opinion, at least not yet, on the role of 
fonts-recommended and whether the proposed change is motivated. But I 
just posted a list message about the ongoing transition from DejaVu to 
Noto, to reach a broader audience:


https://lists.debian.org/debian-devel/2023/09/msg00053.html

Do feel encouraged to respond to it.

--
Cheers,
Gunnar Hjalmarsson

Bug#1051572: python-anyjson: uploader email address maybe invalid

[Ben Tris]

Source: python-anyjson
Version: 0.3.3-5
Severity: minor
X-Debbugs-Cc: benatt...@gezapig.nl, fl...@debian.org, m...@qa.debian.org

Dear Maintainer,

The email under uploader Michael Fladischer  is now
 this is not found in qa. (diff is underscore)
Probably it should be . (active uploader)


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

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

Bug#1050639: bookworm-pu: package clamav/1.0.2+dfsg-1~deb12u1

[Sebastian Andrzej Siewior]

On 2023-08-27 13:20:01 [+0200], To sub...@bugs.debian.org wrote:
> Package: release.debian.org
> Control: affects -1 + src:clamav
> User: release.debian@packages.debian.org
> Usertags: pu
> Tags: bookworm
> Severity: normal

This is a quick update that I updated to 1.0.3+dfsg-1~deb12u1 as of
today. The diff mostly a version update. I additionally removed a log
line from freshclam which logged harmless 304 "not modified" requests.
This line was added in 1.0.0 and people complained, it got in as of
1.0.0 and is already removed in 1.1.x and later.

The main reason for 1.0.3 was the unrar update and I updated so clamav
does not complain about the lower version.

It would be nice if this could be made available via d/updates.

Sebastian
diff -Nru clamav-1.0.2+dfsg/CMakeLists.txt clamav-1.0.3+dfsg/CMakeLists.txt
--- clamav-1.0.2+dfsg/CMakeLists.txt	2023-08-16 00:24:07.0 +0200
+++ clamav-1.0.3+dfsg/CMakeLists.txt	2023-08-25 23:18:34.0 +0200
@@ -22,7 +22,7 @@
 set(VERSION_SUFFIX "")
 
 project( ClamAV
- VERSION "1.0.2"
+ VERSION "1.0.3"
  DESCRIPTION "ClamAV open source email, web, and end-point anti-virus toolkit." )
 
 set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake" ${CMAKE_MODULE_PATH})
diff -Nru clamav-1.0.2+dfsg/debian/changelog clamav-1.0.3+dfsg/debian/changelog
--- clamav-1.0.2+dfsg/debian/changelog	2023-08-27 11:35:11.0 +0200
+++ clamav-1.0.3+dfsg/debian/changelog	2023-09-09 16:36:13.0 +0200
@@ -1,3 +1,10 @@
+clamav (1.0.3+dfsg-1~deb12u1) bookworm; urgency=medium
+
+  * Import 1.0.3
+  * Remove unnecessary warning messages in freshclam during update.
+
+ -- Sebastian Andrzej Siewior   Sat, 09 Sep 2023 16:36:13 +0200
+
 clamav (1.0.2+dfsg-1~deb12u1) bookworm; urgency=medium
 
   * Import 1.0.2 (Closes: #1050057)
diff -Nru clamav-1.0.2+dfsg/debian/.git-dpm clamav-1.0.3+dfsg/debian/.git-dpm
--- clamav-1.0.2+dfsg/debian/.git-dpm	2023-08-27 11:35:11.0 +0200
+++ clamav-1.0.3+dfsg/debian/.git-dpm	2023-09-09 16:35:33.0 +0200
@@ -1,8 +1,8 @@
 # see git-dpm(1) from git-dpm package
-de9cef7ab6e5a57247f9598340a0e64869429870
-de9cef7ab6e5a57247f9598340a0e64869429870
-7b4b490a9f8c93c9ef66c8d34be648796dd9f7bd
-7b4b490a9f8c93c9ef66c8d34be648796dd9f7bd
-clamav_1.0.2+dfsg.orig.tar.xz
-c845d2c777adda943e7421c601924e1bee1864a8
-14134372
+b6798c1c1c1bd4e43f1ffbc36748adb5cf07787a
+b6798c1c1c1bd4e43f1ffbc36748adb5cf07787a
+6aeff1ef1ff425a1a201d8e3f2c5b8b1f8a60fdb
+6aeff1ef1ff425a1a201d8e3f2c5b8b1f8a60fdb
+clamav_1.0.3+dfsg.orig.tar.xz
+329456b2e5930a422859b00ed0e08cc8ab53e2b3
+14191252
diff -Nru clamav-1.0.2+dfsg/debian/libclamav11.symbols clamav-1.0.3+dfsg/debian/libclamav11.symbols
--- clamav-1.0.2+dfsg/debian/libclamav11.symbols	2023-08-27 11:35:11.0 +0200
+++ clamav-1.0.3+dfsg/debian/libclamav11.symbols	2023-09-09 16:36:13.0 +0200
@@ -1,25 +1,25 @@
 libclamav.so.11 libclamav11 #MINVER#
 * Build-Depends-Package: libclamav-dev
- CLAMAV_PRIVATE@CLAMAV_PRIVATE 1.0.2
+ CLAMAV_PRIVATE@CLAMAV_PRIVATE 1.0.3
  CLAMAV_PUBLIC@CLAMAV_PUBLIC 1.0.0
- __cli_strcasestr@CLAMAV_PRIVATE 1.0.2
- __cli_strndup@CLAMAV_PRIVATE 1.0.2
- __cli_strnlen@CLAMAV_PRIVATE 1.0.2
- __cli_strnstr@CLAMAV_PRIVATE 1.0.2
- base64Flush@CLAMAV_PRIVATE 1.0.2
- blobAddData@CLAMAV_PRIVATE 1.0.2
- blobCreate@CLAMAV_PRIVATE 1.0.2
- blobDestroy@CLAMAV_PRIVATE 1.0.2
- cl_ASN1_GetTimeT@CLAMAV_PRIVATE 1.0.2
+ __cli_strcasestr@CLAMAV_PRIVATE 1.0.3
+ __cli_strndup@CLAMAV_PRIVATE 1.0.3
+ __cli_strnlen@CLAMAV_PRIVATE 1.0.3
+ __cli_strnstr@CLAMAV_PRIVATE 1.0.3
+ base64Flush@CLAMAV_PRIVATE 1.0.3
+ blobAddData@CLAMAV_PRIVATE 1.0.3
+ blobCreate@CLAMAV_PRIVATE 1.0.3
+ blobDestroy@CLAMAV_PRIVATE 1.0.3
+ cl_ASN1_GetTimeT@CLAMAV_PRIVATE 1.0.3
  cl_always_gen_section_hash@CLAMAV_PUBLIC 1.0.0
- cl_base64_decode@CLAMAV_PRIVATE 1.0.2
- cl_base64_encode@CLAMAV_PRIVATE 1.0.2
- cl_cleanup_crypto@CLAMAV_PRIVATE 1.0.2
+ cl_base64_decode@CLAMAV_PRIVATE 1.0.3
+ cl_base64_encode@CLAMAV_PRIVATE 1.0.3
+ cl_cleanup_crypto@CLAMAV_PRIVATE 1.0.3
  cl_countsigs@CLAMAV_PUBLIC 1.0.0
  cl_cvdfree@CLAMAV_PUBLIC 1.0.0
  cl_cvdhead@CLAMAV_PUBLIC 1.0.0
  cl_cvdparse@CLAMAV_PUBLIC 1.0.0
- cl_cvdunpack@CLAMAV_PRIVATE 1.0.2
+ cl_cvdunpack@CLAMAV_PRIVATE 1.0.3
  cl_cvdverify@CLAMAV_PUBLIC 1.0.0
  cl_debug@CLAMAV_PUBLIC 1.0.0
  cl_engine_addref@CLAMAV_PUBLIC 1.0.0
@@ -28,7 +28,7 @@
  cl_engine_get_num@CLAMAV_PUBLIC 1.0.0
  cl_engine_get_str@CLAMAV_PUBLIC 1.0.0
  cl_engine_new@CLAMAV_PUBLIC 1.0.0
- cl_engine_set_clcb_engine_compile_progress@CLAMAV_PRIVATE 1.0.2
+ cl_engine_set_clcb_engine_compile_progress@CLAMAV_PRIVATE 1.0.3
  cl_engine_set_clcb_file_inspection@CLAMAV_PUBLIC 1.0.0
  cl_engine_set_clcb_file_props@CLAMAV_PUBLIC 1.0.0
  cl_engine_set_clcb_hash@CLAMAV_PUBLIC 1.0.0
@@ -37,7 +37,7 @@
  cl_engine_set_clcb_pre_cache@CLAMAV_PUBLIC 1.0.0
  cl_engine_set_clcb_pre_scan@CLAMAV_PUBLIC 1.0.0
  cl_engine_set_clcb_sigload@CLAMAV_PUBLIC 1.0.0
- cl_engine_set_clcb_sigload_progress@CLAMAV_PRIVATE 1.0.2
+ 

Bug#1050638: bullseye-pu: package clamav/0.103.9+dfsg-0+deb11u1

[Sebastian Andrzej Siewior]

On 2023-08-27 13:20:09 [+0200], To sub...@bugs.debian.org wrote:
> Package: release.debian.org
> Control: affects -1 + src:clamav
> User: release.debian@packages.debian.org
> Usertags: pu
> Tags: bullseye
> Severity: normal

This is a quick update that I updated to 0.103.10+dfsg-0+deb11u1 as of
today. The diff mostly a version update.

The main reason for 1.0.3 was the unrar update and I updated so clamav
does not complain about the lower version.

It would be nice if this could be made available via d/updates.

Sebastian
diff -Nru clamav-0.103.9+dfsg/CMakeLists.txt clamav-0.103.10+dfsg/CMakeLists.txt
--- clamav-0.103.9+dfsg/CMakeLists.txt	2023-08-16 08:21:10.0 +0200
+++ clamav-0.103.10+dfsg/CMakeLists.txt	2023-08-28 09:15:02.0 +0200
@@ -15,7 +15,7 @@
 set(VERSION_SUFFIX "")
 
 project( ClamAV
- VERSION "0.103.9"
+ VERSION "0.103.10"
  DESCRIPTION "ClamAV open source email, web, and end-point anti-virus toolkit." )
 
 set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake" ${CMAKE_MODULE_PATH})
diff -Nru clamav-0.103.9+dfsg/configure clamav-0.103.10+dfsg/configure
--- clamav-0.103.9+dfsg/configure	2023-08-16 08:21:37.0 +0200
+++ clamav-0.103.10+dfsg/configure	2023-08-28 09:15:31.0 +0200
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for ClamAV 0.103.9.
+# Generated by GNU Autoconf 2.69 for ClamAV 0.103.10.
 #
 # Report bugs to .
 #
@@ -592,8 +592,8 @@
 # Identity of this package.
 PACKAGE_NAME='ClamAV'
 PACKAGE_TARNAME='clamav'
-PACKAGE_VERSION='0.103.9'
-PACKAGE_STRING='ClamAV 0.103.9'
+PACKAGE_VERSION='0.103.10'
+PACKAGE_STRING='ClamAV 0.103.10'
 PACKAGE_BUGREPORT='https://github.com/Cisco-Talos/clamav/issues'
 PACKAGE_URL='https://www.clamav.net/'
 
@@ -1606,7 +1606,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures ClamAV 0.103.9 to adapt to many kinds of systems.
+\`configure' configures ClamAV 0.103.10 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1687,7 +1687,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of ClamAV 0.103.9:";;
+ short | recursive ) echo "Configuration of ClamAV 0.103.10:";;
esac
   cat <<\_ACEOF
   --enable-dependency-tracking
@@ -1922,7 +1922,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-ClamAV configure 0.103.9
+ClamAV configure 0.103.10
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2550,7 +2550,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by ClamAV $as_me 0.103.9, which was
+It was created by ClamAV $as_me 0.103.10, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -4308,7 +4308,7 @@
 
 # Define the identity of the package.
  PACKAGE='clamav'
- VERSION='0.103.9'
+ VERSION='0.103.10'
 
 
 # Some tools Automake needs.
@@ -6036,7 +6036,7 @@
 $as_echo "#define PACKAGE PACKAGE_NAME" >>confdefs.h
 
 
-VERSION="0.103.9"
+VERSION="0.103.10"
 
 major=`echo $PACKAGE_VERSION |cut -d. -f1 | sed -e "s/^0-9//g"`
 minor=`echo $PACKAGE_VERSION |cut -d. -f2 | sed -e "s/^0-9//g"`
@@ -31896,7 +31896,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by ClamAV $as_me 0.103.9, which was
+This file was extended by ClamAV $as_me 0.103.10, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -31963,7 +31963,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-ClamAV config.status 0.103.9
+ClamAV config.status 0.103.10
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
@@ -34813,7 +34813,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by ClamAV $as_me 0.103.9, which was
+This file was extended by ClamAV $as_me 0.103.10, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -34880,7 +34880,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-ClamAV config.status 0.103.9
+ClamAV config.status 0.103.10
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
diff -Nru clamav-0.103.9+dfsg/configure.ac clamav-0.103.10+dfsg/configure.ac
--- clamav-0.103.9+dfsg/configure.ac	

Bug#965009: ratt: Please allow passing through options to sbuild

[IOhannes m zmoelnig]

Package: ratt
Version: 0.0~git20190123.9e77a6d-1+b7
Followup-For: Bug #965009

Dear Maintainer,

i was going to do a feature request of this too (but luckily checked the BTS
first).

in any case, i'm aware of ~/.sbuildrc.

in my case, this file is already heavily customized and for that is actually the
reason why i want to add some additional overrides when invoking ratt. (e.g.
for a quick test which packages FTBFS i don't really want to run lintian and
autopkgtests)

maintaining a separate sbuild-configuration file (via SBUILD_CONFIG) seems like
overkill.


cheers.


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

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

Versions of packages ratt depends on:
ii  libc6   2.37-8
ii  sbuild  0.85.2

Versions of packages ratt recommends:
ii  dose-extra  7.0.0-4

ratt suggests no packages.

-- no debconf information

Bug#1051570: mlt: FTBFS with RtAudio 6

[IOhannes m zmoelnig]

Source: mlt
Version: 7.18.0-2
Severity: serious
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

mlt ftbfs with RtAudio 6 (currently in experimental).

```
[ 89%] Building CXX object 
src/modules/rtaudio/CMakeFiles/mltrtaudio.dir/consumer_rtaudio.cpp.o
cd /build/mlt-zme0kO/mlt-7.18.0/obj-x86_64-linux-gnu/src/modules/rtaudio && 
/usr/lib/ccache/c++ -Dmltrtaudio_EXPORTS 
-I/build/mlt-zme0kO/mlt-7.18.0/src/framework/.. -isystem /usr/include/rtaudio 
-g -O2 -ffile-prefix-map=/build/mlt-zme0kO/mlt-7.18.0=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 
-std=c++14 -fPIC -mmmx -msse -msse2 -pthread -D__LINUX_ALSA__ -D__LINUX_PULSE__ 
-D__UNIX_JACK__ -D_REENTRANT -MD -MT 
src/modules/rtaudio/CMakeFiles/mltrtaudio.dir/consumer_rtaudio.cpp.o -MF 
CMakeFiles/mltrtaudio.dir/consumer_rtaudio.cpp.o.d -o 
CMakeFiles/mltrtaudio.dir/consumer_rtaudio.cpp.o -c 
/build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp
/build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp: In 
member function ‘bool RtAudioConsumer::create_rtaudio(RtAudio::Api, int, int)’:
/build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp:164:26: 
error: ‘struct RtAudio::DeviceInfo’ has no member named ‘probed’
  164 | if (info.probed && info.name == resource) {
  |  ^~
/build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp:212:16: 
error: ‘RtAudioError’ does not name a type; did you mean ‘RtAudioErrorType’?
  212 | catch (RtAudioError ) {
  |^~~~
  |RtAudioErrorType
In file included from 
/build/mlt-zme0kO/mlt-7.18.0/src/framework/../framework/mlt.h:50,
 from 
/build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp:20:
/build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp:214:49: 
error: ‘e’ was not declared in this scope
  214 | mlt_log_info(getConsumer(), "%s\n", e.getMessage().c_str());
  | ^
/build/mlt-zme0kO/mlt-7.18.0/src/framework/../framework/mlt_log.h:88:93: note: 
in definition of macro ‘mlt_log_info’
   88 | #define mlt_log_info(service, format, args...) mlt_log((service), 
MLT_LOG_INFO, (format), ##args)
  | 
^~~~
/build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp: In 
member function ‘int RtAudioConsumer::stop()’:
/build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp:365:24: 
error: ‘RtAudioError’ does not name a type; did you mean ‘RtAudioErrorType’?
  365 | catch (RtAudioError ) {
  |^~~~
  |RtAudioErrorType
/build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp:367:58: 
error: ‘e’ was not declared in this scope
  367 | mlt_log_error(getConsumer(), "%s\n", 
e.getMessage().c_str());
  |  ^
/build/mlt-zme0kO/mlt-7.18.0/src/framework/../framework/mlt_log.h:85:95: note: 
in definition of macro ‘mlt_log_error’
   85 | #define mlt_log_error(service, format, args...) mlt_log((service), 
MLT_LOG_ERROR, (format), ##args)
  | 
  ^~~~
make[2]: *** [src/modules/rtaudio/CMakeFiles/mltrtaudio.dir/build.make:79: 
src/modules/rtaudio/CMakeFiles/mltrtaudio.dir/consumer_rtaudio.cpp.o] Error 1
make[2]: Target 'src/modules/rtaudio/CMakeFiles/mltrtaudio.dir/build' not 
remade because of errors.
make[2]: Leaving directory '/build/mlt-zme0kO/mlt-7.18.0/obj-x86_64-linux-gnu'
```

Attached is a patch that fixes the FTBFS (but is otherwise untested).
No debdiff this time, sorry.

cheers.
Description: Fix FTBFS with RtAudio 6
 replace try/catch with check for return codes.
 check device.ID instead of device.probed
Author: IOhannes m zmölnig
Origin: Debian
Forwarded: no
Last-Update: 2023-09-09
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp
===
--- mlt-7.18.0.orig/src/modules/rtaudio/consumer_rtaudio.cpp
+++ mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp
@@ -161,7 +161,7 @@ public:
 for (i = 0; i < n; i++) {
 info = rt->getDeviceInfo(i);
 mlt_log_verbose(NULL, "RtAudio device %d = %s\n", i, 
info.name.c_str());
-if (info.probed && info.name == resource) {
+if (info.ID > 0 && info.name == resource) {
 device_id = i;
 break;
 }
@@ -192,11 +192,11 @@ public:
 }

Bug#1051571: dkms: uploader email address maybe invalid

[Ben Tris]

Source: dkms
Version: 3.0.10-8+deb12u1
Severity: minor
X-Debbugs-Cc: benatt...@gezapig.nl, mario.limoncie...@dell.com, 
m...@qa.debian.org

Dear Maintainer,

The email under uploader Mario Limonciello is now
 this is not found in qa. (diff is underscore)
Probably it should be . (active uploader)


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

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

Bug#1051569: bookworm-pu: package brltty/6.5-7+deb12u1

[Samuel Thibault]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: brl...@packages.debian.org
Control: affects -1 + src:brltty

Hello,

I have uploaded brltty/6.5-7+deb12u1 for inclusion in bookworm.

Samuel

[ Reason ]
As discussed on
https://www.freelists.org/post/orca/Braille-navigation-issues-with-Orca-441
with the brltty version installed in bookworm, if a user has the orca
and xbrlapi packages installed, but not the brltty-x11 package
installed, the braille navigation and cursor routing keys are not
working in the Orca screen reader. This is a regression in bookworm
compared to buster.

[ Impact ]
The user loses a lot of navigation convenience when e.g. browsing the
Internet, they cannot just "click" on a link (with the routing keys) to
follow it.

[ Tests ]
This was tested by hand and reported as fixed by the reporter.

[ Risks ]
The code is relatively simple.

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

[ Changes ]

The proposed fix is actually fixing the issue twice:

- it makes xbrlapi check whether the brltty-x11 package is
installed before starting brltty with the ba and a2 drivers.

- and it makes the missing of the brltty-x11 package (in case the user
started brltty by hand with the ba and a2 drivers) not consume the
braille key events out of orca's reach.
diff -Nru brltty-6.5/debian/changelog brltty-6.5/debian/changelog
--- brltty-6.5/debian/changelog 2023-04-06 01:27:28.0 +0200
+++ brltty-6.5/debian/changelog 2023-09-07 19:46:53.0 +0200
@@ -1,3 +1,12 @@
+brltty (6.5-7+deb12u1) bookworm; urgency=medium
+
+  * patches/git-xbrlapi: Fix ba+a2 load failure log flood, and failure to use
+braille shortcuts in Orca.
+  * patches/git-base-none-quality: Set quality to low or none for base and no
+screen drivers.
+
+ -- Samuel Thibault   Thu, 07 Sep 2023 19:46:53 +0200
+
 brltty (6.5-7) unstable; urgency=medium
 
   [ Remus-Gabriel Chelu ]
diff -Nru brltty-6.5/debian/patches/git-base-none-quality 
brltty-6.5/debian/patches/git-base-none-quality
--- brltty-6.5/debian/patches/git-base-none-quality 1970-01-01 
01:00:00.0 +0100
+++ brltty-6.5/debian/patches/git-base-none-quality 2023-09-07 
19:46:53.0 +0200
@@ -0,0 +1,42 @@
+commit aadd8a93de29fb1d7d47dbe91b815655e76ef5f8
+Author: Samuel Thibault 
+Date:   Tue Sep 5 00:00:56 2023 +0200
+
+screen: Set quality to low or none for base and no
+
+When e.g. brltty cannot load a screen driver, but can load the BrlAPI
+driver, we have to make sure to know that we have a low screen reading
+quality, otherwise the BrlAPI driver would consume braille keyboard
+events, without being able to do anything about them.
+
+This notably fixes cursor routing and braille panning in Orca when
+xbrlapi is installed but the a2 screen driver is not installed.
+
+diff --git a/Programs/scr_base.c b/Programs/scr_base.c
+index 23c7e4d1f..de867a7d5 100644
+--- a/Programs/scr_base.c
 b/Programs/scr_base.c
+@@ -149,6 +149,7 @@ refresh_BaseScreen (void) {
+ 
+ static void
+ describe_BaseScreen (ScreenDescription *description) {
++  description->quality = SCQ_NONE;
+   description->rows = 1;
+   description->cols = strlen(text_BaseScreen);
+   description->posx = 0;
+diff --git a/Programs/scr_driver.c b/Programs/scr_driver.c
+index 57e602b0b..416487471 100644
+--- a/Programs/scr_driver.c
 b/Programs/scr_driver.c
+@@ -81,6 +81,11 @@ describe_NoScreen (ScreenDescription *description) {
+ screenMessage = message;
+   }
+ 
++  if (screenMessage)
++description->quality = SCQ_LOW;
++  else
++description->quality = SCQ_NONE;
++
+   description->rows = 1;
+   description->cols = strlen(screenMessage);
+   description->posx = 0;
diff -Nru brltty-6.5/debian/patches/git-xbrlapi 
brltty-6.5/debian/patches/git-xbrlapi
--- brltty-6.5/debian/patches/git-xbrlapi   1970-01-01 01:00:00.0 
+0100
+++ brltty-6.5/debian/patches/git-xbrlapi   2023-09-07 19:46:53.0 
+0200
@@ -0,0 +1,35 @@
+https://github.com/brltty/brltty/pull/419
+
+commit 898350dcbe11bd46d2e3babffe0764169d0a0457
+Author: Samuel Thibault 
+Date:   Sat Jun 17 22:52:42 2023 +0200
+
+xbrlapi: Do not try to start brltty with ba+a2 when unavailable
+
+When a distribution ships them separately they may not be available, and
+brltty would then flood logs with driver load failure warning every 5
+seconds.
+
+diff --git a/Autostart/X11/90xbrlapi.in b/Autostart/X11/90xbrlapi.in
+index ecb2f5e57..cb3e3e5b3 100644
+--- a/Autostart/X11/90xbrlapi.in
 b/Autostart/X11/90xbrlapi.in
+@@ -2,6 +2,7 @@
+ 
+ prefix="@prefix@"
+ exec_prefix="@exec_prefix@"
++drivers_directory="@drivers_directory@"
+ program_directory="@program_directory@"
+ xbrlapi="$program_directory/xbrlapi"
+ 

Bug#1051568: gthumb: please package 3.12.3

[Martin-Éric Racine]

Package: gthumb
Version: 3:3.12.2-3+b1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

3.12.3 was just released upstream. Could you please package it and then 
backport it to stable?

Thanks!
Martin-Éric


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

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

Versions of packages gthumb depends on:
ii  gsettings-desktop-schemas   43.0-1
ii  gthumb-data 3:3.12.2-3
ii  libbrasero-media3-1 3.12.3-2
ii  libc6   2.36-9+deb12u1
ii  libcairo2   1.16.0-7
ii  libchamplain-0.12-0 0.12.20-1+b1
ii  libchamplain-gtk-0.12-0 0.12.20-1+b1
ii  libclutter-1.0-01.26.4+dfsg-4
ii  libclutter-gtk-1.0-01.8.4-4+b1
ii  libcolord2  1.4.6-2.2
ii  libexiv2-27 0.27.6-1
ii  libgcc-s1   12.2.0-14
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii  libgl1-mesa-dri 22.3.6-1+deb12u1
ii  libglib2.0-02.74.6-2
ii  libgstreamer-plugins-base1.0-0  1.22.0-3+deb12u1
ii  libgstreamer1.0-0   1.22.0-2
ii  libgtk-3-0  3.24.37-2
ii  libheif11.15.1-1
ii  libjpeg62-turbo 1:2.1.5-2
ii  liblcms2-2  2.14-2
ii  libpango-1.0-0  1.50.12+ds-1
ii  libpangocairo-1.0-0 1.50.12+ds-1
ii  libpng16-16 1.6.39-2
ii  libraw200.20.2-2.1
ii  librsvg2-2  2.54.7+dfsg-1~deb12u1
ii  libsecret-1-0   0.20.5-3
ii  libsoup2.4-12.74.3-1
ii  libstdc++6  12.2.0-14
ii  libtiff64.5.0-6
ii  libwebkit2gtk-4.0-372.40.5-1~deb12u1
ii  libwebp71.2.4-0.2
ii  libx11-62:1.8.4-2+deb12u1
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages gthumb recommends:
ii  libgphoto2-6   2.5.30-1
ii  libgphoto2-port12  2.5.30-1

gthumb suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmT83GsACgkQrh+Cd8S0
17YJJA/9GPbXMeZPv8WD7J0e3ub+WZTfqH9SqNXvTSTMXfXOvE9P9xtw62Y5TVeN
qn63+VLwr/B/vyK0H8nUu6VPN22tXz4csMAGKeMMD5+pcd4s7fWsVBziWShNChqL
2I4S9q1qJJfXWaSDWNaeF2OcvkAV1r4ce2fUYkRFE8fqwpOTdBNHc86CW1rOxe//
VqoQA7RXHqr/g3TpgGQaiWR9R89/E0yUwx671Rm3YJ+N0KAlwYVbCNrcUWmYGPY/
TO6ddwdbuCV/5WwaJiCDxW5w9CyTJA4lE8W/mhMCZ298XQjrBxVWx8wokA7DRYFN
m7Uy1Q6xTmhk7rBU0/AeFRaRafYqXGynGQgipnTsxLgU/jDQPAF/2faZUp3cGR90
J/+pQEDvjdg0kdUAPY8H1w5wkkJcT/Bi/HkSQw2/wIKC6mGMdccAw5EZphVdFRG6
5HOQuuxwiN65c6F8oGwd8S+SdZTg2TF4umwAUfip7/zDBPxoV/yQpJzQxtHa7pOV
l9V1yBRkchDnDIoxn0+DNNDQ8YgAPIXE24Dgf+l+xrsRE0foTCe19+DJYwXvChTN
f+vKcTagwDsYivhT4AIQttVvjj4IZocGrntSbI42h04J1w8ymBqPZug6e0ZyQI/O
rtNctBR/nhxEwh40ARWn9VFOcMETuG1u5Iku2yZl78g3xbNX+hI=
=3Oq4
-END PGP SIGNATURE-

Bug#1051567: cubicsdr: FTBFS with RtAudio 6

[IOhannes m zmoelnig]

Source: cubicsdr
Version: 0.2.7+dfsg-2
Severity: important
Tags: ftbfs patch

Dear Maintainer,

cubicsdr ftbfs with RtAudio6 (currently found in experimental)

```
/<>/src/audio/AudioThread.cpp: In member function ‘void 
AudioThread::setupDevice(int)’:
/<>/src/audio/AudioThread.cpp:435:12: error: ‘RtAudioError’ does 
not name a type; did you mean ‘RtAudioErrorType’?
  435 | catch (RtAudioError& e) {
  |^~~~
  |RtAudioErrorType
/<>/src/audio/AudioThread.cpp:436:9: error: ‘e’ was not declared 
in this scope
  436 | e.printMessage();
  | ^
/<>/src/audio/AudioThread.cpp: In member function ‘virtual void 
AudioThread::run()’:
/<>/src/audio/AudioThread.cpp:539:16: error: ‘RtAudioError’ does 
not name a type; did you mean ‘RtAudioErrorType’?
  539 | catch (RtAudioError& e) {
  |^~~~
  |RtAudioErrorType
/<>/src/audio/AudioThread.cpp:540:13: error: ‘e’ was not declared 
in this scope
  540 | e.printMessage();
  | ^
make[3]: *** [CMakeFiles/CubicSDR.dir/build.make:485: 
CMakeFiles/CubicSDR.dir/src/audio/AudioThread.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs
```

Attached you find a patch that fixes the FTBFS (but is otherwise untested, so
use with care).
No debdiff this time, sorry

cheers
Description: Fix FTBFS with RtAudio 6
 Replace try/catch with checking for return codes
Author: IOhannes m zmölnig
Origin: Debian
Forwarded: no
Last-Update: 2023-09-09
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: cubicsdr-0.2.7+dfsg/src/audio/AudioThread.cpp
===
--- cubicsdr-0.2.7+dfsg.orig/src/audio/AudioThread.cpp
+++ cubicsdr-0.2.7+dfsg/src/audio/AudioThread.cpp
@@ -7,6 +7,7 @@
 #include "CubicSDR.h"
 #include "DemodulatorInstance.h"
 #include 
+#include 
 
 //50 ms
 #define HEARTBEAT_CHECK_PERIOD_MICROS (50 * 1000) 
@@ -378,7 +379,6 @@ void AudioThread::setupDevice(int device
 
 opts.streamName = "CubicSDR Audio Output";
 
-try {
 if (deviceController.find(outputDevice.load()) != 
deviceController.end()) {
 //'this' is not the controller, so remove it from the bounded list:
 //beware, we must take the controller mutex, because the audio 
callback may use the list of bounded
@@ -418,8 +418,14 @@ void AudioThread::setupDevice(int device
 else if (deviceController[parameters.deviceId] == this) {
 
 //Attach callback
-dac.openStream(, nullptr, RTAUDIO_FLOAT32, sampleRate, 
, , (void *)this, );
-dac.startStream();
+   if(dac.openStream(, nullptr, RTAUDIO_FLOAT32, 
sampleRate, , , (void *)this, )) {
+   std::cerr << dac.getErrorText() << std::endl;
+   return;
+   }
+if(dac.startStream()) {
+   std::cerr << dac.getErrorText() << std::endl;
+   return;
+   }
 }
 else {
 //we are a bound thread, add ourselves to the controller 
deviceController[parameters.deviceId].
@@ -431,11 +437,6 @@ void AudioThread::setupDevice(int device
 }
 active = true;
 
-}
-catch (RtAudioError& e) {
-e.printMessage();
-return;
-}
 if (deviceId != -1) {
 outputDevice = deviceId;
 }
@@ -530,15 +531,12 @@ void AudioThread::run() {
 }
 else {
 // 'this' is a controller thread:
-try {
 if (dac.isStreamOpen()) {
-dac.stopStream(); 
+if(dac.stopStream()) {
+   std::cerr << dac.getErrorText() << std::endl;
+   }
 }
 dac.closeStream();
-}
-catch (RtAudioError& e) {
-e.printMessage();
-}
 }
 
 //std::cout << "Audio thread done." << std::endl;

Bug#967542: jack-capture: depends on deprecated GTK 2

[Bastian Germann]

jack_capture_gui2 is not built, so Build-Depends: libgtk2.0-dev is not needed.
Please just drop it.

Bug#967301: darnwdl: depends on deprecated GTK 2

[Bastian Germann]

darnwdl is not used a lot. So when gtk2 is removed, this package should be 
removed as well.

Bug#1051566: pyhamcrest: uploader email address maybe invalid

[Ben Tris]

Source: pyhamcrest
Version: 2.0.3-2
Severity: minor
X-Debbugs-Cc: benatt...@gezapig.nl, m...@qa.debian.org

Dear Maintainer,

The email under uploader David Villa Alises is now
 this is not found in qa.
There is another address  but also not found in qa.


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

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

Bug#1051565: unbound: Please backport unbound 1.18.0 for bookworm to enable NAT64 support

[Daniel Gröber]

Source: unbound
Version: 1.17.1-2
Severity: wishlist
Tags: ipv6
X-Debbugs-Cc: d...@darkboxed.org

Dear Maintainer,

I would like to run an unbound resolver on an IPv6-only network. This
is problematic because many nameservers on the internet are only
reachable over IPv4.

Starting with 1.18.0 unbound provides NAT64 support on the recursor
side. Meaning when it encounters an IPv4 only NS it will try to reach
it though a NAT64 prefix instead.

I've rebuilt and tested 1.18.0-2 on bookworm and it works fine, could
you upload a backport for bookworm please so other users can benefit
from this new feature too?

Thanks,
--Daniel

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

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

-- no debconf information

Bug#1050266: Upload?

[Martin Dosch]

Dear Tobias,

I forgot to ask: Is it enough to change the uploaders in the repo or do 
you need an upload to go ahead with your MIA process?


Best regards,
Martin


signature.asc
Description: PGP signature

Bug#1051564: stk: FTBFS with RtAudio 6

[IOhannes m zmoelnig]

Package: stk
Version: 4.6.2+dfsg-2
Severity: important
Tags: ftbfs patch

Dear Maintainer,

stk ftbfs with RtAudio 6 (as currently found in experimental):

a small excerpt from the build-logs:
```
RtWvOut.cpp:110:11: error: ‘RtAudioError’ does not name a type; did you mean 
‘RtAudioErrorType’?
  110 |   catch ( RtAudioError  ) {
  |   ^~~~
  |   RtAudioErrorType
RtWvOut.cpp:111:18: error: ‘error’ was not declared in this scope; did you mean 
‘perror’?
  111 | handleError( error.what(), StkError::AUDIO_SYSTEM );
  |  ^
  |  perror
make[3]: *** [Makefile:79: RtWvOut.o] Error 1
make[3]: *** Waiting for unfinished jobs
RtWvIn.cpp: In constructor ‘stk::RtWvIn::RtWvIn(unsigned int, stk::StkFloat, 
int, int, int)’:
RtWvIn.cpp:89:11: error: ‘RtAudioError’ does not name a type; did you mean 
‘RtAudioErrorType’?
   89 |   catch ( RtAudioError  ) {
  |   ^~~~
  |   RtAudioErrorType
RtWvIn.cpp:90:18: error: ‘error’ was not declared in this scope; did you mean 
‘perror’?
   90 | handleError( error.what(), StkError::AUDIO_SYSTEM );
  |  ^
  |  perror
```

attached is a patch that fixes the FTBFS (but is otherwise untested).
no debdiff this time, sorry.

cheers.
Description: Fix FTBFS with RtAudio 6
 replace try/catch with checking error-codes
Author: IOhannes m zmölnig
Origin: Debian
Forwarded: no
Last-Update: 2023-09-09
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: stk-4.6.2+dfsg/src/RtWvIn.cpp
===
--- stk-4.6.2+dfsg.orig/src/RtWvIn.cpp
+++ stk-4.6.2+dfsg/src/RtWvIn.cpp
@@ -83,11 +83,8 @@ RtWvIn :: RtWvIn( unsigned int nChannels
   unsigned int size = bufferFrames;
   RtAudioFormat format = ( sizeof(StkFloat) == 8 ) ? RTAUDIO_FLOAT64 : 
RTAUDIO_FLOAT32;
 
-  try {
-adc_.openStream( NULL, , format, (unsigned 
int)Stk::sampleRate(), , , (void *)this );
-  }
-  catch ( RtAudioError  ) {
-handleError( error.what(), StkError::AUDIO_SYSTEM );
+  if(adc_.openStream( NULL, , format, (unsigned 
int)Stk::sampleRate(), , , (void *)this )) {
+handleError(adc_.getErrorText(), StkError::AUDIO_SYSTEM );
   }
 
   data_.resize( size * nBuffers, nChannels );
Index: stk-4.6.2+dfsg/src/RtWvOut.cpp
===
--- stk-4.6.2+dfsg.orig/src/RtWvOut.cpp
+++ stk-4.6.2+dfsg/src/RtWvOut.cpp
@@ -104,11 +104,8 @@ RtWvOut :: RtWvOut( unsigned int nChanne
   RtAudioFormat format = ( sizeof(StkFloat) == 8 ) ? RTAUDIO_FLOAT64 : 
RTAUDIO_FLOAT32;
 
   // Open a stream and set the callback function.
-  try {
-dac_.openStream( , NULL, format, (unsigned 
int)Stk::sampleRate(), , , (void *)this );
-  }
-  catch ( RtAudioError  ) {
-handleError( error.what(), StkError::AUDIO_SYSTEM );
+  if(dac_.openStream( , NULL, format, (unsigned 
int)Stk::sampleRate(), , , (void *)this )) {
+handleError( dac_.getErrorText(), StkError::AUDIO_SYSTEM );
   }
 
   data_.resize( size * nBuffers, nChannels );
Index: stk-4.6.2+dfsg/projects/demo/demo.cpp
===
--- stk-4.6.2+dfsg.orig/projects/demo/demo.cpp
+++ stk-4.6.2+dfsg/projects/demo/demo.cpp
@@ -259,11 +259,8 @@ int main( int argc, char *argv[] )
 parameters.deviceId = dac.getDefaultOutputDevice();
 parameters.nChannels = data.channels;
 unsigned int bufferFrames = RT_BUFFER_SIZE;
-try {
-  dac.openStream( , NULL, format, (unsigned 
int)Stk::sampleRate(), , , (void *) );
-}
-catch ( RtAudioError& error ) {
-  error.printMessage();
+if(dac.openStream( , NULL, format, (unsigned 
int)Stk::sampleRate(), , , (void *) )) {
+  std::cerr << dac.getErrorText() << std::endl;
   goto cleanup;
 }
   }
@@ -279,11 +276,8 @@ int main( int argc, char *argv[] )
   // If realtime output, set our callback function and start the dac.
 #if defined(__STK_REALTIME__)
   if ( data.realtime ) {
-try {
-  dac.startStream();
-}
-catch ( RtAudioError  ) {
-  error.printMessage();
+if(dac.startStream()) {
+  std::cerr << dac.getErrorText() << std::endl;
   goto cleanup;
 }
   }
@@ -304,12 +298,7 @@ int main( int argc, char *argv[] )
   // Shut down the output stream.
 #if defined(__STK_REALTIME__)
   if ( data.realtime ) {
-try {
-  dac.closeStream();
-}
-catch ( RtAudioError& error ) {
-  error.printMessage();
-}
+dac.closeStream();
   }
 #endif
 
Index: stk-4.6.2+dfsg/projects/effects/effects.cpp
===
--- stk-4.6.2+dfsg.orig/projects/effects/effects.cpp
+++ stk-4.6.2+dfsg/projects/effects/effects.cpp
@@ -253,11 +253,8 @@ int main( int argc, char *argv[] )
   iparameters.deviceId = adac.getDefaultInputDevice();
   iparameters.nChannels = 1;
   unsigned int bufferFrames = 

Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875

[Salvatore Bonaccorso]

Source: mutt
Version: 2.2.9-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for mutt.

CVE-2023-4874[0]:
| Null pointer dereference when viewing a specially crafted email in
| Mutt >1.5.2 <2.2.12


CVE-2023-4875[1]:
| Null pointer dereference when composing from a specially crafted
| draft message in Mutt >1.5.2 <2.2.12

Make sure to include all three commits referenced from [2], the last
one is technically not part of the two CVEs, but another crash found
by upstream.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-4874
https://www.cve.org/CVERecord?id=CVE-2023-4874
[1] https://security-tracker.debian.org/tracker/CVE-2023-4875
https://www.cve.org/CVERecord?id=CVE-2023-4875
[2] 
http://lists.mutt.org/pipermail/mutt-announce/Week-of-Mon-20230904/56.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1051247: muse-el: Choose living upstream for muse-el and merge updates

[Manphiz]

Xiyue Deng  writes:

> Package: elpa-muse
> Severity: minor
> X-Debbugs-Cc: none, Xiyue Deng 
>
> Currently muse-el has two main upstream repositories: one from Elpa
> external branch[1], one from github[2], and the two has diverged
> somehow.  We should decide on which repo to track in d/watch.
>
> [1] http://git.savannah.gnu.org/cgit/emacs/elpa.git/log/?h=externals/muse
> [2] https://github.com/alexott/muse
>
> -- System Information:
> Debian Release: 12.1
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
> 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.1.0-11-amd64 (SMP w/16 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>

Hi sten,

When trying to pick a new upstream to rebase, I found that pulling
either upstream repo will result in an incompatible git history versus
the current debian/master branch on salsa.  I wonder how I should handle
this?  Is it OK to force push to master?  Will it affect existing
annotated tags?

-- 
Manphiz


signature.asc
Description: PGP signature

Bug#1051562: fis-gtm: uploader email adres maybe invalid

[Ben Tris]

Package: fis-gtm
Severity: minor
X-Debbugs-Cc: benatt...@gezapig.nl, m...@qa.debian.org

Dear Maintainer,

The email under uploader Amul Shah is now
 this is not found in qa.
I could not find more info.


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

Kernel: Linux 6.1.0-11-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 fis-gtm depends on:
pn  fis-gtm-7.0  

fis-gtm recommends no packages.

fis-gtm suggests no packages.

Bug#1050165: [PATCH] Resolve missing newlines in libsmartcols

[Matthijs Melchior]

Hi,
   Here is a patch for 'libsmartcols'  that corrects the "lsblk -M" 
omission of some newlines.


--
Description: libsmartcols missing newlines
 The "scols_walk_is_last" function is not always correct,
 it should also test for the end of a group.
Author: Matthijs Melchior 
Bug: Debian #1050165; https://github.com/util-linux/util-linux/issues/2446
Last-Update: 2023-09-09
---
--- a/libsmartcols/src/walk.c
+++ b/libsmartcols/src/walk.c
@@ -69,6 +69,8 @@
    }
    if (is_tree_root(parent) && !is_last_tree_root(tb, parent))
    return 0;
+   if (is_group_child(parent) && !is_last_group_child(parent))
+   return 0;
    }
    if (is_group_child(ln) && !is_last_group_child(ln))
    return 0;
--

This has been tested with 'lsblk -M' and the output is now correct.
All the other ls* commands from util-linux have no changes in their output.

Regards,
    Matthijs.

--
--
Matthijs MelchiorZeist
mmelch...@xs4all.nlNetherlands
--

Bug#1051561: RM: zimlib -- RoQA; binary packages were moved

[Bastian Germann]

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

src:zimlib's binary packages were moved to src:libzim. Please remove src:zimlib.

Bug#1051559: grandorgue: FTBFS with RtAudio 6

[IOhannes m zmoelnig]

Source: grandorgue
Version: 3.12.3-1
Followup-For: Bug #1051559
Control: tags -1 patch

Dear Maintainer,

the attached patch fixes the FTBFS (no debdiff for now, sorry).
I haven't really done any functional tests though, so use it with care.
Description: Fix FTBFS with RtAudio6
 Use return codes instead of catching exceptions
Author: IOhannes m zmölnig
Origin: Debian
Forwarded: no
Last-Update: 2023-09-09
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: grandorgue-3.12.3/src/grandorgue/sound/ports/GOSoundRtPort.cpp
===
--- grandorgue-3.12.3.orig/src/grandorgue/sound/ports/GOSoundRtPort.cpp
+++ grandorgue-3.12.3/src/grandorgue/sound/ports/GOSoundRtPort.cpp
@@ -24,26 +24,21 @@ GOSoundRtPort::GOSoundRtPort(
 
 GOSoundRtPort::~GOSoundRtPort() {
   Close();
-  try {
 if (m_rtApi) {
   const RtAudio *rtApi = m_rtApi;
 
   m_rtApi = NULL;
   delete rtApi;
 }
-  } catch (RtAudioError ) {
-wxString error = wxString::FromAscii(e.getMessage().c_str());
-wxLogError(_("RtAudio error: %s"), error.c_str());
-  }
 }
 
 void GOSoundRtPort::Open() {
   Close();
-  if (!m_rtApi)
+  if (!m_rtApi) {
 throw wxString::Format(
   _("Audio device %s not initialised"), m_Name.c_str());
+  }
 
-  try {
 RtAudio::StreamParameters aOutputParam;
 RtAudio::StreamOptions aOptions;
 
@@ -58,7 +53,7 @@ void GOSoundRtPort::Open() {
 
 unsigned samples_per_buffer = m_SamplesPerBuffer;
 
-m_rtApi->openStream(
+if (m_rtApi->openStream(
   ,
   NULL,
   RTAUDIO_FLOAT32,
@@ -66,7 +61,10 @@ void GOSoundRtPort::Open() {
   _per_buffer,
   ,
   this,
-  );
+  )) {
+wxString error = wxString::FromAscii(m_rtApi->getErrorText().c_str());
+throw wxString::Format(_("RtAudio error: %s"), error.c_str());
+}
 m_nBuffers = aOptions.numberOfBuffers;
 if (samples_per_buffer != m_SamplesPerBuffer) {
   if (samples_per_buffer != m_SamplesPerBuffer)
@@ -77,18 +75,17 @@ void GOSoundRtPort::Open() {
   samples_per_buffer);
 }
 m_IsOpen = true;
-  } catch (RtAudioError ) {
-wxString error = wxString::FromAscii(e.getMessage().c_str());
-throw wxString::Format(_("RtAudio error: %s"), error.c_str());
-  }
 }
 
 void GOSoundRtPort::StartStream() {
-  if (!m_rtApi || !m_IsOpen)
+  if (!m_rtApi || !m_IsOpen) {
 throw wxString::Format(_("Audio device %s not open"), m_Name.c_str());
+  }
 
-  try {
-m_rtApi->startStream();
+  if (m_rtApi->startStream()) {
+wxString error = wxString::FromAscii(m_rtApi->getErrorText().c_str());
+throw wxString::Format(_("RtAudio error: %s"), error.c_str());
+  }
 double actual_latency = m_rtApi->getStreamLatency();
 
 /* getStreamLatency returns zero if not supported by the API, in which
@@ -98,10 +95,6 @@ void GOSoundRtPort::StartStream() {
   actual_latency = m_SamplesPerBuffer * m_nBuffers;
 
 SetActualLatency(actual_latency / m_SampleRate);
-  } catch (RtAudioError ) {
-wxString error = wxString::FromAscii(e.getMessage().c_str());
-throw wxString::Format(_("RtAudio error: %s"), error.c_str());
-  }
 
   if (m_rtApi->getStreamSampleRate() != m_SampleRate)
 throw wxString::Format(
@@ -111,18 +104,11 @@ void GOSoundRtPort::StartStream() {
 void GOSoundRtPort::Close() {
   if (!m_rtApi || !m_IsOpen)
 return;
-  try {
-m_rtApi->abortStream();
-  } catch (RtAudioError ) {
-wxString error = wxString::FromAscii(e.getMessage().c_str());
-wxLogError(_("RtAudio error: %s"), error.c_str());
-  }
-  try {
-m_rtApi->closeStream();
-  } catch (RtAudioError ) {
-wxString error = wxString::FromAscii(e.getMessage().c_str());
+  if(m_rtApi->abortStream()) {
+wxString error = wxString::FromAscii(m_rtApi->getErrorText().c_str());
 wxLogError(_("RtAudio error: %s"), error.c_str());
   }
+  m_rtApi->closeStream();
   m_IsOpen = false;
 }
 
@@ -209,8 +195,7 @@ GOSoundPort *GOSoundRtPort::create(
   const GOPortsConfig , GOSound *sound, wxString name) {
   GOSoundRtPort *port = NULL;
 
-  if (portsConfig.IsEnabled(PORT_NAME))
-try {
+  if (portsConfig.IsEnabled(PORT_NAME)) {
   GOSoundPortFactory::NameParser parser(name);
   const wxString subsysName = parser.nextComp();
   wxString apiName
@@ -230,7 +215,6 @@ GOSoundPort *GOSoundRtPort::create(
   && (apiName == rtApiName || apiName.IsEmpty())) {
   RtAudio *rtApi = NULL;
 
-  try {
 rtApi = new RtAudio(apiIndex);
 for (unsigned l = rtApi->getDeviceCount(), i = 0; i < l; i++) {
   const RtAudio::DeviceInfo info = rtApi->getDeviceInfo(i);
@@ -247,10 +231,6 @@ GOSoundPort *GOSoundRtPort::create(
 break;
   }
 }
-  } catch (RtAudioError ) {
-wxString error = wxString::FromAscii(e.getMessage().c_str());
-wxLogError(_("RtAudio error: %s"), error.c_str());
-  }
 

Bug#1051559: grandorgue: FTBFS with RtAudio 6

[IOhannes m zmoelnig]

Source: grandorgue
Version: 3.12.3-1
Severity: important
Tags: ftbfs

Dear Maintainer,

grandorgue ftbfs with RtAudio 6 (currently in experimental):

```
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp: In destructor 
‘virtual GOSoundRtPort::~GOSoundRtPort()’:
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp:34:12: error: 
‘RtAudioError’ does not name a type; did you mean ‘RtAudioErrorType’?
   34 |   } catch (RtAudioError ) {
  |^~~~
  |RtAudioErrorType
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp:35:42: error: ‘e’ 
was not declared in this scope
   35 | wxString error = wxString::FromAscii(e.getMessage().c_str());
  |  ^
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp: In member 
function ‘virtual void GOSoundRtPort::Open()’:
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp:80:12: error: 
‘RtAudioError’ does not name a type; did you mean ‘RtAudioErrorType’?
   80 |   } catch (RtAudioError ) {
  |^~~~
  |RtAudioErrorType
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp:81:42: error: ‘e’ 
was not declared in this scope
   81 | wxString error = wxString::FromAscii(e.getMessage().c_str());
  |  ^
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp: In member 
function ‘virtual void GOSoundRtPort::StartStream()’:
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp:101:12: error: 
‘RtAudioError’ does not name a type; did you mean ‘RtAudioErrorType’?
  101 |   } catch (RtAudioError ) {
  |^~~~
  |RtAudioErrorType
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp:102:42: error: 
‘e’ was not declared in this scope
  102 | wxString error = wxString::FromAscii(e.getMessage().c_str());
  |  ^
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp: In member 
function ‘virtual void GOSoundRtPort::Close()’:
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp:116:12: error: 
‘RtAudioError’ does not name a type; did you mean ‘RtAudioErrorType’?
  116 |   } catch (RtAudioError ) {
  |^~~~
  |RtAudioErrorType
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp:117:42: error: 
‘e’ was not declared in this scope
  117 | wxString error = wxString::FromAscii(e.getMessage().c_str());
  |  ^
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp:122:12: error: 
‘RtAudioError’ does not name a type; did you mean ‘RtAudioErrorType’?
  122 |   } catch (RtAudioError ) {
  |^~~~
  |RtAudioErrorType
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp:123:42: error: 
‘e’ was not declared in this scope
  123 | wxString error = wxString::FromAscii(e.getMessage().c_str());
  |  ^
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp: In static member 
function ‘static GOSoundPort* GOSoundRtPort::create(const GOPortsConfig&, 
GOSound*, wxString)’:
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp:250:20: error: 
‘RtAudioError’ does not name a type; did you mean ‘RtAudioErrorType’?
  250 |   } catch (RtAudioError ) {
  |^~~~
  |RtAudioErrorType
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp:251:50: error: 
‘e’ was not declared in this scope
  251 | wxString error = 
wxString::FromAscii(e.getMessage().c_str());
  |  ^
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp:261:14: error: 
‘RtAudioError’ does not name a type; did you mean ‘RtAudioErrorType’?
  261 | } catch (RtAudioError ) {
  |  ^~~~
  |  RtAudioErrorType
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp:262:44: error: 
‘e’ was not declared in this scope
  262 |   wxString error = wxString::FromAscii(e.getMessage().c_str());
  |^
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp: In static member 
function ‘static void GOSoundRtPort::addDevices(const GOPortsConfig&, 
std::vector&)’:
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp:285:29: error: 
‘struct RtAudio::DeviceInfo’ has no member named ‘probed’
  285 |   if (!dev_info.probed)
  | ^~
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp:295:20: error: 
‘RtAudioError’ does not name a type; did you mean ‘RtAudioErrorType’?
  295 |   } catch (RtAudioError ) {
  |^~~~
  |RtAudioErrorType
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp:296:50: error: 
‘e’ was not declared in this scope
  296 | wxString error = 
wxString::FromAscii(e.getMessage().c_str());
  |  ^
/<>/src/grandorgue/sound/ports/GOSoundRtPort.cpp:303:14: error: 

Bug#1051558: dpf-plugins: FTBFS with RtAudio 6

[IOhannes m zmoelnig]

Source: dpf-plugins
Version: 1.7+ds-2
Severity: important
Tags: ftbfs

Dear Maintainer,

dpf-plugins fails to build with RtAudio 6 (currently found in experimental):

```
In file included from ../../dpf/distrho/src/jackbridge/JackBridge.cpp:67,
 from ../../dpf/distrho/src/DistrhoPluginJACK.cpp:38,
 from ../../dpf/distrho/DistrhoPluginMain.cpp:24:
../../dpf/distrho/src/jackbridge/RtAudioBridge.hpp: In member function ‘bool 
RtAudioBridge::_open(bool, RtAudio*)’:
../../dpf/distrho/src/jackbridge/RtAudioBridge.hpp:339:32: error: no matching 
function for call to ‘RtAudio::openStream(RtAudio::StreamParameters* const&, 
RtAudio::StreamParameters*&, const RtAudioFormat&, int, uint*, int (&)(void*, 
void*, uint, double, RtAudioStreamStatus, void*), RtAudioBridge*, 
RtAudio::StreamOptions*, std::nullptr_t)’
  339 | rtAudio->openStream(outParamsPtr, inParamsPtr, 
RTAUDIO_FLOAT32, 48000, ,
  | 
~~~^
  340 | RtAudioCallback, this, , nullptr);
  | ~~
In file included from ../../dpf/distrho/src/jackbridge/RtAudioBridge.hpp:49:
/usr/include/rtaudio/RtAudio.h:548:20: note: candidate: ‘RtAudioErrorType 
RtAudio::openStream(StreamParameters*, StreamParameters*, RtAudioFormat, 
unsigned int, unsigned int*, RtAudioCallback, void*, StreamOptions*)’
  548 |   RtAudioErrorType openStream( RtAudio::StreamParameters 
*outputParameters,
  |^~
/usr/include/rtaudio/RtAudio.h:548:20: note:   candidate expects 8 arguments, 9 
provided
../../dpf/distrho/src/jackbridge/RtAudioBridge.hpp:341:24: error: ISO C++ 
forbids declaration of ‘RtAudioError’ with no type [-fpermissive]
  341 | } catch (const RtAudioError& err) {
  |^~~~
../../dpf/distrho/src/jackbridge/RtAudioBridge.hpp:341:36: error: expected ‘)’ 
before ‘&’ token
  341 | } catch (const RtAudioError& err) {
  |^
../../dpf/distrho/src/jackbridge/RtAudioBridge.hpp:341:17: note: to match this 
‘(’
  341 | } catch (const RtAudioError& err) {
  | ^
../../dpf/distrho/src/jackbridge/RtAudioBridge.hpp:341:36: error: expected ‘{’ 
before ‘&’ token
  341 | } catch (const RtAudioError& err) {
  |^
../../dpf/distrho/src/jackbridge/RtAudioBridge.hpp:341:38: error: ‘err’ was not 
declared in this scope; did you mean ‘erf’?
  341 | } catch (const RtAudioError& err) {
  |  ^~~
  |  erf

In file included from ../../dpf/distrho/src/../extra/../DistrhoUtils.hpp:20,
 from ../../dpf/distrho/src/../extra/String.hpp:20,
 from ../../dpf/distrho/src/../DistrhoDetails.hpp:20,
 from ../../dpf/distrho/src/../DistrhoPlugin.hpp:20,
 from ../../dpf/distrho/src/DistrhoPluginInternal.hpp:20,
 from ../../dpf/distrho/src/DistrhoPlugin.cpp:17,
 from ../../dpf/distrho/DistrhoPluginMain.cpp:17:
../../dpf/distrho/src/../extra/../src/DistrhoDefines.h:143:49: error: expected 
primary-expression before ‘catch’
  143 | #define DISTRHO_SAFE_EXCEPTION_RETURN(msg, ret) catch(...) { 
d_safe_exception(msg, __FILE__, __LINE__); return ret; }
  | ^
../../dpf/distrho/src/jackbridge/RtAudioBridge.hpp:348:11: note: in expansion 
of macro ‘DISTRHO_SAFE_EXCEPTION_RETURN’
  348 | } DISTRHO_SAFE_EXCEPTION_RETURN("rtAudio->openStream()", false);
  |   ^
In file included from ../../dpf/distrho/src/jackbridge/JackBridge.cpp:69:
../../dpf/distrho/src/jackbridge/rtaudio/RtAudio.cpp: In member function ‘void 
RtAudio::openRtApi(Api)’:
../../dpf/distrho/src/jackbridge/rtaudio/RtAudio.cpp:210:18: error: expected 
type-specifier before ‘RtApiAlsa’
  210 | rtapi_ = new RtApiAlsa();
  |  ^
../../dpf/distrho/src/jackbridge/rtaudio/RtAudio.cpp:214:18: error: expected 
type-specifier before ‘RtApiPulse’
  214 | rtapi_ = new RtApiPulse();
  |  ^~
../../dpf/distrho/src/jackbridge/rtaudio/RtAudio.cpp: At global scope:
../../dpf/distrho/src/jackbridge/rtaudio/RtAudio.cpp:242:1: error: no 
declaration matches ‘RtAudio::RtAudio(Api)’
  242 | RtAudio :: RtAudio( RtAudio::Api api )
  | ^~~
/usr/include/rtaudio/RtAudio.h:267:26: note: candidates are: ‘constexpr 
RtAudio::RtAudio(const RtAudio&)’
  267 | class RTAUDIO_DLL_PUBLIC RtAudio
  |  ^~~
/usr/include/rtaudio/RtAudio.h:433:3: note: 
‘RtAudio::RtAudio(Api, RtAudioErrorCallback&&)’
  433 |   RtAudio( RtAudio::Api api=UNSPECIFIED, RtAudioErrorCallback&& 

Bug#1051556: soapyaudio: FTBFS with RtAudio 6

[IOhannes m zmoelnig]

Source: soapyaudio
Followup-For: Bug #1051556
Control: tags -1 patch

Please find the attached quilt patch that fixes the problem.
(No debdiff for now, sorry)
Description: Fix FTBFS with RtAudio 6
 Replace Exceptions with error-codes
Author: IOhannes m zmölnig
Origin: Debian
Forwarded: no
Last-Update: 2023-09-09
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: soapyaudio-0.1.1/Streaming.cpp
===
--- soapyaudio-0.1.1.orig/Streaming.cpp
+++ soapyaudio-0.1.1/Streaming.cpp
@@ -223,11 +223,11 @@ int SoapyAudio::activateStream(
 const long long timeNs,
 const size_t numElems)
 {
+RtAudioErrorType err;
 if (flags != 0) return SOAPY_SDR_NOT_SUPPORTED;
 resetBuffer = true;
 bufferedElems = 0;
 
-try {
 #ifndef _MSC_VER
 opts.priority = sched_get_priority_max(SCHED_FIFO);
 #endif
@@ -235,13 +235,14 @@ int SoapyAudio::activateStream(
 opts.flags = RTAUDIO_SCHEDULE_REALTIME;
 
 sampleRateChanged.store(false);
-dac.openStream(NULL, , RTAUDIO_FLOAT32, sampleRate, 
, &_rx_callback, (void *) this, );
-dac.startStream();
+err = dac.openStream(NULL, , RTAUDIO_FLOAT32, 
sampleRate, , &_rx_callback, (void *) this, );
+   if (RTAUDIO_NO_ERROR == err)
+err = dac.startStream();
+   if (RTAUDIO_NO_ERROR != err) {
+   throw std::runtime_error("RtAudio init error '" + 
dac.getErrorText() + "'");
+   }
 
 streamActive = true;
-} catch (RtAudioError& e) {
-throw std::runtime_error("RtAudio init error '" + e.getMessage());
-}
 
 return 0;
 }

Bug#1050682: closed by Bastian Germann (Re: WiFi stopped working)

[Daniel]

Just an observation.

It was not me who removed the package, It was a system upgrade that removed
It automatically. I had to search out what made my wi-fi stop working.

When I discovered that was this package I tried to reinstall, but that day
apt (Trixie) did not find it anymore. I've downloaded again from Debian
package website to reinstall and I open this bug just to warn it happened.
If it is in Trixie repository again, I guess it is fixed.

Em sáb, 9 de set de 2023 05:45, Debian Bug Tracking System <
ow...@bugs.debian.org> escreveu:

> This is an automatic notification regarding your Bug report
> which was filed against the firmware-ath9k-htc package:
>
> #1050682: WiFi stopped working
>
> It has been closed by Bastian Germann .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Bastian Germann <
> b...@debian.org> by
> replying to this email.
>
>
> --
> 1050682: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050682
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Bastian Germann 
> To: 1050682-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sat, 9 Sep 2023 10:41:50 +0200
> Subject: Re: WiFi stopped working
> Control: tags -1 wontfix
>
> When you remove firmware-atheros, you cannot expect your device to work
> that needs that driver.
> The packages do not conflict so I am closing this bug.
>
>
> -- Forwarded message --
> From: Daniel 
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sun, 27 Aug 2023 23:53:15 -0300
> Subject: WiFi stopped working
> Package: firmware-ath9k-htc
> Version: 1.4.0-108-gd856466+dfsg1-1.4
>
> In a recent upgrade, firmware-ath9k-htc has been installed
> and firmware-atheros has been removed, after a system reboot my WiFi
> stopped working. To fix it I had to download and reinstall firmware-atheros.
>
> lspci shows
> Network controller: Qualcomm Atheros QCA9377 802.11ac Wireless Network
> Adapter (rev 31)
>
> I'm using Linux debian 6.4.0-3-amd64 #1 SMP PREEMPT_DYNAMIC Debian
> 6.4.11-1 (2023-08-17) x86_64 GNU/Linux
>

Bug#1051557: RFP: siso -- experimental build tool that aims to replace ninja

[Andres Salomon]

Package: wnpp
Severity: wishlist

Chromium has started replacing ninja with Siso. I don't have the time 
right now to package or even play with it, but if it's everything that 
the README promises then I suspect it would be useful to have it in the 
archive for others to use.





I don't see a dedicated LICENSE file yet, but source headers mention 
that it's under the same license as chromium:
// Use of this source code is governed by a BSD-style license that can 
be// found in the LICENSE file.


Siso is an experimental build tool (written in Go) that aims to 
significantly speed up Chromium's build.


It is a drop-in replacement for Ninja, which means it can be easily 
used instead of Ninja without requiring a migration or change in 
developer's workflows.It runs build actions on RBE natively, and falls 
back to local.It avoids stat, disk and network I/O as much as 
possible.It reduces CPU usage and memory consumption by sharing in one 
process memory space.It collects performance metrics for each action 
during a build and allows to analyze them using cloud trace/cloud 
profiler.

Bug#868539: The BTS does not know that -dbgsym packages exist

[Adam D. Barratt]

On Sun, 2017-07-16 at 10:04 -0700, Don Armstrong wrote:
> Control: clone -1 -2
> Control: retitle -2 please mirror debian-debug metadata onto
> buxtehude
> Control: reassign -2 mirrors
> Control: block -1 by -2
> 
> On Sun, 16 Jul 2017, Adrian Bunk wrote:
> > The BTS does not know that these are from src:abiword
> > https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=abiword-dbgsym
> > https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=abiword-plugin-grammar-dbgsym
> 
> Thanks for the report; this requires some more mirroring of package
> information to the BTS first, and then some more work on my end. I've
> pinged people to get that started.

It looks like the BTS changes still need to happen, but for the record
the metadata mirroring happened some time ago.

Regards,

Adam

Bug#1051556: soapyaudio: FTBFS with RtAudio 6

[IOhannes m zmoelnig]

Source: soapyaudio
Version: 0.1.1-5
Severity: important
Tags: ftbfs

Dear Maintainer,

soapyaudio ftbfs with RtAudio 6 (currently available in experimental):

```
[ 66%] Building CXX object CMakeFiles/audioSupport.dir/Streaming.cpp.o
/usr/lib/ccache/c++ -DUSE_HAMLIB -D_REENTRANT -D__LINUX_ALSA__ 
-D__LINUX_PULSE__ -D__UNIX_JACK__ -DaudioSupport_EXPORTS -I/<> 
-I/usr/include/rtaudio -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 
-std=c++11 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden   
-Wno-unused-parameter -pthread -Wall -Wextra -Wnon-virtual-dtor -MD -MT 
CMakeFiles/audioSupport.dir/Streaming.cpp.o -MF 
CMakeFiles/audioSupport.dir/Streaming.cpp.o.d -o 
CMakeFiles/audioSupport.dir/Streaming.cpp.o -c /<>/Streaming.cpp
/<>/Streaming.cpp: In member function ‘virtual int 
SoapyAudio::activateStream(SoapySDR::Stream*, int, long long int, size_t)’:
/<>/Streaming.cpp:242:14: error: ‘RtAudioError’ does not name a 
type; did you mean ‘RtAudioErrorType’?
  242 | } catch (RtAudioError& e) {
  |  ^~~~
  |  RtAudioErrorType
/<>/Streaming.cpp:243:59: error: ‘e’ was not declared in this scope
  243 | throw std::runtime_error("RtAudio init error '" + 
e.getMessage());
  |   ^
make[3]: *** [CMakeFiles/audioSupport.dir/build.make:107: 
CMakeFiles/audioSupport.dir/Streaming.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs
/<>/Settings.cpp: In member function ‘virtual void 
SoapyAudio::writeSetting(const std::string&, const std::string&)’:
/<>/Settings.cpp:497:40: warning: catching polymorphic type ‘class 
std::invalid_argument’ by value [-Wcatch-value=]
  497 | } catch (std::invalid_argument e) { }
  |^
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
```

cheers

Bug#1051555: muse: FTBFS with RtAudio 6

[IOhannes m zmoelnig]

Source: muse
Version: 4.1.0-1
Severity: important
Tags: ftbfs

Dear Maintainer,


muse FTBFS with RtAudio 6 (currently available in experimental):

```
[ 62%] Building CXX object muse/driver/CMakeFiles/driver.dir/rtaudio.cpp.o
cd /<>/obj-x86_64-linux-gnu/muse/driver && /usr/lib/ccache/c++ 
-DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_SVG_LIB -DQT_UITOOLS_LIB 
-DQT_WIDGETS_LIB -DQT_XML_LIB -Ddriver_EXPORTS 
-I/<>/obj-x86_64-linux-gnu/muse/driver 
-I/<>/src/muse/driver -I/<>/src/. 
-I/<>/src -I/<>/src/libs/evdata 
-I/<>/src/libs/memory -I/<>/src/libs/midi_controller 
-I/<>/src/libs/midnam -I/<>/src/libs/mpevent 
-I/<>/src/libs/plugin -I/<>/src/libs/string 
-I/<>/src/libs/sysex_helper 
-I/<>/src/libs/time_stretch -I/<>/src/libs/wave 
-I/<>/src/libs/xml -I/<>/src/muse 
-I/<>/src/muse/function_dialogs 
-I/<>/src/muse/widgets -I/<>/src/muse/components 
-I/<>/src/muse/instruments -I/<>/obj-x86_64-linux-gnu 
-I/<>/obj-x86_64-linux-gnu/muse 
-I/<>/obj-x86_64-linux-gnu/muse/function_dialogs 
-I/<>/obj-x86_64-linux-gnu/muse/widgets 
-I/<>/obj-x86_64-linux-gnu/muse/components 
-I/<>/obj-x86_64-linux-gnu/muse/instruments 
-I/<>/obj-x86_64-linux-gnu/muse/ctrl 
-I/<>/src/vestige -I/usr/include/opus -I/usr/include/rtaudio 
-I/usr/include/lilv-0 -I/usr/include/serd-0 -I/usr/include/sord-0 
-I/usr/include/sratom-0 -I/<>/src/muse/lv2Support 
-I/usr/include/libinstpatch-2 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/<>/src/muse/arranger -I/<>/src/muse/cliplist 
-I/<>/src/muse/liste -I/<>/src/muse/midiedit 
-I/<>/src/muse/mixer -I/<>/src/muse/mplugins 
-I/<>/src/muse/remote -I/<>/src/muse/waveedit 
-I/<>/obj-x86_64-linux-gnu/muse/arranger 
-I/<>/obj-x86_64-linux-gnu/muse/cliplist 
-I/<>/obj-x86_64-linux-gnu/muse/liste 
-I/<>/obj-x86_64-linux-gnu/muse/midiedit 
-I/<>/obj-x86_64-linux-gnu/muse/mixer 
-I/<>/obj-x86_64-linux-gnu/muse/mplugins 
-I/<>/obj-x86_64-linux-gnu/muse/remote 
-I/<>/obj-x86_64-linux-gnu/muse/waveedit -isystem 
/usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtUiTools -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtXml -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtSvg -Werror=format-security -Wextra 
-Winvalid-pch -fexceptions -Wall -fPIC -std=c++17 -fPIC -fPIC -MD -MT 
muse/driver/CMakeFiles/driver.dir/rtaudio.cpp.o -MF 
CMakeFiles/driver.dir/rtaudio.cpp.o.d -o CMakeFiles/driver.dir/rtaudio.cpp.o -c 
/<>/src/muse/driver/rtaudio.cpp
/<>/src/muse/driver/rtaudio.cpp: In member function ‘virtual bool 
MusECore::RtAudioDevice::start(int)’:
/<>/src/muse/driver/rtaudio.cpp:225:13: error: ‘struct 
RtAudio::DeviceInfo’ has no member named ‘probed’
  225 |   if(!in_di.probed || !out_di.probed)
  | ^~
/<>/src/muse/driver/rtaudio.cpp:225:31: error: ‘struct 
RtAudio::DeviceInfo’ has no member named ‘probed’
  225 |   if(!in_di.probed || !out_di.probed)
  |   ^~
/<>/src/muse/driver/rtaudio.cpp:326:13: error: ‘RtAudioError’ does 
not name a type; did you mean ‘RtAudioErrorType’?
  326 |   } catch ( RtAudioError& e ) {
  | ^~~~
  | RtAudioErrorType
/<>/src/muse/driver/rtaudio.cpp:328:5: error: ‘e’ was not declared 
in this scope
  328 | e.printMessage();
  | ^
/<>/src/muse/driver/rtaudio.cpp: In member function ‘virtual void 
MusECore::RtAudioDevice::stop()’:
/<>/src/muse/driver/rtaudio.cpp:347:12: error: ‘RtAudioError’ does 
not name a type; did you mean ‘RtAudioErrorType’?
  347 |   } catch (RtAudioError& e) {
  |^~~~
  |RtAudioErrorType
/<>/src/muse/driver/rtaudio.cpp:349:5: error: ‘e’ was not declared 
in this scope
  349 | e.printMessage();
  | ^
make[3]: *** [muse/driver/CMakeFiles/driver.dir/build.make:169: 
muse/driver/CMakeFiles/driver.dir/rtaudio.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs
```

cheers

Bug#1051554: RFS: runit-services/0.5.5~deb12u1 -- UNIX init scheme with service supervision (services)

[Lorenzo]

Package: sponsorship-requests
Severity: normal

Dear mentors,

Please upload to stable; this has already been approved by release
team in #1050722
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050722

 * Package name : runit-services
   Version  : 0.5.5~deb12u1
   Upstream contact : [fill in name and email of upstream]
 * URL  : [fill in URL of upstream's web site]
 * License  : CC0-1.0, BSD-3-Clause
 * Vcs  :
   https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section
  : admin

The source builds the following binary packages:

  runit-services - UNIX init scheme with service supervision (services)

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

  https://mentors.debian.net/package/runit-services/

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

  dget -x
  
https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.5.5~deb12u1.dsc

Git :

  
https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/bookworm-pu?ref_type=heads

Changes since the last upload:

 runit-services (0.5.5~deb12u1) bookworm; urgency=medium
 .
   * Rebuild for bookworm.

Regards,
Lorenzo

Bug#1051553: ITP: lib25519 -- X25519/Ed25519 microlibrary

[Jan Mojzis]

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

* Package name: lix25519
  Version : 20230630
  Upstream Authort: Daniel J. Bernstein
* URL : https://lib25519.cr.yp.to/
* License : LicenseRef-PD-hp OR CC0-1.0 OR 0BSD OR MIT-0 OR MIT
  Programming Lang: C
  Description : X25519 microlibrary


lib25519 is a microlibrary for the X25519 encryption system and the Ed25519 
signature system, both of which use the Curve25519 elliptic curve. Curve25519 
is the fastest curve in TLS 1.3, and the only curve in Wireguard, Signal, and 
many other applications (see Nicolai Brown's page 
https://ianix.com/pub/curve25519-deployment.html).

lib25519 has a very simple stateless API based on the SUPERCOP API, with 
wire-format inputs and outputs, providing functions that directly match the 
central cryptographic operations in X25519 and Ed25519:

lib25519_dh_keypair(pk,sk): X25519 key generation
lib25519_dh(k,pk,sk): shared-secret generation
lib25519_sign_keypair(pk,sk): Ed25519 key generation
lib25519_sign(sm,,m,mlen,sk): signing
lib25519_sign_open(m,,sm,smlen,pk): verification + message recovery
Internally, lib25519 includes implementations designed for performance on 
various CPUs, implementations designed to work portably across CPUs, and 
automatic run-time selection of implementations.

lib25519 is intended to be called by larger multi-function libraries, including 
libraries in other languages via FFI. The idea is that lib25519 will take 
responsibility for the details of X25519/Ed25519 computation, including 
optimization, timing-attack protection, and eventually verification, freeing up 
the calling libraries to concentrate on application-specific needs such as 
protocol integration. Applications can also call lib25519 directly.

I'm using this library and I'm going to maintain using https://salsa.debian.org/
I need sponsor for the first upload (I'm DM).

Bug#1051552: bookworm-pu: package timg/1.4.5-1+deb12u1

[Tobias Frost]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@packages.debian.org
Control: affects -1 + src:timg


[ Reason ]

Fixing CVE-2023-40968 (buffer overflow vulnerability)


[ Risks ]
Patch is trivial, taken from uptream; local testing done.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable
diff -Nru timg-1.4.5/debian/changelog timg-1.4.5/debian/changelog
--- timg-1.4.5/debian/changelog 2022-11-30 20:09:18.0 +0100
+++ timg-1.4.5/debian/changelog 2023-09-09 19:07:01.0 +0200
@@ -1,3 +1,9 @@
+timg (1.4.5-1+deb12u1) bookworm; urgency=medium
+
+  * Cherry-pick upstream fix for CVE-2023-40968 (Closes: #1051231)
+
+ -- Tobias Frost   Sat, 09 Sep 2023 19:07:01 +0200
+
 timg (1.4.5-1) unstable; urgency=medium
 
   [ Tobias Frost ]
diff -Nru timg-1.4.5/debian/patches/CVE-2023-40968.patch 
timg-1.4.5/debian/patches/CVE-2023-40968.patch
--- timg-1.4.5/debian/patches/CVE-2023-40968.patch  1970-01-01 
01:00:00.0 +0100
+++ timg-1.4.5/debian/patches/CVE-2023-40968.patch  2023-09-09 
19:07:01.0 +0200
@@ -0,0 +1,23 @@
+Description: CVE-2023-40968 buffer overflow vulnerability
+Origin: 
https://github.com/hzeller/timg/commit/2e9414e668144bbe0afc074dac17b74ef4acfdcf 
+Bug: https://github.com/hzeller/timg/issues/115
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051231
+--- a/src/unicode-block-canvas.cc
 b/src/unicode-block-canvas.cc
+@@ -417,13 +417,14 @@
++ SCREEN_END_OF_LINE_LEN);  // Finishing a 
line.
+ 
+ // Depending on even/odd situation, we might need one extra row.
+-const size_t new_backing = width * (height + 1) * sizeof(rgba_t);
++// For quarter, we have one extra possible pixel wider.
++const size_t new_backing = (width + 1) * (height + 1) * sizeof(rgba_t);
+ if (new_backing > backing_buffer_size_) {
+ backing_buffer_  = (rgba_t *)realloc(backing_buffer_, 
new_backing);
+ backing_buffer_size_ = new_backing;
+ }
+ 
+-const size_t new_empty = width * sizeof(rgba_t);
++const size_t new_empty = (width + 1) * sizeof(rgba_t);
+ if (new_empty > empty_line_size_) {
+ empty_line_  = (rgba_t *)realloc(empty_line_, new_empty);
+ empty_line_size_ = new_empty;
diff -Nru timg-1.4.5/debian/patches/series timg-1.4.5/debian/patches/series
--- timg-1.4.5/debian/patches/series2022-11-30 19:52:10.0 +0100
+++ timg-1.4.5/debian/patches/series2023-09-09 19:07:01.0 +0200
@@ -1 +1,2 @@
 use-system-qui.patch
+CVE-2023-40968.patch

Bug#1051551: thunderbird: When deleting a message, the list scrolls up a few messages.

[Alejandro Colomar]

Package: thunderbird
Version: 1:115.2.0-1
Severity: normal
X-Debbugs-Cc: alx.manpa...@gmail.com


Hi,

Since some recent version, every time I delete a mail, the list scrolls
up a few messages, and I need to manually scroll down again, every time.

Cheers,
Alex


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

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

Versions of packages thunderbird depends on:
ii  debianutils  5.12
ii  fontconfig   2.14.2-5
ii  libasound2   1.2.9-2
ii  libatk1.0-0  2.49.91-2
ii  libc62.37-7
ii  libcairo-gobject21.17.8-3
ii  libcairo21.17.8-3
ii  libdbus-1-3  1.14.10-1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.2-5
ii  libfreetype6 2.13.2+dfsg-1
ii  libgcc-s113.2.0-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.77.3-1
ii  libgtk-3-0   3.24.38-4
ii  libnspr4 2:4.35-1.1
ii  libnss3  2:3.92-1
ii  libotr5  4.1.1-5
ii  libpango-1.0-0   1.51.0+ds-2
ii  librnp0  0.17.0-3
ii  libstdc++6   13.2.0-3
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.6-1
ii  libx11-xcb1  2:1.8.6-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxext6 2:1.3.4-1+b1
ii  libxrandr2   2:1.5.2-2+b1
ii  psmisc   23.6-1
ii  x11-utils7.7+5
ii  zlib1g   1:1.2.13.dfsg-3

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2020.12.07-2

Versions of packages thunderbird suggests:
ii  apparmor  3.0.12-1
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.20.1-3

-- no debconf information

Bug#1051537: Acknowledgement (reprepro: upgrade from 5.3.1 to 5.4.2 leaves the database in an inconsistent state upon src inclusion)

[Giorgio Comitini]

I think I can confirm the bug is due to the flag I mentioned in the report.

Using the `berkeleydb` package I wrote the following migrate.py python3 
script:



#!/usr/bin/env python3

import os
import sys
from berkeleydb import db as bdb


def get_paths(db_dir):
    db_dir = os.path.realpath(db_dir, strict=True)
    old_db_file = os.path.join(db_dir, 'references.db')
    new_db_file = old_db_file+'.new'
    old_db_backup_file = old_db_file+'.old'
    return (db_dir, old_db_file, new_db_file, old_db_backup_file)


def create_new_db(filename):
    new_db = bdb.DB()
    new_db.set_flags(bdb.DB_DUPSORT)
    new_db.open(filename, 'references', bdb.DB_BTREE, bdb.DB_CREATE)
    return new_db


def open_old_db(filename):
    old_db = bdb.DB()
    old_db.open(filename, 'references')
    return old_db


def copy_old_to_new(old_db, new_db):
    for (key, value) in old_db.items():
    new_db.put(key, value)


def print_usage(file, exit_code):
    print('Usage: migrate.py db_dir', file=file)
    sys.exit(exit_code)


if __name__ == '__main__':
    if len(sys.argv) != 2:
    print_usage(sys.stderr, 1)
    elif sys.argv[1] in ['-h', '--help']:
    print_usage(sys.stdout, 0)

    (db_dir, old_db_file, new_db_file,
 old_db_backup_file) = get_paths(sys.argv[1])

    if os.path.exists(old_db_backup_file):
    print(
    f'Error: cannot start as a references.db.old file already 
exists in {db_dir}')


    new_db = create_new_db(new_db_file)
    old_db = open_old_db(old_db_file)
    copy_old_to_new(old_db, new_db)

    # store the old references.db file as references.db.old as a backup
    os.rename(old_db_file, old_db_backup_file)
    os.rename(new_db_file, old_db_file)


What this does is it replaces the references.db file with a copy of the same
file with the DUPSORT flag instead of DUP. If I pass the old file and 
the new

one to `db_dump -p`, they are shown to be the same except for the new
`dupsort=1` flag. Also their stats (`db_stat`) appear to be the same.

Turning the dupsort flag on using the above script in a references.db file
created with reprepro v5.4.2, and then including two source packages which
share the same upstream package does indeed yield the DB_KEYEXIST error I
reported. Thus that flag appears to be actually causing this issue.

Note that the script - as written above - spoils a v5.4.2 references.db, it
does not fix one created with v5.3.1! To fix the latter one needs to replace


def create_new_db(filename):
    new_db = bdb.DB()
    new_db.set_flags(bdb.DB_DUPSORT) # FLAG HERE
    new_db.open(filename, 'references', bdb.DB_BTREE, bdb.DB_CREATE)
    return new_db


with


def create_new_db(filename):
    new_db = bdb.DB()
    new_db.set_flags(bdb.DB_DUP) # FLAG HERE
    new_db.open(filename, 'references', bdb.DB_BTREE, bdb.DB_CREATE)
    return new_db


so that the database file is created with the v5.4.2 DUP flag instead of
DUPSORT. I checked that, after changing the flag, the old database is 
able to

store source packages with the same *.orig.tar.gz/.xz file without showing
undesidered behavior (as far as I can tell).

Thus it looks like rewriting the references.db file with the DUP flag 
instead

of DUPSORT upon first opening of the database, after an upgrade of reprepro,
may be sufficient to fix this bug.

Bug#1016957: kbd-chooser: please add support for riscv64

[Bastian Germann]

Control: severity -1 serious

On Wed, 10 Aug 2022 21:42:34 +0200 Holger Wansing  wrote:

kbd-chooser is no longer in use, I think.
Or am I missing something?


I am raising severity to serious then so that it can be autoremoved from 
testing.

Bug#784811: d-i.debian.org: rmadison on dillon fails because of certificate checks

[Adam D. Barratt]

On Sat, 2015-05-09 at 05:02 +0200, Cyril Brulebois wrote:
> Cyril Brulebois  (2015-05-09):
> > I've crafted a patch and I'll block this bug report with it; I
> > might set
> > up some workaround until this is resolved in a proper way.
> 
> That's #784812.
> 
> Local changes in dillon include:
>  - mailing kibi@d.o instead of debian-boot@, because debugging and
> other
>annoyances listed as d-i.debian.org bug reports; I don't want more
>junk to be sent to the list.
>  - hardcoded paths in an additional $ua->ssl_opts(…) call, because
>rmadison isn't the only one which needs to be told about the CA
> path.
>  - calling ./rmadison instead of /usr/bin/rmadison, so that #784812
>isn't a blocker.
> 

For the record, #784812 was resolved a couple of months after the
above.

All debian.org hosts should also now be able to run tools such as
rmadison without needing any special configuration.

I'm not closing the bug, as it's not clear to me from the above whether
there are changes which might want to be reverted on the d-i.d.o side.

Regards,

Adam

Bug#1051550: node-rollup-plugin-terser: Please update (or embed) to @rollup/plugin-terser

[Yadd]

Package: node-rollup-plugin-terser
Version: 7.0.2+~5.0.1-8
Severity: wishlist

Hi,

rollup-plugin-terser is going to be replaced by @rollup/plugin-terser.
Could you update this package or embed both during transition ?

Cheers,
Yadd

Bug#1051241: headsup for gtk + pipewire update

[Matthias Geiger]

On 05.09.23 18:22, Jonas Smedegaard wrote:

Hi Matthias,

Quoting Matthias Geiger (2023-09-05 00:59:16)

Hi Jonas. This is just a heads-up for the upcoming gtk + pipewire
transition I am working on. the latest (0.4.1) release of helvum
does depend on the versions I will update to anyway; so this won't be
much of an issue. A problem might be helvum 0.4.1 depending on rustc
1.70. Can you maybe test if you can get it to build with the older one
currently in debian ? note that I patched all gtk-rs crates to use the
older version; they are compiling fine.

I will upload gtk-rs probably until eow.

Please release gtk-rs to experimental first, so that I can test-build
against.

Thanks,

  - Jonas

I uploaded all -sys crates with their regenerated code and new upstream 
to experimental.


The regular crates can't be built atm because they require rustc 1.70. 
The update will commence once the newer rustc lands.


best,

--
Matthias Geiger (werdahias)
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1051549: ITP: node-jsan -- JavaScript "All The Things" Notation

[Yadd]

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

* Package name: node-jsan
  Version : 3.1.14
  Upstream Contact: Moshe Kolodny
  
* URL : https://github.com/kolodny/jsan
* License : Expat
  Programming Lang: JavasCRIPT
  Description : JavaScript "All The Things" Notation

node-jsan Easily stringify and parse any object including objects with
circular references, self references, dates, regexes, `undefined`, errors,
and even functions.

node-jsan is a dependency of node-redux-devtools which is needed by
node-jupyterlab. This package will be maintained under JS Team umbrella.

Bug#1037629: dublin-traceroute: ftbfs with GCC-13

[Jonathan Bergh]

Control: tags 1037629 + patch

Patch to update to use gcc-13


patch1.debdiff
Description: Binary data

Bug#1051548: Regression: live-build 20230502 generates corrupted images when using bookworm-backports APT pinning for kernel

[S.]

Package: live-build
X-Debbugs-Cc: wfhnb...@duck.com
Version: 20230502
Severity: normal

Hi there,

I have used live-build 20210407 on Debian 11 to successfully build a large 
number of Debian 11 based images. Now I'm using the same config and process 
with live-build 20230502 on Debian 12 to build Debian 12 based images. There 
appears to be a major regression with live-build 20230502 on Debian 12 when 
using this APT pinning:

### config/includes.chroot/etc/apt/preferences.d/99backports ###

Package: linux-image-*
Pin: release a=stable-backports
Pin-Priority: 600

Package: linux-headers-*
Pin: release a=stable-backports
Pin-Priority: 600

Package: firmware-*
Pin: release a=stable-backports
Pin-Priority: 600

Package: nvidia-driver
Pin: release a=stable-backports
Pin-Priority: 600



With that APT pinning, live-build 20210407 on Debian 11 generates a Debian 12 
ISO with the latest Debian Stable kernel (6.1.0) as well as the latest Debian 
Backports kernel (6.4.0) that successfully boots and works as expected. Here's 
a screenshot:
https://sourceforge.net/projects/spirallinux/files/dev/SpiralLinux-built-Debian11.png/download

Here's the full live-build config I'm using:
https://sourceforge.net/projects/spirallinux/files/dev/SpiralLinux-Cinnamon.tar.gz/download

However, with the exact same config but using live-build 20230502 on Debian 12, 
it generates an ISO that shows both the 6.1.0 and the 6.4.0 kernels in the live 
system GRUB boot menu (on an EFI system), but when selecting the 6.4.0 kernel 
it boots into X11 and then completely freezes. I've confirmed this same 
behavior with VirtualBox, Qemu, and real hardware. When booting into runlevel 3 
it bizarrely says I'm running the 6.4.0 kernel and yet the 6.4.0 kernel doesn't 
appear in /boot. Here's a screenshot:
https://sourceforge.net/projects/spirallinux/files/dev/SpiralLinux-built-Debian12.png/download

Just to confirm that it's not an issue with my config, I also built an image 
with https://github.com/nodiscc/debian-live-config but added the above 
mentioned APT pinning, and the exact same thing happened.

Here's the build log with live-build 20210407 on Debian 11 and the resulting 
ISO:
- 
https://sourceforge.net/projects/spirallinux/files/dev/SpiralLinux-built-Debian11.log/download
- 
https://sourceforge.net/projects/spirallinux/files/dev/SpiralLinux-test-working.iso/download
And here's the build log with live-build 20230502 on Debian 12 and the 
resulting ISO:
- 
https://sourceforge.net/projects/spirallinux/files/dev/SpiralLinux-built-Debian12.log/download
- 
https://sourceforge.net/projects/spirallinux/files/dev/SpiralLinux-test-broken.iso/download

Please let me know if you need any more information. Thanks!

Bug#1050124: vte2.91 0.70.6-2~deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: vte2.91
Version: 0.70.6-2~deb12u1

Explanation: 

Bug#1050838: debian-edu-install 2.12.9~deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: debian-edu-install
Version: 2.12.9~deb12u1

Explanation: new upstream release; adjust D-I auto-partitioning sizes

Bug#1051429: openrefine 3.6.2-2+deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: openrefine
Version: 3.6.2-2+deb12u1

Explanation: fix arbitrary code execution issue [CVE-2023-37476]

Bug#1051257: horizon 23.0.0-5+deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: horizon
Version: 23.0.0-5+deb12u1

Explanation: fix open redirect issue [CVE-2022-45582]

Bug#1050721: sitesummary 0.1.56~deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: sitesummary
Version: 0.1.56~deb12u1

Explanation: new upstream release; fix installation of sitesummary-maintenance 
CRON/systemd-timerd script; fix insecure temporary file and directory creation

Bug#1050681: inn2 2.7.1-1+deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: inn2
Version: 2.7.1-1+deb12u1

Explanation: fix nnrpd hangs when compression is enabled; add support for 
high-precision syslog timestamps; make inn-{radius,secrets}.conf not world 
readable

Bug#1050572: openssl 3.0.10-1~deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: openssl
Version: 3.0.10-1~deb12u1

Explanation: new upstream stable release; security fixes [CVE-2023-2975 
CVE-2023-3446 CVE-2023-3817]

Bug#1050562: unrar-nonfree 6.2.6-1+deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: unrar-nonfree
Version: 6.2.6-1+deb12u1

Explanation: fix remote code execution issue [CVE-2023-40477]

Bug#1050546: vorta 0.8.10-1+deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: vorta
Version: 0.8.10-1+deb12u1

Explanation: handle ctime and mtime changes in diffs

Bug#1050457: arctica-greeter 0.99.3.0-1+deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: arctica-greeter
Version: 0.99.3.0-1+deb12u1

Explanation: support configuring the onscreen keyboard theme via 
ArcticaGreeter's gsettings; use 'Compact' OSK layout (instead of Small) which 
includes special keys such as German Umlauts; fix display of authentication 
failure messages; use active theme rather then emerald

Bug#1051508: libclamunrar 0.103.10-1~deb11u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libclamunrar
Version: 0.103.10-1~deb11u1

Explanation: new upstream stable release

Bug#1051339: horizon 18.6.2-5+deb11u2 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: horizon
Version: 18.6.2-5+deb11u2

Explanation: fix open redirect issue [CVE-2022-45582]

Bug#1050333: ltsp 21.01-1+deb11u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: ltsp
Version: 21.01-1+deb11u1

Explanation: avoid using "mv" on init symlink in order to work around overlayfs 
issue

Bug#1050573: openssl 1.1.1v-0~deb11u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: openssl
Version: 1.1.1v-0~deb11u1

Explanation: new upstream stable release; fix denial of service issues 
[CVE-2023-3446 CVE-2023-3817]

Bug#1050119: unrar-nonfree 6.0.3-1+deb11u3 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: unrar-nonfree
Version: 6.0.3-1+deb11u3

Explanation: fix remote code execution issue [CVE-2023-40477]

Bug#1050119: unrar-nonfree 6.0.3-1+deb11u2 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: unrar-nonfree
Version: 6.0.3-1+deb11u2

Explanation: fix file overwrite issue [CVE-2022-48579]

Bug#1050044: rar 6.23-1~deb11u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: rar
Version: 6.23-1~deb11u1

Explanation: new upstream stable version; fix arbitrary code execution issue 
[CVE-2023-40477]

Bug#1050044: rar 6.20-0.1~deb11u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: rar
Version: 6.20-0.1~deb11u1

Explanation: new upstream release; fix directory traversal issue 
[CVE-2022-30333]

Bug#1051547: Regression: live-build 20230502 generates corrupted images when using bookworm-backports APT pinning for kernel

[sb56637]

Package: live-build
Version: 20230502

Hi there,

I have used live-build 20210407 on Debian 11 to successfully build a large 
number of Debian 11 based images. Now I'm using the same config and process 
with live-build 20230502 on Debian 12 to build Debian 12 based images. There 
appears to be a major regression with live-build 20230502 on Debian 12 when 
using this APT pinning:

### config/includes.chroot/etc/apt/preferences.d/99backports ###

Package: linux-image-*
Pin: release a=stable-backports
Pin-Priority: 600

Package: linux-headers-*
Pin: release a=stable-backports
Pin-Priority: 600

Package: firmware-*
Pin: release a=stable-backports
Pin-Priority: 600

Package: nvidia-driver
Pin: release a=stable-backports
Pin-Priority: 600



With that APT pinning, live-build 20210407 on Debian 11 generates a Debian 12 
ISO with the latest Debian Stable kernel (6.1.0) as well as the latest Debian 
Backports kernel (6.4.0) that successfully boots and works as expected. Here's 
a screenshot:
https://sourceforge.net/projects/spirallinux/files/dev/SpiralLinux-built-Debian11.png/download

Here's the full live-build config I'm using:
https://sourceforge.net/projects/spirallinux/files/dev/SpiralLinux-Cinnamon.tar.gz/download

However, with the exact same config but using live-build 20230502 on Debian 12, 
it generates an ISO that shows both the 6.1.0 and the 6.4.0 kernels in the live 
system GRUB boot menu (on an EFI system), but when selecting the 6.4.0 kernel 
it boots into X11 and then completely freezes. I've confirmed this same 
behavior with VirtualBox, Qemu, and real hardware. When booting into runlevel 3 
it bizarrely says I'm running the 6.4.0 kernel and yet the 6.4.0 kernel doesn't 
appear in /boot. Here's a screenshot:
https://sourceforge.net/projects/spirallinux/files/dev/SpiralLinux-built-Debian12.png/download

Just to confirm that it's not an issue with my config, I also built an image 
with https://github.com/nodiscc/debian-live-config but added the above 
mentioned APT pinning, and the exact same thing happened.

Here's the build log with live-build 20210407 on Debian 11 and the resulting 
ISO:
- 
https://sourceforge.net/projects/spirallinux/files/dev/SpiralLinux-built-Debian11.log/download
- 
https://sourceforge.net/projects/spirallinux/files/dev/SpiralLinux-test-working.iso/download
And here's the build log with live-build 20230502 on Debian 12 and the 
resulting ISO:
- 
https://sourceforge.net/projects/spirallinux/files/dev/SpiralLinux-built-Debian12.log/download
- 
https://sourceforge.net/projects/spirallinux/files/dev/SpiralLinux-test-broken.iso/download

Please let me know if you need any more information. Thanks!

Bug#1031842: xdg-desktop-portal-gnome: 44 appears incompatible with GNOME Shell 43

[Simon McVittie]

On Thu, 23 Feb 2023 at 19:58:20 -0500, Jeremy Bícha wrote:
> It appears that xdg-desktop-portal-gnome 44 is incompatible with
> mutter/gnome-shell 43.
>
> GNOME Shell 43 uses libmutter-11-0 ; GNOME Shell 44 uses libmutter-12-0
> 
> Therefore, would it be correct to set an unversioned
> Breaks: libmutter-11-0

Sorry, I don't know why I didn't see this bug report until now. We now
have all of GNOME 44 (and a GNOME-44-compatible version of Budgie) in
trixie, so this is only practically relevant for upgrades from bookworm
to trixie.

A Breaks on libmutter-11-0 seems a bit weird, because it isn't really
true to say that x-d-p-gnome has any relationship with libmutter,
a library that it isn't linked to; it's more like it needs a desktop
environment that provides org.gnome.Mutter.ServiceChannel on D-Bus and
mutter_x11_interop on Wayland, for which the two examples I know of are
gnome-shell and budgie-desktop.

x-d-p-gnome already Recommends gnome-shell (>= x) | budgie-desktop (>= y).
We should certainly increase these to gnome-shell (>= 44) and an analogous
version of Budgie, and maybe we should strengthen them to Depends?

If we don't strengthen that to Depends, I think giving x-d-p a Breaks on
gnome-shell (<< 44), budgie-desktop (<< equivalent version) would be a
good thing to have too.

We might also want Breaks on gnome-shell (>= 45~), or Depends on
gnome-shell (<< 45~)?

If I understand correctly, the next major version of Budgie is going to
stop using mutter, so maybe it will also stop being compatible with
x-d-p-gnome? We'll see.

smcv

Bug#1051546: jstest-gtk: Unable to open file "data/generic.png"

[Arnaud Meyer]

Package: jstest-gtk
Version: 0.1.1~git20180602-1
Severity: important
X-Debbugs-Cc: arnaudme...@gmx.com

Dear Maintainer,

jstest-gtk immediately crashes on start, regardless on whether a
controller is connected or not. When run on a terminal, it issues a
message telling that it cannot open file "data/generic.png".

A workaround is to change directories on the terminal and run jstest-gtk
directly from its data directory:

$ cd /usr/share/jstest-gtk
$ jstest-gtk

Regards,
Arnaud Meyer.


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

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

Versions of packages jstest-gtk depends on:
ii  libatkmm-1.6-1v52.28.3-1
ii  libc6   2.37-7
ii  libcairomm-1.0-1v5  1.14.4-2
ii  libgcc-s1   13.2.0-2
ii  libglibmm-2.4-1v5   2.66.6-2
ii  libgtkmm-3.0-1v53.24.8-2
ii  libsigc++-2.0-0v5   2.12.0-1
ii  libstdc++6  13.2.0-2
ii  libx11-62:1.8.6-1

Versions of packages jstest-gtk recommends:
ii  joystick  1:1.8.1-1

jstest-gtk suggests no packages.

-- no debconf information

Bug#1051544: ding: looking up words is very slow

[Christian Weiske]

Hello Roland,


Thank you for your very kind answer.

I installed glimpse, set the search tool to agrep and now have blazing
fast results.

I'd see this as configuration problem and not as a wishlist item.

But a note in the man page would be nice; telling people to install
glimpse when searching is slow.

-- 
Regards/Mit freundlichen Grüßen
Christian Weiske

-=≡ Geeking around in the name of science since 1982 ≡=-