Bug#1051186: *-dkms packages shouldn't fail postinst if all modules to be installed already exist in identical versions

[Andras Korn]

Package: dkms
Version: 3.0.11-3
Severity: normal

Hi,

I have computers where I install both zfs-dkms and sometimes 
zfs-modules- packages.

When zfs-modules- is installed, zfs-dkms fails postinst:

[...]
zzstd.ko:
Running module version sanity check.
Module version 1.4.5a-2.1.12-2 for zzstd.ko
exactly matches what is already found in kernel 6.4.0-3-amd64.
DKMS will not replace this module.
You may override by specifying --force.
Error! Installation aborted.
dpkg: error processing package zfs-dkms (--configure):
 installed zfs-dkms package post-installation script subprocess returned error 
exit status 6

I think that when all modules to be installed exactly match the ones already in 
place, that shouldn't result in a failure.

In case you wonder why I'm doing this: these computers take forever to build 
kernel modules, so whenever possible, I install pre-built modules and want to 
keep dkms only as a failsafe, to make sure the zfs modules are in place before 
I reboot (because they're needed for booting).

I'm filing the bugreport against dkms because it contains these lines of code 
(around line 800):

if [[ ! "$force" ]]; then
# if the module has neither version nor srcversion/checksum, check 
the binary files instead
local verinfo="$(get_module_verinfo "${dkms_module}")"
if [[ "$(echo "$verinfo" | tr -d '[:space:]')" ]] || diff 
"${kernels_module}" "${dkms_module}" &>/dev/null; then
echo $"Module version $(echo "$verinfo" | head -n 1) for 
$4${module_suffix}" >&2
echo $"exactly matches what is already found in kernel $1." >&2
echo $"DKMS will not replace this module." >&2
echo $"You may override by specifying --force." >&2
return 1
fi
fi

I believe that "return 1" should be a "return 0" because there is no failure. A 
binary with the exact same version and/or contents is already installed; that's 
exactly the outcome dkms was asked to achieve.

I'll file a separate bug against zfs-dkms asking to avoid building the module 
for kernels for which an appropriate zfs-modules- package is installed.

András

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

Kernel: Linux 6.4.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Init: runit (via /run/runit.stopit)

-- 
  Give a man a fire and he's warm for a day, but set
  fire to him and he's warm for the rest of his life.

Bug#1051185: libsass: Please update symbols file for loong64

[John Paul Adrian Glaubitz]

Source: libsas
Version: 3.6.5+20220909-3
Severity: normal
User: debian-de...@lists.debian.org
Usertags: loong64
X-Debbugs-Cc: zhangjial...@loongson.cn,zhangdan...@loongson.cn

Hi!

src:libsass currently FTBFS on loong64 due to a mismatching symbols file:

  
(optional=templinst)_ZSt22__final_insertion_sortIN9__gnu_cxx17__normal_iteratorIPP13Sass_ImporterSt6vectorIS3_SaIS3_NS0_5__ops15_Iter_comp_iterIPFbRKS3_SC_vT_SG_T0_@Base
 3.5.5-4~
  
(optional=templinst)_ZSt25__unguarded_linear_insertIN9__gnu_cxx17__normal_iteratorIPN4Sass10SharedImplINS2_14SimpleSelectorEEESt6vectorIS5_SaIS5_NS0_5__ops14_Val_comp_iterIPFbPS4_SD_vT_T0_@Base
 3.6.4-2~
  
(optional=templinst)_ZSt4swapIN4Sass10SharedImplINS0_14SimpleSelectorNSt9enable_ifIXsrSt6__and_IJSt6__not_ISt15__is_tuple_likeIT_EESt21is_move_constructibleIS8_ESt18is_move_assignableIS8_EEE5valueEvE4typeERS8_SI_@Base
 3.6.4-2~
- 
(optional=templinst)_ZSteqIcSt11char_traitsIcESaIcEEbRKNSt7__cxx1112basic_stringIT_T0_T1_EEPKS5_@Base
 3.6.5+20220909
- 
(optional=templinst)_ZSteqIcSt11char_traitsIcESaIcEEbRKNSt7__cxx1112basic_stringIT_T0_T1_EESA_@Base
 3.6.5+20220909
+#MISSING: 3.6.5+20220909-3# 
(optional=templinst)_ZSteqIcSt11char_traitsIcESaIcEEbRKNSt7__cxx1112basic_stringIT_T0_T1_EEPKS5_@Base
 3.6.5+20220909
+#MISSING: 3.6.5+20220909-3# 
(optional=templinst)_ZSteqIcSt11char_traitsIcESaIcEEbRKNSt7__cxx1112basic_stringIT_T0_T1_EESA_@Base
 3.6.5+20220909
  
(optional=templinst)_ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EEOS8_S9_@Base
 3.6.4-2~
  (optional=templinst|arch=amd64 arm64 kfreebsd-amd64 
x32)_ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EEPKS5_OS8_@Base
 3.5.5-4~
+ 
_ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EEPKS5_RKS8_@Base
 3.6.5+20220909-3
  _ZTIN4Sass10AssignmentE@Base 3.5.5-4~
  _ZTIN4Sass10AtRootRuleE@Base 3.6.4-2~
  _ZTIN4Sass10Color_HSLAE@Base 3.6.4
dh_makeshlibs: error: failing due to earlier errors
make: *** [debian/rules:15: binary-arch] Error 25

Could this be updated for the next upload using the build log?

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=libsass=loong64=3.6.5%2B20220909-3=1693584389=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1051184: debhelper: expose restore_file_on_clean() in an helper command

[Mattia Rizzolo]

Package: debhelper
Version: 13.11.6
Severity: wishlist

Hello dh people!

To fix one of the recent bugs about double-build, I found myself writing
this in my rules file:

execute_before_dh_auto_build:
set -e; [ ! -e $(shell command -v ragel) ] || \
perl -MDebian::Debhelper::Dh_Lib=restore_file_on_clean \
-e 
'restore_file_on_clean("src/2geom/svg-path-parser.cpp")'


I find your bucket function very handy, and overall this is still
shorter than doing everything myself, however I think it would be nice
if you could provide a proper command or something somewhere that does
not require manually invoking perl.


Thank you for considering!

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#1051090: emacsql: FTBFS: 5 unexpected results

[Manphiz]

control: tags -1 patch

Hi,

I have prepare a patch set that sync to the latest head version that
fixes the test failures.  The patch set also contains upstream patches,
and Debian related work starts from
0043-Update-changelog-for-new-upstream-3.1.1-git20230417..patch.

Thanks, and PTAL!


emacsql-patches.tar.xz
Description: application/xz

-- 
Manphiz

Bug#1051181: more info

[Russell Coker]

# id test
uid=1001(test) gid=1001(test) groups=1001(test),1003(),1004(zzz2),
1005(test2),1006(test6),1007(test7),1008(test8),1009(test9),1010(test10),
1011(test11),1012(test12),1013(test13),1014(test14),1015(test15),1016(test16),
1017(test17),1018(test18),1019(test19)

The above is the test user I used for compiling.  The real use case was a user 
in a corporate network with 30+ groups from Active Directory.  This sort of AD 
configuration is increasingly common and should work.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#1051183: RFS: gsimplecal/2.5-1 -- lightweight GUI calendar application

[Hugo Torres]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gsimplecal":

 * Package name : gsimplecal
   Version  : 2.5-1
   Upstream contact : https://github.com/dmedvinsky/gsimplecal/issues
 * URL  : https://dmedvinsky.github.io/gsimplecal
 * License  : BSD-3-Clause
 * Vcs  : https://salsa.debian.org/debian/gsimplecal
   Section  : misc

The source builds the following binary packages:

  gsimplecal - lightweight GUI calendar application

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

  https://mentors.debian.net/package/gsimplecal/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gsimplecal/gsimplecal_2.5-1.dsc

Changes since the last upload:

 gsimplecal (2.5-1) unstable; urgency=medium
 .
   * New upstream version 2.5
   * debian/control: bumped·Standards-Version·to 4.6.2
   * debian/copyright: Updated upstream copyright year.

Regards,
--
  Hugo Torres de Lima

Bug#1051182: wsjtx: new upstream version 2.7.x

[tony mancill]

Source: wsjtx
Version: 2.6.1+repack-1
Severity: wishlist

This bug is for coordination purposes.  I am in the process of preparing
an upload of WSJT-X 2.7.0-rc2 to experimental, but I believe that it
may require an upload of hamlib 4.6 (which will also likely need to go
to experimental first).

The debian branch will be pushed to debian/experimental to follow DEP-14
(https://dep-team.pages.debian.net/deps/dep14/), and if the team is okay
with it, I propose switching from master -> debian/latest when the
package is ready for upload to unstable.

Cheers,
tony

Bug#1051181: FTBFS: can't build package when user has more than 16 supplementary groups

[Russell Coker]

Package: fapolicyd
Version: 1.1.7-5
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

# TOTAL: 2
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: gid_proc_test
===

./gid_proc_test: Too many groups
FAIL gid_proc_test (exit status: 1)

Above are the relevant parts of the compile output when trying to build it by a
user with more than 16 supplementary groups.

Below is the patch to fix this:


Index: fapolicyd-1.1.7/src/tests/gid_proc_test.c
===
--- fapolicyd-1.1.7.orig/src/tests/gid_proc_test.c
+++ fapolicyd-1.1.7/src/tests/gid_proc_test.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "attr-sets.h"
 #include "process.h"
@@ -9,7 +10,7 @@
 int main(void)
 {
int res, num, i, check_intersect = 0;
-   gid_t gid, gids[16];
+   gid_t gid, gids[NGROUPS_MAX];
attr_sets_entry_t *groups = get_gid_set_from_pid(getpid());
 
gid = getgid();
@@ -17,7 +18,7 @@ int main(void)
if (!res)
error(1, 0, "Group %d not found", gid);
 
-   num = getgroups(16, gids);
+   num = getgroups(NGROUPS_MAX, gids);
if (num < 0)
error(1, 0, "Too many groups");
 

-- System Information:
Debian Release: trixie/sid
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.0-4-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#1051180: checkinstall: cmake 'No such file or directory' while using with checkinstall

[axet]

Package: checkinstall
Version: 1.6.2+git20170426.d24a630-3+b1
Severity: normal

Dear Maintainer,

When using cmake build with checkinstall I see 'No such file or directory' 
error,
even when file and folder actually exists.

git clone https://github.com/dpayne/cli-visualizer
cd cli-visualizer
mkdir build
cd build
cmake ..
make
checkinstall

  file INSTALL cannot copy file
  "/media/axet/128GB/local/cli-visualizer/build/vis" to "/usr/local/bin/vis":
  No such file or directory

If I run 'checkinstall ./123.sh' and copy this file using 'cp' command it works 
and deb fill will be created.

-- 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 checkinstall depends on:
ii  dpkg-dev1.21.22
ii  file1:5.44-3
ii  libc6   2.36-9+deb12u1
ii  sensible-utils  0.0.17+nmu1

Versions of packages checkinstall recommends:
ii  make  4.3-4.1

Versions of packages checkinstall suggests:
ii  gettext  0.21-12

-- no debconf information

Bug#1050013: gcc-13: Please don't build the Ada, Go, D and M2 on LoongArch

[zhangdandan]

Control: tags -1 - moreinfo

Dear maintainer,

Thanks for your reply.
During this time, we've been confirming upstream reports for each of 
these frontends.


在 2023/8/18 下午8:08, Matthias Klose 写道:

Control: tags -1 + moreinfo

please can you file upstream reports for each of these frontends?

In the gcc-13 release, support for the LoongArch architecture in Ada, 
Go, D, and Modula-2 are as follows.


- Ada
The Ada module of gcc-13 does not support LoongArch.
Support for the LoongArch architecture has been submitted to gcc 
upstream, see [1].


- Go
The Go module of gcc-13 does not support LoongArch.
The code for go is synchronized from https://go.googlesource.com/gofrontend.
The LoongArch architecture has not yet submitted a patch to the go 
repository.


- D
The D module of gcc-13 does not support LoongArch.
The code for D is synchronized from https://github.com/dlang/dmd
LoongArch architecture has not yet submitted a patch to the D repository.

- Modula-2
The M2 module does not need to add architectural support.
Would like to be consistent with other architectures in gcc-14 release.

Anyway, regarding the gcc-13 version, we would like to turn off Ada, Go, 
D and M2 modules on the LoongArch architecture in the gcc-13 source 
package.
In the future, the appropriate modules will be turned on, depending on 
gcc upstream's support for the loongarch architecture.


[1]:https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627951.html

thanks,
Dandan Zhang

Bug#1051179: flameshot: Flameshot Wayland Bookworm doesn't work, vendor stock version works out of the box

[Jonathan Kamens]

Package: flameshot
Version: 12.1.0-2
Severity: important

Dear Maintainer,

The version of flameshot included in Bookworm is incapable of taking
screenshots in Wayland. When you tell it to take a screenshot it just
hangs.

I cloned https://github.org/flameshot-org/flameshot, ran "apt
build-dep flameshot", and then followed the instructions in README.md
to build and install in /usr/local, and it works just fine. This is
probably just a matter of upgrading the Debian repository to match the
current Flameshot codebase.

-- 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/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages flameshot depends on:
ii  hicolor-icon-theme  0.17-2
ii  libc6   2.36-9+deb12u1
ii  libgcc-s1   12.2.0-14
ii  libqt5core5a5.15.8+dfsg-11
ii  libqt5dbus5 5.15.8+dfsg-11
ii  libqt5gui5  5.15.8+dfsg-11
ii  libqt5network5  5.15.8+dfsg-11
ii  libqt5svg5  5.15.8-3
ii  libqt5widgets5  5.15.8+dfsg-11
ii  libstdc++6  12.2.0-14

Versions of packages flameshot recommends:
ii  grim  1.4.0+ds-2
ii  xdg-desktop-portal-gnome  43.1-2
ii  xdg-desktop-portal-gtk1.14.1-1

Versions of packages flameshot suggests:
ii  ca-certificates  20230311
ii  openssl  3.0.9-1

-- no debconf information

Bug#1027989: Does not work with current ntpdate

[Roger Shimizu]

control: tags -1 +help

On Thu, Jan 5, 2023 at 8:09 AM Klaus Ethgen  wrote:
>
> Package: adjtimex
> Version: 1.29-11+b1
> Severity: normal
>
> Logging the clock screw to optimize parameters in /etc/adjtime is a
> major function of adjtimex. But it is now incompatible to the needed
> ntpdate:
>~> adjtimex -l -h 
>ntpdate: -p is no longer supported.
>ntpdig: querying xxx.xxx.xx.x ()
>cannot understand ntpdate output

Thanks for the report!

Package ntpdate became deprecated since bookworm [1]
and was replaced by ntpsec-ntpdate [2].

[1] https://packages.debian.org/bookworm/ntpdate
[2] https://packages.debian.org/bookworm/ntpsec-ntpdate

in adjtimex.c

ntpdate command output is supposed to be:

  /* read and save the significant lines, which should look like this:
filter offset: -0.02800 -0.01354 -0.01026 -0.01385
offset -0.013543
 1 Sep 11:51:23 ntpdate[598]: adjust time server 1.2.3.4 offset -0.013543 sec
 */

however, ntpdate provides by ntpsec-ntpdate output like this:

$ /usr/sbin/ntpdate -d -q pool.ntp.org
ntpdig: querying 208.113.130.146 (pool.ntp.org)
ntpdig: querying 138.236.128.36 (pool.ntp.org)
ntpdig: querying 68.112.4.226 (pool.ntp.org)
ntpdig: querying 66.228.58.20 (pool.ntp.org)
org t1: e89fa995.15b83000 rec t2: e89fa995.1f6674d8
xmt t3: e89fa995.1f673573 dst t4: e89fa995.29a78000
org t1: 1693788949.084842 rec t2: 1693788949.122657
xmt t3: 1693788949.122669 dst t4: 1693788949.162712
rec-org t21: 0.037816  xmt-dst t34: -0.040043
2023-09-03 17:55:49.122668 (-0700) -0.001114 +/- 0.038931 pool.ntp.org
208.113.130.146 s2 no-leap

so looks like it's hard to get the 4 samples of "filter offset" from
current output.
If you have any ideas, please let me know. Thank you!

Cheers,
Roger

Bug#1050256: autopkgtest fails on debci

[Michael Biebl]

Am 03.09.23 um 10:50 schrieb Paul Gevers:

Hi,

On 03-09-2023 02:56, Michael Biebl wrote:

ng?


Do the debci maintainers  / lxc maintainers / release team have any 
preference regarding a/, b/ and c/ ?


One part of me likes the ci.d.n infrastructure to run stable as an 
example of "eat your own dogfood". Another part of me agrees with 
Antonio that it makes sense if it would run a backports kernel to be as 
close as possible to testing as we can reasonably (maintenance wise) can 
get. Because we have a known issue at hand, the balance goes to 
backports for me. If Antonio doesn't beat me to it, I'll get to it 
(although I don't know yet how to do that in our configuration [1] and 
exclude riscv64 too). I have manually upgraded the s390x host and 
rebooted, so that can serve as a test arch.


Seems it worked, the latest run succeeded:
https://ci.debian.net/data/autopkgtest/testing/s390x/s/systemd/37374052/log.gz

Thanks!




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050944: debhelper-compat level

[Vladimir Petko]

Hi,

 Yes, the main reason for keeping the old debhelper for jtreg is that
its version is kept in sync with openjdk (due to the build
requirements of openjdk). The updated versions of jtreg normally work
with older dependencies, so we do not need to upgrade them often. The
security updates (of Ubuntu and Debian) require us to publish updated
jtregX along with the openjdk and this forces us to keep the old
debhelper version.

Best Regards,
 Vladimir.

On Mon, Sep 4, 2023 at 11:48 AM tony mancill  wrote:
>
> Hi Vladimir,
>
> Definitely no need for you to apologize.  I hope my tone didn't come
> across as aggressive.  My goal is merely to establish what we (meaning,
> the Java Team) should take into consideration for backports.  Based on
> the exchange so far, it appears
> that we want to keep jtreg6 (and all other direct build-deps for
> openjdk-${x}) at debhelper 11 for as long as Ubuntu bionic receives
> security support , but that transitive build-deps, for example
> libhamcrest-java, can be upgraded without causing problems.  Does that
> capture the rationale correctly?
>
> By the way, the reason we bump debhelper-compat is because some of the
> Debian Java tooling behaves differently at the older compatibility
> versions, and so keeping things consistent and current means fewer
> exceptions in package build behavior.
>
> Specifically, gradle-debian-helper doesn't automatically run tests at
> debhelper-compat 11, but does at dh 13 [1].  This is one response to
> Matthias' question "is there any reason to use debhelper 13?" in May of
> 2021 [2].  (Yes, because gradle-debian-helper behaves differently in
> debhelper 13 since November of 2019.)
>
> I will make a note in the jtreg6 README.source as to why we want to stay
> with debhelper 11.
>
> Thanks!
> tony
>
> [1] 
> https://salsa.debian.org/java-team/gradle-debian-helper/-/commit/9417606c1ffaed9571045cb055f80350783c0555
> [2] https://lists.debian.org/debian-java/2021/05/msg00012.html
>
> On Sun, Sep 03, 2023 at 05:33:36PM +1200, Vladimir Petko wrote:
> > Hi,
> >
> >  I apologise for my earlier comment being too vague and in the wrong
> > tone and mentioning a completely wrong (or misleading) thing. We do
> > openjdk security updates in -security pocket in Ubuntu and according
> > to security team FAQ[1] the updates are built with -release and
> > -security pockets. The updated debhelper is present in the backports
> > pocket which is not used by the security team for security updates.
> > This means that we are stuck with the older (11) debhelper version in
> > order to build security updates for bionic and up.
> >
> > Best Regards,
> >  Vladimir.
> >
> > [1] 
> > https://wiki.ubuntu.com/SecurityTeam/FAQ#How_are_the_.22-updates.22_and_.22-security.22_pockets_different.3F
> >
> > On Sun, Sep 3, 2023 at 5:41 AM tony mancill  wrote:
> > >
> > > Hi Matthias,
> > >
> > > On Fri, Sep 01, 2023 at 07:19:15AM -0700, tony mancill wrote:
> > > > On Fri, Sep 01, 2023 at 07:04:05PM +1200, Vladimir Petko wrote:
> > > > >  The debhelper-compat was intentionally set to >=11 in order to
> > > > > support backports.
> > > >
> > > > Thank you for the reminder.  I can easily revert the change.  But to
> > > > make sure I understand the requirements, how far back do we want to
> > > > support backports of new uploads of jtreg6?
> > > >
> > > > Although it wasn't part of the buster release, debhelper 13.x is
> > > > available in old-old-stable (buster) backports [0,1], which is as far as
> > > > I looked before making the change.  Is jtreg6 needed for stretch, which
> > > > is currently in EOL ELTS [2]?
> > > >
> > > > Thank you,
> > > > tony
> > > >
> > > > [0] https://packages.debian.org/source/buster-backports/debhelper
> > > > [1] https://packages.debian.org/source/oldoldstable-backports/debhelper
> > > > [2] https://wiki.debian.org/DebianReleases
> > >
> > > Thank you for the upload.  As I mentioned to Vladimir above, I'd like to
> > > document the reason debhelper 13 is not backport friendly.  If you can
> > > give me a pointer or a brief explanation, I'll add it to README.source
> > > so it's clear to all.  (I assume it has to do with releases older than
> > > Debian buster or Ubuntu focal [3], since both of their backport suites
> > > already contain debhelper 13.)
> > >
> > > Also, there are build-deps of jtreg6, for example libhamcrest-java [4]
> > > that depend on debhelper-compat 13 and presumably need to be adjusted as
> > > well.
> > >
> > > Thanks,
> > > tony
> > >
> > > [3] 
> > > https://packages.ubuntu.com/search?suite=default=all=any=debhelper=sourcenames
> > > [4] 
> > > https://salsa.debian.org/java-team/libhamcrest-java/-/blob/master/debian/control#L10

Bug#1050944: debhelper-compat level

[tony mancill]

Hi Vladimir,

Definitely no need for you to apologize.  I hope my tone didn't come
across as aggressive.  My goal is merely to establish what we (meaning,
the Java Team) should take into consideration for backports.  Based on
the exchange so far, it appears
that we want to keep jtreg6 (and all other direct build-deps for
openjdk-${x}) at debhelper 11 for as long as Ubuntu bionic receives
security support , but that transitive build-deps, for example
libhamcrest-java, can be upgraded without causing problems.  Does that
capture the rationale correctly?

By the way, the reason we bump debhelper-compat is because some of the
Debian Java tooling behaves differently at the older compatibility
versions, and so keeping things consistent and current means fewer
exceptions in package build behavior.

Specifically, gradle-debian-helper doesn't automatically run tests at
debhelper-compat 11, but does at dh 13 [1].  This is one response to
Matthias' question "is there any reason to use debhelper 13?" in May of
2021 [2].  (Yes, because gradle-debian-helper behaves differently in
debhelper 13 since November of 2019.)

I will make a note in the jtreg6 README.source as to why we want to stay
with debhelper 11.

Thanks!
tony

[1] 
https://salsa.debian.org/java-team/gradle-debian-helper/-/commit/9417606c1ffaed9571045cb055f80350783c0555
[2] https://lists.debian.org/debian-java/2021/05/msg00012.html

On Sun, Sep 03, 2023 at 05:33:36PM +1200, Vladimir Petko wrote:
> Hi,
> 
>  I apologise for my earlier comment being too vague and in the wrong
> tone and mentioning a completely wrong (or misleading) thing. We do
> openjdk security updates in -security pocket in Ubuntu and according
> to security team FAQ[1] the updates are built with -release and
> -security pockets. The updated debhelper is present in the backports
> pocket which is not used by the security team for security updates.
> This means that we are stuck with the older (11) debhelper version in
> order to build security updates for bionic and up.
> 
> Best Regards,
>  Vladimir.
> 
> [1] 
> https://wiki.ubuntu.com/SecurityTeam/FAQ#How_are_the_.22-updates.22_and_.22-security.22_pockets_different.3F
> 
> On Sun, Sep 3, 2023 at 5:41 AM tony mancill  wrote:
> >
> > Hi Matthias,
> >
> > On Fri, Sep 01, 2023 at 07:19:15AM -0700, tony mancill wrote:
> > > On Fri, Sep 01, 2023 at 07:04:05PM +1200, Vladimir Petko wrote:
> > > >  The debhelper-compat was intentionally set to >=11 in order to
> > > > support backports.
> > >
> > > Thank you for the reminder.  I can easily revert the change.  But to
> > > make sure I understand the requirements, how far back do we want to
> > > support backports of new uploads of jtreg6?
> > >
> > > Although it wasn't part of the buster release, debhelper 13.x is
> > > available in old-old-stable (buster) backports [0,1], which is as far as
> > > I looked before making the change.  Is jtreg6 needed for stretch, which
> > > is currently in EOL ELTS [2]?
> > >
> > > Thank you,
> > > tony
> > >
> > > [0] https://packages.debian.org/source/buster-backports/debhelper
> > > [1] https://packages.debian.org/source/oldoldstable-backports/debhelper
> > > [2] https://wiki.debian.org/DebianReleases
> >
> > Thank you for the upload.  As I mentioned to Vladimir above, I'd like to
> > document the reason debhelper 13 is not backport friendly.  If you can
> > give me a pointer or a brief explanation, I'll add it to README.source
> > so it's clear to all.  (I assume it has to do with releases older than
> > Debian buster or Ubuntu focal [3], since both of their backport suites
> > already contain debhelper 13.)
> >
> > Also, there are build-deps of jtreg6, for example libhamcrest-java [4]
> > that depend on debhelper-compat 13 and presumably need to be adjusted as
> > well.
> >
> > Thanks,
> > tony
> >
> > [3] 
> > https://packages.ubuntu.com/search?suite=default=all=any=debhelper=sourcenames
> > [4] 
> > https://salsa.debian.org/java-team/libhamcrest-java/-/blob/master/debian/control#L10


signature.asc
Description: PGP signature

Bug#1049333: ITS: eboard

[Bastian Germann]

Control: reassign -1 wnpp

Instead of removing the package I am hereby orphaning it.
There is at least the zseal binary which is also useful for other packages.

Bug#1041508: tex-common: fmutil fails to rebuild formats

[Preuße]

On 03.09.2023 07:20, Paul Gevers wrote:

Hello Paul,


I've just added an ignore hint for texlive-extra, as the
r-bioc-biocstyle issue is clearly less of a problem than this one (and
bug reports are filed).


Thanks for your response! When will the ignore hint be effective?

Hilmar
--
sigfault

Bug#1051099: Acknowledgement (bookworm-pu: package igtf-policy-bundle/1.22-1~deb12u1)

[Dennis van Dok]

Due to spam filtering this report came through later, it is in fact the 
same as #1051024 and should probably be merged or closed.

Bug#1051144: reportbug: tex-common fails to install due to fmtutil error

[Preuße]

Control: reassign -1 texlive-binaries
Control: severity -1 serious
Control: merge -1 1051080

On 03.09.2023 15:11, Philip Armstrong wrote:


Setting up tex-common (6.18) ...
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.Jzo9pPaf
Please include this file if you report a bug.

Happens due to an outdated texlive-extra. I merge this with a similar 
bug and hope that tl-extra will enter testing soon.


H.
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000955: I have the same problem

[Kai Herlemann]

Hi,

I have the same issue for maybe two months now.

The problem occurs in two cases:
1) If I use the computer again after suspend.
2) If I just disable the screen by the power button without suspending
the computer. Of course, I have configured my power saving settings
accordingly.

I use additional to Debian (stable version) openSUSE Tumbleweed with
the most recent packages, so with the latest state of development. I
don't have the issue with it, although I use the same user data.
I'm able to solve the problem by running "systemctl --user restart
plasma-kglobalaccel.service", which works until the next time I bring
the computer back from suspend mode or until the next time I press the
power off button to turn off the screen.

Feel free to ask for additional information.

Regards,
Kai

Bug#932957: #932957 Please migrate Release Notes to reStructuredText

[Holger Wansing]

Package: www.debian.org
Severity: normal


Paul Gevers  wrote (Thu, 24 Aug 2023 14:10:41 +0200):
> Hi Holger,
> 
> On 29-07-2023 21:29, Holger Wansing wrote:
> > I have worked out the last big blocker for this migration now.
> > That is, to allow the build on wolkenstein, which is happening via the
> > parts/7release-notes script in webmaster-team/cron git repo.
> 
> I have just requested webmaster to switch the bookworm build from the 
> master branch to the bookworm branch [1]. After that request gets merged 
> and deployed, I'd like you to publish your work in the master branch 
> such that we can work from there (and see the results too [2]). Because 
> in your worked we stopped making notes per architecture, we probably 
> need to make further changes to the webmaster archive, but let's first 
> build something.

Hey webmaster team,

please consider MR13 in webmaster's cron repo:

https://salsa.debian.org/webmaster-team/cron/-/merge_requests/13


Thanks
Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1050911: i3-wm: please provide an i3-portals.conf for xdg-desktop-portal

[Simon McVittie]

On Sun, 03 Sep 2023 at 20:25:52 +0200, Michael Stapelberg wrote:
> If I'm reading its code correctly, I think i3-wm asks the display manager
> to set XDG_CURRENT_DESKTOP to "i3"?
> 
> I don’t know what code you’re referring to.
> I don’t recall i3 asking any display manager anything, but maybe I’m missing
> something?

i3-wm_4.22-2/share/xsessions/i3.desktop contains DesktopNames=i3, which is
how you ask a display manager to set XDG_CURRENT_DESKTOP=i3 when running
the command defined in i3.desktop as an X11 session.

> i3 isn’t a desktop environment, it’s a window manager only.

It's behaving like a (very small) desktop environment to the extent that
it installs a file in /usr/share/xsessions, which results in it appearing
in the menu of possible session types in display managers like gdm,
lightdm or sddm.

> I’m also not familiar with what these xdg portals are, and I don’t think I’m
> using them (yet)?

I don't expect that i3 uses them, but some of the applications that users
run within an i3 session are going to be using them.

The most prominent use is that sandboxed Flatpak and Snap apps make D-Bus
calls to xdg-desktop-portal to get things like File -> Open and File ->
Save As dialogs, ask to open URLs or files outside the sandbox, pop up
notifications, take screenshots and other outside-sandbox actions.
xdg-desktop-portal implements all those things by passing on the request
to a backend such as xdg-desktop-portal-gtk, which can be desktop-specific.

Non-sandboxed apps are starting to use the same portal mechanism to do
things that are otherwise hard to do in a desktop-independent way, like
screenshots, screen-sharing and remote-desktop.

> I don’t want to make the choice of whether gtk or qt should be used for parts
> of a user’s desktop.
...
> I think for the case of i3, the defaults should be fine, so I would prefer not
> to add this config file.

When we stop patching xdg-desktop-portal to hard-code its GTK backend
as a fallback, the default will be to use no portal backends at all,
which means the apps I described above will try and fail to make use of
those desktop features, unless the user has written a portals.conf(5)
of their own (which they can always do anyway, and it will overrule the
desktop environment's choices).

I'm aware that i3 is quite an "assemble it yourself" environment, so
perhaps users of i3 would expect to have to write their own configuration
to make things like this work? If that's the case then this could be
closed as "won't fix".

smcv

Bug#1051178: broken security manual link on debian portal

[Holger Wansing]

Package: harden-doc
Severity: minor


Aeou ROUND  wrote (Thu, 24 Aug 2023 21:35:35 +0200):
> 
> the .pdf version shows a broken link page "please inform our team of this
> broken link".
> 
> https://www.debian.org/doc/manuals/securing-debian-manual/changelog.en.html

thanks for the hint.

However, there is nothing the webpage people can do about this in the first
instance, because the Debian package "harden-doc" (this is the package which
holds the Securing Debian manual) does not contain any txt or pdf file for
the manual.
As a consequence, they cannot be displayed on the webpage as well :-(


So, this has to be fixed in the package first.

Turning this into a bugreport against harden-doc.
Thanks

Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1051177: pokerth: build-depends on old libgsasl7-dev

[Gianfranco Costamagna]

Source: pokerth
Version: 1.1.2-2
Severity: Serious
tags: patch

Hello, for some reasons, libgsasl7-dev was renamed in libgsasl-dev
$ sed s/libgsasl7-dev/libgsasl-dev/g -i debian/control

Should be enough to fix the issue.

G.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1051176: jreen: build-depends on old libgsasl7-dev

[Gianfranco Costamagna]

Source: jreen
Version: 1.2.0+ds-1
Severity: Serious
tags: patch

Hello, for some reasons, libgsasl7-dev was renamed in libgsasl-dev
$ sed s/libgsasl7-dev/libgsasl-dev/g -i debian/control

Should be enough to fix the issue.

G.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1051175: jabberd2: build-depends on old libgsasl7-dev

[Gianfranco Costamagna]

Source: jabberd2
Version: 2.7.0-4
Severity: Serious
tags: patch

Hello, for some reasons, libgsasl7-dev was renamed in libgsasl-dev
$ sed s/libgsasl7-dev/libgsasl-dev/g -i debian/control

Should be enough to fix the issue.

G.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1051174: clickhouse: build-depends on old libgsasl7-dev

[Gianfranco Costamagna]

Source: clickhouse
Version: 18.16.1+ds-7.3
Severity: Serious
tags: patch

Hello, for some reasons, libgsasl7-dev was renamed in libgsasl-dev
$ sed s/libgsasl7-dev/libgsasl-dev/g -i debian/control

Should be enough to fix the issue.

G.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1050915: truncate unsigned parts of signed mails to d-d-a

[Don Armstrong]

severity -1 wishlist
thanks

On Thu, 31 Aug 2023, Lee Garrett wrote:
> currently, when using Thunderbird to send OpenPGP/MIME signed mails to
> d-d-a, the mail gets silently blackholed (#1050906). It seems like the
> reason is that there is a small piece of text before the actual
> MIME-encoded data:
> 
> "This is an OpenPGP/MIME signed message (RFC 4880 and 3156)"
> 
> Would be nice if the tool in question could just truncate the unsigned bits
> instead and accept the mail, assuming there's a valid signature.

The problem there is that we would break DKIM or oversigning of the mail
message if we stripped that out. [It also adds a whole bit of
complicated code to the signature verification tool which is likely to
be wrong.]

The real fix is for thunderbird to stop adding unsigned text before the
actual mime encoded data. It doesn't add any value whatsoever. [It's one
of the only e-mail clients which does this that I'm aware of.]

-- 
Don Armstrong  https://www.donarmstrong.com

Thanks be to God, that he gave me Stubbornness, when I know I am right.
 -- John Adams (Letter to Edmund Jennings, 27 September 1782)

Bug#1051173: libgwenhywfar FTCBFS: fails to run mklistdoc

[Helmut Grohne]

Source: libgwenhywfar
Version: 5.10.2-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libgwenhywfar fails to cross build from source, because it fails running
mklistdoc with an "Exec format error". This happens when attempting to
run a tool that is built for the host architecture. mklistdoc really
needs to be built for the host architecture, because it is installed
into gwenhywfar-tools. On the flip side that means that we can just run
the mklistdoc from a system gwenhywfar-tools. Note that this change only
affects cross compilation. In native builds, the built mklistdoc will
continue to be used. I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru libgwenhywfar-5.10.2/debian/changelog 
libgwenhywfar-5.10.2/debian/changelog
--- libgwenhywfar-5.10.2/debian/changelog   2023-08-13 20:42:52.0 
+0200
+++ libgwenhywfar-5.10.2/debian/changelog   2023-09-02 09:14:50.0 
+0200
@@ -1,3 +1,10 @@
+libgwenhywfar (5.10.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use mklistdoc from installed gwenhywfar-tools. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 02 Sep 2023 09:14:50 +0200
+
 libgwenhywfar (5.10.2-1) unstable; urgency=medium
 
   * New upstream version 5.10.2.
diff --minimal -Nru libgwenhywfar-5.10.2/debian/control 
libgwenhywfar-5.10.2/debian/control
--- libgwenhywfar-5.10.2/debian/control 2023-08-13 20:40:31.0 +0200
+++ libgwenhywfar-5.10.2/debian/control 2023-09-02 09:14:50.0 +0200
@@ -4,6 +4,7 @@
 Maintainer: Micha Lenk 
 Uploaders: Henning Glawe 
 Build-Depends: debhelper-compat (= 13),
+ gwenhywfar-tools ,
  libgcrypt20-dev, libgpg-error-dev,
  libgnutls28-dev,
  libxml2-dev,
diff --minimal -Nru libgwenhywfar-5.10.2/debian/patches/cross.patch 
libgwenhywfar-5.10.2/debian/patches/cross.patch
--- libgwenhywfar-5.10.2/debian/patches/cross.patch 1970-01-01 
01:00:00.0 +0100
+++ libgwenhywfar-5.10.2/debian/patches/cross.patch 2023-09-02 
09:14:45.0 +0200
@@ -0,0 +1,30 @@
+--- libgwenhywfar-5.10.2.orig/Makefile.am
 libgwenhywfar-5.10.2/Makefile.am
+@@ -51,8 +51,15 @@
+ distclean-local-check:
+   rm -rf apidoc gwenhywfar5
+ 
+-listdoc.h: $(top_builddir)/admin/mklistdoc
+-  admin/mklistdoc -v -I $(top_srcdir)/src/base `find 
"$(top_builddir)/gwenhywfar5/gwenhywfar" -name "*.h" | LC_ALL=C sort` >listdoc.h
++if CROSS_COMPILING
++mklistdoc_preqreq =
++mklistdoc_exe = mklistdoc
++else
++mklistdoc_prereq = $(top_builddir)/admin/mklistdoc
++mklistdoc_exe = admin/mklistdoc
++endif
++listdoc.h: $(mklistdoc_prereq)
++  $(mklistdoc_exe) -v -I $(top_srcdir)/src/base `find 
"$(top_builddir)/gwenhywfar5/gwenhywfar" -name "*.h" | LC_ALL=C sort` >$@
+ 
+ $(top_builddir)/admin/mklistdoc:  
+   $(MAKE) -C "$(top_builddir)/admin" mklistdoc
+--- libgwenhywfar-5.10.2.orig/configure.ac
 libgwenhywfar-5.10.2/configure.ac
+@@ -218,6 +218,7 @@
+ 
+ # Check for the tool "astyle", but if not found, replace its program call by 
the no-op "echo" instead
+ AC_CHECK_PROG(ASTYLE, astyle, astyle, echo)
++AM_CONDITIONAL(CROSS_COMPILING, test x$cross_compiling = xyes)
+ 
+ ###-
+ #
diff --minimal -Nru libgwenhywfar-5.10.2/debian/patches/series 
libgwenhywfar-5.10.2/debian/patches/series
--- libgwenhywfar-5.10.2/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ libgwenhywfar-5.10.2/debian/patches/series  2023-09-02 09:04:35.0 
+0200
@@ -0,0 +1 @@
+cross.patch

Bug#967629: mhwaveedit: depends on deprecated GTK 2

[Bastian Germann]

The fork gwaveedit has some gtk3 port work done but it is not complete.

Bug#1050660: fontconfig-config: dangling symlink /etc/fonts/conf.d/10-no-sub-pixel.conf

[Jörg-Volker Peetz]

Thank you very much for taking care.

Regards,
Jörg.

Bug#1051172: Update to 0.5.1

[Jérôme Charaoui]

Package: libfixposix
Severity: wishlist

Hello,

Please update libfixposix to 0.5.1, as it is needed to update JRuby in 
Debian (via its new Ruby SubSpawn dependency).


Thanks!

-- Jérôme

Bug#934463: initscripts: consider taking over hwclock policy machinery

[Steve Litt]

Hi all,

This message was dated 8/22/2023 but arrived on 9/3/2023. From the
headers, it looks like the 12 day discrepancy happened due to either
buxtehude.debian.org or chiark.greenend.org.uk sitting on the email for
12 days without forwarding.

SteveT


Mark Hindley said on Tue, 22 Aug 2023 09:58:47 +0100

>Andreas,
>
>I have prepared the necessary updates to src:sysvinit to incorporate
>the hwclock machinery in initscripts. Specifically the files
>
> /etc/default/hwclock
> /etc/init.d/hwclock.sh
> /usr/share/man/man5/hwclock.5
> /usr/lib/udev/hwclock-set
> /usr/lib/udev/rules.d/hwclock.rules
>
>Obviously we need to coordinate the transition and I will add
>Breaks/Replaces << the util-linux-extra version which drops the files.
>
>If util-linux-extra were to use it, my understanding is that
>rm_conffile only removes *unmodified* conffiles so user modifications
>should be preserved. But we might consider synchronised uploads to
>experimental to test and confirm.
>
>Best wishes
>
>Mark
>

Bug#1051171: bookworm-pu: package qtlocation-opensource-src/5.15.8+dfsg-3+deb12u1

[Dmitry Shachnev]

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

[ Reason ]
This fixes bug which made applications using Qt Location freeze when trying to
load the map tiles.

[ Impact ]
Some applications will be broken. I don't have a list of such applications,
but it can be reproduced with examples shipped in qtlocation5-examples.

[ Tests ]
It can be reproduced with minimal_map example from qtlocation5-examples
(e.g. /usr/lib/x86_64-linux-gnu/qt5/examples/location/minimal_map/minimal_map
on amd64). Without the fix only one tile loads and the application does not
respond to any events (e.g. dragging or scrolling). With the fix everything
works as expected.

[ Risks ]
The change is trivial (patch adding one character). It is applied both by
Qt upstream [1] and by KDE's Qt patch collection [2].

[1]: https://code.qt.io/cgit/qt/qtlocation.git/commit/?id=6cb20a08b65c73b4
[2]: https://invent.kde.org/qt/qt/qtlocation/-/commit/1c6a9479c9f5bf61

[ 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 ]
* Backport upstream patch to fix condition for appendChildNode() call
  (closes: #1050240).

[ Other info ]
In unstable/testing, this bug was fixed in version 5.15.10+dfsg-3.

The debdiff against stable is attached.

--
Dmitry Shachnev
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+qtlocation-opensource-src (5.15.8+dfsg-3+deb12u1) bookworm; urgency=medium
+
+  * Backport upstream patch to fix condition for appendChildNode() call
+(closes: #1050240).
+
+ -- Dmitry Shachnev   Sun, 03 Sep 2023 21:57:28 +0300
+
 qtlocation-opensource-src (5.15.8+dfsg-3) unstable; urgency=medium
 
   * Let the system build the serial plugin by adding libqt5serialport5-dev as
--- /dev/null
+++ b/debian/patches/fix_appendChildNode_call.diff
@@ -0,0 +1,22 @@
+Description: fix appendChildNode() call
+ The QSGNode::appendChildNode() method checks that its parameter must
+ not have a parent. Before this patch we always called appendChildNode()
+ on a node that already had parent, which was always leading to ASSERT
+ in a debug build.
+ .
+ Seems that the right approach would be to call this method, if the
+ node *does not* have a parent.
+Origin: upstream, https://code.qt.io/cgit/qt/qtlocation.git/commit/?id=6cb20a08b65c73b4
+Last-Update: 2023-08-18
+
+--- a/src/location/labs/qsg/qgeomapobjectqsgsupport.cpp
 b/src/location/labs/qsg/qgeomapobjectqsgsupport.cpp
+@@ -158,7 +158,7 @@ void QGeoMapObjectQSGSupport::updateMapO
+ if (!root)
+ return;
+ 
+-if (m_mapObjectsRootNode && m_mapObjectsRootNode->parent())
++if (m_mapObjectsRootNode && !m_mapObjectsRootNode->parent())
+ root->appendChildNode(m_mapObjectsRootNode.get());
+ 
+ if (!m_mapObjectsRootNode) {
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@ use_system_dependencies.diff
 hurd_geoclue.diff
 mapboxgl_thread_portability.diff
 opengl.diff
+fix_appendChildNode_call.diff


signature.asc
Description: PGP signature

Bug#994081: Patch

[Geert Stappers]

Control: tags 994081 +patch

The patch is in Message #47
( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994081#47 )

And attached to this email.


Groeten
Geert Stappers
DD
-- 
Silence is hard to parse
>From 09bbe34369307aaf25c2139fa62f79742d2e3622 Mon Sep 17 00:00:00 2001
From: Geert Stappers 
Date: Sun, 3 Sep 2023 19:34:45 +0200
Subject: [PATCH] Dry run apt check, no abort on fail.

Fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994081
 "Upgrade Results in 'apt-get check' Failure"

It is fairly nasty bug. Nasty because it hides well.
Thing is that the `apt check` is during development never called
as a child proces of `apt`.  It reveals it self only during
an upgrade by `apt` or `apt-get`, not during a `dpkg --install`.

Adding '--dry-run' is to prevent bail out on
  E: Could not get lock /var/lib/dpkg/lock-frontend.
 It is held by process PID (apt)
  E: Unable to acquire the dpkg frontend lock

Manual page of `apt-get` says about `--dry-run`
  Locking will be disabled (Debug::NoLocking) so the system
  state could change while apt-get is running.

The removal of 'exit 0' makes it possible that the (build) script
continues. Frankly, I think the whole `apt check` part should
be removed. It is not up to /usr/lib/libdvd-pkg/b-i_libdvdcss.sh
to judge the sanity of the build system.

--dry-run suggested by Alban Browaeys in Message #37

'What does the apt check?' by The Wanderer in Message #10
---
 debian/b-i_libdvdcss.sh | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/debian/b-i_libdvdcss.sh b/debian/b-i_libdvdcss.sh
index 536614c..6d77a50 100755
--- a/debian/b-i_libdvdcss.sh
+++ b/debian/b-i_libdvdcss.sh
@@ -43,10 +43,9 @@ if [ $? -ne 0 ]; then
 exit 1
 fi
 
-apt-get check >/dev/null 2>&1
+apt-get --dry-run check >/dev/null 2>&1
 if [ "$?" -ne 0 ]; then
-echo "${PKGI}: \`apt-get check\` failed, you may have broken packages. Aborting..."
-exit 0
+echo "${PKGI}: \`apt-get --dry-run check\` failed, you may have broken packages."
 fi
 
 set -e
-- 
2.40.1

Bug#994081: [PATCH] Dry run apt check, no abort on fail.

[Cecil Westerhof]

On Sun,  3 Sep 2023 20:48:31 +0200 Geert Stappers 
wrote:
> From: Geert Stappers 
>
> Fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994081
>  "Upgrade Results in 'apt-get check' Failure"
>
> It is fairly nasty bug. Nasty because it hides well.
> Thing is that the `apt check` is during development never called
> as a child proces of `apt`.  It reveals it self only during
> an upgrade by `apt` or `apt-get`, not during a `dpkg --install`.
>
> Adding '--dry-run' is to prevent bail out on
>   E: Could not get lock /var/lib/dpkg/lock-frontend.
>  It is held by process PID (apt)
>   E: Unable to acquire the dpkg frontend lock
>
> Manual page of `apt-get` says about `--dry-run`
>   Locking will be disabled (Debug::NoLocking) so the system
>   state could change while apt-get is running.

No it could not.
The problem is that 'apt-get check' wants to get the lock that already is
taken by 'apt upgrade'. So when the lock is not taken by using --dry-run we
do not have the problem that a lock is requested that already is taken. And
because the lock is already taken by 'apt upgrade' it should not be
possible that the system state changes.

Bug#1042713: wireplumber: High cpu usage

[Marc-Aurèle Brothier]

On Sun, 30 Jul 2023 18:06:06 -0400 Nick  wrote:
> Package: wireplumber
> Version: 0.4.13-1
> Severity: important
> 
> Dear Maintainer,
> 
>    * What led up to the situation?
> 
> Upgrading to debian 12.
> 
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Followed the instructions in the release notes.
> 
>    * What was the outcome of this action?
> 
> On rebooting, a process called wireplumber consumes most of the cpu.
> Sound does work.  If I kill the process, cpu usage falls, my fan
stops
> spinning and I no longer have sound.  I have to kill wireplumber on
> each reboot (or let it try to fry my cpu).
> 
> Please let me know if I can provide more information.
> 
> -- 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-10-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages wireplumber depends on:
> ii  init-system-helpers   1.65.2
> ii  libc6 2.36-9+deb12u1
> ii  libglib2.0-0  2.74.6-2
> ii  libpipewire-0.3-0 0.3.65-3
> ii  libwireplumber-0.4-0  0.4.13-1
> ii  pipewire  0.3.65-3
> 
> Versions of packages wireplumber recommends:
> ii  pipewire-pulse  0.3.65-3
> 
> Versions of packages wireplumber suggests:
> pn  libspa-0.2-bluetooth  
> pn  wireplumber-doc   
> 
> -- no debconf information
> 
> 


I'm running the version 0.4.14-4 and the issue remains on my side. I
can send you more information if needed.

$ dpkg -s wireplumber
Package: wireplumber
Status: install ok installed
Priority: optional
Section: video
Installed-Size: 514
Maintainer: Utopia Maintenance Team

Architecture: amd64
Version: 0.4.14-4
Replaces: pipewire-media-session
Depends: libc6 (>= 2.34), libglib2.0-0 (>= 2.62), libpipewire-0.3-0 (>=
0.3.52), libwireplumber-0.4-0 (= 0.4.14-4), init-system-helpers (>=
1.52), default-dbus-session-bus | dbus-session-bus, pipewire (>=
0.3.52)
Recommends: pipewire-pulse
Suggests: libspa-0.2-bluetooth, libspa-0.2-libcamera, wireplumber-doc
Conflicts: pipewire-media-session

Bug#1050462: gtg: crashes on startup often

[François Mazen]

Hi Antonio,

> We probably want to fix the code to *not* segfault when the workaround
> is not in place. 

Agreed!

> I'm not sure whether this is a bug in gtg itself, or
> in pango.

The issue is likely in the g_object_get_property or in
pango_font_description_to_string, or in the code calling both methods in
GTG/gtk/general_preferences.py

For now, I've followed the upstream advice to revert the behavior to get a
default font when font_name is not available, hence by-passing the two
problematic methods. I've just committed the patch [1], and I'll likely upload a
new package shortly to prevent package removal.

Let me know if this sounds acceptable to you.

Best,
François

[1]
https://salsa.debian.org/python-team/packages/gtg/-/commit/e9ac644f40629704a4e85b56ff887a59d6748d58


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

Bug#994081: [PATCH] Dry run apt check, no abort on fail.

[Geert Stappers]

From: Geert Stappers 

Fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994081
 "Upgrade Results in 'apt-get check' Failure"

It is fairly nasty bug. Nasty because it hides well.
Thing is that the `apt check` is during development never called
as a child proces of `apt`.  It reveals it self only during
an upgrade by `apt` or `apt-get`, not during a `dpkg --install`.

Adding '--dry-run' is to prevent bail out on
  E: Could not get lock /var/lib/dpkg/lock-frontend.
 It is held by process PID (apt)
  E: Unable to acquire the dpkg frontend lock

Manual page of `apt-get` says about `--dry-run`
  Locking will be disabled (Debug::NoLocking) so the system
  state could change while apt-get is running.

The removal of 'exit 0' makes it possible that the (build) script
continues. Frankly, I think the whole `apt check` part should
be removed. It is not up to /usr/lib/libdvd-pkg/b-i_libdvdcss.sh
to judge the sanity of the build system.

--dry-run suggested by Alban Browaeys in Message #37

'What does the apt check?' by The Wanderer in Message #10
---
 debian/b-i_libdvdcss.sh | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/debian/b-i_libdvdcss.sh b/debian/b-i_libdvdcss.sh
index 536614c..6d77a50 100755
--- a/debian/b-i_libdvdcss.sh
+++ b/debian/b-i_libdvdcss.sh
@@ -43,10 +43,9 @@ if [ $? -ne 0 ]; then
 exit 1
 fi
 
-apt-get check >/dev/null 2>&1
+apt-get --dry-run check >/dev/null 2>&1
 if [ "$?" -ne 0 ]; then
-echo "${PKGI}: \`apt-get check\` failed, you may have broken packages. 
Aborting..."
-exit 0
+echo "${PKGI}: \`apt-get --dry-run check\` failed, you may have broken 
packages."
 fi
 
 set -e
-- 
2.40.1

Bug#1051170: RM: nomad-driver-lxc/0.3.0-1

[Moritz Muehlenhoff]

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

Needs to be removed alongside with nomad.

Cheers,
Moritz

Bug#1051169: RM: nomad/0.12.10+dfsg1-3

[Moritz Muehlenhoff]

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

Hashicorp switched to the non-free BSL and security fixes will
only be made available until December 31 2023, so we should
remove it with the Bullseye 11.8 point release:
https://www.hashicorp.com/license-faq#products-covered-by-bsl

(nomad-driver-lxc is related, will file a separate RM bug for it)

Cheers,
Moritz

Bug#1051168: gtk4: 4.12 regression: FTBFS on riscv64: multiple test failures

[Aurelien Jarno]

Source: gtk4
Version: 4.12.1+ds-2
Severity: important
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear maintainer,

gtk4 fails to build on riscv64, due to multiple test failures, which
have been added in version 4.12:

| Summary of Failures:
| 
|   57/1434 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-flipped-gl / 
gl border-one-rounded flipped FAIL 
11.04s   exit status 1
|  300/1434 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl / gl opacity-overdraw 
 FAIL 
10.48s   exit status 1
|  301/1434 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-flipped-gl / 
gl opacity-overdraw flipped   FAIL 
10.48s   exit status 1
|  302/1434 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-repeated-gl / 
gl opacity-overdraw repeated FAIL 
10.61s   exit status 1
|  303/1434 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-rotated-gl / 
gl opacity-overdraw rotated   FAIL 
10.53s   exit status 1
|  304/1434 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-masked-gl / 
gl opacity-overdraw masked FAIL 
10.68s   exit status 1
| 1393/1434 gtk:reftest / reftest opacity.ui
 FAIL 
12.37s   0/1 subtests passed
| 
| Ok: 1412
| Expected Fail:  0   
| Fail:   7   
| Unexpected Pass:0   
| Skipped:15  
| Timeout:0   

The full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=gtk4=riscv64=4.12.1%2Bds-2=1693193191=0

Investigation has shown that the issue is only present for the gl
backend, but not the cairo backend. It is due to a difference of
rendering between llvmpipe and softpipe. It seems the referenced in the
testsuite is generated with it. Rebuilding gtk4 on amd64 with
GALLIUM_DRIVER=softpipe trigger the same failures and resulting in
identical png files as on riscv64.

While support for llvmpipe is being worked on, it is currently blocked
because mesa uses the deprecated mcjit interface, which does not accept
new architectures. Support for the new interface, orcjit, in mesa is
being worked on, but it will take time bringing it to the same level as
mcjit [1].

In the meantime, would it be possible to ignore the corresponding
failures like it is done on mips*? I have tested the following patch:

--- gtk4-4.12.1+ds/debian/rules
+++ gtk4-4.12.1+ds/debian/rules
@@ -258,7 +258,7 @@
 endif
 
 # https://bugs.debian.org/1050077
-ifneq ($(filter mips%,$(DEB_HOST_ARCH_CPU)),)
+ifneq ($(filter mips% riscv64,$(DEB_HOST_ARCH_CPU)),)
 fuzzy_gsk_compare += opacity-overdraw
 ignore_gsk_compare += border-one-rounded
 fuzzy_reftests += opacity

Thanks,
Aurelien

[1] 
https://lists.riscv.org/g/sig-graphics/topic/minutes_for_risc_v_graphics/97648261

Bug#877016: Time to drop cpufrequtils?

[Moritz Mühlenhoff]

severity 877016 serious
thanks

Am Thu, Sep 28, 2017 at 06:51:30AM -0700 schrieb Mattia Dongili:
> On Wed, Sep 27, 2017 at 03:16:52PM -0400, Phil Susi wrote:
> > Package: cpufrequtils
> > Version: 008-1
> ...
> > is the case, should cpufrequtils not be removed now?
> 
> Yes, indeed it should. Thanks for nagging.

Bumping the severity to RC to move forward with this for trixie.

Cheers,
Moritz

Bug#1050911: i3-wm: please provide an i3-portals.conf for xdg-desktop-portal

[Michael Stapelberg]

Hey Simon

Answers inline:

On Thu, 31 Aug 2023 at 13:27, Simon McVittie  wrote:

> Source: i3-wm
> Severity: normal
> Tags: trixie sid
> User: xdg-desktop-por...@packages.debian.org
> Usertags: portals.conf
>
> xdg-desktop-portal 1.17.x introduces a new way to select which portals will
> be used for which desktop environments, modelled on mimeapps.list:
>
> - each desktop environment should provide a file like
>   /usr/share/xdg-desktop-portal/i3-portals.conf
>
> - the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
>   environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
>   from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case
>
> - sysadmins and users can override this via files named portals.conf or
>   ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
>   and ~/.config/xdg-desktop-portal
>
> Please see portals.conf(5) or its source code
>
> https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
> for full details.
>
> If I'm reading its code correctly, I think i3-wm asks the display manager
> to set XDG_CURRENT_DESKTOP to "i3"?
>

I don’t know what code you’re referring to.
I don’t recall i3 asking any display manager anything, but maybe I’m
missing something?


>
> As a backwards-compatibility mechanism, x-d-p will fall back to trying to
> guess the most appropriate portals from the portals' deprecated UseIn=
> fields, but it will log warnings when it does that, and anyway Debian
> doesn't currently ship any portal backends that are flagged as suitable
> for i3. Please add an i3-portals.conf to tell x-d-p more explicitly
> what backends i3-wm is meant to be using by default.
>
> For example, if the intention is to use the x-d-p-gtk backend,
> the way to write that would be:
>
> [preferred]
> default=gtk;
>
> The desktop environment (either i3-wm or some larger metapackage) should
> probably also have a Recommends, or at least a Suggests, on whatever
> portals would be most appropriate for it.


i3 isn’t a desktop environment, it’s a window manager only.

I don’t want to make the choice of whether gtk or qt should be used for
parts of a user’s desktop.
I’m also not familiar with what these xdg portals are, and I don’t think
I’m using them (yet)?

I think for the case of i3, the defaults should be fine, so I would prefer
not to add this config file.

If you think i3 should provide a portal file, it would probably be best to
discuss upstream:
https://github.com/i3/i3/issues

-- 
Best regards,
Michael

Bug#1050987: transition: jimtcl

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2023-09-01 11:17:23 +0800, Bo YU wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: jim...@packages.debian.org
> Control: affects -1 + src:jimtcl
> 
> I'm looking for the transition from jimtcl-0.81 to jimtcl-0.82 due to
> an upstream SONAME bump in the new release.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1042082: Please take over udev SysV init script

[Mark Hindley]

Control: reassign -1 initscripts

Michael,

We have decided that initscripts from src:sysvinit is a better fit for
/etc/init.d/udev. Therefore reassigning.

I have prepared a branch[1]. The only outstanding item I am aware of is to add
versioned Breaks/Replaces against the version of udev that no longer ships the
file.

In my testing of this transition, it became apparent that if udev uses either
dpkg-maintscript-helper rm_conffile or dpkg remove-on-upgrade, user
modifications to /etc/init.d/udev are not preserved. So, I would ask that you
not do that until Forky so we can be sure that any changes to those files are
correctly preserved.

Can you see any other issues?

Thanks and best wishes

Mark

[1]  https://salsa.debian.org/debian/sysvinit/-/tree/wip/udev_initscript

Bug#1051154: FTBFS with doxygen 1.9.8

[Sebastian Ramacher]

Control: tags -1 moreinfo unreproducible

On 2023-09-03 17:50:52 +0200, Paolo Greppi wrote:
> Package: libcaca-dev
> Version: 0.99.beta20-3
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the
> past)
> X-Debbugs-Cc: paolo.gre...@libpf.com
> 
> While preparing to upload doxygen 1.9.8, I did a partial rebuild of packages
> that build-depend on it.
> More info here: 
> https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial
> 
> Of 510 packages I tried, 6 failed and one is libcaca-dev.
> 
> The build error was:
> 
>   The control sequence at the end of the top line
>   of your error message was never \def'ed. If you have
>   misspelled it (e.g., `\hobx'), type `I' and the correct
>   spelling (e.g., `I\hbox'). Otherwise just continue,
>   and I'll forget about whatever was undefined.
> 
>   ! TeX capacity exceeded, sorry [text input levels=15].
>   \tabu@textbar ...ar \m@ne \scantokens {\def \:{|}}
> \expandafter \endgroup
> \ex...
>   l.46 \begin{DoxyParams}{Parameters}
> ^^M
>   If you really absolutely need more capacity,
>   you can ask a wizard to enlarge me.
> 
> 
>   Here is how much of TeX's memory you used:
>   18690 strings out of 477695
>   304727 string characters out of 5831649
>   1925759 words of memory out of 500
>   38172 multiletter control sequences out of 15000+60
>   560241 words of font info for 97 fonts, out of 800 for 9000
>   14 hyphenation exceptions out of 8191
>   101i,15n,117p,1820b,797s stack positions out of
> 1i,1000n,2p,20b,20s
>   !  ==> Fatal error occurred, no output PDF file produced!
>   make[3]: *** [Makefile:663: stamp-latex] Error 1
> 
> I attach the full build log.

I'm afraid I am unable to reproduce the issue. Any hint how to reproduce
it?

Cheers
-- 
Sebastian Ramacher

Bug#1051086: general: networking misconfigured and unusable after bookworm upgrade

[D. R. Evans]

Michael Biebl wrote on 9/2/23 18:26:

Control: reassign -1 network-manager

Am 02.09.23 um 16:51 schrieb D. R. Evans:


[Z:~] nmcli
enp12s0: connected to Wired connection enp11s0(eth0)


It appears you have a connection configuration named "Wired connection
enp11s0(eth0)" which is applied to enp12s0.
This leads me to believe, that you don't have the connection
configuration bound to a certain interface and as a result
NetworkManager will pick the first one that is ready.


I don't know. The system set it all up in answer to my questions when debian 
stable was first installed on the machine, which I thinks was when debian 
stable was stretch; it has worked ever since then until the upgrade from 
bullseye to bookworm. Never really paid attention to any of this before, as it 
all worked fine; I'm just a user.





You should be able to find the configuration file in
/etc/NetworkManager/system-connections/ under the above name.



There is a file called: "Wired connection enp11s0(eth0).nmconnection"

(The similar file for enp12s0 is, for some reason, called: "Wired connection 
enp12s0(eth1)"; i.e., no ".nmconnection" is part of its name)



Please attach this file to the bug report.


Done. (At least, I'm attaching it to this e-mail and assuming that the 
software on the recipient machine is smart enough to extract it and add it to 
the report.)


H... I see that the file for enp12s0 contains the line:
  mac-address=D8:50:E6:C2:76:03

whereas there is no similar line for enps11s0. Although one would think that 
the networking manager would be smart enough to figure out that if enps12s0 is 
on D8:50:E6:C2:76:03, then enp11s0 should be on the one other available active 
port. Maybe that used to be the case, but the current version of NM can no 
longer figure that out??? That could lead to something like what I'm seeing, I 
suppose. In which case, I suppose a wish request should be filed against NM to 
require it to behave intelligently in this case. It certainly seems that 
something has changed in NM such that a configuration that has worked 
correctly for a long time no longer does so.


--
Web:  http://enginehousebooks.com/drevans
[connection]
id=Wired connection enp11s0(eth0)
uuid=8e308949-5232-47aa-b9b6-8aab6369ec4d
type=ethernet
permissions=

[ethernet]
mac-address-blacklist=

[ipv4]
address1=209.97.232.18/24,209.97.232.1
dns=127.0.0.1;209.97.224.2;209.97.224.3;
dns-search=
method=manual

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

[proxy]

Bug#1051162: FTBFS with doxygen 1.9.8

[Sebastiaan Couwenberg]

On 9/3/23 18:16, Paolo Greppi wrote:
While preparing to upload doxygen 1.9.8, I did a partial rebuild of 
packages that build-depend on it.


doxygen 1.9.8 is not in experimental, so we can't test potential fixes.

When will 1.9.8 be available in the archive?

Kind Regards,

Bas

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

Bug#1051120: debian-installer: can't use YubiKey for secure drive encryption passphrase because enter clears form

[Jonathan Kamens]

I am not proposing to change that Enter moves to the next screen. I am 
proposing to change WHEN Enter can move to the next screen, or at the 
very least, what happens when it fails to do so because the inputs on 
the current screen are invalid.


Regarding either of these, what the installer does is _objectively 
wrong_ when compared to the best practices that pretty much everyone 
else in this industry uses.


Most installers don't activate the button to move to the next screen (or 
the Enter shortcut for it) until the fields on the current screen are 
valid. For those that do, if the fields are invalid, they just say that; 
they don't clear the screen and make the user enter everything again.


The current behavior is clearly incorrect and improving it would 
literally harm no one and not break any existing, working workflows.


I cannot even imagine the reasoning behind refusing to change it.

What do you think is "unreasonable" about improving the behavior? Whom 
would it harm? Who would prefer the old behavior, and why?


Using a YubiKey to hold an encryption passphrase is a high-security 
option which you should support, and YubiKey owners do not have control 
over the character that the YubiKey sends at the end of the passphrase.


If you'd said to me, "You're right that we could improve this behavior, 
but it isn't a high priority. We'll consider it at some point in the 
future," I could understand that. I might be disappointed, but at least 
I could understand that work has to be prioritized. But saying it's not 
"reasonable" to change it? Completely unfathomable to me.

Bug#1051163: linux-image-6.1.0-11-amd64: NVIDIA graphics cards have no frame buffer during boot

[Martin Johnson]

Hi Diederik,

Thanks very much, glad to hear its already been fixed :-)

Look forward to being able to install the updated kernel soon,

Kind Regards,

Martin.

On 03/09/2023 18:02, Diederik de Haas wrote:

Control: tag -1 fixed-upstream

On Sunday, 3 September 2023 18:24:11 CEST Martin Johnson wrote:

 Applying this patch from upstream fixes the issue:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i
d=5ae3716cfdcd286268133867f67d0803847acefc

 Once the patch applied then the framebuffer works fine again on
boot, both Linux machines with dual NVIDIA GeForce 1050TI cards tested.

 Please can you backport this fix to the Debian Kernel? Thank you.

 If you need me to test it please let me know :-)

That commit is part of upstream's 6.1.47 version in upstream commit
485ec8f8e1d8ae12aa1daa5ad345ba8940ad2db7

And it's also already included in Debian kernel's git repo:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/803/diffs?
commit_id=cb54af62e4db43555b93920b5d06bcba7f06dfc7#9c96da0e9f91d7d8937b69b524702c106258f0d1_1514_1593

Bug#1051163: linux-image-6.1.0-11-amd64: NVIDIA graphics cards have no frame buffer during boot

[Diederik de Haas]

Control: tag -1 fixed-upstream

On Sunday, 3 September 2023 18:24:11 CEST Martin Johnson wrote:
> Applying this patch from upstream fixes the issue:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i
> d=5ae3716cfdcd286268133867f67d0803847acefc
> 
> Once the patch applied then the framebuffer works fine again on
> boot, both Linux machines with dual NVIDIA GeForce 1050TI cards tested.
> 
> Please can you backport this fix to the Debian Kernel? Thank you.
> 
> If you need me to test it please let me know :-)

That commit is part of upstream's 6.1.47 version in upstream commit 
485ec8f8e1d8ae12aa1daa5ad345ba8940ad2db7

And it's also already included in Debian kernel's git repo:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/803/diffs?
commit_id=cb54af62e4db43555b93920b5d06bcba7f06dfc7#9c96da0e9f91d7d8937b69b524702c106258f0d1_1514_1593

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

Bug#1051167: RFP: gwaveedit -- Sound file editor

[Bastian Germann]

Package: wnpp
Severity: wishlist
Control: block 967629 by -1

* Package name: gwaveedit
  Version : (use git HEAD)
  Upstream Author : Magnus Hjorth, wdlkmpx
* URL : https://github.com/wdlkmpx/gWaveEdit
* License : GPL-2+
  Programming Lang: C
  Description : Sound file editor

This is the sound editor mhwaveedit ported to GTK 3.

Bug#1040970: libwebp: Please package new upstream release 1.3.1 with libsharpyuv

[Boyuan Yang]

X-Debbugs-CC: j...@debian.org

On Thu, 13 Jul 2023 08:11:32 -0400 Boyuan Yang  wrote:
> Source: libwebp
> Version: 1.2.4-0.2
> Tags: sid trixie
> X-Debbugs-CC: f...@debian.org j...@debian.org
> 
> Dear Debian libwebp maintainer,
> 
> As previously discussed in https://bugs.debian.org/1022001 , we have a need
> for a separate libsharpyuv library, which is available only after libwebp
> v1.3.0. For Debian 12 Bookworm release, we postponed the preparation of
> new libwebp for stability. Now that Debian Bookworm has been released, it is
> the time to do the packaging for new version.

Is there any progress on this issue? If you need a proposed patch, I will be
happy to provide one as a new upload or debdiff.

Thanks,
Boyuan Yang


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

Bug#1051157: Possible solution (?)

[Ervin Hegedüs]

The file /etc/apparmor.d/abstractions/apache2-common contains
these rules:

22# Apache
23network inet stream,
24network inet6 stream,

which (I guess) needs to enable the trafic.

Seems like the profiles need to include this file too, so the
added this line to the profile

^myvhost.mydomain {

  #include 
  ...

solved the problem. This was not necessary in previous Debian
versions.


It would be nice to know, is that the final solution? Should I
check any other thing? (Eg. in case of a version upgrade...)


a.

Bug#1051166: FTBFS with doxygen 1.9.8

[Paolo Greppi]

Package: breathe-doc
Version: 4.35.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the 
past)

X-Debbugs-Cc: paolo.gre...@libpf.com

While preparing to upload doxygen 1.9.8, I did a partial rebuild of 
packages that build-depend on it.
More info here: 
https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial


Of 510 packages I tried, 6 failed and one is breathe-doc.

The build error was:

  Exception occurred while building, starting debugger:
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 
281, in build_main

  app.build(args.force_all, args.filenames)
File "/usr/lib/python3/dist-packages/sphinx/application.py", line 
341, in build

  self.builder.build_update()
File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", 
line 310, in build_update

  self.build(to_build,
File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", 
line 325, in build

  with logging.pending_warnings():
File "/usr/lib/python3.11/contextlib.py", line 144, in __exit__
  next(self.gen)
File "/usr/lib/python3/dist-packages/sphinx/util/logging.py", line 
218, in pending_warnings

  memhandler.flushTo(logger)
File "/usr/lib/python3/dist-packages/sphinx/util/logging.py", line 
183, in flushTo

  logger.handle(record)
File "/usr/lib/python3.11/logging/__init__.py", line 1644, in handle
  self.callHandlers(record)
File "/usr/lib/python3.11/logging/__init__.py", line 1706, in 
callHandlers

  hdlr.handle(record)
File "/usr/lib/python3.11/logging/__init__.py", line 974, in handle
  rv = self.filter(record)
  ^^^
File "/usr/lib/python3.11/logging/__init__.py", line 830, in filter
  result = f.filter(record)
  
File "/usr/lib/python3/dist-packages/sphinx/util/logging.py", line 
426, in filter

  raise exc
  sphinx.errors.SphinxWarning: 
/<>/documentation/source/specific.rst:195:Invalid C++ 
declaration: Expected identifier in nested name. [error at 0]


^
  > /usr/lib/python3/dist-packages/sphinx/util/logging.py(426)filter()
  -> raise exc
  (Pdb)
  make[3]: *** [Makefile:56: html] Error 2

I attach the full build log.

Paolo

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

Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages breathe-doc depends on:
ii  libjs-mathjax2.7.9+dfsg-1
ii  libjs-sphinxdoc  5.3.0-7

breathe-doc recommends no packages.

breathe-doc suggests no packages.

-- no debconf information

breathe_4.35.0-2.xz
Description: application/xz

Bug#1051165: FTBFS with doxygen 1.9.8

[Paolo Greppi]

Package: libstxxl-doc
Version: 1.4.1-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the 
past)

X-Debbugs-Cc: paolo.gre...@libpf.com

While preparing to upload doxygen 1.9.8, I did a partial rebuild of 
packages that build-depend on it.
More info here: 
https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial


Of 510 packages I tried, 6 failed and one is libstxxl-doc.

The build error was:

  ! LaTeX Error: File `topics.tex' not found.

  Type X to quit or  to proceed,
  or enter new name. (Default extension: tex)

  Enter file name:
  ! Emergency stop.
  

  l.211 \input{topics}
  ^^M
  !  ==> Fatal error occurred, no output PDF file produced!
  Transcript written on refman.log.

I attach the full build log.

Paolo

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

Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libstxxl-doc depends on:
ii  libjs-jquery  3.6.1+dfsg+~3.5.14-1

libstxxl-doc recommends no packages.

libstxxl-doc suggests no packages.

-- no debconf information

libstxxl_1.4.1-3.xz
Description: application/xz

Bug#1051164: RFS: ffmpegfs/2.14-1~bpo12+1 [ ITP] -- read-only FUSE filesystem which transcodes between audio and video formats on the fly)

[Norbert Schlia]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "ffmpegfs":

 * Package name    : ffmpegfs
   Version : 2.14-1~bpo12+1
   Upstream Author : Norbert Schlia 
 * URL : https://nschlia.github.io/ffmpegfs/
 * License : CC0-1.0, GFDL-NIV-1.3 or GPL-3+, GPL-3+
 * Vcs : https://salsa.debian.org/nschlia/ffmpegfs
   Section : utils

The source builds the following binary packages:

  ffmpegfs - Fuse Multi Media Filesystem

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


  https://mentors.debian.net/package/ffmpegfs/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/ffmpegfs/ffmpegfs_2.14-1~bpo12+1.dsc


Changes since the last upload:

 ffmpegfs (2.14-1~bpo12+1) bookworm-backports; urgency=medium
 .
   * Rebuild for bookworm-backports.

Bug#967647: mtr: depends on deprecated GTK 2

[Bastian Germann]

I have changed the Build-Depends to build with gtk3 in git.
Please consider uplloading an unstable version soon.

Bug#1051163: linux-image-6.1.0-11-amd64: NVIDIA graphics cards have no frame buffer during boot

[Martin Johnson]

Package: src:linux
Version: 6.1.38-4
Severity: normal
X-Debbugs-Cc: martin.d.john...@outlook.com

Dear Maintainer,

A patch in the kernel caused problems with the NVIDIA graphics cards
causing the frame buffer to be disabled and not to appear at boot under certain
circumstances. This issue appears on both my machines with dual GeForce 1050TI
graphics cards and the proprietary NVIDIA driver. Not having the frame buffer
also makes it very difficult to install said proprietary drivers on the debian
kernel (and other kernels), since they often crash the system when installing
with graphical.target.

Applying this patch from upstream fixes the issue:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5ae3716cfdcd286268133867f67d0803847acefc

Once the patch applied then the framebuffer works fine again on boot,
both Linux machines with dual NVIDIA GeForce 1050TI cards tested.

Please can you backport this fix to the Debian Kernel? Thank you.

If you need me to test it please let me know :-)


-- Package-specific info:
** Version:
Linux version 6.1.0-11-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.38-4 (2023-08-08)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-11-amd64 
root=UUID=3e84e00c-d5b7-4110-bbcf-c52b84e50b16 ro amd_iommu=on iommu=pt 
pcie_acs_override=id:1022:43c6 kvm.ignore_msrs=1 kvm.report_ignored_msrs=0 
quiet nvidia-drm.modeset=1

** Not tainted

** Kernel log:
[5.478766] usb 1-1: Warning! Unlikely big volume range (=9472), cval->res 
is probably wrong.
[5.478772] usb 1-1: [13] FU [PCM Playback Volume] ch = 2, val = -9473/-1/1
[5.481916] usbcore: registered new interface driver snd-usb-audio
[5.509650] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:03.1/:08:00.1/sound/card0/input14
[5.509872] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:03.1/:08:00.1/sound/card0/input15
[5.510144] input: HDA Digital PCBeep as 
/devices/pci:00/:00:08.1/:0a:00.3/sound/card1/input18
[5.510182] iwlwifi :06:00.0: Detected Intel(R) Wi-Fi 6 AX200 160MHz, 
REV=0x340
[5.510459] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.1/:08:00.1/sound/card0/input16
[5.510538] thermal thermal_zone0: failed to read out thermal zone (-61)
[5.510657] input: HD-Audio Generic Front Mic as 
/devices/pci:00/:00:08.1/:0a:00.3/sound/card1/input19
[5.510761] input: HD-Audio Generic Rear Mic as 
/devices/pci:00/:00:08.1/:0a:00.3/sound/card1/input20
[5.510886] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:03.1/:08:00.1/sound/card0/input17
[5.518568] input: HD-Audio Generic Line as 
/devices/pci:00/:00:08.1/:0a:00.3/sound/card1/input21
[5.524551] input: HD-Audio Generic Line Out Front as 
/devices/pci:00/:00:08.1/:0a:00.3/sound/card1/input22
[5.525155] input: HD-Audio Generic Line Out Surround as 
/devices/pci:00/:00:08.1/:0a:00.3/sound/card1/input23
[5.527214] input: HD-Audio Generic Line Out CLFE as 
/devices/pci:00/:00:08.1/:0a:00.3/sound/card1/input24
[5.527823] input: HD-Audio Generic Front Headphone as 
/devices/pci:00/:00:08.1/:0a:00.3/sound/card1/input25
[5.585414] usb 3-1.3: New USB device found, idVendor=2109, idProduct=2817, 
bcdDevice=90.24
[5.585421] usb 3-1.3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[5.585423] usb 3-1.3: Product: USB2.0 Hub 
[5.585426] usb 3-1.3: Manufacturer: VIA Labs, Inc. 
[5.613601] Bluetooth: Core ver 2.22
[5.613631] NET: Registered PF_BLUETOOTH protocol family
[5.613633] Bluetooth: HCI device and connection manager initialized
[5.613639] Bluetooth: HCI socket layer initialized
[5.613642] Bluetooth: L2CAP socket layer initialized
[5.613651] Bluetooth: SCO socket layer initialized
[5.638016] iwlwifi :06:00.0: Detected RF HR B3, rfid=0x10a100
[5.639984] hub 3-1.3:1.0: USB hub found
[5.640411] hub 3-1.3:1.0: 4 ports detected
[5.666508] SVM: TSC scaling supported
[5.666513] kvm: Nested Virtualization enabled
[5.666515] SVM: kvm: Nested Paging enabled
[5.666518] SEV supported: 16 ASIDs
[5.666548] SVM: Virtual VMLOAD VMSAVE supported
[5.666549] SVM: Virtual GIF supported
[5.666550] SVM: LBR virtualization supported
[5.671270] usbcore: registered new interface driver btusb
[5.677308] MCE: In-kernel MCE decoding enabled.
[5.684219] intel_rapl_common: Found RAPL domain package
[5.684224] intel_rapl_common: Found RAPL domain core
[5.691790] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-20-1-3.sfi
[5.691802] Bluetooth: hci0: Found device firmware: intel/ibt-20-1-3.sfi
[5.691824] Bluetooth: hci0: Boot Address: 0x24800
[5.691827] 

Bug#1051162: FTBFS with doxygen 1.9.8

[Paolo Greppi]

Package: netcdf-doc
Version: 1:4.9.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the 
past)

X-Debbugs-Cc: paolo.gre...@libpf.com

While preparing to upload doxygen 1.9.8, I did a partial rebuild of 
packages that build-depend on it.
More info here: 
https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial


Of 510 packages I tried, 6 failed and one is netcdf-doc.

The build error was:

  /<>/docs/dispatch.md:392: error: Unexpected 
subsubsection command found inside section! (warning treated as error, 
aborting now)
  make[3]: *** [docs/CMakeFiles/doc_all.dir/build.make:74: 
docs/CMakeFiles/doc_all] Error 1


I attach the full build log.

Paolo

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

Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

netcdf_1:4.9.2-1.xz
Description: application/xz

Bug#1051120: debian-installer: can't use YubiKey for secure drive encryption passphrase because enter clears form

[Cyril Brulebois]

Hi,

Jonathan Kamens  (2023-09-02):
> The Debian installer, however, *erases the contents of the first
> passphrase field* when the YubiKey sends the Enter.

I'm assuming the main problem is that Enter moves to the next screen,
you would have to send passphrase +  instead of passphrase +
 to have a desired effect in the graphical installer.

Try the text-based installer instead, password and passphrase
confirmations happen on two separate screens?

> TLDR The Enter key should not clear the passphrase field that has
> already been entered.

I realize this makes your life harder, but I don't think it would be
reasonable to change what Enter does at this point.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1051161: postfix: Postfix does not start with default configuration

[Henrik Stoerner]

Package: postfix
Version: 3.7.6-0+deb12u2
Severity: important

Dear Maintainer,

On a fresh Debian 12 Bookworm installation, the Postfix package was installed 
and configured as "Internet site".

The service does not start. 

"systemctl start postfix" shows as "started (exited)". 
journalctl for the service just says that "A start job for unit postfix.service 
has finished successfully." but no processes are running.

It is possible to start Postfix with the command "postfix start", then it runs 
as expected. But I would expect the systemd configuration to do this.


Regards,
Henrik Stoerner

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

Kernel: Linux 6.1.0-11-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=C, 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 postfix depends on:
ii  adduser3.134
ii  cpio   2.13+dfsg-7.1
ii  debconf [debconf-2.0]  1.5.82
ii  dpkg   1.21.22
ii  e2fsprogs  1.47.0-2
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u1
ii  libdb5.3   5.3.28+dfsg2-1
ii  libicu72   72.1-3
ii  libnsl21.3.0-2
ii  libsasl2-2 2.1.28+dfsg-10
ii  libssl33.0.9-1
ii  netbase6.4
ii  ssl-cert   1.1.2

Versions of packages postfix recommends:
ii  ca-certificates  20230311
ii  python3  3.11.2-1+b1

Versions of packages postfix suggests:
ii  dovecot-core [dovecot-common]  1:2.3.19.1+dfsg1-2.1
ii  libsasl2-modules   2.1.28+dfsg-10
ii  mutt [mail-reader] 2.2.9-1+b1
ii  postfix-cdb3.7.6-0+deb12u2
ii  postfix-doc3.7.6-0+deb12u2
pn  postfix-ldap   
pn  postfix-lmdb   
pn  postfix-mta-sts-resolver   
ii  postfix-mysql  3.7.6-0+deb12u2
ii  postfix-pcre   3.7.6-0+deb12u2
pn  postfix-pgsql  
ii  postfix-sqlite 3.7.6-0+deb12u2
pn  procmail   
pn  resolvconf 
ii  ufw0.36.2-1

-- debconf information:
  postfix/not_configured:
  postfix/newaliases: false
  postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
  postfix/destinations: $myhostname, vmail2.vservers, localhost.vservers, , 
localhost
  postfix/bad_recipient_delimiter:
  postfix/relayhost:
* postfix/main_mailer_type: Internet Site
  postfix/rfc1035_violation: false
  postfix/procmail: false
  postfix/root_address:
  postfix/mailbox_limit: 0
  postfix/chattr: false
* postfix/mailname: mx2.hswn.dk
  postfix/recipient_delim: +
  postfix/protocols: all

Bug#967518: hardinfo: depends on deprecated GTK 2

[Bastian Germann]

Please try to build a gtk3 version with the HARDINFO_GTK3 option.

Bug#1051160: auto-multiple-choice: FTBFS: Error: The font "DejaVu Serif" cannot be found.

[Aurelien Jarno]

Source: auto-multiple-choice
Version: 1.6.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

auto-multiple-choice fails to build from source. From my build log on
amd64:

| rsvg-convert -f pdf img_src/warning.svg -o img_pdf/warning.pdf
| set -e ; xelatex -halt-on-error -interaction=nonstopmode 
auto-multiple-choice.en.tex; xelatex -halt-on-error -interaction=nonstopmode 
auto-multiple-choice.en.tex
| This is XeTeX, Version 3.141592653-2.6-0.95 (TeX Live 2023/Debian) 
(preloaded format=xelatex)
|  restricted \write18 enabled.
| entering extended mode
| (./auto-multiple-choice.en.tex
| LaTeX2e <2023-06-01>
| L3 programming layer <2023-06-05>
| (/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
| Document Class: article 2023/05/17 v1.4n Standard LaTeX document class
| (/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
| (/usr/share/texlive/texmf-dist/tex/latex/base/ifthen.sty)
| (/usr/share/texlive/texmf-dist/tex/generic/iftex/ifxetex.sty
| (/usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty))
| (/usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.sty
| (/usr/share/texlive/texmf-dist/tex/latex/l3packages/xparse/xparse.sty
| (/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.sty
| (/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-xetex.def)))
| (/usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
| (/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty)
| (/usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.cfg)))
| (/usr/share/texlive/texmf-dist/tex/xelatex/xltxtra/xltxtra.sty
| (/usr/share/texlive/texmf-dist/tex/generic/iftex/ifluatex.sty)
| (/usr/share/texlive/texmf-dist/tex/latex/realscripts/realscripts.sty)
| (/usr/share/texlive/texmf-dist/tex/latex/metalogo/metalogo.sty
| (/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
| (/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty)
| (/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
| (/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty)
| (/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg)
| (/usr/share/texlive/texmf-dist/tex/latex/graphics-def/xetex.def)
| 
| ! Package fontspec Error: The font "DejaVu Serif" cannot be found.
| 
| For immediate help type H .
|  ...  
|   
| l.23 \setsansfont
|  {DejaVu Sans}
| No pages of output.
| Transcript written on auto-multiple-choice.en.log.
| make[3]: *** [Makefile:73: auto-multiple-choice.en.pdf] Error 1
| rm img_pdf/important.pdf img_pdf/warning.pdf auto-multiple-choice.en.tex 
img_pdf/note.pdf
| make[3]: Leaving directory '/<>/doc'
| make[2]: *** [Makefile:165: doc] Error 2
| rm icons/auto-multiple-choice.png
| make[2]: Leaving directory '/<>'
| make[1]: *** [Makefile:118: all] Error 2
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j1 "INSTALL=install --strip-program=true" 
returned exit code 2
| make: *** [debian/rules:8: binary-arch] Error 25
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

A full build log on riscv64 is also available:
https://buildd.debian.org/status/fetch.php?pkg=auto-multiple-choice=riscv64=1.6.0-1=1693738582=0

Regards
Aurelien

Bug#1051158: aseba: FTBFS: error: ‘uint16_t’ does not name a type

[Aurelien Jarno]

Source: aseba
Version: 1.6.99+dfsg-7
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

aseba fails to build from source. From my build log on amd64:

| [  2%] Building CXX object 
aseba/common/CMakeFiles/asebacommon.dir/msg/TargetDescription.cpp.o
| cd /<>/obj-x86_64-linux-gnu/aseba/common && /usr/bin/c++ 
-DASEBA_ASSERT -I/<>/aseba -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu++14   -fPIC -MD -MT 
aseba/common/CMakeFiles/asebacommon.dir/msg/TargetDescription.cpp.o -MF 
CMakeFiles/asebacommon.dir/msg/TargetDescription.cpp.o.d -o 
CMakeFiles/asebacommon.dir/msg/TargetDescription.cpp.o -c 
/<>/aseba/common/msg/TargetDescription.cpp
| In file included from 
/<>/aseba/common/msg/TargetDescription.cpp:20:
| /<>/aseba/common/msg/TargetDescription.h:88:17: error: 
‘uint16_t’ does not name a type
|88 | uint16_t crc() const;
|   | ^~~~
| /<>/aseba/common/msg/TargetDescription.h:26:1: note: ‘uint16_t’ 
is defined in header ‘’; did you forget to ‘#include ’?
|25 | #include 
|   +++ |+#include 
|26 | 
| /<>/aseba/common/msg/TargetDescription.cpp:26:18: error: no 
declaration matches ‘uint16_t Aseba::TargetDescription::crc() const’
|26 | uint16_t TargetDescription::crc() const
|   |  ^
| /<>/aseba/common/msg/TargetDescription.cpp:26:18: note: no 
functions named ‘uint16_t Aseba::TargetDescription::crc() const’
| /<>/aseba/common/msg/TargetDescription.h:39:16: note: ‘struct 
Aseba::TargetDescription’ defined here
|39 | struct TargetDescription
|   |^
| make[3]: *** [aseba/common/CMakeFiles/asebacommon.dir/build.make:163: 
aseba/common/CMakeFiles/asebacommon.dir/msg/TargetDescription.cpp.o] Error 1
| make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[2]: *** [CMakeFiles/Makefile2:993: 
aseba/common/CMakeFiles/asebacommon.dir/all] Error 2
| make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[1]: *** [Makefile:169: all] Error 2
| make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j1 "INSTALL=install 
--strip-program=true" VERBOSE=1 returned exit code 2
| make: *** [debian/rules:18: build-arch] Error 25
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

A full build log on riscv64 is also available:
https://buildd.debian.org/status/fetch.php?pkg=aseba=riscv64=1.6.99%2Bdfsg-7=1693729588=0

Regards
Aurelien

Bug#1051159: gnome-packagekit: FTBFS: gnome-packagekit-self-test FAIL

[Aurelien Jarno]

Source: gnome-packagekit
Version: 43.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

gnome-packagekit fails to build from source due to an issue in the
testsuite. From my build log on amd64:

| xvfb-run dh_auto_test
|   cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 
MESON_TESTTHREADS=1 meson test
| ninja: Entering directory `/<>/obj-x86_64-linux-gnu'
| ninja: no work to do.
| 1/1 gnome-packagekit-self-test FAIL0.22s   killed by signal 5 
SIGTRAP
| >>> MALLOC_PERTURB_=101 
/<>/obj-x86_64-linux-gnu/src/gpk-self-test
| 
| 
| Ok: 0   
| Expected Fail:  0   
| Fail:   1   
| Unexpected Pass:0   
| Skipped:0   
| Timeout:0   
| 
| Full log written to 
/<>/obj-x86_64-linux-gnu/meson-logs/testlog.txt
|   cd obj-x86_64-linux-gnu && tail -v -n \+0 meson-logs/testlog.txt
| ==> meson-logs/testlog.txt <==
| Log of Meson test suite run on 2023-09-03T10:39:44.785950
| 
| Inherited environment: DEB_HOST_GNU_SYSTEM=linux-gnu DFLAGS=-frelease 
DEB_BUILD_ARCH_BITS=64 DEB_TARGET_GNU_CPU=x86_64 DEB_HOST_ARCH_OS=linux 
USER=aurel32 CXXFLAGS='-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection' DEB_BUILD_GNU_TYPE=x86_64-linux-gnu 
DEB_TARGET_MULTIARCH=x86_64-linux-gnu OBJCFLAGS='-g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection' 
DH_INTERNAL_OPTIONS=-a DEB_BUILD_ARCH_CPU=amd64 DEB_HOST_ARCH_LIBC=gnu 
DEB_HOST_ARCH_ABI=base 
HOME=/<>/debian/.debhelper/generated/_source/home 
APT_CONFIG=/var/lib/sbuild/apt.conf SCHROOT_CHROOT_NAME=sid-amd64-sbuild 
DEB_BUILD_ARCH_ENDIAN=little LDFLAGS=-Wl,-z,relro DEB_TARGET_ARCH_BITS=64 
DEB_BUILD_GNU_SYSTEM=linux-gnu MAKEFLAGS=w SCHROOT_UID=1000 
DEB_BUILD_ARCH_OS=linux DEB_TARGET_GNU_TYPE=x86_64-linux-gnu 
DEB_TARGET_ARCH_CPU=amd64 LOGNAME=aurel32 DEB_BUILD_ARCH_LIBC=gnu 
DEB_BUILD_ARCH_ABI=base DEB_HOST_ARCH=amd64 DEB_TARGET_ARCH_ENDIAN=little 
DH_INTERNAL_OVERRIDE=dh_auto_test DEB_HOST_GNU_CPU=x86_64 LC_COLLATE=C.UTF-8 
DEB_TARGET_GNU_SYSTEM=linux-gnu 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games 
DEB_TARGET_ARCH_OS=linux CFLAGS='-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection' MAKELEVEL=2 
DEB_HOST_MULTIARCH=x86_64-linux-gnu SOURCE_DATE_EPOCH=1668444324 FCFLAGS='-g 
-O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -fcf-protection' 
SCHROOT_SESSION_ID=sid-amd64-sbuild-de330d22-e06b-4bad-9ea9-b7730d412354 
SCHROOT_COMMAND='dpkg-buildpackage --sanitize-env -us -uc -mAurelien Jarno 
 -eAurelien Jarno  -B -rfakeroot' 
DISPLAY=:99 OBJCXXFLAGS='-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection' LANG=fr_FR.UTF-8 
SCHROOT_ALIAS_NAME=sid-amd64-sbuild DEB_TARGET_ARCH_LIBC=gnu 
DEB_TARGET_ARCH_ABI=base XAUTHORITY=/tmp/xvfb-run.G9VJQT/Xauthority 
DEB_BUILD_OPTIONS=parallel=1 SCHROOT_GROUP=aurel32 SCHROOT_USER=aurel32 
CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2' DH_INTERNAL_BUILDFLAGS=1 
SHELL=/bin/sh DEB_HOST_ARCH_BITS=64 DEB_BUILD_ARCH=amd64 
DEB_BUILD_GNU_CPU=x86_64 ASFLAGS='' DEB_HOST_GNU_TYPE=x86_64-linux-gnu 
LC_ALL=C.UTF-8 DEB_HOST_ARCH_CPU=amd64 DEB_RULES_REQUIRES_ROOT=no 
PWD=/<> FFLAGS='-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -fcf-protection' 
DEB_BUILD_MULTIARCH=x86_64-linux-gnu SCHROOT_GID=1000 MFLAGS=-w GCJFLAGS='-g 
-O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -fcf-protection' DEB_HOST_ARCH_ENDIAN=little 
DEB_TARGET_ARCH=amd64 XDG_RUNTIME_DIR=/tmp/dh-xdg-rundir-f0RupSXS 
DEB_PYTHON_INSTALL_LAYOUT=deb MESON_TESTTHREADS=1 
| 
|  1/1 =
| test: gnome-packagekit-self-test
| start time:   10:39:44
| duration: 0.22s
| result:   killed by signal 5 SIGTRAP
| command:  MALLOC_PERTURB_=101 
/<>/obj-x86_64-linux-gnu/src/gpk-self-test
| --- stdout ---
| TAP version 13
| # random seed: R02S25cbff34a39c57c81b4b9d67ffa07155
| 1..2
| # Start of gnome-packagekit tests
| not ok /gnome-packagekit/enum - GnomePackageKit-FATAL-WARNING: group 
unrecognized: 35
| Bail out!
| ==
| 
| 
| Summary of Failures:
| 
| 1/1 gnome-packagekit-self-test FAIL0.22s   killed by signal 5 
SIGTRAP
| 
| Ok: 0   
| Expected Fail:  0   
| Fail:   1   
| Unexpected Pass:0   
| Skipped:0   
| Timeout:0   
| dh_auto_test: error: cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb 

Bug#1051157: Apparmor blocks Apache's network trafic

[Ervin Hegedüs]

Package: apparmor
Version: 3.0.8-3

# dpkg -l "*apparmor*"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion  Architecture Description
+++-===---
ii  apparmor3.0.8-3  amd64user-space parser 
utility for AppArmor
ii  apparmor-profiles   3.0.8-3  all  experimental 
profiles for AppArmor security policies
ii  apparmor-utils  3.0.8-3  all  utilities for 
controlling AppArmor
ii  libapache2-mod-apparmor 3.0.8-3  amd64changehat 
AppArmor library as an Apache module
ii  libapparmor1:amd64  3.0.8-3  amd64changehat 
AppArmor library
ii  python3-apparmor3.0.8-3  all  AppArmor Python3 
utility library
ii  python3-libapparmor 3.0.8-3  amd64AppArmor library 
Python3 bindings


I've configured Apparmor: enabled Apache and created a profile
for the virtual host. I've copied the working configuration files
from my previous systems (Debian 10 and Debian 11).

The Apache2 profile (usr.sbin.apache2) is untouched (except I
removed the complain flag, so it's in enforce mode). The profile
contains only the paths what I want to allow for Apache's VHOST.

When I send the HTTP request to Apache, I got this response:

* Empty reply from server
* Closing connection 0
curl: (52) Empty reply from server

In this case I see the lines in syslog:

2023-09-03T17:51:48.864732+02:00 server kernel: [ 2028.475849] audit: type=1400 
audit(1693756308.859:335): apparmor="DENIED" operation="file_perm" 
profile="apache2//myvhost.mydomain" pid=1851 comm="apache2" laddr=192.168.0.246 
lport=80 faddr=192.168.100.140 fport=58896 family="inet" sock_type="stream" 
protocol=6 requested_mask="receive" denied_mask="receive"
2023-09-03T17:51:48.864735+02:00 server kernel: [ 2028.475859] audit: type=1400 
audit(1693756308.859:336): apparmor="DENIED" operation="file_perm" 
profile="apache2//myvhost.mydomain" pid=1851 comm="apache2" laddr=192.168.0.246 
lport=80 faddr=192.168.100.140 fport=58896 family="inet" sock_type="stream" 
protocol=6 requested_mask="send" denied_mask="send"


# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 12 (bookworm)
Release:12
Codename:   bookworm

# cat /etc/debian_version 
12.1



Thanks,


a.

Bug#967436: gmpc: depends on deprecated GTK 2

[Bastian Germann]

The upstream git repository has evolved to gtk3.
Please consider importing the latest git commit as new version and switch to 
gkt3.

Bug#1050592: perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl

[Aurelien Jarno]

On 2023-09-03 17:48, Niko Tyni wrote:
> Control: reassign -1 libc6-dev 2.37-2
> Control: found -1 2.36-9+deb12u1
> Control: tag -1 bookworm
> 
> On Mon, Aug 28, 2023 at 11:46:14PM +0200, Aurelien Jarno wrote:
> 
> > > I think it's an ABI breakage that should be fixed, but just reverting
> > > the patch will break the case without -D_FILE_OFFSET_BITS=64. I'll check
> > > with upstream and try to get the issue fixed in both testing/sid and
> > > stable. I'll keep you updated. In the meantime feel free to reassign the
> > > bug to the glibc.
> > 
> > I have opened a bug upstream:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=30804
> > 
> > And submitted a possible patch:
> > https://sourceware.org/pipermail/libc-alpha/2023-August/151199.html
> 
> Many thanks! I'm reassigning this. Hope I got the versions right.
> 
> Looks like the discussion upstream has quieted down now.

I have submitted the v3 of the patch and I am waiting for it to be
rebuilt:
https://sourceware.org/pipermail/libc-alpha/2023-August/151273.html

Unfortunately upstream does not consider it as an ABI breakage on the
glibc side, just an API breakage. But it causes an ABI breakage on the
perl side.

> My understanding is that for sid/trixie we'll just need a binNMU of perl
> on ppc64el afterwards. I'll request that once glibc has the fix.

I believe so (well probably on all architectures for multiarch sync).

> For stable I don't think anything needs to be done on the perl side.
> Both perl and libfile-fcntllock-perl were build with the old constants
> before the regression. So just fixing glibc should be enough.

I agree.

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

Bug#1051156: FTBFS with doxygen 1.9.8

[Paolo Greppi]

Package: seqan-raptor-doc
Version: 3.0.1+ds-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the 
past)

X-Debbugs-Cc: paolo.gre...@libpf.com

While preparing to upload doxygen 1.9.8, I did a partial rebuild of 
packages that build-depend on it.
More info here: 
https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial


Of 510 packages I tried, 6 failed and one is seqan-raptor-doc.

The build error was:

  xelatex refman
  This is XeTeX, Version 3.141592653-2.6-0.95 (TeX Live 
2023/Debian) (preloaded format=xelatex)

  restricted \write18 enabled.
  entering extended mode
  (./refman.tex
  LaTeX2e <2023-06-01>
  L3 programming layer <2023-06-05>

  make[2]: *** [Makefile:12: refman.pdf] Error 1

I attach the full build log.

Paolo

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

Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

seqan-raptor_3.0.1+ds-3.xz
Description: application/xz

Bug#1051155: FTBFS with doxygen 1.9.8

[Paolo Greppi]

Package: wxpython-tools
Version: 4.2.1+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the 
past)

X-Debbugs-Cc: paolo.gre...@libpf.com

While preparing to upload doxygen 1.9.8, I did a partial rebuild of 
packages that build-depend on it.
More info here: 
https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial


Of 510 packages I tried, 5 failed and one is wxpython-tools.

The build error was:

  Running command: etg
  "/usr/bin/python3.11" etg/_core.py --sip --nodoc
  "/usr/bin/python3.11" etg/_html2.py --sip --nodoc
  "/usr/bin/python3.11" etg/_xml.py --sip --nodoc
  "/usr/bin/python3.11" etg/_xrc.py --sip --nodoc
  "/usr/bin/python3.11" etg/_richtext.py --sip --nodoc
  "/usr/bin/python3.11" etg/_stc.py --sip --nodoc
  "/usr/bin/python3.11" etg/_grid.py --sip --nodoc
  "/usr/bin/python3.11" etg/_msw.py --sip --nodoc 


  "/usr/bin/python3.11" etg/_propgrid.py --sip --nodoc
  "/usr/bin/python3.11" etg/_dataview.py --sip --nodoc
  "/usr/bin/python3.11" etg/_glcanvas.py --sip --nodoc
  Traceback (most recent call last):
File "/<>/etg/_glcanvas.py", line 137, in 
  run()
File "/<>/etg/_glcanvas.py", line 49, in run
  etgtools.parseDoxyXML(module, ITEMS) 


File "/<>/etgtools/__init__.py", line 91, in parseDoxyXML
  item = module.addElement(element)
^^
File "/<>/etgtools/extractors.py", line 1576, in 
addElement

  self.addElement(node)
File "/<>/etgtools/extractors.py", line 1547, in 
addElement

  item = EnumDef(element, inClass)
^
File "/<>/etgtools/extractors.py", line 1185, in __init__
  self.extract(element) 


File "/<>/etgtools/extractors.py", line 1189, in extract
  super(EnumDef, self).extract(element)
File "/<>/etgtools/extractors.py", line 65, in extract
  if '::' in self.name:
^
  TypeError: argument of type 'NoneType' is not iterable

I attach the full build log.

Paolo

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

Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wxpython-tools depends on:
ii  python3   3.11.4-5+b1
ii  python3-wxgtk4.0  4.2.1+dfsg-1

wxpython-tools recommends no packages.

wxpython-tools suggests no packages.

-- no debconf information

wxpython4.0_4.2.1+dfsg-1.xz
Description: application/xz

Bug#1051154: FTBFS with doxygen 1.9.8

[Paolo Greppi]

Package: libcaca-dev
Version: 0.99.beta20-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the 
past)

X-Debbugs-Cc: paolo.gre...@libpf.com

While preparing to upload doxygen 1.9.8, I did a partial rebuild of 
packages that build-depend on it.
More info here: 
https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial


Of 510 packages I tried, 6 failed and one is libcaca-dev.

The build error was:

  The control sequence at the end of the top line
  of your error message was never \def'ed. If you have
  misspelled it (e.g., `\hobx'), type `I' and the correct
  spelling (e.g., `I\hbox'). Otherwise just continue,
  and I'll forget about whatever was undefined.

  ! TeX capacity exceeded, sorry [text input levels=15].
  \tabu@textbar ...ar \m@ne \scantokens {\def \:{|}}
\expandafter 
\endgroup \ex...

  l.46 \begin{DoxyParams}{Parameters}
^^M
  If you really absolutely need more capacity,
  you can ask a wizard to enlarge me.


  Here is how much of TeX's memory you used:
  18690 strings out of 477695
  304727 string characters out of 5831649
  1925759 words of memory out of 500
  38172 multiletter control sequences out of 15000+60
  560241 words of font info for 97 fonts, out of 800 for 9000
  14 hyphenation exceptions out of 8191
  101i,15n,117p,1820b,797s stack positions out of 
1i,1000n,2p,20b,20s

  !  ==> Fatal error occurred, no output PDF file produced!
  make[3]: *** [Makefile:663: stamp-latex] Error 1

I attach the full build log.

Paolo


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

Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libcaca-dev depends on:
ii  libcaca0   0.99.beta20-3
ii  libslang2-dev  2.3.3-3

libcaca-dev recommends no packages.

libcaca-dev suggests no packages.

-- no debconf information

libcaca_0.99.beta20-3.xz
Description: application/xz

Bug#1050660: fontconfig-config: dangling symlink /etc/fonts/conf.d/10-no-sub-pixel.conf

[Gunnar Hjalmarsson]

On 2023-09-01 20:29, Gunnar Hjalmarsson wrote:

I have submitted this merge request:

https://salsa.debian.org/freedesktop-team/fontconfig/-/merge_requests/12

While it doesn't remove the obsolete symlink, it ought to create the
correct symlink going forward.


After some additions to the MR, it now does both.

--
Gunnar

Bug#1051153: sagemath: crash on startup due to a python error

[Amaury Pouly]

Package: sagemath
Version: 9.5-6
Severity: important

Dear Maintainer,

I cannot start sage on my computer. Simply running 'sage' in console leads to
the following errors:

┌┐
│ SageMath version 9.5, Release Date: 2022-01-30 │
│ Using Python 3.11.5. Type "help()" for help.   │
└┘
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python3.11/pathlib.py", line 1251, in is_dir
return S_ISDIR(self.stat().st_mode)
   ^
AttributeError: 'str' object has no attribute 'stat'

Original exception was:
Traceback (most recent call last):
  File "/usr/bin/sage-ipython", line 15, in 
app.initialize()
  File "/usr/lib/python3/dist-packages/traitlets/config/application.py", line 
110, in inner
return method(app, *args, **kwargs)
   
  File "/usr/lib/python3/dist-packages/IPython/terminal/ipapp.py", line 279, in 
initialize
self.init_shell()
  File "/usr/lib/python3/dist-packages/sage/repl/interpreter.py", line 789, in 
init_shell
self.shell.extension_manager.load_extension(SAGE_EXTENSION)
  File "/usr/lib/python3/dist-packages/IPython/core/extensions.py", line 76, in 
load_extension
return self._load_extension(module_str)
   
  File "/usr/lib/python3/dist-packages/IPython/core/extensions.py", line 93, in 
_load_extension
if self._call_load_ipython_extension(mod):
   ^^
  File "/usr/lib/python3/dist-packages/IPython/core/extensions.py", line 145, 
in _call_load_ipython_extension
mod.load_ipython_extension(self.shell)
  File "/usr/lib/python3/dist-packages/sage/repl/__init__.py", line 5, in 
load_ipython_extension
sage.repl.ipython_extension.load_ipython_extension(*args)
  File "/usr/lib/python3/dist-packages/sage/repl/ipython_extension.py", line 
617, in wrapper
result = func(*args, **kwargs)
 ^
  File "/usr/lib/python3/dist-packages/sage/repl/ipython_extension.py", line 
630, in load_ipython_extension
SageCustomizations(shell=ip)
  File "/usr/lib/python3/dist-packages/sage/repl/ipython_extension.py", line 
434, in __init__
import sage.all # until sage's import hell is fixed
^^^
  File "/usr/lib/python3/dist-packages/sage/all.py", line 169, in 
from sage.rings.all  import *
  File "/usr/lib/python3/dist-packages/sage/rings/all.py", line 87, in 
from .qqbar import (AlgebraicRealField, AA,
  File "/usr/lib/python3/dist-packages/sage/rings/qqbar.py", line 2810, in 

QQxy = QQ['x', 'y']
   ~~^^
  File "sage/structure/parent.pyx", line 1276, in 
sage.structure.parent.Parent.__getitem__ 
(build/cythonized/sage/structure/parent.c:11543)
  File "/usr/lib/python3/dist-packages/sage/categories/rings.py", line 1177, in 
__getitem__
return PolynomialRing(self, elts)
   ^^
  File 
"/usr/lib/python3/dist-packages/sage/rings/polynomial/polynomial_ring_constructor.py",
 line 647, in PolynomialRing
return _multi_variate(base_ring, names, **kwds)
   
  File 
"/usr/lib/python3/dist-packages/sage/rings/polynomial/polynomial_ring_constructor.py",
 line 775, in _multi_variate
from sage.rings.polynomial.multi_polynomial_libsingular import 
MPolynomialRing_libsingular
ImportError: libsingular-Singular-4.3.1.so: cannot open shared object file: No 
such file or directory

It used to work and I am not sure what I updated since the last time I tried (a 
few weeks ago I think).


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

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

Versions of packages sagemath depends on:
ii  python3   3.11.4-5+b1
ii  python3-sage  9.5-6

Versions of packages sagemath recommends:
pn  sagemath-doc
ii  sagemath-jupyter9.5-6
pn  sagetex 
ii  texlive-latex-base  2023.20230613-3

Versions of packages sagemath suggests:
ii  dot2tex  2.11.3-3
pn  gap-design   
ii  gap-factint  1.6.3+ds-2
pn  gap-grape
pn  gap-guava
ii  gap-laguna   3.9.5+ds-2
pn  gap-sonata   
pn  gap-toric

-- no debconf information

Bug#1050974: binNMU: Rebuild against curl without NSS support

[Aurelien Jarno]

Hi,

On 2023-09-02 19:42, Sebastian Ramacher wrote:
> > On top of that, those two packages have already been rebuilt for
> > riscv64 (no binNMUs required there), whereas if we force another
> > upload only to solve this, we will trigger a build for every arch and
> > needlessly consume at the very least 77 hours of the riscv builders'
> > time (while we are still rebuilding the archive for riscv, delaying it
> > all).
> > https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-14=riscv64
> > https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-15=riscv64
> > 
> > Do you think that's a sensible compromise?
> > I'm asking to proceed with binNMUs because eg25-manager has been fixed
> > in git already and the llvm packages are about to be removed (although
> > I want curl to migrate before that), also rebuilding them on riscv
> > takes a lot of effort at a not-so-great time (no binNMUs required for
> > riscv).
> 
> Please get those uploaded instead. We will rebuild
> llvm-toolchain-{14,15} a bunch of times for transitions anyway. If
> riscv64 buildds are not ready to cope with that, the architecture is not
> ready to become a release architecture.

Please note that avoiding an upload on riscv64 is NOT a request from the
riscv64 porters. Despite the long building time, we believe that the
build daemons will be able to handle a rebuild of those packages. In
addition 2 more buildds are being prepared.

Regards
Aurelien

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


signature.asc
Description: PGP signature

Bug#1051152: RFP: cli-visualizer -- console alasa/pipewire spectrum visualizer

[Alexey Kuznetsov]

Package: wnpp
Severity: wishlist

* Package name: cli-visualizer
  Version : 1.7
  Upstream Contact: Darby Payne
* URL : https://github.com/dpayne/cli-visualizer
* License : (MIT)
  Programming Lang: (C++)
  Description : console alasa/pipewire spectrum visualizer

Command line visualizer. Supports mpd, with experimental support for alsa and 
pulseaudio.

Bug#1047168: opendmarc: no longer able to send email reports due to sandboxing

[Sébastien Villemot]

Hi David,

Sorry for my late reply, but I did not get your answer. The Debian BTS
does not send a copy to bug reporters by default (you need to
explicitly CC the bug reporter, either using their personal address or
using the special nnn-submit...@bugs.debian.org address). See
/usr/share/doc/debian/bug-maint-info.txt.gz for details.

On Fri, 18 Aug 2023 08:59:16 +0200 David =?utf-8?Q?B=C3=BCrgin?=
 wrote:
> I was worried something like this would come up … Can you try
removing
> the setting
> 
> RestrictSUIDSGID=yes
> 
> in the systemd service file (‘sudo systemctl edit --full opendmarc’)?
> If this doesn’t work can you try also removing the setting
> 
> NoNewPrivileges=yes
> 
> Please let us know what works, thank you.

I’ve removed both settings and it still does not work.

Thanks,

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



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

Bug#1042517: Fixed in 6.4.13-1

[Salvatore Bonaccorso]

Source: linux
Source-Version: 6.4.13-1

Hi

On Sun, Sep 03, 2023 at 10:20:15PM +0800, Mad Horse wrote:
> The fix
> https://patchwork.freedesktop.org/patch/msgid/20230804084600.1005818-1-jani.nik...@intel.com
> has been merged to upstream and backported to 6.4.13, so it is
> available in linux-image-6.4.0-4-amd64_6.4.13-1, and I have
> confirmed that this bug is fixed  on this version.

Thanks for confirming.

Regards,
Salvatore

Bug#1051140: Bug #1051140: lintian in bookworm does not know about bookworm-backports

[Joachim Wiedorn]

Hello Lee,

you can fix the problem by yourself:

Open file /usr/share/lintian/data/changes-file/known-dists
and add one line with "bookworm".

---
Have a nice day.
Joachim (Germany)


pgpVbnw04KJ6x.pgp
Description: Digitale Signatur von OpenPGP

Bug#1051151: norm: update d/watch file

[Patrice Duroux]

Source: norm
Version: 1.5.9+dfsg-2
Severity: minor

Dear Maintainer,

Here is a suggested patch for.

Many thanks,
Patrice


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

Kernel: Linux 6.4.0-4-amd64 (SMP w/12 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
diff --git a/debian/watch b/debian/watch
index 5f7d680..f31346b 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,3 +1,3 @@
 version=4
-opts=dversionmangle=s/\+dfsg$//,repacksuffix=+dfsg,filenamemangle=s/.+\/src-norm-(\d\S+)\.tgz/norm_$1\.orig\.tar/
 \
- https://github.com/USNavalResearchLaboratory/norm/releases 
.*/v\d.+/src-norm-([\d\.]+)\.(?:tgz|tbz2|txz|tar\.(?:gz|bz2|xz))
+opts=dversionmangle=s/\+dfsg$//,repacksuffix=+dfsg,filenamemangle=s/(?:.*?)@ANY_VERSION@(@ARCHIVE_EXT@)/@PACKAGE@-$1$2/
 \
+ https://github.com/USNavalResearchLaboratory/@PACKAGE@/tags 
(?:.*?/)@ANY_VERSION@@ARCHIVE_EXT@

Bug#1051140: Bug #1051140: lintian in bookworm does not know about bookworm-backports

[Lee Garrett]

Indeed, however the bug is about fixing it in stable.

On 03.09.23 16:45, Joachim Wiedorn wrote:

Hello Lee,

you can fix the problem by yourself:

Open file /usr/share/lintian/data/changes-file/known-dists
and add one line with "bookworm".

---
Have a nice day.
Joachim (Germany)

Bug#1043522: blhc: Please allow -std=gnu++20 inside bin/blhc:L1114 regex exception

[Eriberto Mota]

Hi Simon,

> |but the additional "||-std=gnu++20" is found, which causes the 
> exception regex not to be triggered: could you please change the 
> mentioned line in bin/blhc to allow for optional arguments between 
> "/usr/lib/ccache/c++" and "-dM"?|

The same case for -std=gnu++11:

CPPFLAGS missing (-D_FORTIFY_SOURCE=2): /usr/lib/ccache/c++ -std=gnu++11 -dM -E 
-c /usr/share/cmake-3.27/Modules/CMakeCXXCompilerABI.cpp -DHAVE_OBSCONFIG_H 
-DQT_CORE_LIB -DQT_GUI_LIB [...]

Regards,

Eriberto

Bug#1051150: RFS: blender-doc/3.6-1 [ITP] -- Blender Manual by the Blender Foundation

[Jonathan Rubenstein]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "blender-doc":

 * Package name : blender-doc
   Version  : 3.6-1
   Upstream contact : Blender Documentation Team 
 * URL  : https://docs.blender.org/manual/
 * License  : Apache-2.0, GPL-2.0-or-later, MIT, CC-BY-SA-4.0
 * Vcs  : https://salsa.debian.org/JJRcop/blender-doc
   Section  : doc

The source builds the following binary packages:

  blender-doc - Blender Manual by the Blender Foundation

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


  https://mentors.debian.net/package/blender-doc/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/blender-doc/blender-doc_3.6-1.dsc


Changes for the initial release:

 blender-doc (3.6-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1006255)


Additional notes:

I have already attempted this a little over a year ago in #1017875 but 
didn't get around to fixing the copyright issues; these are now fixed 
and the debian/copyright file should include all of the correct 
copyright attributions (all are compatible with DFSG to my knowledge).


Additionally, I have added the lintian-override as suggested in my first 
attempt.


I intend to maintain this package, but if it should be transitioned to a 
team, that's fine as well. It's quite simple to update as the patchset 
is very light and everything generally works out of the box especially 
with the sphinx debhelper tools.


Please let me know if any further changes are required, I should be more 
responsive this time. 


Regards,
--
  Jonathan Rubenstein

Bug#1050592: perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl

[Niko Tyni]

Control: reassign -1 libc6-dev 2.37-2
Control: found -1 2.36-9+deb12u1
Control: tag -1 bookworm

On Mon, Aug 28, 2023 at 11:46:14PM +0200, Aurelien Jarno wrote:

> > I think it's an ABI breakage that should be fixed, but just reverting
> > the patch will break the case without -D_FILE_OFFSET_BITS=64. I'll check
> > with upstream and try to get the issue fixed in both testing/sid and
> > stable. I'll keep you updated. In the meantime feel free to reassign the
> > bug to the glibc.
> 
> I have opened a bug upstream:
> https://sourceware.org/bugzilla/show_bug.cgi?id=30804
> 
> And submitted a possible patch:
> https://sourceware.org/pipermail/libc-alpha/2023-August/151199.html

Many thanks! I'm reassigning this. Hope I got the versions right.

Looks like the discussion upstream has quieted down now.

My understanding is that for sid/trixie we'll just need a binNMU of perl
on ppc64el afterwards. I'll request that once glibc has the fix.

For stable I don't think anything needs to be done on the perl side.
Both perl and libfile-fcntllock-perl were build with the old constants
before the regression. So just fixing glibc should be enough.
-- 
Niko

Bug#1051149: rust-leptonica-sys, upcoming rust-bindgen update.

[Peter Michael Green]

Package: rust-leptonica-sys
Version: 0.4.6-2

In the rust team we are working on upgrading rust-bindgen from 0.60 to
0.66, there are a few reasons for this. Firstly it's part of the 
dependency stack
for the new version of rust-cargo. Secondly the version currently in sid 
has a
compatibility issue with new versions of llvm. Thirdly Jonas has filed a 
bug report

requesting the new upstream version.

bindgen bumps semver on most releases, however the changes tend to be
relatively minor. You can read the changelog at
https://github.com/rust-lang/rust-bindgen/blob/main/CHANGELOG.md#0610
I don't see anything too scary in there.

The new version of rust-bindgen has been uploaded to experimental so people
can test against it. After bumping the dependencies your package built
successfully and the autopkgtests passed.

The attatched debdiff, raises the upper limit for the bindgen dependency.diff -Nru rust-leptonica-sys-0.4.6/debian/changelog 
rust-leptonica-sys-0.4.6/debian/changelog
--- rust-leptonica-sys-0.4.6/debian/changelog   2023-08-14 12:07:09.0 
+
+++ rust-leptonica-sys-0.4.6/debian/changelog   2023-09-03 14:19:09.0 
+
@@ -1,3 +1,10 @@
+rust-leptonica-sys (0.4.6-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Relax dependeny to allow bindgen 0.66.
+
+ -- Peter Michael Green   Sun, 03 Sep 2023 14:19:09 +
+
 rust-leptonica-sys (0.4.6-2) unstable; urgency=medium
 
   * update DEP-3 patch headers
diff -Nru rust-leptonica-sys-0.4.6/debian/control 
rust-leptonica-sys-0.4.6/debian/control
--- rust-leptonica-sys-0.4.6/debian/control 2023-07-29 23:47:09.0 
+
+++ rust-leptonica-sys-0.4.6/debian/control 2023-09-03 14:19:02.0 
+
@@ -6,7 +6,7 @@
  debhelper-compat (= 13),
  dh-cargo (>= 25),
  libleptonica-dev ,
- librust-bindgen-0+default-dev (<< 0.65) ,
+ librust-bindgen-0+default-dev (<< 0.67) ,
  librust-bindgen-0+default-dev (>= 0.60) ,
  librust-pkg-config-0.3+default-dev (>= 0.3.25) ,
  libstring-shellquote-perl,
@@ -22,7 +22,7 @@
 Multi-Arch: foreign
 Depends:
  libleptonica-dev,
- librust-bindgen-0+default-dev (<< 0.65),
+ librust-bindgen-0+default-dev (<< 0.67),
  librust-bindgen-0+default-dev (>= 0.60),
  librust-pkg-config-0.3+default-dev (>= 0.3.25),
  ${misc:Depends},
diff -Nru rust-leptonica-sys-0.4.6/debian/patches/2001_bindgen.patch 
rust-leptonica-sys-0.4.6/debian/patches/2001_bindgen.patch
--- rust-leptonica-sys-0.4.6/debian/patches/2001_bindgen.patch  2023-08-14 
09:55:41.0 +
+++ rust-leptonica-sys-0.4.6/debian/patches/2001_bindgen.patch  2023-09-03 
14:18:19.0 +
@@ -1,7 +1,9 @@
 Description: relax dependency to cover older crate bindgen 0.60.1
+ and newer crate bindgen 0.66.1.
 Author: Jonas Smedegaard 
+Author: Peter Michael Green 
 Forwarded: not-needed
-Last-Update: 2023-08-14
+Last-Update: 2023-09-03
 ---
 This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 --- a/Cargo.toml
@@ -11,7 +13,7 @@
  
  [build-dependencies]
 -bindgen = "0.64.0"
-+bindgen = ">= 0.60, < 0.65"
++bindgen = ">= 0.60, < 0.67"
  
  [target.'cfg(windows)'.build-dependencies]
  vcpkg = "0.2.15"
diff -Nru rust-leptonica-sys-0.4.6/debian/patches/2002_no_windows.patch 
rust-leptonica-sys-0.4.6/debian/patches/2002_no_windows.patch
--- rust-leptonica-sys-0.4.6/debian/patches/2002_no_windows.patch   
2023-08-14 09:55:44.0 +
+++ rust-leptonica-sys-0.4.6/debian/patches/2002_no_windows.patch   
2023-09-03 14:19:09.0 +
@@ -8,7 +8,7 @@
 +++ b/Cargo.toml
 @@ -14,8 +14,5 @@
  [build-dependencies]
- bindgen = ">= 0.60, < 0.65"
+ bindgen = ">= 0.60, < 0.67"
  
 -[target.'cfg(windows)'.build-dependencies]
 -vcpkg = "0.2.15"

Bug#1051087: reportbug: linux-headers-amd64 from bullseye-backports cannot be installed (unmet dependencies)

[Kenno Vanommeslaeghe]

On Sun, 3 Sep 2023 12:54:17 +0200 Bastian Blank  wrote:
> But a really good solution this is not.

Yeah, I feel that's a slight understatement. A few of my users are on 
backported kernels because they have new hardware and we haven't found 
time to migrate our software stack to bookworm yet. One of them dutifully 
ran regular updates through gpk-update-viewer , rebooted and bam... system 
doesn't boot to a graphical desktop anymore.


What happened is that we're relying on the commercial Nvidia driver 
(because we're doing CAD), which failed to update in tandem with with the 
new kernel image by lack of corresponding headers. I guess some DKMS error 
message must have briefly flashed by, but went unnoticed.


I know, I know,

 * using the commercial nvidia driver is not really supported
 * backports are a semi-unofficial favor that we shouldn't rely on in
   production
 * one could easily fix the problem either from a text terminal or by
   choosing the previous kernel in grub

But it nevertheless leaves a poor impression on users if their system 
"fails to boot" (as it's perceived) after running a routine update. One 
risks getting comments like: "why, again, aren't we running Windows (or OSX)?"


So, I'm wondering about a mechanism that holds back on updating the kernel 
image until the corresponding updated headers are available.

Bug#1051148: /usr/share/man/man8/rpcbind.8.gz: stray n in header?

[наб]

Package: rpcbind
Version: 1.2.6-6+b1
Severity: normal
File: /usr/share/man/man8/rpcbind.8.gz

Dear Maintainer,

The manual starts
-- >8 --
RPCBIND(8)BSD System Manager's Manual   RPCBIND(8)

n

NAME
 rpcbind — universal addresses to RPC program number mapper

SYNOPSIS
 rpcbind [-adhiLlsr]
-- >8 --
and indeed,
-- >8 --
.\" @(#)rpcbind.1m 1.19 92/09/14 SMI; from SVr4
.\" Copyright 1989 AT
.\" Copyright 1991 Sun Microsystems, Inc.
.\" $FreeBSD: src/usr.sbin/rpcbind/rpcbind.8,v 1.5 2002/11/27 15:33:47 ru Exp $
n
.Dd September 14, 1992
.Dt RPCBIND 8
.Os
.Sh NAME
.Nm rpcbind
.Nd universal addresses to RPC program number mapper
.Sh SYNOPSIS
.Nm
.Op Fl adhiLlsr
.Sh DESCRIPTION
-- >8 --

Baffling! Remove it please?

Best,
наб

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

Kernel: Linux 6.3.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 rpcbind depends on:
ii  adduser3.137
ii  init-system-helpers1.65.2
ii  libc6  2.37-6
ii  libsystemd0254.1-3
ii  libtirpc3  1.3.3+ds-1
ii  libwrap0   7.6.q-32
ii  sysvinit-utils [lsb-base]  3.07-1

rpcbind recommends no packages.

rpcbind suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1042517: Fixed in 6.4.13-1

[Mad Horse]

The fix 
https://patchwork.freedesktop.org/patch/msgid/20230804084600.1005818-1-jani.nik...@intel.com
 has been merged to upstream and backported to 6.4.13, so it is available in 
linux-image-6.4.0-4-amd64_6.4.13-1, and I have confirmed that this bug is fixed 
 on this version.

Bug#999458: zynaddsubfx: Feature Request: Integration of Zyn-fusion (new GUI)

[Olivier Humbert]

Hi all,
I'm adding some information here.



By the way, some people tell that Zyn-fusion is not working well (see
messages on
http://lists.sourceforge.net/mailman/listinfo/zynaddsubfx-user).
I didn't test it myself but upgrading to Zyn-fusion does not seem to
be a priority.


Caution here, if I'm not wrong, the upstream developement is on 
Zyn-Fusion rather than the oldish-GUI.
Hence a few new features are only usable in the zyn-fusion GUI which can 
make it a priority.




Another solution (if possible): compile two versions of zynaddsubfx,
the "old" interface and the new one (zyn-fusion).


Agreed here, that would be the best solution.

Bye all and take care.
Olivier

Bug#1051146: rust-laurel, upcoming rust-bindgen update.

[Peter Michael Green]

On 03/09/2023 14:58, Peter Michael Green wrote:


The attatched debdiff,

Sorry, really attached nowdiff -Nru rust-laurel-0.5.3/debian/changelog rust-laurel-0.5.3/debian/changelog
--- rust-laurel-0.5.3/debian/changelog  2023-07-18 14:26:32.0 +
+++ rust-laurel-0.5.3/debian/changelog  2023-09-02 17:04:14.0 +
@@ -1,3 +1,10 @@
+rust-laurel (0.5.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove upper limit from bindgen dependency.
+
+ -- Peter Michael Green   Sat, 02 Sep 2023 17:04:14 +
+
 rust-laurel (0.5.3-1) unstable; urgency=medium
 
   * New upstream version 0.5.3
diff -Nru rust-laurel-0.5.3/debian/control rust-laurel-0.5.3/debian/control
--- rust-laurel-0.5.3/debian/control2023-07-18 14:26:05.0 +
+++ rust-laurel-0.5.3/debian/control2023-09-02 17:01:16.0 +
@@ -6,7 +6,7 @@
  cargo:native,
  rustc:native,
  libstd-rust-dev,
- librust-bindgen-0.60+default-dev,
+ librust-bindgen+default-dev (>= 0.60),
  librust-caps-0.5+default-dev,
  librust-exacl+default-dev (>= 0.6-~~),
  librust-getopts-0.2+default-dev,
diff -Nru rust-laurel-0.5.3/debian/patches/fix-deps.patch 
rust-laurel-0.5.3/debian/patches/fix-deps.patch
--- rust-laurel-0.5.3/debian/patches/fix-deps.patch 2023-07-18 
14:04:16.0 +
+++ rust-laurel-0.5.3/debian/patches/fix-deps.patch 2023-09-02 
17:03:46.0 +
@@ -1,7 +1,7 @@
-Index: rust-laurel/Cargo.toml
+Index: rust-laurel-0.5.3/Cargo.toml
 ===
 rust-laurel.orig/Cargo.toml
-+++ rust-laurel/Cargo.toml
+--- rust-laurel-0.5.3.orig/Cargo.toml
 rust-laurel-0.5.3/Cargo.toml
 @@ -62,7 +62,7 @@ version = "0.2"
  version = "0.4"
  
@@ -11,3 +11,12 @@
  
  [dependencies.nom]
  version = "7"
+@@ -101,7 +101,7 @@ version = "0"
+ version = "0"
+ 
+ [build-dependencies.bindgen]
+-version = "0.60"
++version = ">= 0.60"
+ 
+ [badges.maintenance]
+ status = "actively-developed"

Bug#1051147: gnome-color-manager: profiles not working correctly (regression)

[g]

Package: gnome-color-manager
Version: 3.36.0-1+b1
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where
appropriate ***
Profiles don't get loaded up , also same profile can't apply to 2
monitors. (have 4)
   * What led up to the situation?
upgrade to bookworm (working flawlessly before)
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
EFFECTIVE: unload/reload profiles for each screen
make profile clones
   * What was the outcome of this action?
   * What outcome did you expect instead?
Work OOthe box liuke it used to
*** End of the template - remove these template lines ***


-- 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-10-amd64 (SMP w/16 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 gnome-color-manager depends on:
ii  colord   1.4.6-2.2
ii  libc6    2.36-9+deb12u1
ii  libcairo2    1.16.0-7
ii  libcolord2   1.4.6-2.2
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  liblcms2-2   2.14-2
ii  libpango-1.0-0   1.50.12+ds-1

gnome-color-manager recommends no packages.

gnome-color-manager suggests no packages.

-- no debconf information

Bug#1051146: rust-laurel, upcoming rust-bindgen update.

[Peter Michael Green]

Package: rust-laurel
Version: 0.5.3-1

In the rust team we are working on upgrading rust-bindgen from 0.60 to
0.66, there are a few reasons for this. Firstly it's part of the 
dependency stack
for the new version of rust-cargo. Secondly the version currently in sid 
has a
compatibility issue with new versions of llvm. Thirdly Jonas has filed a 
bug report

requesting the new upstream version.

bindgen bumps semver on most releases, however the changes tend to be
relatively minor. You can read the changelog at
https://github.com/rust-lang/rust-bindgen/blob/main/CHANGELOG.md#0610
but I don't see anything too scary in there.

The new version of rust-bindgen has been uploaded to experimental so people
can test against it. After bumping the dependencies your package built
successfully. Unfortunately your package doesn't seem to have any 
autopkgtests.


The attatched debdiff, removes the upper limit from the bindgen dependency,
(similar to how you have already removed the upper limit from the nix 
dependency)
given the history of the bindgen package I think this is a sensible way 
forward

OTOH if you would preffer to simply bump the dependency when the new
bindgen is uploaded that would be fine too.

Bug#994081: libdvd-pkg: 1.4.3-1-1 Upgrade Results in 'apt-get check' Failure

[Cecil Westerhof]

On Tue, 13 Jun 2023 00:11:16 +0200 Alban Browaeys  wrote:
> Package: libdvd-pkg
> Version: 1.4.3-1-1
> Followup-For: Bug #994081
>
> Dear Maintainer,
> TL;DR: could apt-get be called with "--dry-run" a flag when we call its
> "check" command as to get libdvd-pkg triggers script to run?

Why is nothing done with this? Even if it just would have been: this is no
solution because --dry-run does not what needs to be done?
I just switched to Debian 12 from 11 and ran into this issue. And when I
saw that the issue was about two years old I was flabbergasted: I am used
to the high quality of Debian.

I made in /usr/lib/libdvd-pkg/b-i_libdvdcss.sh the following change:
#  added ry-run and /dev/null redirection removed
apt-get check --dry-run # >/dev/null 2>&1

I am now waiting until my system needs an upgrade to see the result from
this change.
I will share it when I have it.

Bug#1051145: nfs4-acl-tools: all manuals point to nf...@linux-nfs.org, which upstream describes as defunct

[наб]

Package: nfs4-acl-tools
Version: 0.3.7-1
Severity: normal

Dear Maintainer,

All manuals have a
-- >8 --
CONTACT
   Please send bug reports, feature requests, and comments to 
.
-- >8 --
stanza, but http://linux-nfs.org/wiki/index.php/Main_Page says 
-- >8 --
 Mailing lists:
linux-...@vger.kernel.org (archive)
linux-fsde...@vger.kernel.org (archive)
linux-ker...@vger.kernel.org (archive)
defunct pnfs list archive
defunct nfsv4 list archive 
-- >8 --
(the nfsv4 and pnfs archives are 404s as well, so that's cool)
so this should probably be a link to linux-nfs.org and a mailto
.

-- 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)
Foreign Architectures: i386

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

Versions of packages nfs4-acl-tools depends on:
ii  libc6  2.36-9+deb12u1

nfs4-acl-tools recommends no packages.

nfs4-acl-tools suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1051144: reportbug: tex-common fails to install due to fmtutil error

[Philip Armstrong]

Package: tex-common
Version: 6.18
Severity: normal

Output of apt:

Setting up tex-common (6.18) ...
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time... 
fmtutil failed. Output has been stored in
/tmp/fmtutil.Jzo9pPaf
Please include this file if you report a bug.

/tmp/fmtutil.Jzo9pPaf contains the following:
---
fmtutil [ERROR]: no (or empty) hitex.fmt made by: hitex -ini   -jobname=hitex 
-progname=hitex -etex -ltx hitex.ini  
   p
 p
refer
 
   e
l.48 prefere
d 0
? 
! Emergency stop.
 
   p
 p
refer
 
   e
l.48 prefere
d 0
Transcript written on hitex.log.
--

Looking at /usr/share/texlive/texmf-dist/tex/hitex/base/hiplainpage.tex & 
diffing it with the
version at CTAN, it seems that the latter spells the word in question as 
“preferred”.

If I edit prefered -> preferred in the Debian file, the install completes 
successfully.

cheers,

Phil


dpkg: error processing package tex-common (--configure):
 installed tex-common package post-installation script subprocess returned 
error exit status 1


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

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

Versions of packages tex-common depends on:
ii  ucf  3.0043+nmu1

tex-common recommends no packages.

Versions of packages tex-common suggests:
ii  debhelper  13.11.6

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libpaper-utils 1.1.29
ii  sensible-utils 0.0.20
ii  texlive-binaries   2023.20230311.66589-3
ii  ucf3.0043+nmu1
ii  xdg-utils  1.1.3-4.1

Versions of packages texlive-base recommends:
ii  lmodern  2.005-1

Versions of packages texlive-base suggests:
ii  evince [postscript-viewer]   45~alpha-2
ii  ghostscript [postscript-viewer]  10.01.2~dfsg-1
ii  gv [postscript-viewer]   1:3.7.4-2+b1
ii  perl-tk  1:804.036-1+b2
pn  xpdf | pdf-viewer
pn  xzdec

Versions of packages texlive-binaries depends on:
ii  libc6   2.37-7
ii  libcairo2   1.16.0-7
ii  libfontconfig1  2.14.2-4
ii  libfreetype62.13.2+dfsg-1
ii  libgcc-s1   13.2.0-2
ii  libgraphite2-3  1.3.14-1
ii  libharfbuzz0b   8.0.1-1
ii  libicu7272.1-3
ii  libkpathsea62023.20230311.66589-3
ii  libmpfr64.2.0-1
ii  libpaper1   1.1.29
ii  libpixman-1-0   0.42.2-1
ii  libpng16-16 1.6.40-1
ii  libpotrace0 1.16-2
ii  libptexenc1 2023.20230311.66589-3
ii  libstdc++6  13.2.0-2
ii  libsynctex2 2023.20230311.66589-3
ii  libteckit0  2.5.11+ds1-1+b1
ii  libtexlua53-5   2023.20230311.66589-3
ii  libtexluajit2   2023.20230311.66589-3
ii  libx11-62:1.8.6-1
ii  libxaw7 2:1.0.14-1
ii  libxi6  2:1.8-1+b1
ii  libxmu6 2:1.1.3-3
ii  libxpm4 1:3.5.12-1.1
ii  libxt6  1:1.2.1-1.1
ii  libzzip-0-130.13.72+dfsg.1-1.1
ii  perl5.36.0-7
ii  t1utils 1.41-4
ii  zlib1g  1:1.2.13.dfsg-3

Versions of packages texlive-binaries recommends:
ii  dvisvgm   3.1-1
ii  texlive-base  2022.20230122-3

-- debconf information:
  texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi
  texlive-base/texconfig_ignorant:

Bug#1051087: reportbug: linux-headers-amd64 from bullseye-backports cannot be installed (unmet dependencies)

[Laurent BRULET]

Package: linux-headers-amd64
Followup-For: Bug #1051087
X-Debbugs-Cc: spm-deb...@lebernie.net

Dear Maintainer,

Thank you for this clarification, this is much clearer now.

Regards,

LB.

Bug#1051143: bookworm-pu: package dput-ng/1.35+deb12u1

[Mattia Rizzolo]

Package: release.debian.org
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: dput...@packages.debian.org
Control: affects -1 + src:dput-ng


[ Reason ]

Fix FTBFS.
Allow upload to bookworm-backports from bookworm hosts.

[ Tests ]
Both automated and manual tests 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

[ Other info ]
I will find a way to fix this time bomb once and for all during this
cycle, since this was postponed several times in the last half decade…


Also, I already uploaded this package.

-- 
regards,
Mattia Rizzolo

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

 debian/changelog |   14 ++
 debian/control   |2 +-
 debian/gbp.conf  |1 +
 skel/codenames/debian.json   |   15 ++-
 tests/dputng/codenames/debian.json   |   15 ++-
 tests/fake_package/fake-package-1.0/debian/changelog |2 +-
 tests/fake_package/fake-package-1.1/debian/changelog |2 +-
 7 files changed, 38 insertions(+), 13 deletions(-)

diff -Nru dput-ng-1.35/debian/changelog dput-ng-1.35+deb12u1/debian/changelog
--- dput-ng-1.35/debian/changelog	2022-08-29 15:11:49.0 +0530
+++ dput-ng-1.35+deb12u1/debian/changelog	2023-09-03 18:26:54.0 +0530
@@ -1,3 +1,17 @@
+dput-ng (1.35+deb12u1) bookworm; urgency=medium
+
+  * Team upload.
+
+  [ Mattia Rizzolo ]
+  * Update codenames of allowed upload targets.  Closes: #1051142
+Add bookworm-backports, bullseye-backports-sloppy, and trixie.
+
+  [ Gianfranco Costamagna ]
+  * Fix FTBFS due to time bomb, move from bionic to jammy in test fixtures,
+also postpone another time bomb due to focal.  Closes: #1042271
+
+ -- Mattia Rizzolo   Sun, 03 Sep 2023 18:26:54 +0530
+
 dput-ng (1.35) unstable; urgency=medium
 
   [ Stefano Rivera ]
diff -Nru dput-ng-1.35/debian/control dput-ng-1.35+deb12u1/debian/control
--- dput-ng-1.35/debian/control	2022-08-29 15:11:49.0 +0530
+++ dput-ng-1.35+deb12u1/debian/control	2023-09-03 18:26:42.0 +0530
@@ -28,7 +28,7 @@
 Standards-Version: 4.6.0
 Rules-Requires-Root: no
 Vcs-Browser: https://salsa.debian.org/debian/dput-ng
-Vcs-Git: https://salsa.debian.org/debian/dput-ng.git
+Vcs-Git: https://salsa.debian.org/debian/dput-ng.git -b bookworm
 Homepage: https://debian.pages.debian.net/dput-ng
 
 Package: dput-ng
diff -Nru dput-ng-1.35/debian/gbp.conf dput-ng-1.35+deb12u1/debian/gbp.conf
--- dput-ng-1.35/debian/gbp.conf	2019-07-19 11:46:20.0 +0530
+++ dput-ng-1.35+deb12u1/debian/gbp.conf	2023-09-03 18:26:52.0 +0530
@@ -1,3 +1,4 @@
 [DEFAULT]
 pristine-tar = True
 debian-tag = %(version)s
+debian-branch = bookworm
diff -Nru dput-ng-1.35/skel/codenames/debian.json dput-ng-1.35+deb12u1/skel/codenames/debian.json
--- dput-ng-1.35/skel/codenames/debian.json	2021-06-24 19:01:59.0 +0530
+++ dput-ng-1.35+deb12u1/skel/codenames/debian.json	2023-09-03 18:22:51.0 +0530
@@ -2,7 +2,9 @@
 "backport": [
 "stable-backports",
 "oldstable-backports",
+"bookworm-backports",
 "bullseye-backports",
+"bullseye-backports-sloppy",
 "buster-backports",
 "buster-backports-sloppy",
 "stretch-backports",
@@ -18,6 +20,11 @@
 "testing",
 "stable",
 "oldstable",
+"testing-proposed-updates",
+"stable-proposed-updates",
+"oldstable-proposed-updates",
+"trixie",
+"trixie-proposed-updates",
 "bookworm",
 "bookworm-proposed-updates",
 "bullseye",
@@ -27,10 +34,7 @@
 "stretch",
 "stretch-proposed-updates",
 "jessie",
-"jessie-proposed-updates",
-"testing-proposed-updates",
-"stable-proposed-updates",
-"oldstable-proposed-updates"
+"jessie-proposed-updates"
 ],
 "security": [
 "testing-security",
@@ -40,7 +44,8 @@
 "stretch-security",
 "buster-security",
 "bullseye-security",
-"bookworm-security"
+"bookworm-security",
+"trixie-security"
 ],
 "ports": [
 "unreleased"
diff -Nru dput-ng-1.35/tests/dputng/codenames/debian.json dput-ng-1.35+deb12u1/tests/dputng/codenames/debian.json
--- dput-ng-1.35/tests/dputng/codenames/debian.json	2021-06-24 19:01:59.0 +0530
+++ dput-ng-1.35+deb12u1/tests/dputng/codenames/debian.json	

Bug#1051142: bookworm dput-ng does not know about bookworm-backports

[Lee Garrett]

Package: dput-ng
Version: 1.35
Severity: important
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

when trying to upload a package to bookworm-backports, it's impossible to do
with dput-ng from bookworm:

$ dput rhsrvany_1.1-2~bpo12+1_source.changes
Uploading rhsrvany using ftp to ftp-master (host: ftp.upload.debian.org; 
directory: /pub/UploadQueue/)
running allowed-distribution: check whether a local profile permits uploads to 
the target distribution
`bookworm-backports' not in the codename group

It would be nice if dput-ng would know about bookworm-backports.

Greetings,
Lee

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

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

Versions of packages dput-ng depends on:
ii  python3   3.11.2-1+b1
ii  python3-dput  1.35

dput-ng recommends no packages.

Versions of packages dput-ng suggests:
ii  dput-ng-doc  1.35
pn  python3-twitter  

-- no debconf information

Bug#1047929: irclog2html: Fails to build source after successful build

[Mattia Rizzolo]

Control: tag -1 unreproducible

On Sun, Aug 13, 2023 at 09:20:48PM +0200, Lucas Nussbaum wrote:
> This package fails to build a source package after a successful build
> (dpkg-buildpackage ; dpkg-buildpackage -S).
> 
> This is probably a clear violation of Debian Policy section 4.9 (clean 
> target),
> but this is filed as severity:minor for now, because a discussion on
> debian-devel showed that we might want to revisit the requirement of a working
> 'clean' target.
> 
> More information about this class of issues, included common problems and
> solutions, is available at
> https://wiki.debian.org/qa.debian.org/FTBFS/SourceAfterBuild

I tried to reproduce this with `pbuilder b --twice`, as well as to
manually run `dpkg-buildpackage ; dpkg-buildpackage -S`, but I can
rebuild this without issue.

> > dpkg-source: info: using options from 
> > irclog2html-2.17.3/debian/source/options: 
> > --extend-diff-ignore=^[^/]src/*[.]egg-info/
> > dpkg-source: info: using source format '3.0 (quilt)'
> > dpkg-source: info: building irclog2html using existing 
> > ./irclog2html_2.17.3.orig.tar.gz
> > dpkg-source: warning: file 
> > irclog2html-2.17.3/src/irclog2html.egg-info/entry_points.txt has no final 
> > newline (either original or modified version)
> > dpkg-source: info: local changes detected, the modified files are:
> >  irclog2html-2.17.3/src/irclog2html.egg-info/PKG-INFO
> >  irclog2html-2.17.3/src/irclog2html.egg-info/entry_points.txt
> > dpkg-source: error: aborting due to unexpected upstream changes, see 
> > /tmp/irclog2html_2.17.3-2.diff.5hNGFY


I'm confused, as also the log mentions that this is using
--extend-diff-ignore.

Could you please try to reproduce this again?

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature