Bug#1012987: libpodofo: ftbfs with GCC-12

[yokota]

Hi Nicholas

> It looks like the a "Source" or "Forwarded" DEP3 header with a link to
> Pino's pull request is missing.
>   https://dep-team.pages.debian.net/deps/dep3

I was updated my salsa merge request.
  https://salsa.debian.org/debian/libpodofo/-/merge_requests/2

--
YOKOTA Hiroshi

Bug#1017586: RMs modifications for nrepl-clojure

[Louis-Philippe Véronneau]

retitle 1017586 RM: ROM, libnrepl-clojure [i386 armhf armel ppc64el s390x] -- 
ANAIS; No longer built
user 1017586 ftp.debian@packages.debian.org
usertags 1017586 + remove
thanks

Hi,

Renaming this bug report and tagging it properly, as per recommendations
of people on #debian-qa.

Note that I've added s390x to the list of arches to remove, as 0.9.0-6 only 
builds
on amd64 and arm64.

Cheers,

--
   ⢀⣴⠾⠻⢶⣦⠀
   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
   ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
   ⠈⠳⣄



OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017772: GCC-12 internal error when compiling onetbb on ppc64el

[M. Zhou]

Package: gcc-12
Version: 12.1.0-8
Severity: important

This bug seems like a regression. GCC-11 has no issue compiling the same source.

https://buildd.debian.org/status/fetch.php?pkg=onetbb=ppc64el=2021.5.0-13=1660844413=0

[183/315] : && /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now-rdynamic 
test/CMakeFiles/test_join_node.dir/tbb/test_join_node.cpp.o -o 
gnu_12.1_cxx11_64_none/test_join_node  
-Wl,-rpath,/<>/obj-powerpc64le-linux-gnu/gnu_12.1_cxx11_64_none  
gnu_12.1_cxx11_64_none/libtbb.so.12.5  -ldl && :
FAILED: gnu_12.1_cxx11_64_none/test_join_node 
: && /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now-rdynamic 
test/CMakeFiles/test_join_node.dir/tbb/test_join_node.cpp.o -o 
gnu_12.1_cxx11_64_none/test_join_node  
-Wl,-rpath,/<>/obj-powerpc64le-linux-gnu/gnu_12.1_cxx11_64_none  
gnu_12.1_cxx11_64_none/libtbb.so.12.5  -ldl && :
/usr/bin/ld: internal error ../../ld/ldlang.c 6452
collect2: error: ld returned 1 exit status

Bug#1016754: po4a: Incorrect bold handling for manpages bug 2

[Helge Kreutzmann]

Hello Martin,
On Sat, Aug 20, 2022 at 02:25:36AM +0200, Martin Quinson wrote:
> thanks for the additional info. 
> 
> Could you please try to reduce the files to simplify my debugging effort? 
> It'd be great if you could come up with a file as simple as possible, ie, one 
> short paragraph only if possible, and using UPPERCASE as a translation 
> instead of german. We have a lot of such files in our test suite. Search for 
> example for .man, .pot, .po and .trans files eg in t/fmt/man. (.norm is the 
> normalized file, ie the file after po4a parsing but with no translation while 
> .trans is the translated file, using the po file).
> 
> That would be really precious to me.

I'll try, however, it might take some time.

Greetings

 Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1017771: gridengine: ftbfs on riscv64 ("Unsupported architecture UNSUPPORTED-lx-riscv64")

[Bo YU]

Source: gridengine
Version: 8.1.9+dfsg-10
Severity: normal
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear gridengine Maintainer,

The package has a ftbfs issue on riscv64 due to missing support riscv64:

```
...
Unsupported architecture UNSUPPORTED-lx-riscv64
Now run ./aimk with any appropriate options (see ./aimk -help)
Unsupported architecture UNSUPPORTED-lx-riscv64
make[1]: *** [debian/rules:37: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:34: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2
```

The patch attached is trying to add support for riscv64 and I can
confirm it is ok to build on my locally real riscv64 hardware.Could 
you apply it in the next upload?

Any issues please let me know, thanks.

-- 
Regards,
--
  Bo YU

Description: add support riscv64
Author: Bo YU 
Forwarded: no
Last-Update: 2022-08-20 
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/source/aimk
+++ b/source/aimk
@@ -1974,6 +1974,9 @@
 set JAVA_LIB_ARCH = aarch64
  endif
  breaksw
+	 case lx-riscv64:
+	  set JAVA_LIB_ARCH = riscv64
+	  breaksw
 	 case lx-mips64:
 	  set JAVA_LIB_ARCH = mips64el
 	  breaksw
--- a/source/dist/util/arch
+++ b/source/dist/util/arch
@@ -219,6 +219,9 @@
powerpc64le | powerpc64el)
   lxmachine=ppc64el
   ;;
+   riscv64)
+  lxmachine=riscv64
+  ;;
*)
   unsupported="UNSUPPORTED-"
   lxmachine=$osmachine
--- a/source/scripts/compilearch
+++ b/source/scripts/compilearch
@@ -220,6 +220,11 @@
   COMPILE_ARCH=LINUXPPC64EL
   TARGET_BITS=TARGET_64BIT
   ;;
+   lx-riscv64)
+  BUILDARCH=LINUXRISCV64
+  COMPILE_ARCH=LINUXRISCV64
+  TARGET_BITS=TARGET_64BITT
+  ;;
lx-s390)
   BUILDARCH=LINUXS390
   COMPILE_ARCH=LINUXS390


signature.asc
Description: PGP signature

Bug#1017770: zutils: dpkg-divert: warning: diverting file '/bin/zcat' from an Essential package with rename is dangerous, use --no-rename

[Paul Wise]

Package: zutils
Version: 1.11-5
Severity: normal
Usertags: warnings

Installing zutils results in some warnings from dpkg-divert, it sounds
like the dpkg-divert rename option should not be used for diverting
essential packages, since it means the binaries disappear temporarily.

I'm not sure what the right solution is, but at a guess, copy the gzip
version to its diverted name, let dpkg unpack the zutils version over
the gzip version and then add the diversion to the dpkg database.

$ sudo apt install zutils
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  zutils
0 upgraded, 1 newly installed, 0 to remove and 13 not upgraded.
Need to get 508 kB of archives.
After this operation, 4,699 kB of additional disk space will be used.
Get:1 https://deb.debian.org/debian testing/main amd64 zutils amd64 1.11-5 [508 
kB]
Fetched 508 kB in 2s (293 kB/s) 
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Selecting previously unselected package zutils.
(Reading database ... 685697 files and directories currently installed.)
Preparing to unpack .../zutils_1.11-5_amd64.deb ...
dpkg-divert: warning: diverting file '/bin/zcat' from an Essential package with 
rename is dangerous, use --no-rename
dpkg-divert: warning: diverting file '/usr/share/man/man1/zcat.1.gz' from an 
Essential package with rename is dangerous, use --no-rename
dpkg-divert: warning: diverting file '/bin/zcmp' from an Essential package with 
rename is dangerous, use --no-rename
dpkg-divert: warning: diverting file '/usr/share/man/man1/zcmp.1.gz' from an 
Essential package with rename is dangerous, use --no-rename
dpkg-divert: warning: diverting file '/bin/zdiff' from an Essential package 
with rename is dangerous, use --no-rename
dpkg-divert: warning: diverting file '/usr/share/man/man1/zdiff.1.gz' from an 
Essential package with rename is dangerous, use --no-rename
dpkg-divert: warning: diverting file '/bin/zegrep' from an Essential package 
with rename is dangerous, use --no-rename
dpkg-divert: warning: diverting file '/usr/share/man/man1/zegrep.1.gz' from an 
Essential package with rename is dangerous, use --no-rename
dpkg-divert: warning: diverting file '/bin/zfgrep' from an Essential package 
with rename is dangerous, use --no-rename
dpkg-divert: warning: diverting file '/usr/share/man/man1/zfgrep.1.gz' from an 
Essential package with rename is dangerous, use --no-rename
dpkg-divert: warning: diverting file '/bin/zgrep' from an Essential package 
with rename is dangerous, use --no-rename
dpkg-divert: warning: diverting file '/usr/share/man/man1/zgrep.1.gz' from an 
Essential package with rename is dangerous, use --no-rename
Unpacking zutils (1.11-5) ...
Setting up zutils (1.11-5) ...
Processing triggers for install-info (6.8-6) ...
Processing triggers for man-db (2.10.2-1) ...

$ dpkg-divert --help | grep rename
  --rename actually move the file aside (or back).
  --no-rename  do not move the file aside (or back) (default).

$ export COLUMNS=80 ; man dpkg-divert | grep -A7 -- -rename$
   --rename
   Actually move the file aside (or back). dpkg-divert will abort
   operation in case the destination file already exists.  This is the
   common behavior used for diversions of files from the non-Essential
   package set (see --no-rename for more details).

   --no-rename
   Specifies that the file should not be renamed while adding or
   removing the diversion into the database (since dpkg 1.19.1).  This
   is intended for diversions of files from the Essential package set,
   where the temporary disappearance of the original file is not
   acceptable, as it can render the system non-functional.  This is
   the default behavior, but that will change in the dpkg 1.20.x
   cycle.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages zutils depends on:
ii  libc6   2.34-3
ii  libgcc-s1   12.1.0-8
ii  libstdc++6  12.1.0-8

Versions of packages zutils recommends:
ii  bzip2 1.0.8-5
ii  lzip  1.23-4
ii  xz-utils  5.2.5-2.1
ii  zstd  1.5.2+dfsg-1

zutils suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#983146: 983146 RFS: bung/3.2.6-3 [ITP] -- backup next generation

[Charles]

Dear Bastian

Regards "Please use the *.source.tgz as source instead of 
*.source_with_htm_and_pdf.tgz", I assume you refer to the files at 
https://github.com/CharlesMAtkinson/bung/releases/tag/3.2.6.  If that is 
not correct, please correct my assumption and disregard the rest of this 
mail.


Regards "You should then export and install the .htm as documentation 
automatically", when and where do you want that automation to happen?


In case you wanted it to be done while installing the .deb, it is not 
possible.  The .htm files are created from .odt files using soffice from 
package libreoffice-common.  Package libreoffice-common may not be 
installed on computers where the .deb will be installed.  There is no 
way to create .htm files from .odt files on all computers where the .deb 
will be installed


Best

Charles

Bug#1017720: nfs-common: No such file or directory

[Jason Breitman]

> -Original Message-
> From: Ben Hutchings 
> Sent: Friday, August 19, 2022 7:27 PM
> To: Jason Breitman ;
> 1017...@bugs.debian.org
> Subject: Re: Bug#1017720: nfs-common: No such file or directory
> 
> Control: tag -1 moreinfo
> 
> On Fri, 2022-08-19 at 13:16 +, Jason Breitman wrote:
> > Package: nfs-common
> > Version: 1:1.3.4-6
> > Severity: important
> >
> > Kernel: 5.10.0-16-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30) x86_64
> > GNU/Linux
> >
> > -- Description
> > After updating and or creating new files on our file server via
> > rsync, we see many files report the error message below from NFSv4
> > clients since upgrading from Debian 10.8 to Debian 11.4.
> > Clearing the dentry cache resolves the issue right away.
> > I am not sure that nfs-common is the package to blame, but listed
> > it based on the bug submission recommendations.
> 
> The NFS implementation is mostly in the kernel, so probably this issue
> belongs there.  But the kernel team is responsible for both packages.
> 
> [...]
> > -- Error message
> > ls: cannot access 'filename': No such file or directory
> > -? ? ???? filename
> [...]
> 
> So we know the file's there but can't stat it.  I think this means the
> client has cached the handle of the old file of that name, which has
> been deleted.
> 
> - Are client and server clocks closely synchronised?  If not, that
> needs to be fixed.
> 
The clocks are synchronized using NTP.  

> - Are clients likely to read this directory while rsync is running, or
> shortly before?  If so, it may help to reduce the attribute caching
> timeout on the client.  See the "Directory entry caching" section in
> the nfs(5) manual page.
>
Clients are not likely to read this directory while rsync is running for the 
observed cases.  That can happen in our environment, but not in this case.
I am using the lookupcache=pos option.  I tried noac, but the performance 
penalty was too much.  Which option are you referring to and what setting do 
you recommend testing?

> I don't know why you're only seeing this after an upgrade of the
> clients, though.  I'm not aware that there has been any big change to
> attribute caching.
> 
I appreciate you responding to my report and am happy to answer any questions.
We have multiple monitors and log scrapers to detect "file not found" 
exceptions that would let us know if this was happening before.
To share more, I have 2 environments mounting from the same file server.  Each 
environment has several servers.  The issue is only seen in the environment 
running Debian 11.4.
I also should have mentioned that the files in question have a version number 
appended.  filename-.  When the file is updated via rsync, it is called 
filename-1112 and the prior file is removed.  The error is about filename-.
I am not sure if this is the proper terminology, but the issue appears to be 
the negative dentry cache.

> Ben.
> 
> --
> Ben Hutchings
> Beware of bugs in the above code;
> I have only proved it correct, not tried it. - Donald Knuth

Jason Breitman

Bug#1004221: reportbug: automatically add usertags for ftp.debian.org bugs

[Sean Whitton]

Hello,

On Sat 22 Jan 2022 at 09:21PM -05, Sandro Tosi wrote:

>
> Hey Paul,
>
> On Sat, Jan 22, 2022 at 8:45 PM Paul Wise  wrote:
>>
>> Package: reportbug
>> Version: 11.2.0
>> Severity: wishlist
>> X-Debbugs-CC: ftp.debian@packages.debian.org
>> Control: affects -1 ftp.debian@packages.debian.org
>>
>> When filing bugs against ftp.debian.org there is a menu
>> asking what kind of request the bug report is about:
>>
>> 1 ANAIS Package removal - Architecture Not Allowed In Source.
>> 2 ICE   Package removal - Internal Compiler Error.
>> 3 NBS   Package removal - Not Built [by] Source.
>> 4 NPOASRPackage removal - Never Part Of A Stable Release.
>> 5 NVIU  Package removal - Newer Version In Unstable.
>> 6 ROM   Package removal - Request Of Maintainer.
>> 7 ROP   Package removal - Request of Porter.
>> 8 RoQA  Package removal - Requested by the QA team.
>> 9 other Not a package removal request, report other problems.
>>10 override  Change override request.
>>
>> Currently reportbug doesn't add removal usertags, which means people
>> try to do it and then often they get it wrong, many use rm or removal
>> instead of remove for example or make typos like remvoe or similar.
>>
>> Please add these usertags for Package removal requests:
>>
>>User: ftp.debian@packages.debian.org
>>Usertags: remove
>
> no disrespect, according to https://ftp-master.debian.org/ you are not
> part of the FTP master team; we would really like the input from that
> team (CC'ed) on how to structure this: after all, these packages are
> coded for their consumption, and we should do what makes their work
> easier.

I don't believe any of our scripts for removals care about usertags,
just bug subjects, so it seems fine to trust the existing tags the BTS
knows about, as demonstrated by Paul's rsync commands.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1016754: po4a: Incorrect bold handling for manpages bug 2

[Martin Quinson]

Hello Helge,

thanks for the additional info. 

Could you please try to reduce the files to simplify my debugging effort? It'd 
be great if you could come up with a file as simple as possible, ie, one short 
paragraph only if possible, and using UPPERCASE as a translation instead of 
german. We have a lot of such files in our test suite. Search for example for 
.man, .pot, .po and .trans files eg in t/fmt/man. (.norm is the normalized 
file, ie the file after po4a parsing but with no translation while .trans is 
the translated file, using the po file).

That would be really precious to me.

Thanks in advance,
Mt

Bug#1017769: man-db: Uses setpriv which seems to be Linux-only

[Colin Watson]

On Sat, Aug 20, 2022 at 01:35:54AM +0200, Guillem Jover wrote:
> The man-db package seems to have switched from start-stop-daemon to
> setpriv, but the latter seems to be Linux-only. On a hurd-i386 box I
> see the following now:
> 
>   Processing triggers for man-db (2.10.2-2) ...
>   /var/lib/dpkg/info/man-db.postinst: 22: setpriv: not found

Bother.  Do you know of a portable replacement, or do I have to add a
fallback to perl?  I was hoping to avoid the latter, especially since
setpriv is clearly simpler.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1017769: man-db: Uses setpriv which seems to be Linux-only

[Guillem Jover]

Package: man-db
Version: 2.10.2-2
Severity: normal

Hi!

The man-db package seems to have switched from start-stop-daemon to
setpriv, but the latter seems to be Linux-only. On a hurd-i386 box I
see the following now:

  Processing triggers for man-db (2.10.2-2) ...
  /var/lib/dpkg/info/man-db.postinst: 22: setpriv: not found

Thanks,
Guillem

Bug#1017441: debhelper: building src:shadow wrongly makes passwd depend on systemd | systemd-tmpfiles

[Colin Watson]

On Sat, Aug 20, 2022 at 12:17:01AM +0100, Luca Boccassi wrote:
> On Sat, 20 Aug 2022 at 00:09, Colin Watson  wrote:
> > On Fri, Aug 19, 2022 at 11:55:25PM +0100, Luca Boccassi wrote:
> > > Shipping files in /var in a package is a bug though, and it really
> > > needs to be fixed. So it sounds like in this case a dependency is
> > > indeed the right thing, given presence of the directory in /var is
> > > necessary?
> >
> > No.  The actual FHS requirement is that the application must be able to
> > recover from deletion of files under /var/cache.  The only part of the
> > package that I consider to be truly critical is man(1) itself, and that
> > continues to work just fine for most purposes even when /var/cache/man
> > has been entirely removed.  While mandb(8) will fail, that isn't fatal
> > to the operation of the package; it will merely be somewhat degraded.
> 
> Yes. Variable state data != fixed and checksummed content of a binary
> package that fails a package integrity validation check if removed.

I'm not going to discuss this further in this bug.  The debhelper
maintainer can judge my suggestion on its merits.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1017720: nfs-common: No such file or directory

[Ben Hutchings]

Control: tag -1 moreinfo

On Fri, 2022-08-19 at 13:16 +, Jason Breitman wrote:
> Package: nfs-common
> Version: 1:1.3.4-6
> Severity: important
> 
> Kernel: 5.10.0-16-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30) x86_64
> GNU/Linux
> 
> -- Description
> After updating and or creating new files on our file server via
> rsync, we see many files report the error message below from NFSv4
> clients since upgrading from Debian 10.8 to Debian 11.4.
> Clearing the dentry cache resolves the issue right away.
> I am not sure that nfs-common is the package to blame, but listed
> it based on the bug submission recommendations. 

The NFS implementation is mostly in the kernel, so probably this issue
belongs there.  But the kernel team is responsible for both packages.

[...]
> -- Error message
> ls: cannot access 'filename': No such file or directory
> -? ? ???? filename
[...]

So we know the file's there but can't stat it.  I think this means the
client has cached the handle of the old file of that name, which has
been deleted.

- Are client and server clocks closely synchronised?  If not, that
needs to be fixed.

- Are clients likely to read this directory while rsync is running, or
shortly before?  If so, it may help to reduce the attribute caching
timeout on the client.  See the "Directory entry caching" section in
the nfs(5) manual page.

I don't know why you're only seeing this after an upgrade of the
clients, though.  I'm not aware that there has been any big change to
attribute caching.

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth


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

Bug#1017441: debhelper: building src:shadow wrongly makes passwd depend on systemd | systemd-tmpfiles

[Luca Boccassi]

On Sat, 20 Aug 2022 at 00:09, Colin Watson  wrote:
>
> On Fri, Aug 19, 2022 at 11:55:25PM +0100, Luca Boccassi wrote:
> > On Fri, 19 Aug 2022 at 23:43, Colin Watson  wrote:
> > > I just had my attention drawn to this bug because a man-db upload
> > > unexpectedly (to me) gained a dependency on systemd | systemd-tmpfiles,
> > > thus adding to the build-essential set.  /usr/lib/tmpfiles.d/man-db.conf
> > > reads:
> > >
> > >   d /var/cache/man 0755 man man 1w
> > >
> > > This line exists only for cleanup purposes; the directory is also
> > > shipped in the package with matching ownership and permissions, so
> > > man-db clearly doesn't rely on tmpfiles for creating that directory.
> >
> > Shipping files in /var in a package is a bug though, and it really
> > needs to be fixed. So it sounds like in this case a dependency is
> > indeed the right thing, given presence of the directory in /var is
> > necessary?
>
> No.  The actual FHS requirement is that the application must be able to
> recover from deletion of files under /var/cache.  The only part of the
> package that I consider to be truly critical is man(1) itself, and that
> continues to work just fine for most purposes even when /var/cache/man
> has been entirely removed.  While mandb(8) will fail, that isn't fatal
> to the operation of the package; it will merely be somewhat degraded.

Yes. Variable state data != fixed and checksummed content of a binary
package that fails a package integrity validation check if removed.

Kind regards,
Luca Boccassi

Bug#1017768: qutip: build with pyproject.toml

[Drew Parsons]

Source: qutip
Version: 4.7.0-3
Severity: normal
Control: forwarded -1 https://github.com/qutip/qutip/issues/1875

It should be possible to build using pyproject.toml (PEP517),
Build-Depends: pybuild-plugin-pyproject

The problem is that that method does not understand the --with-openmp
flag added to setup.py in the same way as a distutils build (the flag
is ignored)

Discussed upstream at https://github.com/qutip/qutip/issues/1875

Upstream reports that the required flag with python3 -m build
would be

  --config-setting="--global-option=--with-openmp"

(and --build-option does not do the job).

But --global-option gives an error for us (different python3-build
versions?):

  File "/usr/lib/python3/dist-packages/setuptools/build_meta.py", line 211, in 
_build_with_temp_dir
sys.argv = (sys.argv[:1] + setup_command +
TypeError: can only concatenate list (not "str") to list


Something else is needed.

Bug#1017441: debhelper: building src:shadow wrongly makes passwd depend on systemd | systemd-tmpfiles

[Colin Watson]

On Fri, Aug 19, 2022 at 11:55:25PM +0100, Luca Boccassi wrote:
> On Fri, 19 Aug 2022 at 23:43, Colin Watson  wrote:
> > I just had my attention drawn to this bug because a man-db upload
> > unexpectedly (to me) gained a dependency on systemd | systemd-tmpfiles,
> > thus adding to the build-essential set.  /usr/lib/tmpfiles.d/man-db.conf
> > reads:
> >
> >   d /var/cache/man 0755 man man 1w
> >
> > This line exists only for cleanup purposes; the directory is also
> > shipped in the package with matching ownership and permissions, so
> > man-db clearly doesn't rely on tmpfiles for creating that directory.
> 
> Shipping files in /var in a package is a bug though, and it really
> needs to be fixed. So it sounds like in this case a dependency is
> indeed the right thing, given presence of the directory in /var is
> necessary?

No.  The actual FHS requirement is that the application must be able to
recover from deletion of files under /var/cache.  The only part of the
package that I consider to be truly critical is man(1) itself, and that
continues to work just fine for most purposes even when /var/cache/man
has been entirely removed.  While mandb(8) will fail, that isn't fatal
to the operation of the package; it will merely be somewhat degraded.

Even if this weren't the case and I felt that this was an important
problem to solve, I'd probably choose some other way to solve it.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1017441: debhelper: building src:shadow wrongly makes passwd depend on systemd | systemd-tmpfiles

[Luca Boccassi]

On Fri, 19 Aug 2022 at 23:43, Colin Watson  wrote:
>
> On Thu, Aug 18, 2022 at 07:56:27PM +0200, Ansgar wrote:
> > 1. Creating files in non-persistent locations (/run) and cleanup (at boot
> > and via cron job):
> >
> > One example is the case above.
> >
> > The dependency on "systemd | systemd-tmpfiles" does not cause tmpfiles to be
> > processed during boot or normal system operation with sysvinit-core as the
> > systemd-standalone-tmpfiles package ships no init script or cron job taking
> > over the function of systemd-tmpfiles-setup.service and
> > systemd-tmpfiles-clean.timer.
> >
> > I expect that such tmpfiles could mostly be ignored in init-less
> > environments such as containers as these usually don't expect cleanup
> > actions for boot and service startup is handled differently.
> >
> > With one exception this could be covered by mandating that init systems must
> > run tmpfiles during boot and packages do not need an explicit dependency for
> > this to happen.
> >
> > (Why mandate the init system to do so? Because I do not think we want to
> > require passwd and other packages to ship an init script just to call
> > systemd-tmpfiles or reimplement the equivalent behavior in a different way.)
> >
> > However there is also the issue that tmpfiles should probably be called on
> > package installation to create the requested files below /run before the
> > next system reboot; they might be relevant for the service to start. It
> > might be sufficient to only call systemd-tmpfiles if some init system is
> > used (i.e., not in the init-less container case) and so also be covered by
> > the requirement above (it would have to include some systemd-tmpfiles binary
> > to be available).
> >
> > Some tmpfiles also include only exception rules for cleanup, for example
> > gvfsd-fuse-tmpfiles.conf:
> >
> > x /run/user/*/gvfs
> >
> > This case does not need an explicit dependency either.
>
> I just had my attention drawn to this bug because a man-db upload
> unexpectedly (to me) gained a dependency on systemd | systemd-tmpfiles,
> thus adding to the build-essential set.  /usr/lib/tmpfiles.d/man-db.conf
> reads:
>
>   d /var/cache/man 0755 man man 1w
>
> This line exists only for cleanup purposes; the directory is also
> shipped in the package with matching ownership and permissions, so
> man-db clearly doesn't rely on tmpfiles for creating that directory.

Shipping files in /var in a package is a bug though, and it really
needs to be fixed. So it sounds like in this case a dependency is
indeed the right thing, given presence of the directory in /var is
necessary?

Kind regards,
Luca Boccassi

Bug#1017441: debhelper: building src:shadow wrongly makes passwd depend on systemd | systemd-tmpfiles

[Colin Watson]

On Thu, Aug 18, 2022 at 07:56:27PM +0200, Ansgar wrote:
> 1. Creating files in non-persistent locations (/run) and cleanup (at boot
> and via cron job):
> 
> One example is the case above.
> 
> The dependency on "systemd | systemd-tmpfiles" does not cause tmpfiles to be
> processed during boot or normal system operation with sysvinit-core as the
> systemd-standalone-tmpfiles package ships no init script or cron job taking
> over the function of systemd-tmpfiles-setup.service and
> systemd-tmpfiles-clean.timer.
> 
> I expect that such tmpfiles could mostly be ignored in init-less
> environments such as containers as these usually don't expect cleanup
> actions for boot and service startup is handled differently.
> 
> With one exception this could be covered by mandating that init systems must
> run tmpfiles during boot and packages do not need an explicit dependency for
> this to happen.
> 
> (Why mandate the init system to do so? Because I do not think we want to
> require passwd and other packages to ship an init script just to call
> systemd-tmpfiles or reimplement the equivalent behavior in a different way.)
> 
> However there is also the issue that tmpfiles should probably be called on
> package installation to create the requested files below /run before the
> next system reboot; they might be relevant for the service to start. It
> might be sufficient to only call systemd-tmpfiles if some init system is
> used (i.e., not in the init-less container case) and so also be covered by
> the requirement above (it would have to include some systemd-tmpfiles binary
> to be available).
> 
> Some tmpfiles also include only exception rules for cleanup, for example
> gvfsd-fuse-tmpfiles.conf:
> 
>     x /run/user/*/gvfs
> 
> This case does not need an explicit dependency either.

I just had my attention drawn to this bug because a man-db upload
unexpectedly (to me) gained a dependency on systemd | systemd-tmpfiles,
thus adding to the build-essential set.  /usr/lib/tmpfiles.d/man-db.conf
reads:

  d /var/cache/man 0755 man man 1w

This line exists only for cleanup purposes; the directory is also
shipped in the package with matching ownership and permissions, so
man-db clearly doesn't rely on tmpfiles for creating that directory.

Now, for systems where we have a tmpfiles implementation, this is
definitely simpler than the cron equivalent (which takes extra care to
be polite about I/O, but with tmpfiles I assume that's the
implementation's problem, and indeed systemd-tmpfiles.service has
IOSchedulingClass=idle):

  # expunge old catman pages which have not been read in a week
  if [ -d /var/cache/man ]; then
cd /
start-stop-daemon --start --pidfile /dev/null --startas /bin/sh \
  --oknodo --chuid man $iosched_idle -- -c \
  "find /var/cache/man -type f -name '*.gz' -atime +6 -print0 | \
   xargs -r0 rm -f"
  fi

But currently, man-db's cron.daily job starts with a [ -d
/run/systemd/system ] guard, so it'll run on systems not booted with
systemd; and in any case man-db has no dependency on cron, so this
cleanup work is supposed to be optional either way.  As such, I'd
definitely prefer to avoid this dependency.

Perhaps we could have this new behaviour be controlled by a flag to
dh_installtmpfiles, since we have good arguments for different packages
wanting different behaviour?  For compatibility, it would seem most
sensible for the old behaviour to be the default, and for packages to
opt into the new behaviour using something like "dh_installtmpfiles
--require-tmpfiles".

I didn't see anyone suggesting a patch for this bug as yet, so to get
the ball rolling, how about the following untested patch?  I doubt it
solves all the use cases raised in this thread, but it still permits the
roundcube maintainer to deal with the situation described in #1013969
with a simple debhelper override, it avoids introducing many unplanned
dependencies elsewhere, and it doesn't seem like unreasonable extra
complexity in debhelper.  People interested in improving how the
tmpfiles system works on non-systemd init systems can still do that
separately.

diff --git a/autoscripts/postinst-init-tmpfiles 
b/autoscripts/postinst-init-tmpfiles
index d651e09c..2430095b 100644
--- a/autoscripts/postinst-init-tmpfiles
+++ b/autoscripts/postinst-init-tmpfiles
@@ -1,5 +1,7 @@
 if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = 
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
-   if [ -z "${DPKG_ROOT:-}" ] ; then
+   # In case this system is running systemd, we need to ensure that all
+   # necessary tmpfiles (if any) are created before starting.
+   if [ -z "${DPKG_ROOT:-}" ] && [ -d /run/systemd/system ] ; then
systemd-tmpfiles --create #TMPFILES# >/dev/null || true
fi
 fi
diff --git a/autoscripts/postinst-init-tmpfiles-required 
b/autoscripts/postinst-init-tmpfiles-required
new file mode 100644
index ..d651e09c
--- /dev/null
+++ 

Bug#1017767: RM: wireguard-linux-compat -- ROM; As noted in #991768, useless in bullseye, in mainline kernel since linux 5.6

[Unit 193]

Package: ftp.debian.org
Severity: normal

Howdy,

Arguably, wireguard-dkms could be useful if one is using a kernel which does
not enable wireguard, but that's not the case for Debian (and deriv) kernels.
It could also be useful with -backports-sloppy, but as that's not happened
I'm requesting removal.


Thanks,
~Unit 193
Unit193 @ Libera
Unit193 @ OFTC

Bug#1017765: (no subject)

[Sylvestre Ledru]

Hello

Could you please provide a reduce test case?

Thanks
Sylvestre
On 2022-08-19 23:34, Jochen Sprickerhof wrote:

Package: clang-14
Version: 1:14.0.6-2
Severity: normal
X-Debbugs-Cc: jspri...@debian.org
Control: affects -1 libeigen3-dev src:pcl

Hi,

on an up to date armel:

jspricke@harris:~$ dd-schroot-cmd -c $sessionid apt-get install
clang-13 clang-14 libeigen3-dev
(sid_armel-dchroot)jspricke@harris:~$ echo -e "#include
\nint main() {}" > eigen.cpp
(sid_armel-dchroot)jspricke@harris:~$ clang++-14 -I
/usr/include/eigen3 eigen.cpp
In file included from eigen.cpp:1:
In file included from /usr/include/eigen3/Eigen/Core:250:
/usr/include/eigen3/Eigen/src/Core/arch/Default/GenericPacketMathFunctions.h:641:3:
error: invalid output constraint '+g,w' in asm
  EIGEN_OPTIMIZATION_BARRIER(y_round)
  ^
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:1134:61: note:
expanded from macro 'EIGEN_OPTIMIZATION_BARRIER'
  #define EIGEN_OPTIMIZATION_BARRIER(X)  __asm__  ("" : "+g,w" 
(X));

^
In file included from eigen.cpp:1:
In file included from /usr/include/eigen3/Eigen/Core:250:
/usr/include/eigen3/Eigen/src/Core/arch/Default/GenericPacketMathFunctions.h:663:3:
error: invalid output constraint '+g,w' in asm
  EIGEN_OPTIMIZATION_BARRIER(x)
  ^
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:1134:61: note:
expanded from macro 'EIGEN_OPTIMIZATION_BARRIER'
  #define EIGEN_OPTIMIZATION_BARRIER(X)  __asm__  ("" : "+g,w" 
(X));

^
In file included from eigen.cpp:1:
In file included from /usr/include/eigen3/Eigen/Core:250:
/usr/include/eigen3/Eigen/src/Core/arch/Default/GenericPacketMathFunctions.h:665:3:
error: invalid output constraint '+g,w' in asm
  EIGEN_OPTIMIZATION_BARRIER(x)
  ^
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:1134:61: note:
expanded from macro 'EIGEN_OPTIMIZATION_BARRIER'
  #define EIGEN_OPTIMIZATION_BARRIER(X)  __asm__  ("" : "+g,w" 
(X));

^
3 errors generated.

(sid_armel-dchroot)jspricke@harris:~$ clang++-13 -I
/usr/include/eigen3 eigen.cpp
(sid_armel-dchroot)jspricke@harris:~$ g++ -I /usr/include/eigen3 
eigen.cpp


This currently breaks src:pcl, can you have a look?

Cheers Jochen


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
merged-usr: no
Architecture: armel (armv7l)

Kernel: Linux 4.19.0-21-armmp (SMP w/1 CPU thread)
Kernel taint flags: TAINT_DIE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages clang-14 depends on:
ii  binutils2.38.90.20220713-2
ii  libatomic1  12.1.0-8
ii  libc6   2.34-4
ii  libc6-dev   2.34-4
ii  libclang-common-14-dev  1:14.0.6-2
ii  libclang-cpp14  1:14.0.6-2
ii  libclang1-141:14.0.6-2
ii  libgcc-12-dev   12.1.0-8
ii  libgcc-s1   12.1.0-8
ii  libllvm14   1:14.0.6-2
ii  libobjc-12-dev  12.1.0-8
ii  libstdc++-12-dev12.1.0-8
ii  libstdc++6  12.1.0-8
ii  llvm-14-linker-tools1:14.0.6-2

Versions of packages clang-14 recommends:
pn  llvm-14-dev  
ii  python3  3.10.6-1

Versions of packages clang-14 suggests:
pn  clang-14-doc  

-- no debconf information

Bug#1017766: podman: Failed to activate DNS. Missing dependency on golang-github-containernetworking-plugin-dnsname

[Michael Musenbrock]

Package: podman
Version: 4.2.0+ds1-3
Severity: important

Hi,

thanks for bringing up-to-date podman packages to Debian. This is really nice 
to have those current version available.

With the latest version of the podman packages (4.2.0+ds1-3) dns resolution 
fails for podman networks.

This could simply be resolved by installing 
'golang-github-containernetworking-plugin-dnsname'. I think this should be 
installed automatically via dependencies.

hth, keep up the nice work
regards Michael


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (504, 'unstable'), (503, 'testing'), (502, 'experimental'), (1, 
'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-4-amd64 (SMP w/16 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages podman depends on:
ii  conmon   2.1.3+ds1-1
ii  crun 1.5+dfsg-1+b1
ii  golang-github-containers-common  0.49.1+ds1-1
ii  libc62.34-4
ii  libdevmapper1.02.1   2:1.02.185-1
ii  libgpgme11   1.17.1-4
ii  libseccomp2  2.5.4-1+b1
ii  runc 1.1.3+ds1-7
ii  systemd [systemd-tmpfiles]   251.4-1

Versions of packages podman recommends:
ii  buildah1.27.0+ds1-5
ii  catatonit  0.1.7-1
ii  dbus-user-session  1.14.0-2
ii  fuse-overlayfs 1.9-1
ii  slirp4netns1.2.0-1
ii  tini   0.19.0-1
ii  uidmap 1:4.11.1+dfsg1-2

Versions of packages podman suggests:
ii  containers-storage  1.42.0+ds1-1
ii  docker-compose  1.29.2-1
ii  iptables1.8.8-1

-- no debconf information

Bug#1017765: (no subject)

[Jochen Sprickerhof]

Package: clang-14
Version: 1:14.0.6-2
Severity: normal
X-Debbugs-Cc: jspri...@debian.org
Control: affects -1 libeigen3-dev src:pcl

Hi,

on an up to date armel:

jspricke@harris:~$ dd-schroot-cmd -c $sessionid apt-get install clang-13 
clang-14 libeigen3-dev
(sid_armel-dchroot)jspricke@harris:~$ echo -e "#include \nint 
main() {}" > eigen.cpp
(sid_armel-dchroot)jspricke@harris:~$ clang++-14 -I /usr/include/eigen3 
eigen.cpp
In file included from eigen.cpp:1:
In file included from /usr/include/eigen3/Eigen/Core:250:
/usr/include/eigen3/Eigen/src/Core/arch/Default/GenericPacketMathFunctions.h:641:3:
 error: invalid output constraint '+g,w' in asm
  EIGEN_OPTIMIZATION_BARRIER(y_round)
  ^
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:1134:61: note: expanded from 
macro 'EIGEN_OPTIMIZATION_BARRIER'
  #define EIGEN_OPTIMIZATION_BARRIER(X)  __asm__  ("" : "+g,w" (X));
^
In file included from eigen.cpp:1:
In file included from /usr/include/eigen3/Eigen/Core:250:
/usr/include/eigen3/Eigen/src/Core/arch/Default/GenericPacketMathFunctions.h:663:3:
 error: invalid output constraint '+g,w' in asm
  EIGEN_OPTIMIZATION_BARRIER(x)
  ^
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:1134:61: note: expanded from 
macro 'EIGEN_OPTIMIZATION_BARRIER'
  #define EIGEN_OPTIMIZATION_BARRIER(X)  __asm__  ("" : "+g,w" (X));
^
In file included from eigen.cpp:1:
In file included from /usr/include/eigen3/Eigen/Core:250:
/usr/include/eigen3/Eigen/src/Core/arch/Default/GenericPacketMathFunctions.h:665:3:
 error: invalid output constraint '+g,w' in asm
  EIGEN_OPTIMIZATION_BARRIER(x)
  ^
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:1134:61: note: expanded from 
macro 'EIGEN_OPTIMIZATION_BARRIER'
  #define EIGEN_OPTIMIZATION_BARRIER(X)  __asm__  ("" : "+g,w" (X));
^
3 errors generated.

(sid_armel-dchroot)jspricke@harris:~$ clang++-13 -I /usr/include/eigen3 
eigen.cpp
(sid_armel-dchroot)jspricke@harris:~$ g++ -I /usr/include/eigen3 eigen.cpp

This currently breaks src:pcl, can you have a look?

Cheers Jochen


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
merged-usr: no
Architecture: armel (armv7l)

Kernel: Linux 4.19.0-21-armmp (SMP w/1 CPU thread)
Kernel taint flags: TAINT_DIE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages clang-14 depends on:
ii  binutils2.38.90.20220713-2
ii  libatomic1  12.1.0-8
ii  libc6   2.34-4
ii  libc6-dev   2.34-4
ii  libclang-common-14-dev  1:14.0.6-2
ii  libclang-cpp14  1:14.0.6-2
ii  libclang1-141:14.0.6-2
ii  libgcc-12-dev   12.1.0-8
ii  libgcc-s1   12.1.0-8
ii  libllvm14   1:14.0.6-2
ii  libobjc-12-dev  12.1.0-8
ii  libstdc++-12-dev12.1.0-8
ii  libstdc++6  12.1.0-8
ii  llvm-14-linker-tools1:14.0.6-2

Versions of packages clang-14 recommends:
pn  llvm-14-dev  
ii  python3  3.10.6-1

Versions of packages clang-14 suggests:
pn  clang-14-doc  

-- no debconf information

Bug#1017725: dgit-maint-native(7) examples should use push-source (rather than push)

[Sean Whitton]

Hello,

On Fri 19 Aug 2022 at 05:12PM +02, Philip Hands wrote:

>
> Package: dgit
> Version: 9.16
> Severity: minor
>
> It strikes me that examples that currently show the `push` sub-command:
>
>   dgit -wgf --overwrite push
> and
>   dgit -wgf push
>
> should show the use of the `push-source` sub-command instead, since doing 
> binary
> uploads to Debian now prevents migration to testing, so chances are that's not
> what most people want to do.

Yes, that should be updated.

> One could perhaps also add a `--with-binary` option for `push` and
> gently transition to defaulting to doing source-only uploads unless
> one specified that option via config or options.

This is an intriguing suggestion, thank you.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1017763: krb5: re-enable (some) build-time tests

[Andreas Hasenack]

Package: krb5
Version: 1.20-1
Severity: normal

Dear Maintainer,

it came to my attention that it looks like the build-time tests of MIT
krb5 are disabled in debian, via this empty d/rules override:

override_dh_auto_test:

I dug a bit in the git history, and found this commit:
https://salsa.debian.org/debian/krb5/-/commit/d35a1394078eb7dba66d763a6e5347ed3ea14204
"
Tests are not going to run on a buildd; they need to much net
"

Hinting that the tests were reaching out to the internet perhaps, and
would thus fail (probably due to firewall egress rules).

I gave this diff a try in an ubuntu ppa, and the build worked, but I
had to disable parallelization for the tests or one would fail
consistently:
diff --git a/debian/rules b/debian/rules
index bbf73a3c7b..9452277e02 100755
--- a/debian/rules
+++ b/debian/rules
@@ -143,6 +143,7 @@ override_dh_fixperms-arch:
chmod 700 debian/krb5-kdc/etc/krb5kdc

 override_dh_auto_test:
+   dh_auto_test $(DH_BUILD_OPTS) --no-parallel

 %:
dh $@


There are more tests that can be enabled by adding packages do build-depends:
- libcmocka-dev
- keyutils
- python3-pyrad
- slapd
- python-kdcproxy

All of the above I added and they built fine in an ubuntu kinetic ppa.
When I added libresolv-wrapper, that one failed a new test, and I
didn't investigate further.

Maybe we could start slowly, just first re-enabling the tests, and
then start adding these extra test-only build-dependencies? We won't
want to introduce flakiness to the build of this package.

Bug#1017748: libuv1 breaks siridb-server autopkgtest: test times out

[Jérémy Lal]

Hi folks,

Some recent small changes in libuv had unexpected outcomes,
I suppose upstream siridb should be made aware of it.



Le ven. 19 août 2022 à 22:42, Paul Gevers  a écrit :

> Hi Jeroen,
>
> On 19-08-2022 21:39, Paul Gevers wrote:
> > With a recent upload of libuv1 the autopkgtest of siridb-server fails in
> > testing when that autopkgtest is run with the binary packages of libuv1
> > from unstable. It passes when run with only packages from testing. In
> > tabular form:
>
> I quickly cooked up a 2.0.48-1 package, but it seems to hang in the same
> way (I didn't let if finish, but normally it's seconds). While running
> the tests, the fan starts spinning and CPU goes to 100% on
> siridb-server, so it seems that with the new libuv1 siridb-server goes
> in a loop.
>
> Any ideas? Any info I can provide?
>
> Paul
>

Bug#1017762: incompatible after "btrfs subvolume set-default ..."

[Osamu Aoki]

Source: partman-btrfs
Version: 55
Severity: normal

It is great to have btrfs support with @rootfs.  Thanks.  I wish if it
is a bit more verbose on what it does in installer dialogue. This is
more important if we want to use existing btrfs with something like
@home-uid1000 in it ;-)

Anyway, I experienced an unsuccessful install to the existing btrfs
partition.  I had @rootfs-broken-backup in it and I set "btrfs subvolume
set-default ..." to it.   Don't ask me why I did.  But this caused d-i
to stop installation without much error report.

EXPECTED BEHAVIOR:

1.  Clearly mention the use of subvolume @rootfs in d-i dialogue.
(This is for both fsck or fsck-less install cases.)

2.  Check "btrfs subvolume get-default " to be "ID 5
(FS_TREE)".  If not,
* stop installation with clear message or (reasonable?)
* set-default to fix this. (better?)
(This is for fsck-less install)

3.  Check existance of @rootfs.  If exists, 
   * stop installation with clear message or (simple)
   * make a backup snapshot of @rootfs to some other name and
remove @rootfs to have clean start. (better)
   (This is for fsck-less install)

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

Kernel: Linux 5.18.0-4-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

Bug#1017761: java.lang.ClassNotFoundException: org.jpype.classloader.DynamicClassLoader

[Tomas Janousek]

Package: python3-jpype
Version: 1.4.0-2
Severity: normal

Due to how the org.jpype.jar is packaged 
(https://salsa.debian.org/python-team/packages/python-jpype/-/commit/44a8befe0b856609a4095f5d9e3979752e367ad8),
 
jpype.startJVM() doesn't work out of the box as documented in upstream 
documentation:

$ python3 -c 'import jpype; jpype.startJVM()'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/jpype/_core.py", line 218, in 
startJVM
_jpype.startup(jvmpath, tuple(args),
SystemError: java.lang.ClassNotFoundException: 
org.jpype.classloader.DynamicClassLoader

This is because it's expected to be in 
/usr/lib/python3/dist-packages/org.jpype.jar 
(https://github.com/jpype-project/jpype/blob/24a2b95aefc2a59e7cf2c362a92ee5c6b13eb94f/native/common/jp_classloader.cpp#L74)
 
and Debian unfortunately only moves the jar, but doesn't patch jpype to 
look for it in the new location.

As a workaround, one can explicitly add the jar to classpath:

$ python3 -c 'import jpype; 
jpype.startJVM(classpath=["/usr/share/java/org.jpype.jar"])'

Unfortunately, this isn't documented anywhere.

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

Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER, TAINT_WARN
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.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 python3-jpype depends on:
ii  default-jre   2:1.11-72
ii  default-jre-headless [java6-runtime-headless] 2:1.11-72
ii  libc6 2.34-3
ii  libgcc-s1 12.1.0-8
ii  libstdc++612.1.0-8
ii  openjdk-11-jre-headless [java6-runtime-headless]  11.0.16+8-1
ii  python3   3.10.5-3
ii  python3-numpy [python3-numpy-abi9]1:1.21.5-1+b1

python3-jpype recommends no packages.

python3-jpype suggests no packages.

-- no debconf information

-- 
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/

Bug#922545: [pkg-lxc-devel] Bug#922545: Bug#922545: lxc: FTBFS on hppa -

[Mathias Gibbens]

  In a recent thread on debian-mentors, an even cleaner way to
conditionally exclude a missing symbol for given architectures was
mentioned at [1], with details described in deb-src-symbols(5). As that
seems to be the most elegant way to handle this, I've pushed up my
commit to the lxc repo and this bug should be closed out with the next
upload.

Mathias

[1] -- https://lists.debian.org/debian-mentors/2022/08/msg00058.html


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

Bug#1010286: please package new upstream release

[Antoine Beaupré]

On 2022-08-19 17:00:57, Antoine Beaupré wrote:
> I am starting to wonder if I should just skip the test suite on this one
> and move on, because it's getting really gruesome.

Grepping around the source, i see this is an optional dep as well, so we
might not need this at all, and instead we could just skip the affected
tests.

-- 
Like slavery and apartheid, poverty is not natural. It is man-made and
it can be overcome and eradicated by the actions of human
beings. Overcoming poverty is not a gesture of charity. It is an act
of justice. - Nelson Mandela

Bug#1010286: please package new upstream release

[Antoine Beaupré]

Another update on this: I submitted a patch upstream to use Glob instead
of git to list the files.

https://github.com/moneta-rb/moneta/pull/232

... but I'm not sure it works. The build still fails, but I wonder if it
might not be a dependency that's just missing from Debian
altogether. The error seems to be:

/usr/share/rubygems-integration/all/gems/bundler-2.3.15/lib/bundler/source/git/git_proxy.rb:224:in
 `allowed_with_path': The git source 
https://github.com/jruby/activerecord-jdbc-adapter.git is not yet checked out. 
Please run `bundle install` before trying to start your application 
(Bundler::GitError)

I can't find any jdbc adapter in ruby in Debian, so I've filed this as a
RFP bug.

I am starting to wonder if I should just skip the test suite on this one
and move on, because it's getting really gruesome.

Attached, as usual, the build log.

-- 
Celui qui sait jouir du peu qu'il a est toujours assez riche.
 - Démocrite
sbuild (Debian sbuild) 0.81.2 (31 January 2021) on curie.anarc.at

+==+
| ruby-moneta 1.5.1-1 (amd64)  Fri, 19 Aug 2022 20:45:16 + |
+==+

Package: ruby-moneta
Version: 1.5.1-1
Source Version: 1.5.1-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full

I: NOTICE: Log filtering will replace 'autopkgtest-virt-dummy-location' with 
'<>'
I: NOTICE: Log filtering will replace 
'build/ruby-moneta-pGHWy0/resolver-pcmkTk' with '<>'

+--+
| Update chroot|
+--+

Get:1 https://deb.debian.org/debian unstable InRelease [192 kB]
Get:2 https://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB]
Get:3 https://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
[63.6 kB]
Get:4 https://deb.debian.org/debian unstable/main Sources 
T-2022-08-19-1409.11-F-2022-08-19-0804.47.pdiff [19.4 kB]
Get:4 https://deb.debian.org/debian unstable/main Sources 
T-2022-08-19-1409.11-F-2022-08-19-0804.47.pdiff [19.4 kB]
Get:5 https://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-08-19-1409.11-F-2022-08-19-0804.47.pdiff [23.6 kB]
Get:5 https://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-08-19-1409.11-F-2022-08-19-0804.47.pdiff [23.6 kB]
Fetched 362 kB in 11s (32.6 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages were automatically installed and are no longer required:
  apparmor busybox dbus-user-session krb5-locales libldap-common
  libsasl2-modules os-prober zstd
Use 'apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/home/anarcat/src/build-area/ruby-moneta_1.5.1-1.dsc exists in 
/home/anarcat/src/build-area; copying to chroot
I: NOTICE: Log filtering will replace 
'build/ruby-moneta-pGHWy0/ruby-moneta-1.5.1' with '<>'
I: NOTICE: Log filtering will replace 'build/ruby-moneta-pGHWy0' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 12), gem2deb, build-essential, 
fakeroot, lsof, mariadb-server, netcat-openbsd, ruby-activerecord, 
ruby-activesupport, ruby-bundler, ruby-fog-core, ruby-kyotocabinet, 
ruby-multi-json, ruby-mysql2, ruby-parallel-tests, ruby-rack, ruby-rack-cache, 
ruby-rspec, ruby-rspec-retry, ruby-sequel, ruby-sqlite3, ruby-tokyocabinet
Filtered Build-Depends: debhelper-compat (= 12), gem2deb, build-essential, 
fakeroot, lsof, mariadb-server, netcat-openbsd, ruby-activerecord, 
ruby-activesupport, ruby-bundler, ruby-fog-core, ruby-kyotocabinet, 
ruby-multi-json, ruby-mysql2, ruby-parallel-tests, ruby-rack, ruby-rack-cache, 
ruby-rspec, ruby-rspec-retry, ruby-sequel, ruby-sqlite3, ruby-tokyocabinet
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [957 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [515 B]
Get:5 copy:/<>/apt_archive ./ Packages [590 B]
Fetched 2062 B in 0s (17.0 kB/s)
Reading package 

Bug#1017757: emacs: early error: no suitable directory for output in 'comp-native-load-path'

[Florent Rougon]

After downgrading to 1:27.1+1-3, the error is gone.

Regards

-- 
Florent

Bug#1017760: linux-image-5.10.0-17-amd64: No space for directory leaf checksum. Please run e2fsck -D.

[Thorsten Glaser]

Package: src:linux
Version: 5.10.136-1
Severity: grave
Justification: causes non-serious data loss
X-Debbugs-Cc: t...@mirbsd.de

I’ve recently been getting filesystem corruption on this system, which,
incidentally, is a fresh-ish installation since I’ve been hit by the
“forgot LUKS password for the main SSD” problem.

This also happened with 5.10.0-14-amd64, but I think not earlier. It
occasionally happens after some amount of uptime and hits random
directories apparently.


-- Package-specific info:
** Version:
Linux version 5.10.0-17-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.136-1 (2022-08-13)

** Command line:
BOOT_IMAGE=/SDcardBoot/vmlinuz-5.10.0-17-amd64 
root=UUID=d7cfc3b2-8733-481c-9fcc-7de4d41a13d6 ro net.ifnames=0

** Not tainted

** Kernel log:
[119729.028638] iwl4965 :03:00.0:   FH49_TSSR_TX_ERROR_REG: 
0X
[119729.030412] iwl4965 :03:00.0: Can't stop Rx DMA.
[119729.030518] ieee80211 phy0: Hardware restart was requested
[120028.870081] iwl4965 :03:00.0: Microcode SW error detected.  Restarting 
0x8200.
[120028.870091] iwl4965 :03:00.0: Loaded firmware version: 228.61.2.24
[120028.870112] iwl4965 :03:00.0: Start IWL Error Log Dump:
[120028.870117] iwl4965 :03:00.0: Status: 0x000213E4, count: 5
[120028.870302] iwl4965 :03:00.0: Desc  
Time   data1  data2  line
[120028.870309] iwl4965 :03:00.0: NMI_INTERRUPT_WDG(0x0004) 
4055082994 0x0002 0x0243 208
[120028.870314] iwl4965 :03:00.0: pc  blink1  blink2  ilink1  ilink2  
hcmd
[120028.870320] iwl4965 :03:00.0: 0x0046C 0x04BE0 0x004C2 0x006DE 0x04C7C 
0x27F001C
[120028.870324] iwl4965 :03:00.0: FH register values:
[120028.870344] iwl4965 :03:00.0:   FH49_RSCSR_CHNL0_STTS_WPTR_REG: 
0X10606300
[120028.870364] iwl4965 :03:00.0:  FH49_RSCSR_CHNL0_RBDCB_BASE_REG: 
0X01060620
[120028.870383] iwl4965 :03:00.0:FH49_RSCSR_CHNL0_WPTR: 
0X0008
[120028.870402] iwl4965 :03:00.0:   FH49_MEM_RCSR_CHNL0_CONFIG_REG: 
0X80809000
[120028.870422] iwl4965 :03:00.0:FH49_MEM_RSSR_SHARED_CTRL_REG: 
0X003c
[120028.870441] iwl4965 :03:00.0:  FH49_MEM_RSSR_RX_STATUS_REG: 
0X0243
[120028.870460] iwl4965 :03:00.0:   FH49_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 
0X
[120028.870479] iwl4965 :03:00.0:  FH49_TSSR_TX_STATUS_REG: 
0X07ff0002
[120028.870498] iwl4965 :03:00.0:   FH49_TSSR_TX_ERROR_REG: 
0X
[120028.872274] iwl4965 :03:00.0: Can't stop Rx DMA.
[120028.872340] ieee80211 phy0: Hardware restart was requested
[121081.667715] iwl4965 :03:00.0: Microcode SW error detected.  Restarting 
0x8200.
[121081.667739] iwl4965 :03:00.0: Loaded firmware version: 228.61.2.24
[121081.667951] iwl4965 :03:00.0: Start IWL Error Log Dump:
[121081.667959] iwl4965 :03:00.0: Status: 0x000213E4, count: 5
[121081.668140] iwl4965 :03:00.0: Desc  
Time   data1  data2  line
[121081.668151] iwl4965 :03:00.0: NMI_INTERRUPT_WDG(0x0004) 
0812904774 0x0002 0x0243 208
[121081.668158] iwl4965 :03:00.0: pc  blink1  blink2  ilink1  ilink2  
hcmd
[121081.668166] iwl4965 :03:00.0: 0x0046C 0x04BE0 0x004C2 0x006DE 0x04C7C 
0x298001C
[121081.668173] iwl4965 :03:00.0: FH register values:
[121081.668195] iwl4965 :03:00.0:   FH49_RSCSR_CHNL0_STTS_WPTR_REG: 
0X10606300
[121081.668218] iwl4965 :03:00.0:  FH49_RSCSR_CHNL0_RBDCB_BASE_REG: 
0X01060620
[121081.668240] iwl4965 :03:00.0:FH49_RSCSR_CHNL0_WPTR: 
0X0020
[121081.668260] iwl4965 :03:00.0:   FH49_MEM_RCSR_CHNL0_CONFIG_REG: 
0X80809000
[121081.668279] iwl4965 :03:00.0:FH49_MEM_RSSR_SHARED_CTRL_REG: 
0X003c
[121081.668302] iwl4965 :03:00.0:  FH49_MEM_RSSR_RX_STATUS_REG: 
0X0243
[121081.668324] iwl4965 :03:00.0:   FH49_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 
0X
[121081.668347] iwl4965 :03:00.0:  FH49_TSSR_TX_STATUS_REG: 
0X07ff0002
[121081.668367] iwl4965 :03:00.0:   FH49_TSSR_TX_ERROR_REG: 
0X
[121081.670429] iwl4965 :03:00.0: Can't stop Rx DMA.
[121081.670535] ieee80211 phy0: Hardware restart was requested
[125434.083155] wlan0: deauthenticating from 38:10:d5:48:ea:c0 by local choice 
(Reason: 3=DEAUTH_LEAVING)
[128369.139128] e1000e :00:19.0 eth0: NIC Link is Up 100 Mbps Full Duplex, 
Flow Control: Rx/Tx
[128369.139255] e1000e :00:19.0 eth0: 10/100 speed: disabling TSO
[128369.139340] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[135660.818236] e1000e :00:19.0 eth0: NIC Link is Down
[135662.403058] e1000e :00:19.0 eth0: NIC Link is Up 100 Mbps Full Duplex, 
Flow Control: Rx/Tx
[135662.403180] e1000e :00:19.0 eth0: 10/100 speed: disabling TSO

Bug#1017759: RFP: ruby-activerecord-jdbc-adapter -- JRuby's ActiveRecord adapter using JDBC

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-j...@lists.debian.org, debian-r...@lists.debian.org

* Package name: ruby-activerecord-jdbc-adapter
  Version : 1.3.24
  Upstream Author : https://github.com/jruby/
* URL : https://github.com/jruby/activerecord-jdbc-adapter
* License : BSD-2-clause
  Programming Lang: Ruby
  Description : JRuby's ActiveRecord adapter using JDBC

ActiveRecord-JDBC-Adapter (AR-JDBC) is the main database adapter for
Rails' ActiveRecord component that can be used with
JRuby. ActiveRecord-JDBC-Adapter provides full or nearly full support
for: MySQL, PostgreSQL, SQLite3 and MSSQL* (SQLServer).



This seems to be a dependency of the newer ruby-moneta package, see
also #1010286.

Bug#1015831: [hddtemp] Please keep hddtemp in Debian

[Aurelien Jarno]

Hi,

On 2022-07-22 07:18, Roman Mamedov wrote:
> Package: hddtemp
> Severity: wishlist
> 
> Hello,
> 
> I have been surprised to see the changelog entry about the planned removal of
> hddtemp. I would like to leave a couple of comments to that.
> 
> >  hddtemp has been dead upstream for many years and is therefore in a minimal
> >  maintenance mode. It will be shipped in the Debian Bullseye release, but
> >  will not be present in the Debian Bookworm release.
> 
> Could it be a case of a program that is basically _done_, i.e. it works, keeps
> working, and doesn't need any changes or new features, other than "minimal
> maintenance" in the first place?

Definitely not. Maintenance has been done in Debian for many time, with
54 debian specific uploads for the current beta version released
upstream 16 years ago.

In addition this program will never be _done_, as by design there is a
need to maintain a database of drives, contrary to the kernel module.
And it doesn't support NVME or SAS drives that will eventually replace
SCSI or SATA drives.

> Or could you give some examples of issues that arise and go unsolved because
> of "dead" upstream? Seeing from next to no bugreports in Debian, doesn't seem
> that there are many.

All the bugs have been closed when the package has been removed. Please
find the list below.

https://bugs.debian.org/235427
https://bugs.debian.org/316552
https://bugs.debian.org/331446
https://bugs.debian.org/479840
https://bugs.debian.org/654875
https://bugs.debian.org/668961
https://bugs.debian.org/727820
https://bugs.debian.org/740732
https://bugs.debian.org/758748
https://bugs.debian.org/833147
https://bugs.debian.org/854484
https://bugs.debian.org/854806
https://bugs.debian.org/891501
https://bugs.debian.org/924950
https://bugs.debian.org/961817
https://bugs.debian.org/981462

Please note that bug #740732 even asked hddtemp to be removed as the
package was bit rotting. I also regularly receive "my hard drive is not
recognized" bugs through private mails.

In addition hddtemp needs to run as root as a SUID binary. While it was
something usual 20 years ago when the architecture of the hddtemp has
been designed, this is not the case anymore. Given the state of the
software, it's likely a good candidate for privilege elevation.

> >  Nowadays the 'drivetemp' kernel module is a better alternative. It uses the
> >  Linux Hardware Monitoring kernel API (hwmon), so the temperature is 
> > returned
> >  the same way and using the same tools as other sensors.
> 
> Does not seem to be the case. Of course running "sensors" then returns:
> 
> > drivetemp-scsi-4-0
> > Adapter: SCSI adapter
> > temp1:+32.0°C  (low  =  +0.0°C, high = +60.0°C)
> >(crit low = -40.0°C, crit = +65.0°C)
> >(lowest = +28.0°C, highest = +42.0°C)
> 
> And what I wanted to know was the temperature of /dev/sda.
> 
> There is no "sensors /dev/sda" obviously, and not obvious for the user how to
> easily convert sda to scsi-X-Y. Calling *this* the better alternative seems
> extremely premature.

Indeed that is not perfect, however it has the advantage to have a
stable name that depends on the connection and not the way the devices
are discovered. You can lookup the relation by looking at the
/sys/block/sd*/device link.

However it is way more integrated to existing temperature monitoring
software, as it uses the hwmon interface, and reports the temperature
the same way as NVME drives.

> At least some wrapper should be introduced (or maybe there's already one?)
> that would offer the exact command-line interface as hddtemp, but then
> retrieve the temperature in "the better way" under the hood (if there's really
> such a pressing need...)

A wrapper would indeed be a good idea. That said the non-existence of
such a wrapper is not a reason to keep hddtemp any longer. And it
doesn't replace the daemon mode of hddtemp. Anyway do not hesitate to
contribute such a wrapper.

> Not to mention it would return 24 of these paragraphs when called
> (interrupting all the drives to fetch temperature?), assuming e.g. 24 drives,
> even if I wanted the temperature of just one.

That's just bad faith. Just looking at the sensors manpage would have
shown you that you can path the name of the drive (in your case
"drivetemp-scsi-4-0") as an argument.

And while it indeed takes a tiny piece of bandwidth to fetch the
temperature, contrary to the kernel driver the temperature is cached for
sometime to avoid interrupting the drive too often. And contrary to
hddtemp, the driver avoids waking-up the drive.

> >  Loading this module is as easy as creating a file in the 
> > /etc/modules-load.d
> >  directory:
> >
> >echo drivetemp > /etc/modules-load.d/drivetemp.conf
> 
> Loading it might be easy, but as one proverb says, "only if you're not
> interested in the results"...

The replacement is definitely not perfect and users need to adapt a bit
their usage or their scripts. On the other hand it 

Bug#1017758: libsoup3: unsatisfiable dependency on non-linux

[Samuel Thibault]

Source: libsoup3
Version: 3.1.1-1
Severity: important
Tags: patch

Hello,

libsoup-3.0-dev is not installable on non-linux ports because it depends
on the linux-only libsysprof-4-dev package. The attached patch fixes
that, could you apply it?

Thanks,
Samuel

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

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

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/control.original 2022-08-19 22:35:17.362614999 +0200
+++ debian/control  2022-08-19 22:35:43.262749927 +0200
@@ -50,7 +50,7 @@
  libpsl-dev (>= 0.20),
  libsoup-3.0-0 (= ${binary:Version}),
  libsqlite3-dev,
- libsysprof-4-dev,
+ libsysprof-4-dev [linux-any],
  zlib1g-dev,
  ${misc:Depends}
 Suggests: libsoup-3.0-doc
--- debian/control.in.original  2022-08-19 22:35:22.542641982 +0200
+++ debian/control.in   2022-08-19 22:35:32.552694129 +0200
@@ -46,7 +46,7 @@
  libpsl-dev (>= 0.20),
  libsoup-3.0-0 (= ${binary:Version}),
  libsqlite3-dev,
- libsysprof-4-dev,
+ libsysprof-4-dev [linux-any],
  zlib1g-dev,
  ${misc:Depends}
 Suggests: libsoup-3.0-doc

Bug#1017757: emacs: early error: no suitable directory for output in 'comp-native-load-path'

[Florent Rougon]

Package: emacs
Version: 1:28.1+1-1
Severity: normal

Dear maintainer,

After performing the following upgrades today on sid:

[UPGRADE] emacs:amd64 1:27.1+1-3.1 -> 1:28.1+1-1
[UPGRADE] emacs-bin-common:amd64 1:27.1+1-3.1+b1 -> 1:28.1+1-1
[UPGRADE] emacs-bin-common-dbgsym:amd64 1:27.1+1-3.1+b1 -> 1:28.1+1-1
[UPGRADE] emacs-common:amd64 1:27.1+1-3.1 -> 1:28.1+1-1
[UPGRADE] emacs-el:amd64 1:27.1+1-3.1 -> 1:28.1+1-1
[UPGRADE] emacs-gtk:amd64 1:27.1+1-3.1+b1 -> 1:28.1+1-1
[UPGRADE] emacs-gtk-dbgsym:amd64 1:27.1+1-3.1+b1 -> 1:28.1+1-1

starting Emacs, even with the -q option, stops very early with a beep
and the following in the *Messages* buffer:

  defalias: Cannot find suitable directory for output in 
'comp-native-load-path'.

Therefore, it is impossible to execute my initialization files
(I would put severity at least serious, but reportbug wants me to
quote Policy sections in this case, so...).

With 'emacs -q --no-site-file', there is no error.

Thanks!

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

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

Versions of packages emacs depends on:
ii  emacs-gtk  1:28.1+1-1

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#1017756: iem-plugin-suite FTBFS: error: no matching function for call to ‘juce::Matrix3D::Matrix3D(juce::Vector3D)’

[Adrian Bunk]

Source: iem-plugin-suite
Version: 1.13.0-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=iem-plugin-suite=amd64=1.13.0-2%2Bb2=1660937897=0

...
In file included from /<>/AllRADecoder/Source/PluginEditor.h:36,
 from /<>/AllRADecoder/Source/PluginEditor.cpp:24:
/<>/AllRADecoder/Source/LoudspeakerVisualizer.h: In member 
function ‘juce::Matrix3D LoudspeakerVisualizer::getViewMatrix()’:
/<>/AllRADecoder/Source/LoudspeakerVisualizer.h:516:100: error: no 
matching function for call to 
‘juce::Matrix3D::Matrix3D(juce::Vector3D)’
  516 | juce::Matrix3D translationMatrix (juce::Vector3D 
(0.0f, 0.0f, -500.0f * zoom)); // move object further away
  | 
   ^
In file included from /usr/share/juce/modules/juce_opengl/juce_opengl.h:107,
 from 
/<>/obj-x86_64-linux-gnu/AllRADecoder/AllRADecoder_artefacts/JuceLibraryCode/../JuceLibraryCode/JuceHeader.h:28,
 from /<>/AllRADecoder/Source/PluginProcessor.h:26,
 from /<>/AllRADecoder/Source/PluginEditor.cpp:23:
/usr/share/juce/modules/juce_opengl/geometry/juce_Matrix3D.h:82:5: note: 
candidate: ‘juce::Matrix3D::Matrix3D(const juce::AffineTransform&) [with 
Type = float]’
   82 | Matrix3D (const AffineTransform& transform) noexcept
  | ^~~~
/usr/share/juce/modules/juce_opengl/geometry/juce_Matrix3D.h:82:38: note:   no 
known conversion for argument 1 from ‘juce::Vector3D’ to ‘const 
juce::AffineTransform&’
   82 | Matrix3D (const AffineTransform& transform) noexcept
  |   ~~~^
/usr/share/juce/modules/juce_opengl/geometry/juce_Matrix3D.h:76:5: note: 
candidate: ‘juce::Matrix3D::Matrix3D(const Type*) [with Type = float]’
   76 | Matrix3D (const Type* values) noexcept
  | ^~~~
/usr/share/juce/modules/juce_opengl/geometry/juce_Matrix3D.h:76:27: note:   no 
known conversion for argument 1 from ‘juce::Vector3D’ to ‘const float*’
   76 | Matrix3D (const Type* values) noexcept
  |   ^~
/usr/share/juce/modules/juce_opengl/geometry/juce_Matrix3D.h:64:5: note: 
candidate: ‘juce::Matrix3D::Matrix3D(Type, Type, Type, Type, Type, Type, 
Type, Type, Type, Type, Type, Type, Type, Type, Type, Type) [with Type = float]’
   64 | Matrix3D (Type m00, Type m10, Type m20, Type m30,
  | ^~~~
/usr/share/juce/modules/juce_opengl/geometry/juce_Matrix3D.h:64:5: note:   
candidate expects 16 arguments, 1 provided
/usr/share/juce/modules/juce_opengl/geometry/juce_Matrix3D.h:51:5: note: 
candidate: ‘juce::Matrix3D::Matrix3D(const juce::Matrix3D&) [with 
Type = float]’
   51 | Matrix3D (const Matrix3D& other) noexcept
  | ^~~~
/usr/share/juce/modules/juce_opengl/geometry/juce_Matrix3D.h:51:31: note:   no 
known conversion for argument 1 from ‘juce::Vector3D’ to ‘const 
juce::Matrix3D&’
   51 | Matrix3D (const Matrix3D& other) noexcept
  |   ^
/usr/share/juce/modules/juce_opengl/geometry/juce_Matrix3D.h:42:5: note: 
candidate: ‘juce::Matrix3D::Matrix3D() [with Type = float]’
   42 | Matrix3D() noexcept
  | ^~~~
/usr/share/juce/modules/juce_opengl/geometry/juce_Matrix3D.h:42:5: note:   
candidate expects 0 arguments, 1 provided
make[3]: *** [AllRADecoder/CMakeFiles/AllRADecoder.dir/build.make:83: 
AllRADecoder/CMakeFiles/AllRADecoder.dir/Source/PluginEditor.cpp.o] Error 1

Bug#1017748: libuv1 breaks siridb-server autopkgtest: test times out

[Paul Gevers]

Hi Jeroen,

On 19-08-2022 21:39, Paul Gevers wrote:
With a recent upload of libuv1 the autopkgtest of siridb-server fails in 
testing when that autopkgtest is run with the binary packages of libuv1 
from unstable. It passes when run with only packages from testing. In 
tabular form:


I quickly cooked up a 2.0.48-1 package, but it seems to hang in the same 
way (I didn't let if finish, but normally it's seconds). While running 
the tests, the fan starts spinning and CPU goes to 100% on 
siridb-server, so it seems that with the new libuv1 siridb-server goes 
in a loop.


Any ideas? Any info I can provide?

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017755: New package version

[Simon Howard]

Package: sopwith
Version: 1.8.4-18

A new version of this package, 2.0.0, has been released. The upstream
URL has also changed. Please update the Debian package to the new
version.

https://fragglet.github.io/sdl-sopwith

Simon (the upstream maintainer).

-- 
Simon Howard
https://soulsphere.org/

Bug#1011043: golang-ginkgo: Please update to upstream version 2.1.4

[Shengjing Zhu]

On Mon, May 16, 2022 at 9:39 AM Reinhard Tartler  wrote:
>
> Package: ginkgo
> Severity: wishlist
> X-Debbugs-Cc: none, Reinhard Tartler 
>
> I've had to disable various tests from github.com/containers/common that
> depend on ginkgo/v2 interfaces

Please package a new v2 package, as ginkgo v1 and v2 are not compatible.
And there are many packages still using v1.

-- 
Shengjing Zhu

Bug#1017237: sambamba: FTBFS: ../meson.build:9:0: ERROR: Unable to detect linker for compiler `ldc2 -L=--version /tmp/tmp1izbdod0.d -Wl,-z,relro -O -g -release -wi`

[Nilesh Patra]

Control: reassign -1 meson 0.63.1-1
Control: forcemerge -1 1017087
Control: affects 1017087 + sambamba

This is due to bug #1017087 in meson itself which I reported a few days
ago.
I am re-assigning, merging and adding in an affects.

On Sun, 14 Aug 2022 09:51:09 +0200 Lucas Nussbaum  wrote:
> Source: sambamba
> Version: 0.8.2+dfsg-2
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220813 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > dh_auto_configure -- -Doptimize_strong=true -Dcpp_link_args="-wi -L=-z 
> > -L=relro /usr/lib/x86_64-linux-gnu/libhts.a -L=-lz -L=-lcrypto -L=-lcurl 
> > -L=-llzma -L=-lbz2 -L=-ldeflate -L=-llz4"
> > cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson .. 
> > --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
> > --localstatedir=/var --libdir=lib/x86_64-linux-gnu -Doptimize_strong=true 
> > "-Dcpp_link_args=-wi -L=-z -L=relro /usr/lib/x86_64-linux-gnu/libhts.a 
> > -L=-lz -L=-lcrypto -L=-lcurl -L=-llzma -L=-lbz2 -L=-ldeflate -L=-llz4"
> > The Meson build system
> > Version: 0.63.1
> > Source dir: /<>
> > Build dir: /<>/obj-x86_64-linux-gnu
> > Build type: native build
> > Project name: Sambamba
> > Project version: 0.8.2
> > C compiler for the host machine: cc (gcc 12.1.0 "cc (Debian 12.1.0-8) 
> > 12.1.0")
> > C linker for the host machine: cc ld.bfd 2.38.90.20220713
> > 
> > ../meson.build:9:0: ERROR: Unable to detect linker for compiler `ldc2 
> > -L=--version /tmp/tmp1izbdod0.d -Wl,-z,relro -O -g -release -wi`
> > stdout: 
> > stderr: ldc2: Unknown command line argument '-Wl,-z,relro'.  Try: 'ldc2 
> > --help'
> > ldc2: Did you mean '--icp-lto'?
> > 
> > 
> > A full log can be found at 
> > /<>/obj-x86_64-linux-gnu/meson-logs/meson-log.txt
> > cd obj-x86_64-linux-gnu && tail -v -n \+0 meson-logs/meson-log.txt
> > ==> meson-logs/meson-log.txt <==
> > Build started at 2022-08-14T03:13:25.149842
> > Main binary: /usr/bin/python3
> > Build Options: -Doptimize_strong=true '-Dcpp_link_args=-wi -L=-z -L=relro 
> > /usr/lib/x86_64-linux-gnu/libhts.a -L=-lz -L=-lcrypto -L=-lcurl -L=-llzma 
> > -L=-lbz2 -L=-ldeflate -L=-llz4' -Dprefix=/usr -Dlibdir=lib/x86_64-linux-gnu 
> > -Dlocalstatedir=/var -Dsysconfdir=/etc -Dbuildtype=plain 
> > -Dwrap_mode=nodownload
> > Python system: Linux
> > The Meson build system
> > Version: 0.63.1
> > Source dir: /<>
> > Build dir: /<>/obj-x86_64-linux-gnu
> > Build type: native build
> > Project name: Sambamba
> > Project version: 0.8.2
> > -
> > Detecting compiler via: cc --version
> > compiler returned 
> > compiler stdout:
> > cc (Debian 12.1.0-8) 12.1.0
> > Copyright (C) 2022 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> > 
> > 
> > compiler stderr:
> > 

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1017750: multiboot friendly /boot/efi/EFI/debian/grub.cfg update

[Osamu Aoki]

Control: tags -1 patch

Here is a proof-of-concept untested patch to address backup.

With this approach, backup suffix is UUID.


--- postinst.in.orig	2022-08-20 05:00:47.915499523 +0900
+++ postinst.in	2022-08-20 05:15:55.732025173 +0900
@@ -330,7 +330,6 @@
 echo "WARNING: Bootloader is not properly installed, system may not be bootable" >&2
 fi
 }
-
 case "$1" in
   configure)
 . /usr/share/debconf/confmodule
@@ -710,6 +709,10 @@
 FORCE_EXTRA_REMOVABLE="--force-extra-removable"
   fi
   NO_NVRAM="$(no_nvram_arg)"
+  if  -f /boot/efi/EFI/debian/grub.cfg ; then
+  SUFFIX=$(sed -n -e 's,^search.fs_uuid \([^ ]*\) root.*,\1,p' /boot/efi/EFI/debian/grub.cfg)
+  cp -f /boot/efi/EFI/debian/grub.cfg /boot/efi/EFI/debian/grub.cfg.$SUFFIX
+  fi
   run_grub_install --target="$target" "$FORCE_EXTRA_REMOVABLE" "$NO_NVRAM"
 fi
 

Bug#1017741: [PATCH] Update package description for EFI*

[Osamu Aoki]

Hi,

> -Original Message-
> From: Colin Watson 
> To: Osamu Aoki , 1017...@bugs.debian.org
> Subject: Re: Bug#1017741: [PATCH] Update package description for EFI*
> Date: Fri, 19 Aug 2022 20:24:32 +0100
> 
> On Sat, Aug 20, 2022 at 03:50:44AM +0900, Osamu Aoki wrote:
> > diff --git a/debian/control b/debian/control
> > index 71cca4436..74769e0eb 100644
> > --- a/debian/control
> > +++ b/debian/control
> > @@ -263,11 +263,11 @@ Description: GRand Unified Bootloader, version 2 
> > (EFI-IA32
> > modules)
> >  update-grub.
> >   .
> >   This package contains GRUB modules that have been built for use with the
> > - EFI-IA32 architecture, as used by Intel Macs (unless a BIOS interface has
> > - been activated).  It can be installed in parallel with other flavours, but
> > - will not automatically install GRUB as the active boot loader nor
> > - automatically update grub.cfg on upgrade unless grub-efi-ia32 is also
> > - installed.
> > + EFI-IA32 architecture, as used by modern PCs with UEFI (unless a legacy PC
> > + BIOS interface has been activated).  It can be installed in parallel with
> > + other flavours, but will not automatically install GRUB as the active boot
> > + loader nor automatically update grub.cfg on upgrade unless grub-efi-ia32 
> > is
> > + also installed.
> >  
> >  Package: grub-efi-ia32-dbg
> >  Section: debug
> > @@ -296,9 +296,9 @@ Description: GRand Unified Bootloader, version 2 
> > (EFI-IA32
> > version)
> >  update-grub.
> >   .
> >   This is a dependency package for a version of GRUB that has been built for
> > - use with the EFI-IA32 architecture, as used by Intel Macs (unless a BIOS
> > - interface has been activated).  Installing this package indicates that 
> > this
> > - version of GRUB should be the active boot loader.
> > + use with the EFI-IA32 architecture, as used by modern PCs with UEFI 
> > (unless a
> > + legacy PC BIOS interface has been activated).  Installing this package
> > + indicates that this version of GRUB should be the active boot loader.
> >  
> >  Package: grub-efi-ia32-signed-template
> >  Architecture: i386
> 
> This part of the patch looks wrong.  The efi-ia32 platform (i.e. 32-bit
> firmware; note that this is *not* about which OS architecture is in use)
> is in fact suitable for only very few modern PCs; IIRC there were a few
> others beyond just Intel Macs, though I think Intel Macs were still the
> majority sold.
> 
> The changes look more accurate for the efi-amd64 platform (i.e. 64-bit
> firmware).

Come to think of, you are 100% correct.

Bug#1017691: thunderbird: ship mach utilities and test code in a binary package

[Daniel Kahn Gillmor]

Hi Carsten--

Thanks for this prompt and thoughtful response!

On Fri 2022-08-19 07:30:14 +0200, Carsten Schoenert wrote:
> there isn't only the mach Python script, there are a lot of various 
> peaces that act together (I haven't looked into that rabbit hole yet). 
> But yes, the script in question is a Python script.

yep, i agree that it's more complicated than a single python script.
thanks for looking a few layers below the surface already.

> Of course this is doable. Reading your initial ITP I think it would be 
> reasonable to ship this all within a new binary package called 
> thunderbird-mach-tool or mozilla-mach-tool e.g. This could be even a 
> usual python3 package in a long term.

that sounds not unreasonable to me.  I see that
https://pypi.org/project/mach/ is also a Mozilla project (it links back
to the bitrotted
https://developer.mozilla.org/en-US/docs/Developer_Guide/mach), but it
doesn't look like it is the same thing?   Or, it has greatly diverged!

If it is actually the same project, maybe we can try to convince
upstream to reinvigorate their package on pypi directly, then we pull
from there?

> The hardest part will be to get all the parts together that are needed 
> to get the tooling working correctly.
> For me it would work best if you can start to extract the files and 
> folders which are needed.

right.  looking a bit deeper into it, it looks like mach wants to
initialize a python virtualenv -- that's probably a non-starter for
debian, so it might need some additional pruning/patching :(

> Do you might have an (better?) idea how to archive the needs from 
> Daniel? It's mostly a one way communication for me if I start to ask 
> Mike. :-(
> Is there eventually some more or less ready we could pick up from the 
> upstream build system?

I'd definitely be interested in hearing if you know of any other option
too!

All the best,

--dkg


signature.asc
Description: PGP signature

Bug#1017754: fdkaac: CVE-2022-37781

[Salvatore Bonaccorso]

Source: fdkaac
Version: 1.0.0-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/nu774/fdkaac/issues/54
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for fdkaac.

CVE-2022-37781[0]:
| fdkaac v1.0.3 was discovered to contain a heap buffer overflow via
| __interceptor_memcpy.part.46 at
| /sanitizer_common/sanitizer_common_interceptors.inc.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-37781
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-37781
[1] https://github.com/nu774/fdkaac/issues/54
[2] 
https://github.com/nu774/fdkaac/commit/ecddb7d63306e01d137d65bbbe7b78c1e779943c

Regards,
Salvatore

Bug#1017753: autopkgtest-virt-lxc regularly fails to start or return from reboot

[Paul Gevers]

Hi

On 19-08-2022 21:59, Paul Gevers wrote:

The following is seen, but not on every reboot.

$ autopkgtest . --apt-upgrade --shell-fail  -- lxc --sudo 
autopkgtest-unstable-amd64

[...]

autopkgtest [21:45:36]: rebooting testbed after setup commands that affected 
boot
autopkgtest-virt-lxc [21:45:43]: ERROR: Waiting for boot to finish failed
autopkgtest-virt-lxc [21:45:43]: ERROR: Failed to connect to bus: No such 
file or directory
: failure: Waiting for boot to finish failed
autopkgtest [21:45:45]: ERROR: testbed failure: unexpected eof from the testbed


And now I get this:

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
autopkgtest [21:54:22]: rebooting testbed after setup commands that 
affected boot

autopkgtest-virt-lxc [21:55:29]: ERROR: Timed out waiting for boot to finish
Unexpected error:
Traceback (most recent call last):
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 871, in mainloop
command()
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 800, in command
r = f(c, ce)
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 495, in cmd_reboot
caller.hook_wait_reboot(**wait_reboot_args)
  File "/usr/bin/autopkgtest-virt-lxc", line 291, in hook_wait_reboot
wait_booted(lxc_container_name)
  File "/usr/bin/autopkgtest-virt-lxc", line 116, in wait_booted
VirtSubproc.wait_booted(sudoify(['lxc-attach', '--name', lxc_name, 
'--']))
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 262, in 
wait_booted

(rc, err, _) = execute_timeout(
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 151, in 
execute_timeout

(out, err) = sp.communicate(instr)
  File "/usr/lib/python3.10/subprocess.py", line 1139, in communicate
stdout = self.stdout.read()
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 71, in 
alarm_handler

raise Timeout()
VirtSubproc.Timeout
autopkgtest [21:55:32]: ERROR: testbed failure: unexpected eof from the 
testbed


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017753: autopkgtest-virt-lxc regularly fails to start or return from reboot

[Paul Gevers]

Package: autopkgtest
Version: 5.24
Severity: serious

Dear colleagues,

I was just trying to fix some package of mine and was running
autopkgtest to see if the hang I see on ci.d.n is
reproducible. However, autopkgtest has issues running reliably.

Simon already reported this on IRC when releasing 5.24, but it's worse
than I suspected.

The following is seen, but not on every reboot.

$ autopkgtest . --apt-upgrade --shell-fail  -- lxc --sudo 
autopkgtest-unstable-amd64

[...]

autopkgtest [21:45:36]: rebooting testbed after setup commands that affected 
boot
autopkgtest-virt-lxc [21:45:43]: ERROR: Waiting for boot to finish failed
autopkgtest-virt-lxc [21:45:43]: ERROR: Failed to connect to bus: No such 
file or directory
: failure: Waiting for boot to finish failed
autopkgtest [21:45:45]: ERROR: testbed failure: unexpected eof from the testbed

Paul



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 autopkgtest depends on:
ii  apt-utils   2.5.2
ii  libdpkg-perl1.21.9
ii  procps  2:3.3.17-7+b1
ii  python3 3.10.5-3
ii  python3-debian  0.1.46

Versions of packages autopkgtest recommends:
ii  autodep8  0.26
ii  fakeroot  1.29-1

Versions of packages autopkgtest suggests:
pn  docker.io
pn  fakemachine  
ii  lxc  1:5.0.1-1
pn  lxd  
ii  ovmf 2022.05-2
pn  ovmf-ia32
pn  podman   
ii  python3-distro-info  1.1
pn  qemu-efi-aarch64 
pn  qemu-efi-arm 
pn  qemu-system  
ii  qemu-utils   1:7.0+dfsg-7+b1
ii  schroot  1.6.12-2
ii  util-linux   2.38.1-1
ii  vmdb20.26-1

-- no debconf information

Bug#1017752: nheko: FTBFS on mipsel: virtual memory exhausted: Cannot allocate memory

[Shengjing Zhu]

Source: nheko
Version: 0.10.0-1
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: z...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=nheko=mipsel=0.10.0-1=1659971124=0

[ 68%] Building CXX object CMakeFiles/nheko.dir/src/ReadReceiptsModel.cpp.o
virtual memory exhausted: Cannot allocate memory
[ 69%] Building CXX object CMakeFiles/nheko.dir/src/RegisterPage.cpp.o
make[4]: *** [CMakeFiles/nheko.dir/build.make:1043: 
CMakeFiles/nheko.dir/src/Cache.cpp.o] Error 1
make[4]: *** Waiting for unfinished jobs
make[4]: Leaving directory '/<>/build'
make[3]: *** [CMakeFiles/Makefile2:153: CMakeFiles/nheko.dir/all] Error 2
make[3]: Leaving directory '/<>/build'
make[2]: *** [Makefile:139: all] Error 2
make[2]: Leaving directory '/<>/build'
dh_auto_build: error: cd build && make -j4 "INSTALL=install 
--strip-program=true" VERBOSE=1 returned exit code 2
make[1]: *** [debian/rules:22: override_dh_auto_build] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:11: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

And it blocks the package from migrating to testing.

Bug#1017751: fdkaac: CVE-2022-36148

[Salvatore Bonaccorso]

Source: fdkaac
Version: 1.0.0-1
Severity: normal
Tags: security upstream
Forwarded: https://github.com/nu774/fdkaac/issues/52
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for fdkaac.

CVE-2022-36148[0]:
| fdkaac commit 53fe239 was discovered to contain a floating point
| exception (FPE) via wav_open at /src/wav_reader.c.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-36148
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-36148
[1] https://github.com/nu774/fdkaac/issues/52
[2] 
https://github.com/nu774/fdkaac/commit/4ec1422bd951a137225ffa4052da120e2ab0a0f4 

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1017750: multiboot friendly /boot/efi/EFI/debian/grub.cfg update

[Osamu Aoki]

Package: grub-efi-amd64
Version: 2.06-3
Severity: wishlist

Currently, if you have dual boot of 2 Debian system installations, every
time grub2 of one system runs postinst, it overwrites
/boot/efi/EFI/debian/grub.cfg file in ESP pointing search.fs_uuid
pointing to lead to /boot/grub/* by UUID.

It doesn't backup existing /boot/efi/EFI/debian/grub.cfg.

If you consider this to be the result of upstream feature of update-grub
then it will be tough to be fixed.

But can you think of updating Debian postinst script to check the
existence of the /boot/efi/EFI/debian/grub.cfg file first and back it
up?  This helps recovery of system and trivial to be implemented.

I prefer time-stamped string as suffix for the backup file but this can
be anything maintainer likes.

This way, we can easily select /boot/grub/* after crash without manually
typing UUID.  Having at least 2 or 3 stage backups is more friendly.


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/nvme0n1p5 / btrfs 
rw,relatime,ssd,space_cache,subvolid=22924,subvol=/@rootfs 0 0   <--- This is 
my main @rootfs
/dev/nvme0n1p5 /btrfs/main btrfs 
rw,relatime,ssd,space_cache,subvolid=5,subvol=/ 0 0
/dev/nvme0n1p5 /home/osamu btrfs 
rw,relatime,ssd,space_cache,subvolid=596,subvol=/@osamu 0 0
/dev/nvme1n1p1 /btrfs/sub btrfs rw,relatime,ssd,space_cache,subvolid=5,subvol=/ 
0 0 <--- This partition holds 2nd @rootfs
/dev/nvme0n1p1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0 <--- ESP
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates

 (snip uninteresting part)
 Followings are my custom dual boot configuration 

### BEGIN /etc/grub.d/40_fixed_linux ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry 'Debian GNU/Linux --- main SSD' --class debian --class gnu-linux 
--class gnu --class os $menuentry_id_option 
'gnulinux-fixed-fe3e1db5-6454-46d6-a14c-071208ebe4b1' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod btrfs
search --no-floppy --fs-uuid --set=root 
fe3e1db5-6454-46d6-a14c-071208ebe4b1
echo'Loading Linux from /dev/nvme0n1p5 ...'
linux   /@rootfs/vmlinuz root=UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1 
ro rootflags=subvol=@rootfs  quiet
echo'Loading initial ramdisk from /dev/nvme0n1p5 ...'
initrd  /@rootfs/initrd.img
}
menuentry 'Debian GNU/Linux --- sub SSD' --class debian --class gnu-linux 
--class gnu --class os $menuentry_id_option 
'gnulinux-fixed-51f9cd11-30b3-4d99-b2ed-fe411fa22ee6' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod btrfs
search --no-floppy --fs-uuid --set=root 
51f9cd11-30b3-4d99-b2ed-fe411fa22ee6
echo'Loading Linux from /dev/nvme1n1p1 ...'
linux   /@rootfs/vmlinuz root=UUID=51f9cd11-30b3-4d99-b2ed-fe411fa22ee6 
ro rootflags=subvol=@rootfs  quiet
echo'Loading initial ramdisk from /dev/nvme1n1p1 ...'
initrd  /@rootfs/initrd.img
}
### END /etc/grub.d/40_fixed_linux ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f  ${config_directory}/custom.cfg ]; then
  source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg
fi
### END /etc/grub.d/41_custom ###
*** END /boot/grub/grub.cfg


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

Kernel: Linux 5.18.0-4-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 grub-efi-amd64 depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  grub-common2.06-3
ii  grub-efi-amd64-bin 2.06-3
ii  grub2-common   2.06-3
ii  ucf3.0043

grub-efi-amd64 recommends no packages.

grub-efi-amd64 suggests no packages.

-- debconf information:
  grub2/kfreebsd_cmdline:
* grub2/linux_cmdline:
* grub2/force_efi_extra_removable: false
* grub2/update_nvram: true
* grub2/linux_cmdline_default: quiet
  grub2/kfreebsd_cmdline_default: quiet

Bug#1017748: libuv1 breaks siridb-server autopkgtest: test times out

[Paul Gevers]

Source: libuv1, siridb-server
Control: found -1 libuv1/1.44.2-1
Control: found -1 siridb-server/2.0.45-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of libuv1 the autopkgtest of siridb-server fails in 
testing when that autopkgtest is run with the binary packages of libuv1 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
libuv1 from testing1.44.2-1
siridb-server  from testing2.0.45-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. While the test 
normally runs in mere seconds, it now times out after 2:47 hours.


Currently this regression is blocking the migration of libuv1 to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=libuv1

https://ci.debian.net/data/autopkgtest/testing/amd64/s/siridb-server/24968423/log.gz

* fixing /etc/siridb/siridb.conf
* restarting siridb-server
* run queries
  get-version
["2.0.45"]
  new-database
"OK"
  new-account
"OK"
  change-password
"OK"
  drop-account
"OK"
  drop-database
"OK"
  drop-database again
{"error_msg":"cannot find database 'sampledb'"}
  get-accounts
["sa"]
  new-database for queries
"OK"
  get-databases
["sampledb"]
  query data (nothing there)
{}
  insert data
autopkgtest [21:02:28]: ERROR: timed out on command "su -s /bin/bash 
root -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || 
true;  . ~/.profile >/dev/null 2>&1 || true; 
buildtree="/tmp/autopkgtest-lxc.i2gfs6zb/downtmp/build.E6f/src"; mkdir 
-p -m 1777 -- 
"/tmp/autopkgtest-lxc.i2gfs6zb/downtmp/http-api-artifacts"; export 
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.i2gfs6zb/downtmp/http-api-artifacts"; 
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 
"/tmp/autopkgtest-lxc.i2gfs6zb/downtmp/autopkgtest_tmp"; export 
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.i2gfs6zb/downtmp/autopkgtest_tmp"; 
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; 
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=64; unset 
LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY 
LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT 
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo 
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f 
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; export 
AUTOPKGTEST_NORMAL_USER=debci; export ADT_NORMAL_USER=debci; chmod +x 
/tmp/autopkgtest-lxc.i2gfs6zb/downtmp/build.E6f/src/debian/tests/http-api; 
touch /tmp/autopkgtest-lxc.i2gfs6zb/downtmp/http-api-stdout 
/tmp/autopkgtest-lxc.i2gfs6zb/downtmp/http-api-stderr; 
/tmp/autopkgtest-lxc.i2gfs6zb/downtmp/build.E6f/src/debian/tests/http-api 
2> >(tee -a /tmp/autopkgtest-lxc.i2gfs6zb/downtmp/http-api-stderr >&2) > 
>(tee -a /tmp/autopkgtest-lxc.i2gfs6zb/downtmp/http-api-stdout);" 
(kind: test)

autopkgtest [21:02:29]: test http-api



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017747: imdbpy: autopkgtest regression: KeyError: 'top 1000 voters'

[Paul Gevers]

Source: imdbpy
Version: 2021.04.18-3
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer,

I happened to look at the results of the autopkgtest of your package and 
noticed it regressed some months ago. Unfortunately, it went by 
unnoticed, and the artifacts of the passing tests can't be checked 
anymore to see if this is due to a package that migrated while it broke 
your test. However, I have the suspicion this is due to changes on an 
external server.


Paul

https://ci.debian.net/packages/i/imdbpy/

https://ci.debian.net/data/autopkgtest/testing/amd64/i/imdbpy/24973321/log.gz

=== FAILURES 
===
 test_movie_demographics_votes_should_be_integers[http] 



ia = 

def test_movie_demographics_votes_should_be_integers(ia):
movie = ia.get_movie('0133093', info=['vote details'])  # Matrix
>   top1000 = movie['demographics']['top 1000 voters']
E   KeyError: 'top 1000 voters'

tests/test_http_movie_votes.py:34: KeyError
 test_movie_demographics_rating_should_be_numeric[http] 



ia = 

def test_movie_demographics_rating_should_be_numeric(ia):
movie = ia.get_movie('0133093', info=['vote details'])  # Matrix
>   top1000 = movie['demographics']['top 1000 voters']
E   KeyError: 'top 1000 voters'

tests/test_http_movie_votes.py:40: KeyError
___ test_search_movie_if_none_should_be_empty[http] 



ia = 

def test_search_movie_if_none_should_be_empty(ia):
movies = ia.search_movie('%e4%82%a2', results=500)
>   assert movies == []
E   assert [] == []
E Left contains one more item: title:_Episode 482: An Introduction To Jet Ski Fishing With Paul Hayes 
(2022) (Podcast Episode) - Australian Lure Fishing (2018)_>

E Use -v to get more diff

tests/test_http_search_movie.py:32: AssertionError
=== short test summary info 

FAILED 
tests/test_http_movie_votes.py::test_movie_demographics_votes_should_be_integers[http]
FAILED 
tests/test_http_movie_votes.py::test_movie_demographics_rating_should_be_numeric[http]
FAILED 
tests/test_http_search_movie.py::test_search_movie_if_none_should_be_empty[http]
= 3 failed, 338 passed, 19 skipped, 2 deselected in 150.37s 
(0:02:30) ==


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017746: assimp: CMake variable DRACO_LIBRARIES is deprecated

[Timo Röhling]

Source: assimp
Version: 5.2.4~ds0-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

the exported CMake configuration for draco has been overhauled
significantly, and the DRACO_LIBRARIES variable is no longer set.

I have patched draco to keep the variable for the time being, but the
proper way to link against draco is the exported target

draco::draco

now. Please update assimp at your convenience; as you also maintain a
Bullseye backport of assimp, I don't mind keeping the DRACO_LIBRARIES
variable for the Bookworm release. I would like to remove the variable
for Trixie, though.


Cheers
Timo


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmL/5W4ACgkQ+C8H+466
LVnsxgv9FfAzSu7N+H5krGBMudN3fJ+sZ8Pwoe1yyx7lwA5YzRIsSeCYJpQuOnJ4
6vkWsP4EHRr9k+API3SlevsyZyPZsAK7Pi8HepS6X6peTVr2u27OHZeawAQa+6cS
tA3FOgQe3SE2skk7SeaepC5KfhRvMUm23XehZwtRk0kbkCRoPYUljoiYmOAwNNfK
DATKfIHTTLLEaM8n2VMnWEfZZ3bxWh4Q8KmuJL2fjnFMuGXETbK4F2EoO5/A/FcH
LAN7y314nFQKkoOA7rAQJuc8sR0HhrVZZNt5EO74aN/ZgR06NysQhp4SvRIHbLPm
TDxxKYjwP7ZVVG+io9SbL4YLxH6aASkQSw1UO3vB8ZP+X9K6P+0w9SC8i/r1+g/J
pP01hb64Eu6EuR3VI2C7PxV6uZdpdirPfZnsbB4epYqBAokbc3/JmfdKjHYEgyJZ
m25G6IBZdh3Ra6QNzgIrKBQicKKcgGC+XDTtZcr/7nxqUZtwYB7roNz41QyirzB5
f+H8frfL
=Os8n
-END PGP SIGNATURE-

Bug#1017745: ddjvu hangs in some OOM situations

[Jakub Wilk]

Package: djvulibre-bin
Version: 3.5.28-2

It seems ddjvu can hang forever in some out-of-memory situations.
For example, setting the virtual memory limit to 32 MiB makes it hang:

  $ ulimit -Sv 32000
  $ ddjvu /usr/share/doc/libdjvulibre-dev/djvu3spec.djvu > /dev/null

Backtrace:

#0  0xf7f91559 in __kernel_vsyscall ()
#1  0xf7b0f6e2 in __libc_do_syscall () at 
../sysdeps/unix/sysv/linux/i386/libc-do-syscall.S:39
#2  0xf7a80491 in __futex_abstimed_wait_common32 (private=, cancel=, 
abstime=, op=, expected=, futex_word=) at ./nptl/futex-internal.c:40
#3  __futex_abstimed_wait_common (futex_word=0x56b5f108, expected=0, 
clockid=, abstime=0x0, private=0, cancel=true) at 
./nptl/futex-internal.c:99
#4  0xf7a8060b in __GI___futex_abstimed_wait_cancelable64 (futex_word=, 
expected=, clockid=, abstime=0x0, private=0) at 
./nptl/futex-internal.c:139
#5  0xf7a83627 in __pthread_cond_wait_common (abstime=, clockid=, mutex=, cond=) at ./nptl/pthread_cond_wait.c:504
#6  ___pthread_cond_wait (cond=cond@entry=0x56b5f0dc, 
mutex=mutex@entry=0x56b5f0c4) at ./nptl/pthread_cond_wait.c:619
#7  0xf7ec653d in DJVU::GMonitor::wait (this=this@entry=0x56b5f0b8) at 
GThreads.cpp:578
#8  0xf7f03eaa in ddjvu_message_wait (ctx=0x56b5f0b0) at ddjvuapi.cpp:733
#9  0x565c8963 in handle (wait=1) at ddjvu.cpp:164
#10 dopage (pageno=1) at ddjvu.cpp:739
#11 0x565c8d36 in parse_pagespec (s=0x565d8e12 "1", max_page=71, 
dopage=dopage@entry=0x565c8890 ) at ddjvu.cpp:828
#12 0x565c68c4 in main (argc=2, argv=0xffa3e9e4) at ddjvu.cpp:1217


-- System Information:
Architecture: i386

Versions of packages djvulibre-bin depends on:
ii  libc6   2.34-4
ii  libdjvulibre21  3.5.28-2
ii  libgcc-s1   12.1.0-8
ii  libstdc++6  12.1.0-8
ii  libtiff54.4.0-4
ii  curl7.84.0-2

--
Jakub Wilk

Bug#1006500:

[St Savage, Shane]

This is preventing network hardware from being detected during an attempted PXE 
install of Debian Bullseye/Stable for me as well. Any chance of getting 
firmware-bnx2x fixed soon?

Bug#1017744: RFP: solanum -- IRCv3 server designed to be highly scalable

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: solanum
  Version : N/A
  Upstream Author : https://github.com/solanum-ircd
* URL : https://solanum.chat/
* License : GPL-2, but probably a mess
  Programming Lang: C
  Description : IRCv3 server designed to be highly scalable

Solanum is an IRCv3 server designed to be highly scalable. It
implements IRCv3.1 and some parts of IRCv3.2.

It is meant to be used with an IRCv3-capable services implementation
such as Atheme or Anope.



Solanum is the Charybdis fork that has been built, launched, and used
by the Libera.chat folks during the upheaval that ultimately led to
freenode's death. From what I understand the OFTC people are also
involved.

Charybdis has been removed from Debian in #1017344 with the
understanding that it would be replaced by Solanum. Unfortunately, it
doesn't look like the Solanum team is making official releases just
yet.

Bug#1017741: [PATCH] Update package description for EFI*

[Colin Watson]

On Sat, Aug 20, 2022 at 03:50:44AM +0900, Osamu Aoki wrote:
> diff --git a/debian/control b/debian/control
> index 71cca4436..74769e0eb 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -263,11 +263,11 @@ Description: GRand Unified Bootloader, version 2 
> (EFI-IA32 modules)
>  update-grub.
>   .
>   This package contains GRUB modules that have been built for use with the
> - EFI-IA32 architecture, as used by Intel Macs (unless a BIOS interface has
> - been activated).  It can be installed in parallel with other flavours, but
> - will not automatically install GRUB as the active boot loader nor
> - automatically update grub.cfg on upgrade unless grub-efi-ia32 is also
> - installed.
> + EFI-IA32 architecture, as used by modern PCs with UEFI (unless a legacy PC
> + BIOS interface has been activated).  It can be installed in parallel with
> + other flavours, but will not automatically install GRUB as the active boot
> + loader nor automatically update grub.cfg on upgrade unless grub-efi-ia32 is
> + also installed.
>  
>  Package: grub-efi-ia32-dbg
>  Section: debug
> @@ -296,9 +296,9 @@ Description: GRand Unified Bootloader, version 2 
> (EFI-IA32 version)
>  update-grub.
>   .
>   This is a dependency package for a version of GRUB that has been built for
> - use with the EFI-IA32 architecture, as used by Intel Macs (unless a BIOS
> - interface has been activated).  Installing this package indicates that this
> - version of GRUB should be the active boot loader.
> + use with the EFI-IA32 architecture, as used by modern PCs with UEFI (unless 
> a
> + legacy PC BIOS interface has been activated).  Installing this package
> + indicates that this version of GRUB should be the active boot loader.
>  
>  Package: grub-efi-ia32-signed-template
>  Architecture: i386

This part of the patch looks wrong.  The efi-ia32 platform (i.e. 32-bit
firmware; note that this is *not* about which OS architecture is in use)
is in fact suitable for only very few modern PCs; IIRC there were a few
others beyond just Intel Macs, though I think Intel Macs were still the
majority sold.

The changes look more accurate for the efi-amd64 platform (i.e. 64-bit
firmware).

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1014044: dcmtk: Multiple CVEs reported

[Salvatore Bonaccorso]

Control: clone -1 -2
Control: retitle -1 dcmtk: CVE-2022-2121
Control: retitle -2 dcmtk: CVE-2022-2119 CVE-2022-2120
Control: fixed -1 3.6.7-1

Hi

On Wed, Jun 29, 2022 at 10:43:59AM +0200, Mathieu Malaterre wrote:
> Package: dcmtk
> Version: 3.6.5-1
> Severity: important
> 
> Dear Maintainer,
> 
> Multiples CVEs have been reported against DCMTK:
> 
> - CVE-2022-2119
> - CVE-2022-2120
> - CVE-2022-2121
> 
> Should we track them ? Should it be handled by debian-security team ?

Cloning/splitting this bug in two because CVE-2022-2121 got fixed in
the 3.6.7 release upstream but CVE-2022-2120 and CVE-2022-2121 only
afterwards.

Regards,
Salvatore

Bug#1016754: po4a: Incorrect bold handling for manpages bug 2

[Helge Kreutzmann]

Hello Martin,
On Thu, Aug 18, 2022 at 08:29:53PM +0200, Martin Quinson wrote:
> could you please be more specific on what's going wrong? You say that the 
> "english is in roman, while the translated text is in German". Well. The 
> translation being in German does not sound like a bug to me :)

I apologize. The sentence should read:

The english original is in roman font, while the translated text is in bold.
   

> I tried to check on the rendered manpages, but I don't see any difference 
> between the english and german text here. They are both rendered as regular 
> text.

I double checked both in an xterm(1) and on the Linux console, the
english version is in roman, while the German version is in bold.
Several paragraphs.

> I'm using `man -l ` to render the page, so maybe that's why I don't see 
> any difference. Please tell me how to render if I'm not doing it right.

I simply use man , however, this also happens with "man -l "

> Thanks for the info,

Thanks for your support!

Greetings

 Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1017742: po4a: Please provide marker for double strings during po4a-gettextize

[Helge Kreutzmann]

Package: po4a
Version: 0.67-2
Severity: wishlist

Since recently po4a-gettextize adds spaces at the end of strings
during gettextisation, if strings occure multiple times in the master 
file (or translation).

In production, multiple indentical strings in the original file are 
only stored once in the po file (as they are translated the same). 

Therefore, translators need to review those strings carefully and
remove those entries from the po file, which have this final space
added. In this process they need to choose the most appropriate
translation to keep.

Currently, this can be quite difficult, as the string can occur
multiple times and the trailing space(s) are difficult to spot in
large files. Also these trailing spaces are hard to get a good regular
expression for searching.

Therefor I kindly ask you if you could mark those strings in addition
(!) with a suitable translator comment (e.g. "Potential duplicate 
string, review and consolidate"). This would users allow to use msggrep(1)
with the option -C to filter them out for review.

Thanks for considering.


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

Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages po4a depends on:
ii  gettext 0.21-6
ii  libpod-parser-perl  1.65-1
ii  libsgmls-perl   1.03ii-37
ii  libsyntax-keyword-try-perl  0.27-1
ii  libyaml-tiny-perl   1.73-1
ii  opensp  1.5.2-13+b2
ii  perl5.34.0-5

Versions of packages po4a recommends:
ii  liblocale-gettext-perl 1.07-4+b2
ii  libterm-readkey-perl   2.38-2
ii  libtext-wrapi18n-perl  0.06-9
ii  libunicode-linebreak-perl  0.0.20190101-1+b4

po4a suggests no packages.

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1017741: [PATCH] Update package description for EFI*

[Osamu Aoki]

Source: grub2
Version: 2.04-20
Severity: minor
Tags: patch

Most modern PCs has been sold with UEFI support for more than 10 years.

Microsoft's certification requirements for now obsolete Windows 8
required UEFI since 2012.

In 2006, Intel Mac was practically the only one but now Macs are
ARM-based.  So mentioning Macs here is misleading.

(Patch file may be sent separately.)

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

Kernel: Linux 5.18.0-4-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
>From 4ee56739aa78d51224c27a4ea1164160b2368347 Mon Sep 17 00:00:00 2001
From: Osamu Aoki 
Date: Sat, 20 Aug 2022 03:31:54 +0900
Subject: [PATCH] Update package description for EFI*

Most modern PCs has been sold with UEFI support for more than 10 years.

Microsoft's certification requirements for now obsolete Windows 8
required UEFI since 2012.

In 2006, Intel Mac was practically the only one but now Macs are
ARM-based.  So mentioning Macs here is misleading.

Signed-off-by: Osamu Aoki 
---
 debian/control | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/debian/control b/debian/control
index 71cca4436..74769e0eb 100644
--- a/debian/control
+++ b/debian/control
@@ -263,11 +263,11 @@ Description: GRand Unified Bootloader, version 2 
(EFI-IA32 modules)
 update-grub.
  .
  This package contains GRUB modules that have been built for use with the
- EFI-IA32 architecture, as used by Intel Macs (unless a BIOS interface has
- been activated).  It can be installed in parallel with other flavours, but
- will not automatically install GRUB as the active boot loader nor
- automatically update grub.cfg on upgrade unless grub-efi-ia32 is also
- installed.
+ EFI-IA32 architecture, as used by modern PCs with UEFI (unless a legacy PC
+ BIOS interface has been activated).  It can be installed in parallel with
+ other flavours, but will not automatically install GRUB as the active boot
+ loader nor automatically update grub.cfg on upgrade unless grub-efi-ia32 is
+ also installed.
 
 Package: grub-efi-ia32-dbg
 Section: debug
@@ -296,9 +296,9 @@ Description: GRand Unified Bootloader, version 2 (EFI-IA32 
version)
 update-grub.
  .
  This is a dependency package for a version of GRUB that has been built for
- use with the EFI-IA32 architecture, as used by Intel Macs (unless a BIOS
- interface has been activated).  Installing this package indicates that this
- version of GRUB should be the active boot loader.
+ use with the EFI-IA32 architecture, as used by modern PCs with UEFI (unless a
+ legacy PC BIOS interface has been activated).  Installing this package
+ indicates that this version of GRUB should be the active boot loader.
 
 Package: grub-efi-ia32-signed-template
 Architecture: i386
@@ -325,11 +325,11 @@ Description: GRand Unified Bootloader, version 2 
(EFI-AMD64 modules)
 update-grub.
  .
  This package contains GRUB modules that have been built for use with the
- EFI-AMD64 architecture, as used by Intel Macs (unless a BIOS interface has
- been activated).  It can be installed in parallel with other flavours, but
- will not automatically install GRUB as the active boot loader nor
- automatically update grub.cfg on upgrade unless grub-efi-amd64 is also
- installed.
+ EFI-AMD64 architecture, as used by modern PCs with UEFI (unless a legacy PC
+ BIOS interface has been activated).  It can be installed in parallel with
+ other flavours, but will not automatically install GRUB as the active boot
+ loader nor automatically update grub.cfg on upgrade unless grub-efi-amd64 is
+ also installed.
 
 Package: grub-efi-amd64-dbg
 Section: debug
@@ -358,9 +358,9 @@ Description: GRand Unified Bootloader, version 2 (EFI-AMD64 
version)
 update-grub.
  .
  This is a dependency package for a version of GRUB that has been built for
- use with the EFI-AMD64 architecture, as used by Intel Macs (unless a BIOS
- interface has been activated).  Installing this package indicates that this
- version of GRUB should be the active boot loader.
+ use with the EFI-AMD64 architecture, as used by modern PCs with UEFI (unless
+ a legacy PC BIOS interface has been activated).  Installing this package
+ indicates that this version of GRUB should be the active boot loader.
 
 Package: grub-efi-amd64-signed-template
 Architecture: amd64
-- 
2.35.1

Bug#1017740: transition: draco

[Timo Röhling]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear release team,

I'd like to transition draco after its SONAME bump.
The ben file looks good:
https://release.debian.org/transitions/html/auto-draco.html

All reverse dependencies build sucessfully on amd64.


Cheers
Timo


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmL/20sACgkQ+C8H+466
LVluVwv/ZqAVTnKQPAl3V9qwU+9IilDYOuyUhDySmZVwXq79LlIWxTOgCpSHrxAX
4WxOVBUrfCSG7ZkOYvyJ/Do9B/mSI8K5kZ8P+gj8ot5vF+95aq3QftDw5csa3eEH
yEGzdugc42qsKSA1wtNYE1cdC2n8UBTPCePY0OB86/6QHEXFUzhHaz+gGQooKNHd
k8hsW3Z4941KespUyqWB+Qdc//E1BeTVAtzQ52yfTw0GKVMI83iPh2q0B4Umuqts
1Y0KlzijgBfCEUdoU7gqDZ6tYASFiDf7SxKeOPdaaX2o+ugKZO09M4fEAo5pjVKg
j0JkLtjNCplNSm09mFVZXJsT0wv1/IrlJ4G1YYyY/cseB8wKgi5J7LfK8Bn1dT4L
0b3r2ldaq4y7ukyZg/d2Im10m3nOrv7kl8Y6xOTrRLgWpMfq7GkCLGM6g84+skKd
/nCp0pPrd3YzDD/Nt1heUFAyFtmAakh1eV6flqIEuyQjqkSfU6YzN3+jd2mM/Vau
tcstoFPF
=X4pv
-END PGP SIGNATURE-

Bug#1017739: emacs-lucid cannot start after upgrade

[Russ Allbery]

Package: emacs-lucid
Version: 1:28.1+1-1
Severity: grave
X-Debbugs-Cc: r...@debian.org

The 28.1 version of emacs-lucid fails on startup with a cryptic error
message:

% emacs
Cannot find suitable directory for output in ‘comp-native-load-path’.

Running emacs -q allows it to start, but it still reports the same error
immediately during startup, and attempting to do someting as basic as
M-x set-variable (to try to enable debug-on-error) fails with a similar
error message:

defalias: Cannot find suitable directory for output in ‘comp-native-load-path’.

emacs -q --no-site-file avoids the error on startup, but M-x set-variable
still immediately fails with the same error.

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

Kernel: Linux 5.18.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 emacs-lucid depends on:
ii  emacs-bin-common 1:28.1+1-1
ii  emacs-common 1:28.1+1-1
ii  libacl1  2.3.1-1
ii  libasound2   1.2.7.2-1
ii  libc62.34-4
ii  libcairo21.16.0-6
ii  libdbus-1-3  1.14.0-2
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.12.1+dfsg-3
ii  libgccjit0   12.1.0-8
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libgif7  5.2.1-2.5
ii  libglib2.0-0 2.72.3-1+b1
ii  libgmp10 2:6.2.1+dfsg1-1
ii  libgnutls30  3.7.7-2
ii  libgpm2  1.20.7-10
ii  libharfbuzz0b2.7.4-1+b1
ii  libice6  2:1.0.10-1
ii  libjansson4  2.14-2
ii  libjpeg62-turbo  1:2.1.2-1
ii  liblcms2-2   2.13.1-1
ii  libm17n-01.8.0-4
ii  libotf1  0.9.16-3
ii  libpng16-16  1.6.37-5
ii  librsvg2-2   2.54.4+dfsg-1
ii  libselinux1  3.4-1+b1
ii  libsm6   2:1.2.3-1
ii  libsystemd0  251.4-1
ii  libtiff5 4.4.0-4
ii  libtinfo66.3+20220423-2
ii  libx11-6 2:1.8.1-2
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:6.0.0-1
ii  libxinerama1 2:1.1.4-3
ii  libxml2  2.9.14+dfsg-1+b1
ii  libxmu6  2:1.1.3-3
ii  libxpm4  1:3.5.12-1
ii  libxrandr2   2:1.5.2-2+b1
ii  libxrender1  1:0.9.10-1.1
ii  libxt6   1:1.2.1-1
ii  xaw3dg   1.5+F-1
ii  zlib1g   1:1.2.11.dfsg-4.1

Versions of packages emacs-lucid recommends:
pn  fonts-noto-color-emoji  

Versions of packages emacs-lucid suggests:
pn  emacs-common-non-dfsg  

-- no debconf information

Bug#745399: mailpile abandoned?

[Antoine Beaupré]

Hi,

It's been almost three years since the last update on the Mailpile blog:

https://www.mailpile.is/blog/

... and the second to last one was not encouraging:

https://www.mailpile.is/blog/2019-04-06_Burnout.html

More recently, in Sept 2021, upstream made an update here:

https://community.mailpile.is/t/a-very-uninformative-progress-update-mailpile-2/785

... where they say the biggest blocker is the Python 3 port. Apparently,
Mailpile was written in Python 2 and that port isn't complete. The work
is happening in a "quiet" project called "Moggie":

https://github.com/BjarniRunar/moggie

... which can read and search email and ... that's it really. You can't
compose, reply, move, tag, emails, and there isn't even a web
interface. There's no IMAP or SMTP support.

At this point, I suspect someone less tolerant than me might just
declare Mailpile dead, but I'm happy to give upstream the time they need
to do whatever they need to. It's just that we're trying to remove
Python 2 from Bookworm, so, in this state, the project really can't be
packaged yet...

In fact, from that perspective, if anything gets packaged, it would be
moggie, so maybe this RFP should be closed, especially since the moggie
upstream explicitely states that we shouldn't contribute to the project
yet...

A.
-- 
Travail, du latin Tri Palium trois pieux, instrument de torture.

Bug#1017738: installation-reports: 99% successful install

[Vagrant Cascadian]

Package: installation-reports
Severity: normal
X-Debbugs-Cc: vagr...@debian.org

Boot method: network
Image version: 
https://d-i.debian.org/daily-images/arm64/20220818-02:26/netboot/netboot.tar.gz
Date: 2022-08-18 teatime

Machine: Pine64+
Partitions:
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs963048   0963048   0% /dev
tmpfs  tmpfs   203160 592202568   1% /run
/dev/mmcblk0p2 ext4   6157644 2142336   3681536  37% /
tmpfs  tmpfs  1015780   0   1015780   0% /dev/shm
tmpfs  tmpfs 5120   0  5120   0% /run/lock
tmpfs  tmpfs   203156   0203156   0% /run/user/1001


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

Only problem was the device-tree .dtb files were not actually included
in the netboot.tar.gz, and so I had to manually download the
appropriate ones from
https://d-i.debian.org/daily-images/arm64/20220818-02:26/device-tree/
and dump them into my tftp dir.

I guess I also wasn't usiong grub to boot,instead using u-boot's
pxelinux.cfg support, so I was already diverging a bit anyways.

Not sure if we should add pxelinux.cfg and dtbs out of the box. I'd prefer it.

I'm not sure if u-boot supports network-booting EFI ... but it might,
and then I could just try the grub method.


live well,
  vagrant

-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20220818-02:04:56"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux p64cbk 5.18.0-4-arm64 #1 SMP Debian 5.18.16-1 (2022-08-10) 
aarch64 GNU/Linux
usb-list: 
usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.18.0-4-arm64 ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.18.0-4-arm64 ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 03 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.18.0-4-arm64 ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 03 Device 02: USB2.0 Hub [2109:2813]
usb-list:Level 01 Parent 01 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: VIA Labs, Inc.
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 03 Device 03: ASMT1051 [174c:55aa]
usb-list:Level 02 Parent 02 Port 01  Class 00(>ifc ) Subclass 00 Protocol 00
usb-list:Manufacturer: asmedia
usb-list:Interface 00: Class 08(mstor) Subclass 06 Protocol 62 Driver uas
usb-list: 
usb-list: Bus 04 Device 01: MUSB HDRC host driver [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 5.18.0-4-arm64 musb-hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 05 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.18.0-4-arm64 ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
lsmod: Module  Size  Used by
lsmod: dm_mod143360  7
lsmod: dax36864  1 dm_mod
lsmod: md_mod167936  0
lsmod: xfs  1376256  0
lsmod: jfs   196608  0
lsmod: btrfs1470464  0
lsmod: xor20480  1 btrfs
lsmod: xor_neon   20480  1 xor
lsmod: raid6_pq  106496  1 btrfs
lsmod: zstd_compress 253952  1 btrfs
lsmod: libcrc32c  16384  2 btrfs,xfs
lsmod: vfat   28672  0
lsmod: fat81920  1 vfat
lsmod: ext4  761856  1
lsmod: crc16  16384  1 ext4
lsmod: 

Bug#995640: boxbackup: FTBFS with OpenSSL 3.0

[Bastian Germann]

Am 19.08.22 um 16:54 schrieb Ileana Dumitrescu:

I fixed the control file email and copyright file in the most recent commits


The copyright file is not fixed but I will upload because closing the RC bug is 
an improvement.
Just read the upstream license. The project is dual licensed with GPL and one 
of the BSD clauses seems to be gone.

A nitpick that is also mentioned on the tracker for d/watch: gpgmode has to be 
pgpmode.

Bug#1017735: dolphin: Dolphin "back" button incorrect behaviour after search

[Gary Dale]

Package: dolphin
Version: 4:22.04.3-1
Severity: minor

Dear Maintainer,

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

   * What led up to the situation?
This is a longstanding issue. Navigate to a directory, then execute a search 
(Edit | Search). Next go to any
other directory. When you hit the "back" button, you will go to the previous 
directory rather than to the search
results. Hitting "back" again takes you to the directory you just left. Hitting 
it a third time finally returns
you to the search.

   * What exactly did you do (or not do) that was effective (or  
ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?
I should only have to hit "back" once to go back to the search results (the 
previous panel).

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


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

Kernel: Linux 5.18.0-4-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=iu_CA.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dolphin depends on:
ii  baloo-kf5 5.96.0-1
ii  kinit 5.96.0-1
ii  kio   5.96.0-3
ii  libc6 2.34-3
ii  libdolphinvcs54:22.04.3-1
ii  libkf5activities5 5.96.0-2
ii  libkf5baloo5  5.96.0-1
ii  libkf5baloowidgets5   4:22.04.3-1
ii  libkf5bookmarks5  5.96.0-1
ii  libkf5codecs5 5.96.0-1
ii  libkf5completion5 5.96.0-1
ii  libkf5configcore5 5.96.0-1
ii  libkf5configgui5  5.96.0-1
ii  libkf5configwidgets5  5.96.0-1
ii  libkf5coreaddons5 5.96.0-1
ii  libkf5crash5  5.96.0-1
ii  libkf5dbusaddons5 5.96.0-1
ii  libkf5filemetadata3   5.96.0-1
ii  libkf5i18n5   5.96.0-1
ii  libkf5iconthemes5 5.96.0-1
ii  libkf5itemviews5  5.96.0-1
ii  libkf5jobwidgets5 5.96.0-1
ii  libkf5kcmutils5   5.96.0-1
ii  libkf5kiocore55.96.0-3
ii  libkf5kiofilewidgets5 5.96.0-3
ii  libkf5kiogui5 5.96.0-3
ii  libkf5kiowidgets5 5.96.0-3
ii  libkf5newstuff5   5.96.0-1
ii  libkf5notifications5  5.96.0-1
ii  libkf5parts5  5.96.0-1
ii  libkf5service-bin 5.96.0-1
ii  libkf5service55.96.0-1
ii  libkf5solid5  5.96.0-1
ii  libkf5textwidgets55.96.0-1
ii  libkf5widgetsaddons5  5.96.0-1
ii  libkf5windowsystem5   5.96.0-1
ii  libkf5xmlgui5 5.96.0-1
ii  libkuserfeedbackcore1 1.2.0-2
ii  libkuserfeedbackwidgets1  1.2.0-2
ii  libpackagekitqt5-11.0.2-1
ii  libphonon4qt5-4   4:4.11.1-4
ii  libqt5core5a  5.15.4+dfsg-5
ii  libqt5dbus5   5.15.4+dfsg-5
ii  libqt5gui55.15.4+dfsg-5
ii  libqt5widgets55.15.4+dfsg-5
ii  libqt5xml55.15.4+dfsg-5
ii  libstdc++612.1.0-8
ii  phonon4qt54:4.11.1-4

Versions of packages dolphin recommends:
ii  ffmpegthumbs  4:22.04.2-1
ii  kdegraphics-thumbnailers  4:21.12.3-1
ii  kimageformat-plugins  5.96.0-1
ii  kio-extras4:22.04.3-1

Versions of packages dolphin suggests:
ii  dolphin-plugins  4:22.04.1-1

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_GB",
LC_ALL = (unset),
LC_TIME = "en_CA.UTF-8",
LC_MONETARY = "en_CA.UTF-8",
LC_CTYPE = "C.UTF-8",
LC_COLLATE = "en_CA.UTF-8",
LC_MEASUREMENT = "en_CA.UTF-8",
LC_NUMERIC = "en_CA.UTF-8",
LANG = "iu_CA.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

-- debsums errors found:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_GB",
LC_ALL = (unset),
LC_TIME = "en_CA.UTF-8",
LC_MONETARY = "en_CA.UTF-8",
LC_CTYPE = "C.UTF-8",
LC_COLLATE = "en_CA.UTF-8",
LC_MEASUREMENT = "en_CA.UTF-8",
LC_NUMERIC = "en_CA.UTF-8",
LANG = "iu_CA.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Bug#1013578: Cannot reproduce either -- downgrading

[Martina Ferrari]

Ugh, I forgot to CC all interested parties, sorry about that.

On 19/08/2022 18:19, Martina Ferrari wrote:

Control: severity -1 important

Hi,

I am also not being able to reproduce this issue, even when setting 
GOMAXPROC to 1, and since there has been no more activity I am 
downgrading the severity to prevent the package from being autoremoved.


Please, feel free to raise severity again if you can provide some more 
information to reproduce it.




--
Martina Ferrari (Tina)

Bug#1017616: Unicode

[Teus Benschop]

I would agree that this is a package bug.

But I think that this is not related to "packaging" only.

Upstream too would like to fix the licensing issue in a proper way.

Feel free to remove the upstream reference though.

Bug#1013578: Cannot reproduce either -- downgrading

[Martina Ferrari]

Control: severity -1 important

Hi,

I am also not being able to reproduce this issue, even when setting 
GOMAXPROC to 1, and since there has been no more activity I am 
downgrading the severity to prevent the package from being autoremoved.


Please, feel free to raise severity again if you can provide some more 
information to reproduce it.


--
Martina Ferrari (Tina)

Bug#1017734: pmix: mipsel FTBFS: out of memory, needs -mxgot?

[Drew Parsons]

Source: pmix
Version: 4.2.0~rc2-1
Severity: normal


mipsel has started failing to build pmix 4.2.0. It's running out of
memory building the python extensions:

 creating build/temp.linux-mips-3.10/<>/bindings/python
 mipsel-linux-gnu-gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 
-Wall -g -fstack-protector-strong -Wformat -Werror=format-security -DNDEBUG -g 
-O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fPIC -fPIC 
-finline-functions -fvisibility=hidden -Wformat -Werror=format-security 
-iquote/<>/debian/static-build -iquote/<> 
-iquote/<>/src -iquote/<>/debian/static-build/include 
-I/<>/include -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include -fPIC 
-I/<>/debian/static-build/include -I/<>/include 
-I/usr/include/python3.10 -c /<>/bindings/python/pmix.c -o 
build/temp.linux-mips-3.10/<>/bindings/python/pmix.o
 
 cc1: out of memory allocating 65524 bytes after a total of 23920640 bytes
 error: command '/usr/bin/mipsel-linux-gnu-gcc' failed with exit code 1


I've had memory issues in some of my packages, most recently with
dolfinx 0.4.0.  With some discussion on the MIPS mailing list from
https://lists.debian.org/debian-mips/2022/06/msg0.html we resolved
it mainly with the -mxgot build flag (similar to -mcmodel=medium on
other arches).

-Os -g0 can also help if memory exhaustion happens due to heavily
templated C++ header files but I guess that's not the issue in the case
of pmix.

You might have a a better fix for the problem but -mxgot is my
suggestion!

Bug#1017733: emacs: Newest version makes elisp packages builts fail

[Aymeric Agon-Rambosson]

Package: emacs Version: 1:28.1+1-0.1 Severity: serious 
X-Debbugs-Cc:

none, Aymeric Agon-Rambosson 

Dear Maintainer,

Since emacs 1:28.1+1-1 hit unstable today, all elisp packages 
builts fail.


Here I join a log file for an attempt to build a new elpa package 
against unstable using sbuild :




elpa-eglot_1.8-1_amd64-2022-08-19T12:12:11Z.build
Description: Binary data


The problem appears at line 593, just after or during the 
execution of the script 
/usr/lib/emacsen-common/packages/install/emacsen-common.


This information is corroborated by the fact that every elisp 
package that had defined an autopkgtest test suite reports a 
regression (https://tracker.debian.org/pkg/emacs), this regression 
being the same segmentation fault as reported here.


Best,

Aymeric Agon-Rambosson

Bug#1017616: bibledit: Unicode data license violation

[Bastian Germann]

This is a package bug only and not relevant for upstream.

Bug#1017509: Reply

[Andrej Shadura]

Hi,

On Fri, 19 Aug 2022, at 18:47, joffrey575 wrote:
> Be appear,
> 
> IMO this looks like an outdated Python package dependency `matrix-common`.
> 
> python3-matrix-common/bullseye-backports,now 1.2.1-1~bpo11+1
> 

Why is it? pyproject.toml says:

matrix-common = "^1.2.1"


-- 
Cheers,
  Andrej

Bug#1017509: Reply

[joffrey575]

Be appear,

IMO this looks like an outdated Python package dependency matrix-common.

python3-matrix-common/bullseye-backports,now 1.2.1-1~bpo11+1

Bug#1004579: mplayer: FTBFS with ffmpeg 5.0

[Olivier Gayot]

Package: mplayer
Version: 2:1.4+ds1-3
Followup-For: Bug #1004579
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

The upstream release 1.5 supports ffmpeg 5 and would solve this issue.
In the meantime, I have attempted to backport the upstream patches on
top of the 1.4 version.

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

  * Backport upstream patches to build against ffmpeg 5 (LP: #1987114)

Thanks for considering the patch.


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

Kernel: Linux 5.15.0-46-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru mplayer-1.4+ds1/debian/patches/r38215.patch 
mplayer-1.4+ds1/debian/patches/r38215.patch
--- mplayer-1.4+ds1/debian/patches/r38215.patch 1970-01-01 01:00:00.0 
+0100
+++ mplayer-1.4+ds1/debian/patches/r38215.patch 2022-08-19 17:10:25.0 
+0200
@@ -0,0 +1,61 @@
+Description: av_helpers: switch to new lavc audio encode API.
+Origin: upstream, commit: r38215
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004579
+Forwarded: no
+Last-Update: 2022-08-19
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: b/av_helpers.c
+===
+--- a/av_helpers.c 2022-08-19 16:52:03.979666019 +0200
 b/av_helpers.c 2022-08-19 16:52:37.0 +0200
+@@ -98,7 +98,6 @@
+ if (!avcodec_initialized) {
+ show_av_version(MSGT_DECVIDEO, "libavcodec", LIBAVCODEC_VERSION_INT,
+ avcodec_version(), avcodec_configuration());
+-avcodec_register_all();
+ avcodec_initialized = 1;
+ av_log_set_callback(mp_msp_av_log_callback);
+ }
+@@ -109,7 +108,6 @@
+ if (!avformat_initialized) {
+ show_av_version(MSGT_DEMUX, "libavformat", LIBAVFORMAT_VERSION_INT,
+ avformat_version(), avformat_configuration());
+-av_register_all();
+ avformat_initialized = 1;
+ av_log_set_callback(mp_msp_av_log_callback);
+ }
+@@ -132,8 +130,6 @@
+ ctx->channels,
+ src_len / bps, bps);
+ }
+-pkt.data = dst;
+-pkt.size = dst_len;
+ frame->nb_samples = src_len / ctx->channels / bps;
+ if (planar) {
+ // TODO: this is horribly inefficient.
+@@ -150,11 +146,22 @@
+ }
+ }
+ }
++frame->format = ctx->sample_fmt;
++frame->channels = ctx->channels;
+ n = avcodec_fill_audio_frame(frame, ctx->channels, ctx->sample_fmt, src, 
src_len, 1);
+ if (n < 0) return 0;
+-n = avcodec_encode_audio2(ctx, , frame, );
++n = avcodec_send_frame(ctx, frame);
++av_init_packet();
++got = avcodec_receive_packet(ctx, );
+ av_frame_free();
+ if (planar) av_free(src);
+ if (n < 0) return n;
+-return got ? pkt.size : 0;
++if (got >= 0) {
++int size = pkt.size;
++if (size > dst_len) return -1;
++memcpy(dst, pkt.data, size);
++av_packet_unref();
++return size;
++}
++return 0;
+ }
diff -Nru mplayer-1.4+ds1/debian/patches/r38216.patch 
mplayer-1.4+ds1/debian/patches/r38216.patch
--- mplayer-1.4+ds1/debian/patches/r38216.patch 1970-01-01 01:00:00.0 
+0100
+++ mplayer-1.4+ds1/debian/patches/r38216.patch 2022-08-19 17:09:46.0 
+0200
@@ -0,0 +1,86 @@
+Description: ad_ffmpeg: switch to new lavc API.
+Origin: upstream, commit: r38216
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004579
+Forwarded: no
+Last-Update: 2022-08-19
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: b/libmpcodecs/ad_ffmpeg.c
+===
+--- a/libmpcodecs/ad_ffmpeg.c  2022-08-19 16:52:04.011665773 +0200
 b/libmpcodecs/ad_ffmpeg.c  2022-08-19 16:52:04.003665834 +0200
+@@ -310,34 +310,41 @@
+ 
+ static int decode_audio(sh_audio_t *sh_audio,unsigned char *buf,int 
minlen,int maxlen)
+ {
++int draining_started = 0;
+ unsigned char *start=NULL;
+-int y,len=-1, got_frame;
++int y,len=-1;
+ AVFrame *frame = av_frame_alloc();
+ 
+ if (!frame)
+ return AVERROR(ENOMEM);
+ 
+ while(lencontext, frame);
++  if (y == AVERROR(EAGAIN) || y == AVERROR_EOF) {
++  AVPacket pkt;
+   double pts;
+   int x=ds_get_packet_pts(sh_audio->ds,, );
+   if(x<=0) {
+   start = NULL;
+   x = 0;
+   ds_parse(sh_audio->ds, , , MP_NOPTS_VALUE, 0);
+- 

Bug#1017732: gnuradio: Missing build dependency on cppzmq-dev

[Adrian Bunk]

Source: gnuradio
Version: 3.10.3.0-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=gnuradio=3.10.3.0-3%2Bb1

...
-- Checking for module 'libzmq'
--   Found libzmq, version 4.3.4
-- Could NOT find ZeroMQ (missing: ZEROMQ_INCLUDE_DIRS) 
-- 
-- Configuring gr-zeromq support...
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Dependency ZEROMQ_FOUND = FALSE
--   Disabling gr-zeromq support.
--   Override with -DENABLE_GR_ZEROMQ=ON/OFF
...
   dh_install -a -O--buildsystem=cmake\+ninja
dh_install: warning: Cannot find (any matches for) 
"usr/lib/*/libgnuradio-zeromq.so.3.10.3*" (tried in ., debian/tmp)

dh_install: warning: libgnuradio-zeromq3.10.3 missing files: 
usr/lib/*/libgnuradio-zeromq.so.3.10.3*
dh_install: error: missing files, aborting
make: *** [debian/rules:13: binary-arch] Error 25



See #972785 for background.

Bug#1017729: cinnamon-l10n: Upgrading to 5.4.2-2 breaks cinnamon

[Fabio Fantoni]

Control: severity -1 important

Il 19/08/2022 17:55, xioren huan ha scritto:

Package: cinnamon-l10n
Version: 5.4.2-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: xioren00+deb...@protonmail.com

Dear Maintainer,

Updating cinnamon-l10n from 5.2.2-1 to 5.4.2-2 removes the packages: cinnamon, cinnamon-core, 
cinnamon-common. I don't know if this is intended but upon restarting cinnamon fails to load at 
log-in with error: "failed to load session "cinnamon"".
Switching to another tty and entering the command: "exec cinnamon-session --debug" gives 
error: "(cinnamon-session:2300) Warning: cannot open display".


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

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

-- no debconf information

the reverse deps breaks are intentional for avoid partial upgrade (that 
cause big amount of unexpected issues), when not all components packages 
are migrated users must wait cinnamon packages upgrade.


I thinked also make wait the reverse deps to be ready for migrate all in 
the same day but seems that the wait work only with deps, as 
cinnamon-l10n is only in recommends is an exception.


Make as dep is not good because make it uninstallable with both cinnamon 
and nemo for users that don't need and don't want it.


Remove the reverse-deps breaks will make it install without migrate of 
other components and will broke the translations (and probably cause 
also other issues), is also not good.


The breaks should be the better way FWIK so the users can know and avoid 
upgrade, years ago before add of the reverse-deps breaks there was many 
users that partially upgraded cinnamon and reported important or 
critical issues only related to partial upgrade.


Therefore it will be necessary to think carefully about if and what to 
change




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017731: iem-plugin-suite: fails to build with JUCE-7.0.2

[IOhannes m zmoelnig]

Source: iem-plugin-suite
Version: 1.11.1-1
Severity: normal

Dear Maintainer,

JUCE-7.0.2 (not yet in Debian, but soon) introduced some BREAKING-CHANGES.txt
regarding matrix3D multiplication.
iem-plugin-suite is affected by this.

at least the following plugins fail to build:
- AllRadDecoder


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

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

Bug#1017730: pmix: drop Build-Depends: pandoc

[Drew Parsons]

Incidentally the man pages don't seem to be getting installed.  I'm not 
sure how it should be done via make install (they get listed in 
EXTRA_DIST).  Possibly easier to just create a 
debian/libpmix-bin.manpages and let dh_installman install them directly 
from source.


Drew

Bug#1017284: fenics-dolfinx: FTBFS: CheckSymbolExists.c:8:19: error: ‘PETSC_USE_COMPLEX’ undeclared (first use in this function); did you mean ‘PETSC_HAVE_COMPLEX’?

[Adrian Bunk]

On Wed, Aug 17, 2022 at 07:31:30PM +0200, Drew Parsons wrote:
> Source: fenics-dolfinx
> Followup-For: Bug #1017284
> 
> The cmake error logs can be too effusive, they tend to obscure the
> error.  In this case the real problem seems to be that it never found
> scotch, even though it found it.  A mystery indeed. Schrödinger's
> SCOTCH.

My reading of cpp/cmake/modules/FindSCOTCH.cmake is that it fails in

  if (SCOTCH_dgraphInit(, MPI_COMM_WORLD) != 0) {
if (MPI_THREAD_MULTIPLE > provided) {
  std::cout << \"MPI implementation is not thread-safe:\" << std::endl;
  std::cout << \"SCOTCH should be compiled without SCOTCH_PTHREAD\" << 
std::endl;
  exit(1);

glibc 2.34 merged libpthread into libc, some kind of threading 
detection no longer working would not be a complete mystery.

cu
Adrian

Bug#1017730: pmix: drop Build-Depends: pandoc

[Drew Parsons]

Source: pmix
Version: 4.1.2-2
Severity: normal

pmix currently has a Build-Depends: pandoc, which is preventing it
from building on the minor architectures since many of them don't have
a pandoc build.

But pmix doesn't have a doc package, and as far as I can tell from the
build logs, pandoc isn't being used.  There is no doc dir, only the
manpages which have already been created.

If we drop Build-Depends: pandoc then pmix might be able to build on
the minor architectures.

Bug#1017588: Your autotools copyright question

[Michel Alexandre Salim]

On Fri, Aug 19, 2022 at 10:13:00AM +0200, Bastian Germann wrote:
> Am 19.08.22 um 03:41 schrieb Michel Alexandre Salim:
> > Quick question (applies to drgn, not libkdumpfile) - if the tarball
> > contains some m4 rules copied verbatim from autotools, do I have to list
> > them in d/copyright?
> 
> The answer is tricky: Per Debian Policy you have to include every license 
> that appears.
> You do not have to include the Copyright statements because the files are not 
> a compiled part of the binary.
> 
> Legally, it is okay to leave the licenses out of d/copyright and I have
> never seen ftpmaster reject a package because the FSF All Permissive License
> was missing. I do not think there is an official exception for it but there
> is certainly an unwritten exception.
> 
> So the official answer is: include them. The unofficial answer is: it is okay 
> not to.
> 
Got it, thanks! So if a unique license appears in the files that are not
a compiled part, the argument in favor of listing it in d/copyright gets
stronger, but if the license is the same and only the copyright is
different I'll probably lean towards skipping unless someone insists
they are included.

I fixed libkdumpfile last night per your feedback, but there's a minor
update just uploaded (2022-08-19 16:05) that refreshed the
patches - one replaced by the upstream commit fixing a bug I reported,
the other is now merged so I updated the header to include the fixed
commit.

Best,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


signature.asc
Description: PGP signature

Bug#1017509: Reply

[Andrej Shadura]

Hi,

On Fri, 19 Aug 2022, at 17:29, joffrey575 wrote:
> I have check all dependencies of matrix-synapse package.
> 
> All packages come from Debian Bullseye Backports and Main or Security (no 
> Tiers).
> 
> The problem came from upgrade matrix-synapse at 1.61.0-1~bpo11+3 version to 
> 1.63.0-1~bpo11+1 version.
> 
> 
> As follow /var/log/apt/history.log
> Upgrade: matrix-synapse:amd64 (1.61.0-1~bpo11+3, 1.63.0-1~bpo11+1)
> 

I cannot reproduce this. I have all the same versions and it works, and I don’t 
see why it shouldn’t, as versions match those in pyproject.toml.

-- 
Cheers,
  Andrej

Bug#1017728: src:restic: fails to migrate to testing for too long: new Build-Depends fails to migrate to testing

[Paul Gevers]

Source: restic
Version: 0.12.1-2
Severity: serious
Control: close -1 0.13.1-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:restic has been trying to migrate for 62 
days [2]. Hence, I am filing this bug. Your package has a new 
Build-Depends that was stuck in unstable because it wasn't build on a 
buildd. To fix that, I did a no-change source-only upload. However, that 
is now stuck because it fails its own autopkgtests on some architectures.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=restic



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017509: Reply

[joffrey575]

Hi Andrej Shadura,

I have check all dependencies of matrix-synapse package.

All packages come from Debian Bullseye Backports and Main or Security 
(no Tiers).


The problem came from upgrade matrix-synapse at 1.61.0-1~bpo11+3 version 
to 1.63.0-1~bpo11+1 version.


As follow /var/log/apt/history.log
Upgrade: matrix-synapse:amd64 (1.61.0-1~bpo11+3, 1.63.0-1~bpo11+1)

Thanks a lot.

Have a nice day.

Maybe this link can help you : 
https://github.com/matrix-org/synapse/pull/12478

Bug#1017727: autoconf-archive: ax_cc_maxopt.m4 change breaks code due to syntax error

[Alastair McKinstry]

Package: autoconf-archive
Version: 20220211-1
Severity: serious
Tags: patch
Justification: Policy 4.6

m4/ax_cc_maxopt.m4 has a syntax error that causes silo-llnl to FTBFS.
See #1017240.

The following patch fixes it:
--- ax_cc_maxopt.m4.orig2022-08-19 16:13:36.230050352 +0100
+++ ax_cc_maxopt.m4 2022-08-19 16:13:47.994113092 +0100
@@ -146,6 +146,7 @@
 nvhpc)
  # default optimization flags for nvhpc
  CFLAGS="$CFLAGS -O3"
+;;

 gnu)
  # default optimization flags for gcc on all systems

thanks
Alastair



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

Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_IE.UTF-8), LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages autoconf-archive depends on:
ii  dpkg  1.20.11

Versions of packages autoconf-archive recommends:
ii  autoconf  2.69-14

autoconf-archive suggests no packages.

-- no debconf information

Bug#1017726: libx11-6:amd64: inconsistency in some KeySym definitions and string lookup

[Vincent Lefevre]

Package: libx11-6
Version: 2:1.8.1-2
Severity: normal

While "infinity" and "approxeq" KeySym names work correctly,
e.g. xev outputs for them

state 0x81, keycode 31 (keysym 0x8c2, infinity), same_screen YES,
XLookupString gives 3 bytes: (e2 88 9e) "∞"
XmbLookupString gives 3 bytes: (e2 88 9e) "∞"

and

state 0x81, keycode 25 (keysym 0x1002248, approxeq), same_screen YES,
XLookupString gives 3 bytes: (e2 89 88) "≈"
XmbLookupString gives 3 bytes: (e2 89 88) "≈"

this is not the case of some other names, like "identical".

In /usr/include/X11/keysymdef.h, the name "identical" is associated
with the value 0x08cf, but xev outputs for this KeySym:

state 0x80, keycode 25 (keysym 0x8cf, identical), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:

i.e. no lookup strings.

However, if in my XKB symbols config, I change "identical" to "U2261"
(i.e. the KeySym corresponding to the Unicode point), this works:

state 0x80, keycode 25 (keysym 0x1002261, U2261), same_screen YES,
XLookupString gives 3 bytes: (e2 89 a1) "≡"
XmbLookupString gives 3 bytes: (e2 89 a1) "≡"

So either the lookup string "≡" should be added to KeySym 0x8cf
(similar to the "infinity" case) or the KeySym for "identical"
should be changed to 0x1002261 (similar to the "approxeq" case).

KeySym names "horizconnector" and "vertconnector" have the same issue.

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

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

Versions of packages libx11-6:amd64 depends on:
ii  libc62.34-4
ii  libx11-data  2:1.8.1-2
ii  libxcb1  1.15-1

libx11-6:amd64 recommends no packages.

libx11-6:amd64 suggests no packages.

-- no debconf information

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

Bug#1017083: Forwarded upstream to https://github.com/bibledit/cloud/issues/820

[Teus Benschop]

forwarded 1017083 https://github.com/bibledit/cloud/issues/820
thanks

Bug#947800: dh-python: pybuild copying of testfiles loses directory structure

[Stefano Rivera]

Hi Scott (2019.12.31_00:47:02_+0200)
> When a file or directory such as a/b/c.txt is listed in 
> pybuild.testfiles, when it is copied to the build directory, the 
> directory structure portion is lost.  Tests expect certain data files to 
> exist in certain location so this makes it hard to use the 
> pybuild.testfiles feature.  It seems that pybuild.testfiles should 
> retain the original directory structure of the listed files.

Not necessarily. It's quite common to have e.g. src/tests and you don't
want the src directory in the temporary build dir.

I suspect we may need an optional destination path for each entry to
implement this without breaking things.

I did some review of the archive, most pybuild.testfiles users naming a
top-level directory in the source package, and this seems to give them
what they want.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1017724: libaperture-0: flaky autopkgtest on multiple architectures: timeout_reached: code should not be reached

[Simon McVittie]

Source: libaperture-0
Version: 0.1.0+git20200908-3
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

The autopkgtest for libaperture-0 seems to be intermittently failing
with a timeout, particularly on armel and armhf. Some examples:

- 
https://ci.debian.net/data/autopkgtest/testing/armel/liba/libaperture-0/24979047/log.gz
- 
https://ci.debian.net/data/autopkgtest/testing/armhf/liba/libaperture-0/23940701/log.gz
- 
https://ci.debian.net/data/autopkgtest/testing/amd64/liba/libaperture-0/23958726/log.gz

all of which look like this:

> ok 8 /viewfinder/no_camera
> # Aperture-DEBUG: New camera detected: Dummy Camera
> Bail out! ERROR:utils.c:48:timeout_reached: code should not be reached
> **
> ERROR:utils.c:48:timeout_reached: code should not be reached
> Aborted

When testing a proposed update to a package it depends on (such as
gdk-pixbuf or glibc), the test failure is assumed to be a regression in
the updated package, which can delay or prevent testing migration.

Please look into whether this test can be made reliable, or if it cannot,
mark the test with "Restrictions: flaky" so that it doesn't disrupt other
packages.

Upstream commit
https://gitlab.gnome.org/jwestman/libaperture/-/commit/b5bd52a63994becadd5be88814824c0679f85046
looks potentially relevant.

Thanks,
smcv

Bug#1017725: dgit-maint-native(7) examples should use push-source (rather than push)

[Philip Hands]

Package: dgit
Version: 9.16
Severity: minor

It strikes me that examples that currently show the `push` sub-command:

  dgit -wgf --overwrite push
and
  dgit -wgf push

should show the use of the `push-source` sub-command instead, since doing binary
uploads to Debian now prevents migration to testing, so chances are that's not
what most people want to do.

One could perhaps also add a `--with-binary` option for `push` and gently
transition to defaulting to doing source-only uploads unless one specified that
option via config or options.

Bug#1017723: bullseye-pu: package nftables/0.9.8-3.2

[Jeremy Sowden]

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

The related nftables bug is:

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

[ Reason ]
nftables uses a fixed-size array containing the locations of the
expressions within each rule that it sends to the kernel to provide more
informative error-reporting.  If the rule is rejected by the kernel, the
kernel will provide an ID for the expression which was responsible, and
nftables will use this to highlight it when outputting the rule in the
error message:

 # nft add rule t c iif lo reject with icmp 255
 Error: Could not process rule: Invalid argument
 add rule t c iif lo reject with icmp 255
 ^^

There is an off-by-one error in the bounds-checking used before adding
the details of an expression to this array.  The result of this is that
if a rule contains enough expressions, nftables will write past the end
of the array leading to memory-corruption and possibly crashes.

This bug has been present throughout the lifetime of Bullseye.

[ Impact ]
nftables will continue to crash if given sufficiently long rules.

[ Tests ]
I have manually tested that the fixed version does not exhibit the
memory corruption in a Bullseye chroot.

[ Risks ]
The fix is a one-line code-change.  The patch is taken directly from
upstream.

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

[ Changes ]
The upstream fix corrects the bounds-check to ensure that if the number
of locations stored in the array equals the size of the array, no new
location is added.  The upstream patch has been added to the package to
apply the same change to the packaged source.
diff -Nru nftables-0.9.8/debian/changelog nftables-0.9.8/debian/changelog
--- nftables-0.9.8/debian/changelog 2021-07-20 09:01:47.0 +0100
+++ nftables-0.9.8/debian/changelog 2022-07-16 10:29:27.0 +0100
@@ -1,3 +1,13 @@
+nftables (0.9.8-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/p/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
+It fixes a one off for the check for NFT_NLATTR_LOC_MAX
+which leads to double free or corruption (out) error
+(closes: #1017359).
+
+ -- Sven Auhagen   Sat, 16 Jul 2022 11:29:27 +0200
+
 nftables (0.9.8-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
 
nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
--- 
nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
1970-01-01 01:00:00.0 +0100
+++ 
nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
2022-07-16 10:29:27.0 +0100
@@ -0,0 +1,32 @@
+From 2d0a7a9adeb30708d6fbbee57476c0d4b9214dbd Mon Sep 17 00:00:00 2001
+From: Phil Sutter 
+Date: Fri, 11 Jun 2021 17:08:34 +0200
+Subject: rule: Fix for potential off-by-one in cmd_add_loc()
+
+Using num_attrs as index means it must be at max one less than the
+array's size at function start.
+
+Fixes: 27362a5bfa433 ("rule: larger number of error locations")
+Signed-off-by: Phil Sutter 
+---
+ src/rule.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+(limited to 'src/rule.c')
+
+diff --git a/src/rule.c b/src/rule.c
+index dbbe744e..92daf2f3 100644
+--- a/src/rule.c
 b/src/rule.c
+@@ -1275,7 +1275,7 @@ struct cmd *cmd_alloc(enum cmd_ops op, enum cmd_obj obj,
+ 
+ void cmd_add_loc(struct cmd *cmd, uint16_t offset, const struct location *loc)
+ {
+-  if (cmd->num_attrs > NFT_NLATTR_LOC_MAX)
++  if (cmd->num_attrs >= NFT_NLATTR_LOC_MAX)
+   return;
+ 
+   cmd->attr[cmd->num_attrs].offset = offset;
+-- 
+cgit v1.2.3
+
diff -Nru nftables-0.9.8/debian/patches/series 
nftables-0.9.8/debian/patches/series
--- nftables-0.9.8/debian/patches/series2021-07-20 09:01:47.0 
+0100
+++ nftables-0.9.8/debian/patches/series2022-07-16 10:29:27.0 
+0100
@@ -1 +1,2 @@
 payload-check-icmp-dependency-before-removing-previo.patch
+rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch

Bug#995640: boxbackup: FTBFS with OpenSSL 3.0

[Ileana Dumitrescu]

>> Also please note that .gitattributes makes the repo have an unclean
state on checkout when you are not on Windows.
>> You should fix that in future uploads by exluding or patching that file
or by importing the crlf files with the expected
>> line ending.

Ok I will look out for that.

>> I can but please use the same email in d/changelog as in Maintainer
field.

>> I have just added one commit that addresses a dpkg-gencontrol warning.

>> The latest published version is not tagged in git. Please add a
debian/... tag for that.
>> The to-be-sponsored version does not have an upstream tag. Please add
that now and a debian/... tag after the package
>> was uploaded.

> Please also check d/copyright which seems to be incomplete.

I added the previous tags for debian and upstream and a new tag after the
latest updates. I fixed the control file email and copyright file in the
most recent commits, and I added your commit to the changelog.

Thank you for all the feedback! It should be good to upload now.

Ileana

On Thu, Aug 18, 2022 at 7:21 PM Bastian Germann  wrote:

> Please also check d/copyright which seems to be incomplete.
>


-- 
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354

Bug#1016925: kodi: Video playback not working in latest version of kodi

[Vasyl Gello]

Dear James,

Maybe you can advise how to handle this removal properly in Kodi?

15 серпня 2022 р. 21:49:19 UTC, Rogo  написав(-ла):
>Hi,
>
>since kodi in Debian is built against ffmpeg 5.1, TV playback is broken.
>More specifically, kodi can no longer play video transport streams.
>
>One can reproduce this by playing a video from a ts file in kodi, e.g.:
>$ ffmpeg -f lavfi -i testsrc -t 10 -c:v h264 test.ts
>$ kodi test.ts
>
>This worked fine with kodi 19.4, which was built against ffmpeg 4.4,
>but no longer shows the video in kodi 20, which is built against ffmpeg 5.1.
>
>The problem is that kodi tries to manually extract transport stream extradata
>using parser->split in CDVDDemuxFFmpeg::ParsePacket [1], but all the split
>functions were removed in ffmpeg 5.0 by [2]:
>commit e5af9203098a889f36b759652615046254d45102
>Author: Andreas Rheinhardt 
>Date:   Sun Mar 7 00:28:14 2021 +0100
>
>avcodec: Move all AVCodecParser.split functions to remove_extradata_bsf
>
>The remove_extradata bsf is the only user of these functions.
>
>Signed-off-by: Andreas Rheinhardt 
>Signed-off-by: James Almer 
>
>Reverting this commit on top of ffmpeg 5.1 (and including startcode.h in
>files then using avpriv_find_start_code) restores TV playback in kodi.
>
>As the example of kodi shows, these split functions are generally useful
>for API users outside of ffmpeg itself.
>Thus please restore them, e.g. by reverting this commit.
>
>Thanks,
>Rogo
>
>1: 
>https://salsa.debian.org/multimedia-team/kodi-media-center/kodi/-/blob/1690349c890bdf941216218dd6b4f7b9c4204dc0/xbmc/cores/VideoPlayer/DVDDemuxers/DVDDemuxFFmpeg.cpp#L2260
>2: 
>https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/e5af9203098a889f36b759652615046254d45102
>
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1017722: RM: libsbig [armel, mips64el, ppc64el, s390x] -- RoM; NBS no longer builds on several architectures

[Thorsten Alteholz]

Package: ftp.debian.org
Severity: normal

The package no longer builds on several architectures.

   Thorsten

Bug#1017721: cryfs: /usr/bin/cryfs-unmount still missing in cryfs 0.11.2-5

[Thomas R. Shemanske]

Package: cryfs
Version: 0.11.2-5
Severity: important
X-Debbugs-Cc: thomas.r.sheman...@gmail.com

Dear Maintainer,

/usr/bin/cryfs-unmount is not included in cryfs 0.11.2-5 (nor 0.11.2-4)

It is generated when I build the package from the github source, so not sure
why it is not in the debian package.

Without the binary, the unencrypted file system remains visible.


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

Kernel: Linux 5.18.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.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 cryfs depends on:
ii  fuse3 [fuse]3.11.0-1
ii  libboost-chrono1.74.0   1.74.0-16.1
ii  libboost-filesystem1.74.0   1.74.0-16.1
ii  libboost-program-options1.74.0  1.74.0-16.1
ii  libboost-thread1.74.0   1.74.0-16.1
ii  libc6   2.34-3
ii  libcurl47.84.0-2
ii  libfmt8 8.1.1+ds1-2
ii  libfuse22.9.9-5
ii  libgcc-s1   12.1.0-8
ii  libgomp112.1.0-8
ii  libspdlog1 [libspdlog1-fmt8]1:1.10.0+ds-0.1
ii  libstdc++6  12.1.0-8

cryfs recommends no packages.

cryfs suggests no packages.

-- no debconf information

Bug#1017720: nfs-common: No such file or directory

[Jason Breitman]

Package: nfs-common
Version: 1:1.3.4-6
Severity: important

Kernel: 5.10.0-16-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30) x86_64 GNU/Linux

-- Description
After updating and or creating new files on our file server via rsync, we 
see many files report the error message below from NFSv4 clients since 
upgrading from Debian 10.8 to Debian 11.4.
Clearing the dentry cache resolves the issue right away.
I am not sure that nfs-common is the package to blame, but listed it based 
on the bug submission recommendations. 

-- Test
ls -l /mnt/dir/someOtherDir/* | grep '?'

-- Error message
ls: cannot access 'filename': No such file or directory
-? ? ???? filename

-- Workaround
/usr/bin/sync && echo 2 > /proc/sys/vm/drop_caches

-- /etc/fstab snippet --
nfs-server.domain.com:/dir  /mnt/dirnfs4
lookupcache=pos,noresvport,sec=krb5,hard,rsize=1048576,wsize=10485760   0

Jason Breitman 

Bug#1017719: Broken symlink in build directory

[Paul Menzel]

Package: libdvd-pkg
Version: 1.4.3-1-1
Severity: minor


Dear Debian folks,


There is a broken symbolic link in the build directory

$ ls -l 
/usr/src/libdvd-pkg/build/debian/libdvdcss-dev/usr/lib/x86_64-linux-gnu/

total 4
lrwxrwxrwx 1 root root   18 Aug 15 18:36 libdvdcss.so -> 
libdvdcss.so.2.2.0

drwxr-xr-x 2 root root 4096 Aug 15 18:36 pkgconfig
$ ls -l 
/usr/src/libdvd-pkg/build/debian/libdvdcss-dev/usr/lib/x86_64-linux-gnu/libdvdcss.so.2.2.0
ls: cannot access 
'/usr/src/libdvd-pkg/build/debian/libdvdcss-dev/usr/lib/x86_64-linux-gnu/libdvdcss.so.2.2.0': 
No such file or directory


The library file exists at


/usr/src/libdvd-pkg/build/debian/tmp/usr/lib/x86_64-linux-gnu/libdvdcss.so.2.2.0


Kind regards,

Paul