Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.

[Rai]

Hi Otto,

Sry, it was my error - I'm indeed on debian buster here and referring to the 
bug #1031770.
I mixed it up.

Regards
Rai

Am 01.03.2023 um 08:13 schrieb Otto Kekäläinen:

> So Rai has /usr/sbin/mysqld-akonadi from package akonadi-backend-mysql:
> 
> /usr/sbin/mysqld-akonadi
> --defaults-file=/home/rai/.local/share/akonadi/mysql.conf
> --datadir=/home/rai/.local/share/akonadi/db_data/
> --socket=/tmp/akonadi-rai.bxYrSB/mysql.socket
> --pid-file=/tmp/akonadi-rai.bxYrSB/mysql.pid
> 
> Rai was running Debian buster (=oldstable).
> 
> Steven has another version (Bullseye/stable?) with:
> 
> /usr/sbin/mysqld
> --defaults-file=/home/username/.local/share/akonadi/mysql.conf
> --datadir=/home/username/.local/share/akonadi/db_data/
> --socket=/run/user/1000/akonadi/mysql.socket
> --pid-file=/run/user/1000/akonadi/mysql.pid
> 
> The process detection indeed would be more robust if it checked for
> owner 'mysql'. So we could switch it to run this instead?
> 
> pgrep -u root,mysql -x --nslist pid --ns $$ "mysqld|mariadbd"
> 
> Just need to be careful that this is run only on systems where the
> user 'mysql' already exist, otherwise pgrep will return an error.
> 
> 
> The issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031770
> Rai mentioned is unrelated. Let's not mix the discussion about that
> into this one about the preinstall script process check.

Bug#1032177: faketime doesn't fake time (on i386)

[Jakub Wilk]

Package: faketime
Version: 0.9.10-2.1
Severity: grave

faketime no longer works on i386:

   $ faketime -f '2008-12-24 08:15:42' date -R
   Wed, 01 Mar 2023 08:25:58 +0100


-- System Information:
Architecture: i386

Versions of packages faketime depends on:
ii  libfaketime  0.9.10-2.1
ii  libc62.36-8

--
Jakub Wilk

Bug#1032093: jameica: missing dependencies

[Jochen Sprickerhof]

* Thomas Uhle  [2023-02-28 21:00]:

I was not able to reproduce this. On an up to date Debian unstable I tried:

$ sudo apt install debvm
# create a Debian unstable VM
$ debvm-create --size=10G -- --include=task-gnome-desktop 
--aptopt='Apt::Install-Recommends "true"' 
--include=linux-image-amd64 
--hook-dir=/usr/share/mmdebstrap/hooks/useradd

# run it with qemu
$ debvm-run -g -- -m 4G
# inside the VM install hibiscus
$ sudo apt install --no-install-recommends hibiscus
# run it
$ jameica

Can you try this and maybe check the difference to your system?


I cannot do this, I am on an ARMv9 platform (Debian's arm64 architecture).


It should work on arm64 just as well and I would be interested in your 
experience with it.


However, I still had bcpkix.jar linking to bcpkix-jdk18on-1.72.jar as 
well as bcprov.jar and bcputil.jar linking to bcprov-jdk18on-1.72.jar 
and bcutil-jdk18on-1.72.jar resp. which I had been downloading from 
Maven Central before I prepared the pull request for Olaf Willuhn 
(upstream). Although I thought they were basically the same, there 
have to be differences.  After reverting the links to the jar files 
that are provided by Debian, there is no such issue indeed.  So I 
tried to track this down to bcpkix.jar.  If only this jar file is 
exchanged by the one from Maven Central, then it doesn't matter 
whether the other two are from Debian or Maven Central.  Then this 
issue is happening.  So the difference must be within bcpkix.jar.  I 
had a look into both versions and saw that the manifest in Debian's 
bcpkix.jar specifies


 Class-Path: bcprov.jar bcutil.jar

whereas the manifest in Maven's bcpkix.jar has no class path 
specified. I guess this is the reason why it works with Debian's 
BouncyCastle jar files even if the manifest of jameica.jar does not 
specify a class path with bcutil.jar.


Thanks for figuring this out!

I cannot confirm this.  After removing both bcutil-1.72.jar and 
bcutil.jar, (even with the other two libraries taken from Debian) I 
run into this issue when Jameica tries to generate the self-signed 
certificate for a new user profile.  It does not quit after the 
exception but seems to hang forever, the splash screen stays open 
saying "generating new keys and certificates ..." for minutes.  
Eventually I have yet lost my patience and killed the process.


I forgot to move away my ~/.jameica/ so yes I can see the error now.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#1031800: mmdebstrap: --keyring doesn't work properly

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Dima Kogan (2023-02-28 22:56:26)
> It's not actually that weird; I just wasn't looking at the error messages
> closely enough. The /etc/apt/sources.list has two repos:
> 
> - main bookworm repo. Signed with the Debian keys
> - my repo. Signed with its own key
> 
> If I "mmdebstrap --keyring MY-KEY-DIRECTORY" then apt actually does find
> the keys to my repo, and it's happy about it. The problem is that it
> then doesn't look in /etc/apt/trusted.gpg.d and it thinks the main
> bookworm repo is unverifiable. So there's no mystery here, but my use case
> still doesn't work.

ah yes, that makes sense. :)

> Some questions, if I may:
> 
> - By default apt has /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/*.
>   Which of these is expected to contain the keys for Debian?

It seems that /etc/apt/trusted.gpg is a historic relic and keys from it are
removed by the postinst of debian-archive-keyring with the following code
comment next to it:

# remove keys from the trusted.gpg file as they are now shipped in fragment
# files in trusted.gpg.d

> - I want mmdebstrap to use the extra repo and the keys, so what's the right
> way to do that? I guess I need to:
> 
>   - Create new key directory
> 
>   - Copy /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/* and my new
> keys into it
> 
>   - Pass that to mmdebstrap --keyring
> 
>   - Add my new keys into the chroot with an mmdebstrap hook so that
> these are available inside the chroot
> 
> Is that right? If so, can we make this explicit in the manpage?

I probably never should've added the --keyring argument. Its documentation
already states:

> Since apt only supports a single keyring file and directory, respectively,
> you can not use this option to pass multiple files and/or directories.

You can create a directory and copy your keys into it, yes. But the docs for
--keyring also suggest that you use signed-by instead. Is that not a better
solution than copying keys from debian-archive-keyring around? If you use
signed-by you also do not need the --keyring argument anymore.

Though I agree that I should also add some more information to the --keyring
argument. What do you think about the following patch? If that patch does not
answer the questions you've had, please tell me and I improve the patch.
Thanks!

t a/mmdebstrap b/mmdebstrap
index 01d9954..f450049 100755
--- a/mmdebstrap
+++ b/mmdebstrap
@@ -6366,13 +6366,22 @@ Example: Minimizing the number of packages installed 
from experimental
 
 =item B<--keyring>=I|I
 
-Change the default keyring to use by apt. By default, F
-and F are used. Depending on whether a file or
-directory is passed to this option, the former and latter default can be
-changed, respectively.  Since apt only supports a single keyring file and
-directory, respectively, you can B use this option to pass multiple files
-and/or directories. Using the C<--keyring> argument in the following way is
-equal to keeping the default:
+Change the default keyring to use by apt during the initial setup. This is
+similar to setting B and B using
+B<--aptopt> except that the latter setting will be permanently stored in the
+chroot while the keyrings passed via <--keyring> will only be visible to apt as
+run by B. Do not use B<--keyring> if apt inside the chroot needs to
+know about your keys after the initial chroot creation by B.
+
+By default, the local setting of B and
+B are used to choose the keyring used by apt as run by
+B. These two locations are set to F and
+F by default. Depending on whether a file or directory
+is passed to this option, the former and latter default can be changed,
+respectively.  Since apt only supports a single keyring file and directory,
+respectively, you can B use this option to pass multiple files and/or
+directories. Using the C<--keyring> argument in the following way is equal to
+keeping the default:
 
 --keyring=/etc/apt/trusted.gpg --keyring=/etc/apt/trusted.gpg.d
 
@@ -6381,6 +6390,10 @@ specifying the mirror like this:
 
 mmdebstrap mysuite out.tar "deb [signed-by=/path/to/key.gpg] http://...;
 
+Another reason to use C instead of B<--keyring> is if apt inside the
+chroot needs to know by what key the repository is signed even after the
+initial chroot creation.
+
 The C option will automatically be added to the final
 C if the keyring required for the selected I is not yet
 trusted by apt. Automatically adding the C option in these cases
@@ -6392,6 +6405,13 @@ installed, then you can create a Ubuntu Bionic chroot on 
Debian like this:
 The resulting chroot will have a C with a C option
 pointing to F.
 
+You do not need to use B<--keyring> or C if you placed the keys that
+apt needs to know about into F in the B<--setup-hook>
+(which is before C runs), for example by using the 
+special hook. You also need to copy your keys into the chroot explicitly if the
+key you passed via C points to a location that is not otherwise
+populated during chroot creation (for example by installing a 

Bug#1031968: libxfconf-0-dev fails to build with valac installed

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

control: severity -1 important

[please always keep the bug address on CC:]

On Mon, 2023-02-27 at 04:17 +, spinal...@gmail.com wrote:
> 
> The severety was set automatically by reportbug.

Ok, but you're supposed to double-check that. I'm correcting this then.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmP/AOsACgkQ3rYcyPpX
RFscOwgAxIwy5n45QT8gsFZXcGzWyslZNR2cCfJeqvQB7hegbbF6ryx9DaFnxGQg
BPL7918g5eRPcFtGYL+OubFWERJilKdH51p6c2Rcam3SjLKo+CvETvuZJUCWpCoI
0X+4J5pwy8l2xhxkmYPFGMMa/KLZ9U+lucO3eE/L26Qdy9E/7w2R/lPVCeknyQOH
N10jLF/p16tkPEY9fqfedTYxzL/TTw++5USiU90lZHkZpHFZueVm+79y7kVZInl+
ttt301cCTbwqk43Cu2Gf8Pjr86yhNb1z2L1Mvrv7FSUTZbGhuCeg4tiXmrzt9KG1
QSlrdisoEp/FvECU24mqEUqSxXIgNQ==
=XOPV
-END PGP SIGNATURE-

Bug#1032178: O: purple-discord -- Discord messaging service plugin for libpurple

[Paul Wise]

Package: wnpp
Severity: normal
X-Debbugs-Cc: purple-disc...@packages.debian.org
Control: affects -1 + src:purple-discord

I intend to orphan the purple-discord package.

The package description is:
 A plugin for libpurple that adds the option to use the Discord messaging
 service in all libpurple-based clients (including Pidgin and Finch).
 .
 This plugin does not support creating and managing Discord accounts,
 please use the harmony package for those tasks.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1032122: chkrootkit: bad redirection creating file '1'?

[Thomas Dorner]

> ($echo is defined by the main loop, although im sceptical it is
> actually used given echo is a builtin)

At least in the BaSH functions and aliases supersede builtins, although
I'm not sure about what the POSIX standard says about it.
-- 
퓣퓱퓸퓶퓪퓼 퓓퓸퓻퓷퓮퓻

Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.

[Otto Kekäläinen]

So Rai has /usr/sbin/mysqld-akonadi from package akonadi-backend-mysql:

/usr/sbin/mysqld-akonadi
--defaults-file=/home/rai/.local/share/akonadi/mysql.conf
--datadir=/home/rai/.local/share/akonadi/db_data/
--socket=/tmp/akonadi-rai.bxYrSB/mysql.socket
--pid-file=/tmp/akonadi-rai.bxYrSB/mysql.pid

Rai was running Debian buster (=oldstable).

Steven has another version (Bullseye/stable?) with:

/usr/sbin/mysqld
--defaults-file=/home/username/.local/share/akonadi/mysql.conf
--datadir=/home/username/.local/share/akonadi/db_data/
--socket=/run/user/1000/akonadi/mysql.socket
--pid-file=/run/user/1000/akonadi/mysql.pid

The process detection indeed would be more robust if it checked for
owner 'mysql'. So we could switch it to run this instead?

pgrep -u root,mysql -x --nslist pid --ns $$ "mysqld|mariadbd"

Just need to be careful that this is run only on systems where the
user 'mysql' already exist, otherwise pgrep will return an error.


The issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031770
Rai mentioned is unrelated. Let's not mix the discussion about that
into this one about the preinstall script process check.

Bug#1030638: cp -a fails to preserve ownership information on 32-bit arches

[Shengjing Zhu]

On Wed, Mar 1, 2023 at 3:00 PM Johannes Schauer Marin Rodrigues
 wrote:
>
> Hi Shengjing,
>
> Quoting Shengjing Zhu (2023-03-01 06:40:38)
> > I've debugged it as well and here is my write up. Though I don't have
> > solution yet.
>
> you don't have a *good* solution yet but I think you are extremely close! 
> Thank
> you so much for spending all the time debugging this *and* for this very
> helpful writeup which is helpful for guys like me who could've never come this
> far by themselves. Thank you! :)
>
> Would it maybe possible to choose the correct stat struct by trying to see 
> with
> which struct the values make sense? For example it should be easy to check
> which inode numbers actually exist. The other entries of the stat struct also
> can be checked if they look legitimate, like the file mode (which should not 
> be
> larger than 0o4777).

I realized there probably was no need for runtime detection after some
discussion with others.

After all, it has already dispatched the right _time64 function. But
on i386, the only case to use _time64 function is when compiled with
D_TIME_BITS=64.
So there shouldn't be two variants of stat64 struct. It's just
fakeroot is using the wrong one.
fakeroot should compile its all time64 funcs with D_TIME_BITS=64, then
it should get the right struct. (only these _time64 parts, so be in
separate files.)

I'm still exploring this idea, but anyone more familiar with autoconf
would be helpful!

-- 
Shengjing Zhu

Bug#1030638: cp -a fails to preserve ownership information on 32-bit arches

[Johannes Schauer Marin Rodrigues]

Hi Shengjing,

Quoting Shengjing Zhu (2023-03-01 06:40:38)
> I've debugged it as well and here is my write up. Though I don't have
> solution yet.

you don't have a *good* solution yet but I think you are extremely close! Thank
you so much for spending all the time debugging this *and* for this very
helpful writeup which is helpful for guys like me who could've never come this
far by themselves. Thank you! :)

Would it maybe possible to choose the correct stat struct by trying to see with
which struct the values make sense? For example it should be easy to check
which inode numbers actually exist. The other entries of the stat struct also
can be checked if they look legitimate, like the file mode (which should not be
larger than 0o4777).

What do you think?

Thanks!

cheers, josch

Bug#852648: qapt-deb-installer provides .deb-install functionality

[Marcel Partap]

Dear IJ.L.,
if you include the package qapt-deb-installer in your build, .deb packages 
should be installable from the browser. It is not included by default yet.. 
Maybe it could be added to live-task-extra or live-task-recommended?

Best Regards
Marcel

Bug#1032053: Acknowledgement (mariadb: FTBFS on sh4:)

[Otto Kekäläinen]

Seems a re-build randomly passed now in
https://buildd.debian.org/status/fetch.php?pkg=mariadb=sh4=1%3A10.11.2-1=1677526768=0

Bug#1027337: [debian-mysql] Bug#1027337: Bug#1027337: mariadb-server-10.5: Huge increase in memory consumption (leak?) since upgrade from 10.5.15 to 10.5.18

[Otto Kekäläinen]

On Tue, 28 Feb 2023 at 09:25, Faustin Lammler  wrote:
>
> Hi Matteo!
> I am not in charge of doing uploads to Debian FTP so, I don't know.
>
> @Otto do you know when 10.5.19 will be uploaded?

Only Debian release team knows the exact date. Page
https://release.debian.org/ says mid-February.

You can +1 on https://bugs.debian.org/1031042 if you want or you can
already now download binaries from the CI pipeline from commit
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commits/debian/1%2510.5.19-0+deb11u1
= https://salsa.debian.org/mariadb-team/mariadb-10.5/-/pipelines/498296
= 
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/3929573/artifacts/browse/debian/output/

Bug#1032176: ITP: ouch - unified compression and decompression CLI

[Blair Noctis]

Package: wnpp
Severity: wishlist
Owner: Blair Noctis 
X-Debbugs-Cc: debian-de...@lists.debian.org, n...@sail.ng

* Package name: ouch
  Version : 0.4.1
  Upstream Contact: Vinícius R. Miguel 
* URL : https://crates.io/crates/ouch
* License : MIT
  Programming Lang: Rust
  Description : Unified compression and decompression CLI

ouch is a unified CLI that compresses to and decompresses from various formats,
currently tar, zip, gz, xz/lzma, bz(2), lz4, sz, zst. It's easy to use and quite
fast.

I intend to package and maintain it in the Debian Rust team.

-- 
Sdrager,
Blair Noctis


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031863: libqt5sql5-mysql: incompatible change in libmariadb3 breaks kontact, needs upstream fix in libqt5sql5-mysql

[Otto Kekäläinen]

Hi!

The fact that his issue surfaced now about something that changed in
Debian 1-2 years ago and was changed upstream 2 years ago confuses me.
Also I don't have any easy way to fire up a container and reproduce
the issue.

However, as a clear patch was suggested I did it in
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/bugfix/1031863-libmariadb3-version-id

The the Salsa runner comes back online and pipeline works again, there
will be build artifacts available at
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/jobs/4004950 and
you can download the libmariadb3 with this patched and test if it
fixes your mail client situation.

Bug#877601: 5 years and still the website is down, I did see a sourceforge.net page although not sure whether it's the same or not.

[shirish शिरीष]

Hi,

Saw this today again -

$ curl -I http://www.adel.nursat.kz/
curl: (6) Could not resolve host: www.adel.nursat.kz

The last interaction on this bug was in 2017.

I did see a sourceforge.net domain for same/similar project but the
name seems different, dunno.

https://sourceforge.net/p/apwg/wiki/Home/

Looking forward to know more.
-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
https://creativecommons.org/licenses/by-nc/3.0/
https://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#1032139: snmp: snmpbulkwalk.1 mentions snmpbulkget instead of snmpbulkwalk

[Craig Small]

forwarded 1032139 https://github.com/net-snmp/net-snmp/issues/537
thankyou

On Wed, 1 Mar 2023 at 01:36, наб  wrote:

>
> I couldn't for the life of me find where I'd post this, so I trust you
> understand upstream's link jungle and can forward this in my stead.
>
Forwarded to https://github.com/net-snmp/net-snmp/issues/537

I'll put this Debian patch in too.

 - Craig

Bug#1030638: cp -a fails to preserve ownership information on 32-bit arches

[Shengjing Zhu]

X-Debbugs-Cc: z...@debian.org, cl...@debian.org, jo...@debian.org

Hi,

I've debugged it as well and here is my write up. Though I don't have solution
yet.

I use an i386 VM for testing and following code to simplify my test.

```c
int main() {
 struct stat buf;
 int r;
 r = fstatat(AT_FDCWD, "./test.c", , 0);
 printf("%d %d %d\n", r, buf.st_ino, buf.st_gid);
}
```

Compile it with:

$ gcc -g -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 ./test.c

This same as coreutils that enables time64 support.

with the instruction in DEBUG file:

$ gdb ./a.out
(gdb) set env FAKEROOTKEY=430935964
(gdb) set env LD_PRELOAD=./prefix/lib/libfakeroot-0.so
(gdb) b main
Breakpoint 1 at 0x11b6: file ./test.c, line 10.
(gdb) r
Starting program: /home/debian/a.out 
Breakpoint 1, main () at ./test.c:10
10   r = fstatat(AT_FDCWD, "./test.c", , 0);
(gdb) s
__fstatat64_time64 (dir_fd=-100, path=0x402008 "./test.c", st=0xb4d0, 
flags=0) at libfakeroot.c:2700
2700  r=NEXT_FSTATAT64_TIME64(ver, dir_fd, path, st, flags);
(gdb) p st
$1 = (struct stat64 *) 0xb4d0
(gdb) p *st
$2 = {st_dev = 11676941228, __pad1 = 3086760800, __st_ino = 1, st_mode = 0, 
st_nlink = 1, st_uid = 3087006272, st_gid = 0, st_rdev = 13257672154138279935, 
__pad2 = 3087005192, 
  st_size = -5188164414456463360, st_blksize = 44, st_blocks = 
-4611686117211635712, st_atim = {tv_sec = -1208183472, tv_nsec = 0}, st_mtim = 
{tv_sec = -1210426833, 
tv_nsec = -1208328120}, st_ctim = {tv_sec = -1208207344, tv_nsec = 
-1208108853}, st_ino = 13257533047527070255}
(gdb) n
2701  if(r)
(gdb) p *st
$3 = {st_dev = 2049, __pad1 = 262484, __st_ino = 0, st_mode = 33188, st_nlink = 
1, st_uid = 1000, st_gid = 1000, st_rdev = 0, __pad2 = 221, st_size = 
17592186044416, st_blksize = 8, 
  st_blocks = 7205240262505791488, st_atim = {tv_sec = 0, tv_nsec = 29600}, 
st_mtim = {tv_sec = 0, tv_nsec = 1677600726}, st_ctim = {tv_sec = 0, tv_nsec = 
9200}, 
  st_ino = 7205240253915856896}
(gdb) p (struct __stat64_t64)(*st)
$4 = {st_dev = 2049, st_ino = 262484, st_mode = 33188, st_nlink = 1, st_uid = 
1000, st_gid = 1000, st_rdev = 0, st_size = 221, st_blksize = 4096, st_blocks = 
8, st_atim = {
tv_sec = 1677600728, tv_nsec = 29600}, st_mtim = {tv_sec = 1677600726, 
tv_nsec = 9200}, st_ctim = {tv_sec = 1677600726, tv_nsec = 10800}}

We can see that st struct is decoded into a wrong layout.
It causes the message passed to faked has wrong inode.

To verify the guess, I use following dirty patch,

>From ea3eab6ea82604f9a16d658f7fc7ec5ce4bc337d Mon Sep 17 00:00:00 2001
From: Shengjing Zhu 
Date: Wed, 1 Mar 2023 13:21:25 +0800
Subject: [PATCH] hack

---
 communicate.c | 35 +++
 communicate.h |  1 +
 libfakeroot.c |  9 +++--
 stat64.h  | 15 +++
 4 files changed, 58 insertions(+), 2 deletions(-)
 create mode 100644 stat64.h

diff --git a/communicate.c b/communicate.c
index dec9cc6..f7bbaf4 100644
--- a/communicate.c
+++ b/communicate.c
@@ -63,6 +63,8 @@
 #include "stats.h"
 #endif
 
+#include "stat64.h"
+
 #ifndef _UTSNAME_LENGTH
 /* for LINUX libc5 */
 #  define _UTSNAME_LENGTH _SYS_NMLN
@@ -864,6 +866,39 @@ void send_get_stat64(struct stat64 *st
   }
 }
 
+void send_get_stat64_2(struct stat64 *st)
+{
+  struct fake_msg buf;
+
+#ifndef FAKEROOT_FAKENET
+  if(init_get_msg()!=-1)
+#endif /* ! FAKEROOT_FAKENET */
+  {
+  buf.st.mode =((struct x__stat64 *)st)->st_mode;
+  buf.st.ino  =((struct x__stat64 *)st)->st_ino ;
+  buf.st.uid  =((struct x__stat64 *)st)->st_uid ;
+  buf.st.gid  =((struct x__stat64 *)st)->st_gid ;
+  buf.st.dev  =((struct x__stat64 *)st)->st_dev ;
+  buf.st.rdev =((struct x__stat64 *)st)->st_rdev;
+  buf.st.nlink=((struct x__stat64 *)st)->st_nlink;
+
+  fprintf(stderr, "libfakeroot: before ino %ld uid %ld gid %ld \n", 
buf.st.ino, buf.st.uid, buf.st.gid);
+
+buf.id=stat_func;
+send_get_fakem();
+
+
+  ((struct x__stat64 *)st)->st_mode =buf.st.mode;
+  ((struct x__stat64 *)st)->st_ino  =buf.st.ino ;
+  ((struct x__stat64 *)st)->st_uid  =buf.st.uid ;
+  ((struct x__stat64 *)st)->st_gid  =buf.st.gid ;
+  ((struct x__stat64 *)st)->st_dev  =buf.st.dev ;
+  ((struct x__stat64 *)st)->st_rdev =buf.st.rdev;
+
+  fprintf(stderr, "libfakeroot: after ino %ld uid %ld gid %ld \n", buf.st.ino, 
buf.st.uid, buf.st.gid);
+  }
+}
+
 void send_get_xattr64(struct stat64 *st
, xattr_args *xattr
 #ifdef STUPID_ALPHA_HACK
diff --git a/communicate.h b/communicate.h
index a586108..5562402 100644
--- a/communicate.h
+++ b/communicate.h
@@ -211,6 +211,7 @@ extern void unlock_comm_sd(void);
 #ifndef STUPID_ALPHA_HACK
 extern void send_stat64(const struct stat64 *st, func_id_t f);
 extern void send_get_stat64(struct stat64 *buf);
+extern void send_get_stat64_2(struct stat64 *buf);
 extern void send_get_xattr64(struct stat64 *st, xattr_args *xattr);
 #else
 extern void send_stat64(const struct stat64 *st, func_id_t f, int ver);
diff --git a/libfakeroot.c b/libfakeroot.c
index 26a3e90..5eb35b3 

Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[tony mancill]

On Tue, Feb 28, 2023 at 11:13:35PM +0100, Markus Koschany wrote:
> Control: reassign -1 shrinksafe
> Control: severity -1 serious
> 
> I uploaded a new version of rhino a while ago and it seems this bug is still
> relevant. I have rebuilt dojo with rhino 1.7.14 and all shrinksafe tests pass.
> However the same tests fail with autopkgtest and block the migration of rhino
> to testing. Could you take a look at that please?

I'm not able to reproduce the autopkgtest failure locally running in
clean sid chroots.  First, I build the dojo source package and ran the
autopkgtest against those binaries.  When that didn't fail, I pulled the
binary packages from the archive and ran the autopkgtest against those.
Again, no failures.

I see the autopkgtest failure when I run against a bookworm chroot.

So it seems like the migration of rhino will resolve the test failure.
(Or I'm missing something fundamental.)


signature.asc
Description: PGP signature

Bug#1032110: Apparmor denies access to /etc/ipsec.secrets.d/

[Simon Deziel]

On 2023-02-28 18:37, James Lownie wrote:

It sounds like the problem is at our end then, I will investigate further.  
Thanks for helping with this Simon.


Great, please let us know how it goes! Thanks

Bug#1032105: pkg-perl-tools: [dpt prepare] gitddiff shouldn't use last tag but last tag in current branch

[Yadd]

On 2/28/23 20:26, gregor herrmann wrote:

On Tue, 28 Feb 2023 07:39:15 +0400, Yadd wrote:


thanks for this powerful tool. When using `dpt prepare` on a package
that have backports, it shows the difference with last backport, not
last unstable upload. You can try for example with lemonldap-ng.


Indeed, I've encountered this too, and it's annoying :)

Any help in finding an improvement is very welcome.


In lib/dpt-lib.sh, maybe you could replace
TAG=$(git rev-list -n1 --tags)

or simply
   TAG=$(git describe --abbrev=0)


I have a hunch that this doesn't work in all cases, and before
testing it, I even hit another issue:

Example: libsql-translator-perl

   % git tag | grep debian/1\.
   archive/debian/1.60-1
   archive/debian/1.61-1
   archive/debian/1.62-1
   debian/1.60-1
   debian/1.61-1
   debian/1.62-1
   debian/1.62-2
   debian/1.62-3

   % git rev-list -n1 --tags=debian
   ed7aa767edfdb042a5bbc4a19722236e17afd891

[matches tag: debian/1.62-3]

   % git describe --abbrev=0
   archive/debian/1.62-1

Ehm, no; first we don't want the archive/debian/* tag (from a
previous dgit upload) -- although maybe they are the same in
practice? -- , and second we want the -3 upload.


Maybe like this:

   % git describe --abbrev=0 --tags
   debian/1.62-3


Not like this:

   % git describe --abbrev=0 --match "debian/*"
   debian/1.62-1


But maybe this:

   % git describe --abbrev=0 --match "debian/*" --tags
   debian/1.62-3


Anyway, now to my actual question:
This gitddiff function is used for 2 purposes / on 2 occasions in the
dpt-* code:
- before working on a package, for whatever reason, after pulling,
   to check what happened in the repo since the last upload;
   that's the dpt-prepare case
- after importing a new upstream release, to see all changes since
   the last upload and to know what we need to change (that's in
   dpt-import-orig)
- (I also have a git alias:
   ddiff  = "!git diff --ignore-space-at-eol $(if [ \"$(dpkg-source --print-format .)\" != 
\"3.0 (native)\" ]; then git rev-list -n1 --tags=debian; else git rev-list -n1 --tags; fi)"
   so `git ddiff' does basically the same at any time)

I'm wondering that `git describe …' will do after `dpt-import-orig',
so let's try with our example package libsql-translator-perl:

   `dpt import-orig' …

   % git rev-list -n1 --tags=debian
   ed7aa767edfdb042a5bbc4a19722236e17afd891

(still the same debian/1.62-3)

   % git describe --abbrev=0
   upstream/1.63

Ha, that's what I suspected :)

   % git describe --abbrev=0 --tags
   upstream/1.63

Same …

But this works:

   % git describe --abbrev=0 --match "debian/*" --tags # [1]
   debian/1.62-3


So this looks quite well.

Maybe, in order to git rid of the separation between native and
non-native package, something funky as

   % git describe --abbrev=0 --match "$(gbp config DEFAULT.debian-tag | sed -e 
's/%(version)s/*/g;')" --tags # [2]
   debian/1.62-3


:)


Alright, maybe we all try out either [1] or [2] a bit?
I've updated my .gitconfig and my local version of
scripts/lib/dpt-lib.sh to use [2].


Hi,

I tried also [2], perfect with all Perl packages I've locally + 1500 
nodejs packages, works perfectly!


Cheers,
Yadd

Bug#1032140: [External] Re: Bug#1032140: Lenovo Z16 Install issue

[Cyril Brulebois]

David Ober  (2023-03-01):
> Test worked as you expected the network card driver looks to be
> enabled but cannot load firmware.

Thanks for this confirmation, I'll file the MR against linux later on.

> I can test if you want or you can wait until the next formal build

You'll find a local bookworm build including the patched nic-wireless
in the same directory: https://people.debian.org/~kibi/bug-1032140/

(Since it's ~650MB, it will get removed in a week or two.)


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


signature.asc
Description: PGP signature

Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[Jérémy Lal]

Le mer. 1 mars 2023 à 02:30, Thorsten Glaser  a écrit :

> Jérémy Lal dixit:
>
> >I can build nodejs on amhdal.debian.org if you're not comfortable with
> that.
>
> The problem with the DSA porterboxen is that you cannot install your own
> built packages in the chroot to use them there… unless there’s a
> solution not yet known to me?
>

Indeed, but the binary can be run from build dir, so I just need to try and
reproduce the bug from there.

Bug#1032144: New sudo warning: /etc/sudoers.d/xymon:12:12: Syntax-Fehler

[Axel Beckert]

Control: tag -1 + confirmed pending

Hi Christoph,

thanks for this bug report.

Christoph Berg wrote:
> The latest sudo version triggers this warning:
> 
> # sudo -l
> /etc/sudoers.d/xymon:12:12: Syntax-Fehler
> xymon ALL=(list) SETENV:NOPASSWD: /usr/lib/xymon/client/ext/mailman
>^~~~

I wonder what exactly is the syntax error here.

> Removing that line makes the problem go away.

On a first glance this seems to happen if Mailman (for which the list
user is) is not installed, but sudo is installed. But then again, the
user list seems on all my boxes. And for the line before that, it
doesn't argue about the user backuppc which surely doesn't exist on
most systems.

Then again, this line is untouched since 2012 when we switched the
user from hobbit to xymon, i.e. the position where the syntax error is
claimed is even older.

So I wonder: Did sudo's syntax change?

And yes, it did. It seems to have introduced a "list" keyword:

2022-12-26
  […]

  Bump SUDOERS_GRAMMAR_VERSION to 50 for the new list pseudo-command.

郎

eems to have been introduced in Testing yesterday with the migration
of sudo 1.9.13p1-1.

And indeed, if I change "list" to e.g. "listx", the error goes away.

> We should fix that for bookworm.

Ack. So the question is how to fix it.

The man page reads:

 A user name, user-ID, group, group-ID, netgroup, nonunix_group or
 nonunix_gid may be enclosed in double quotes to avoid the need
 for escaping special characters.

I guess this probably also counts for keywords. Let's see and use
double quotes around "list" (sic!):

Yep, changing it to

  xymon ALL=("list") SETENV:NOPASSWD: /usr/lib/xymon/client/ext/mailman

will make the error go away.

Will prepare an upload.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1032140: [External] Re: Bug#1032140: Lenovo Z16 Install issue

[David Ober]

Test worked as you expected the network card driver looks to be enabled but 
cannot load firmware.  I can test if you want or you can wait until the next 
formal build

David

-Original Message-
From: Cyril Brulebois  
Sent: Tuesday, February 28, 2023 4:41 PM
To: David Ober ; 1032...@bugs.debian.org
Cc: Steve McIntyre ; debian-ker...@lists.debian.org
Subject: Re: Bug#1032140: [External] Re: Bug#1032140: Lenovo Z16 Install issue

David Ober  (2023-02-28):
> Happy to test it

Great!

Here's a minimal netboot-gtk mini.iso, to test just the loading aspect:
  https://people.debian.org/~kibi/bug-1032140/

It adds qrtr-mhi (and its dependency qrtr), and both can be loaded just fine in 
QEMU (manually).

This should help ath11k_pci work better (probing shouldn't fail, at least), and 
the next step is probably getting an error about missing firmware. That's 
expected with this small build, but once we make sure ath11k_pci loads and 
probes fine, I'm happy to build a full netinst if you want to go through the 
whole installation process. Otherwise, we can stash the change in linux.git and 
that should get included in the next Debian Installer release.


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

Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[Thorsten Glaser]

Jérémy Lal dixit:

>I can build nodejs on amhdal.debian.org if you're not comfortable with that.

The problem with the DSA porterboxen is that you cannot install your own
built packages in the chroot to use them there… unless there’s a
solution not yet known to me?

bye,
//mirabilos
-- 
“ah that reminds me, thanks for the stellar entertainment that you and certain
other people provide on the Debian mailing lists │ sole reason I subscribed to
them (I'm not using Debian anywhere) is the entertainment factor │ Debian does
not strike me as a place for good humour, much less German admin-style humour”

Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[James Addison]

That'd be great, thank you - my local (emulated) aarch64 build of
nodejs is proving to be much more time consuming than I expected.

On Tue, 28 Feb 2023 at 23:21, Jérémy Lal  wrote:
>
>
>
> Le mar. 28 févr. 2023 à 19:06, James Addison  a écrit :
>>
>> On Tue, Feb 28, 2023, 17:55 Thorsten Glaser  wrote:
>>>
>>> Can you test it? I don’t have the bandwidth for that right now…
>>
>>
>> Should be able to, yep - I seem to remember seeing some repro instructions 
>> from you on the GitHub thread and will give those a try in an emulator/vm.
>
>
> I can build nodejs on amhdal.debian.org if you're not comfortable with that.
>
>> --
>> Pkg-javascript-devel mailing list
>> pkg-javascript-de...@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#1032173: identity recoding is too identical

[Zefram]

Package: recode
Version: 3.6-24
Severity: normal

recode(1) usually checks that its input conforms to the specified input
encoding, and signals an error if it doesn't:

$ echo $'L\xe9on' | recode utf8..utf7
Lrecode: Invalid input in step `UTF-8..UNICODE-1-1-UTF-7'

But if the output encoding happens to be the same as the input encoding
then this checking doesn't happen, and invalid output can be produced:

$ echo $'L\xe9on' | recode utf8..utf8 | od -tc
000   L 351   o   n  \n
005

The invocation with both encodings the same superficially looks like
it's requesting an identity transformation, and it would correctly have
the behaviour of an identity transformation on input that were correctly
encoded.  Because of the input checking that recode(1) usually provides,
it seems like this kind of invocation would be useful, as something
that copies its input while checking the encoding.  Apparently it's
being optimised incorrectly, to a pure identity transformation without
the checking.

-zefram

Bug#1032172: override: libdaxctl1:libs/optional

[Michael Biebl]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: override
X-Debbugs-Cc: nd...@packages.debian.org
Control: affects -1 + src:ndctl

The section of the library package is currently incorrectly set to
libdevel. Please change that to libs.

Thanks.

Bug#1032171: override: libndctl6:libs/optional

[Michael Biebl]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: override
X-Debbugs-Cc: nd...@packages.debian.org
Control: affects -1 + src:ndctl

The section of libndctl6 is currently incorrectly set to libdevel.
Please change that to libs.

Thanks.

Bug#1032110: Apparmor denies access to /etc/ipsec.secrets.d/

[James Lownie]

It sounds like the problem is at our end then, I will investigate further.  
Thanks for helping with this Simon.

- Original Message -
From: "Simon Deziel" 
To: "James Lownie" , 1032...@bugs.debian.org
Sent: Wednesday, 1 March, 2023 10:00:13 AM
Subject: Re: Bug#1032110: Apparmor denies access to /etc/ipsec.secrets.d/

On 2023-02-28 17:42, James Lownie wrote:
> It's not in salsa but it was in my config file.  Is it the case that my 
> version of /etc/apparmor.d/usr.lib.ipsec.charon is different to the package 
> version?
> 
> I didn't modify that file manually (apart from moving the lines up in the 
> file), I did deploy ipsec with an Ansible playbook but I just had a look 
> through it and I don't think it modified it either.

I just downloaded the same package 
(https://packages.debian.org/bullseye/strongswan) and double checked. 
The Apparmor profile doesn't mention any "/etc/ipsec.secrets.d" 
directory. Dunno what to tell you, sorry.

HTH.
Simon


-- 
Message  protected by MailGuard: e-mail anti-virus, anti-spam and content 
filtering.https://www.mailguard.com.au/mg
Click here to report this message as spam:
https://console.mailguard.com.au/ras/24UkePOXmh/8Ecez7b7drcTGdw6LBjfx/5.5

Bug#1031414: clinfo breaks libgpuarray autopkgtest on i386: numerical deltas

[Andreas Beckmann]

On 24/02/2023 23.52, Adrian Bunk wrote:> $ clang-15 -march=i686 -O2 
test_fmod.c -lm -frounding-math  && ./a.out

> (-ffp-model=strict is a superset of -frounding-math)

Very nice finding, unfortunately pocl fails most of its tests (with a 
seemingly unrelated error) if I enable one of these options for kernel 
compilation.

https://github.com/pocl/pocl/issues/1183


Andreas

Bug#971345: libwebkit2gtk: The Epiphany doesn't work anymore after the libwebkit2gtk-4.0

[Alberto Garcia]

On Tue, Feb 28, 2023 at 04:33:13PM -0500, Andreas Kohlbach wrote:

> Followup-For: Bug #971345

Hi, I think that this problem that you are reporting is different from
#971345, ...

> Browser hangs and the console logs
> 
> (WebKitWebProcess:2): GLib-GIO-CRITICAL **: 12:46:14.244: 
> g_dbus_connection_get_unique_name: assertion 'G_IS_DBUS_CONNECTION 
> (connection)' failed

This is odd, do you have at-spi2-core installed ?

Berto

Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[Jérémy Lal]

Le mar. 28 févr. 2023 à 19:06, James Addison  a écrit :

> On Tue, Feb 28, 2023, 17:55 Thorsten Glaser  wrote:
>
>> Can you test it? I don’t have the bandwidth for that right now…
>
>
> Should be able to, yep - I seem to remember seeing some repro instructions
> from you on the GitHub thread and will give those a try in an emulator/vm.
>

I can build nodejs on amhdal.debian.org if you're not comfortable with that.

-- 
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
>

Bug#1032168: meson: autopkgtest fills disk completely

[Jussi Pakkanen]

On Tue, 28 Feb 2023 at 23:30, Paul Gevers  wrote:

> With your last upload of meson, we're seeing issues on
> ci.debian.net. It turns out that the autopkgtest of meson is using so
> much disk space that the most of our hosts runs out of it when meson
> is tested.

This is weird. As far as we know we have not made any changes that
should affect disk usage in 1.0.1.

Is /tmp on the same file system as the rest of the image or is it a
separate partition?

Is it possible to know how close to filling up the disk the old
succeeding builds got? And how much disk space is given to the build
in total?

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Sam Hartman]

> "Michael" == Michael Biebl  writes:

Michael> If a service is not supposed to be enabled, then an
Michael> override for dh_installsystemd is the correct solution,
Michael> setting --no-enable, but not by moving it into a
Michael> subpackage.

Sorry, I was imprecise.
Imagine something like a webserver.
You might well want to install the web server binary so you can run it
as a user for development testing an app or for sharing files.
But you might also want to  install it as a system service.
I think two options are viable depending on factors like whether some
dependencies want to know that it is running as a system service and
how common each configuration will be:

* Install a disabled unit by default but keep everything into one
  package

* or move the system service unit into its own package.  If you just
  want the binary you install one package, but if you want the system
  service, you install the package containing the unit.
  In this case the unit is enabled by default.

If we were to move units back from /usr/lib/systemd/system to
/lib/systemd/system, the second case would potentially trigger the dpkg
bug.  But:


Michael> I also don't see a good reason, why a unit file, once
Michael> installed in /usr/lib/systemd/system should ever move back
Michael> to /lib/systemd/system.

I agree with you here.   This requires keeping the debhelper change
rather than backing it out after the bookworm release.
I think both you and I support that.


signature.asc
Description: PGP signature

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Luca Boccassi]

On Tue, 28 Feb 2023 23:54:15 +0100 Michael Biebl 
wrote:
> Am 28.02.23 um 21:48 schrieb Sam Hartman:
> >  >> Moreover, I suspect in a number of the cases related to
this
> >  >> current bug, replaces will be likely.  I suspect that in
some of
> >  >> the cases where units have been introduced that are
disabled
> >  >> currently, but will be enabled by the dh_installsystemd
change,
> >  >> we will discover we'd like those units disabled in some
> >  >> configurations.  A logical way to handle that may be to
split out
> >  >> the units into separate packages.  That makes the replaces
> >  >> interacts with file moves class of bugs more likely in this
> >  >> situation than average.
> > 
> >  Sebastian> The TC advice refers to files moving between
packages
> >  Sebastian> which wouldn't be the case here (at least not in
> >  Sebastian> general).
> > 
> > Not in general, but I think that these  systemd units will be more
> > likely than average to move packages.
> > 
> > These units have been sitting around more or less doing nothing for
> > months.
> > And in most cases we don't have bugs.
> > 
> > I'm imagining the  following situation:
> > 
> > * We make the debhelper change
> > 
> > * unit b in package a starts running
> > 
> > * Users complain that they don't really always want that.
> > 
> > * We release
> > 
> > * unit b is moved back to /lib/systemd/system
> > 
> > * Later the complaints get serious enough that package a splits
into a
> >    and a-daemon, a-daemon replaces/breaks a<< version-of-split.  a-
daemon
> >    now has b.
> 
> If a service is not supposed to be enabled, then an override for 
> dh_installsystemd is the correct solution, setting --no-enable, but
not 
> by moving it into a subpackage.
> 
> I also don't see a good reason, why a unit file, once installed in 
> /usr/lib/systemd/system should ever move back to /lib/systemd/system.

Also it is trivial for users to disable or mask units, so there is
really no reason to move them to subpackages.

-- 
Kind regards,
Luca Boccassi


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

Bug#1032110: Apparmor denies access to /etc/ipsec.secrets.d/

[Simon Deziel]

On 2023-02-28 17:42, James Lownie wrote:

It's not in salsa but it was in my config file.  Is it the case that my version 
of /etc/apparmor.d/usr.lib.ipsec.charon is different to the package version?

I didn't modify that file manually (apart from moving the lines up in the 
file), I did deploy ipsec with an Ansible playbook but I just had a look 
through it and I don't think it modified it either.


I just downloaded the same package 
(https://packages.debian.org/bullseye/strongswan) and double checked. 
The Apparmor profile doesn't mention any "/etc/ipsec.secrets.d" 
directory. Dunno what to tell you, sorry.


HTH.
Simon

Bug#1032120: tiledb: uses atomic operations, but is not linked to libatomic

[Dirk Eddelbuettel]

Hi Graham,

On 28 February 2023 at 19:36, Graham Inggs wrote:
| Hi Dirk
| 
| Thanks for the quick upload!
| Already got a successful build of tiledb-py on riscv64[1].
| 
| On Tue, 28 Feb 2023 at 17:14, Dirk Eddelbuettel  wrote:
| > TileDB upstream does everything in CMake (which I do not fully speak) so
| > "eventually" it would be nice to port this.
| 
| After testing the patch which I eventually submitted, I found a bug[2]
| that in message #5, discusses a way to automatically link libatomic
| when required by calling the linker with -pthread, instead of linking
| with -lpthread.
| 
| Then, in message #25, the way to do this in CMake is shown:
| 
| set(THREADS_PREFER_PTHREAD_FLAG ON)
| find_package(Threads REQUIRED)
|
| I tried applying this patch to TileDB, but it did not work for me.
| Perhaps upstream can make more sense of what is suggested in that bug
| report and in the linked cmake issue[3].

That's quite helpful. I will pass that on. 

Cheers, Dirk
 
| Regards
| Graham
| 
| 
| [1] https://buildd.debian.org/status/logs.php?pkg=tiledb-py=riscv64
| [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895969
| [3] https://cmake.org/Bug/view.php?id=14767

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Michael Biebl]

Am 28.02.23 um 21:48 schrieb Sam Hartman:

 >> Moreover, I suspect in a number of the cases related to this
 >> current bug, replaces will be likely.  I suspect that in some of
 >> the cases where units have been introduced that are disabled
 >> currently, but will be enabled by the dh_installsystemd change,
 >> we will discover we'd like those units disabled in some
 >> configurations.  A logical way to handle that may be to split out
 >> the units into separate packages.  That makes the replaces
 >> interacts with file moves class of bugs more likely in this
 >> situation than average.

 Sebastian> The TC advice refers to files moving between packages
 Sebastian> which wouldn't be the case here (at least not in
 Sebastian> general).

Not in general, but I think that these  systemd units will be more
likely than average to move packages.

These units have been sitting around more or less doing nothing for
months.
And in most cases we don't have bugs.

I'm imagining the  following situation:

* We make the debhelper change

* unit b in package a starts running

* Users complain that they don't really always want that.

* We release

* unit b is moved back to /lib/systemd/system

* Later the complaints get serious enough that package a splits into a
   and a-daemon, a-daemon replaces/breaks a<< version-of-split.  a-daemon
   now has b.


If a service is not supposed to be enabled, then an override for 
dh_installsystemd is the correct solution, setting --no-enable, but not 
by moving it into a subpackage.


I also don't see a good reason, why a unit file, once installed in 
/usr/lib/systemd/system should ever move back to /lib/systemd/system.



Michael




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032133: dh_python3: Record debian as INSTALLER in .dist-info

[Scott Kitterman]

Okay.  Nevermind on that idea then.

Would it make sense to include debian, installer, version (of installer) in 
whatever the proper format is as a troubleshooting aid?

Scott K

Bug#1032133: dh_python3: Record debian as INSTALLER in .dist-info

[Stefano Rivera]

Hi Scott (2023.02.28_10:24:34_-0400)
> > At the moment, I don't think this would affect much, but it would give
> > python installers more information about what's going on. In pip's case,
> > it can disable its own "outdated version of pip" notifications when it
> > detects that it wasn't installed by pip. That allows us to drop a patch
> > in pip.
> 
> Would it make more sense to mimic the PEP 668 terminology and say installer 
> is 
> "EXTERNALLY-MANAGED".  Then pip wouldn't need to keep a list of installers to 
> ignore.  Distros could all just use that.

In pip, it's the other way around. Not a list of known things to leave
alone, but just a sanity check that it was installed by pip, not
something else:

https://github.com/pypa/pip/blob/30fd549c77031275b9f2bde2b30a7f614780939c/src/pip/_internal/self_outdated_check.py#L146-L153

I don't think "EXTERNALLY-MANAGED" would be the right thing to put in
INSTALLER. It doesn't fit within the description of the file.

SR

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


signature.asc
Description: PGP signature

Bug#1032160: tfortune FTCBFS: multiple reasons

[Andre Noll]

On Tue, Feb 28, 06:04, Helmut Grohne wrote
> Source: tfortune
> Version: 1.0.1-1
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> tfortune fails to cross build from source.

First of all, thanks for pointing this out and for providing a
patch. Most likely, nobody has ever tried to cross build tfortune,
so failures are kind of expected...

> The immediate failure is failing to find the lopsub library since it
> configures for the build architecture. This happens as no --build nor --host
> is passed which would have happened automatically if dh_auto_configure could
> be used.  Thus it'll have to be passed manually.

Do you recommend to get rid of the override_dh_auto_configure target
in debian/rules?

> Then configure fails finding config.h.in, which for some reason is not
> created (nor asked for) by the override_dh_autoreconf. And finally, the
> actual Makefile does not pick up the compiler detected by configure and
> rather uses plain cc, so we'll have to tell it as well. All in all, the build
> system is quite arcane and requires many fiddles to make it work properly.
> I'm attaching a patch for your convenience and generally recommend using
> something more standard if possible.

I'm in favor of switching to something more standard, but I will
need your help. What's the best way forward to improve on the current
situation? Do you want me to apply your patch as is and push out the
result to the public repo? Is there anything else I can do to make
life easier for the Debian people?

Thanks again
Andre
-- 
Max Planck Institute for Biology
Tel: (+49) 7071 601 829
Max-Planck-Ring 5, 72076 Tübingen, Germany
http://people.tuebingen.mpg.de/maan/


signature.asc
Description: PGP signature

Bug#1032110: Apparmor denies access to /etc/ipsec.secrets.d/

[Simon Deziel]

On 2023-02-28 17:12, James Lownie wrote:

Hi Simon, thanks for the suggestion.  I'm going to wait and see if other people 
can reproduce this before running any tests, this machine is now in production 
which makes things awkward.  I would have thought putting the secrets in 
/etc/ipsec.secrets.d/ would just work given it was already in the profile as a 
directory with read access.


Hmm, I don't see such *directory* rule in salsa:

https://salsa.debian.org/debian/strongswan/-/blob/debian/master/debian/usr.lib.ipsec.charon#L47-51

Maybe you thought that "/etc/ipsec.*.secrets" covered your dir? If so, 
that's not the case because Apparmor needs the trailing "/" to apply to 
directories. So the rule "/etc/ipsec.*.secrets" only covers files with a 
prefix of "ipsec." and a ".secrets" suffix.


HTH,
Simon

Bug#1025823: qt6-base FTBFS on Alpha; Unknown Q_PROCESSOR_xxx macro

[Patrick Franz]

Hi,

somehow the patch still doesn't apply cleanly:

dpkg-source: info: building qt6-base using existing 
./qt6-base_6.4.2+dfsg.orig.tar.xz
dpkg-source: info: using patch list from debian/patches/series
patching file src/corelib/global/qprocessordetection.h
patching file src/corelib/plugin/qelfparser_p.cpp
Hunk #2 FAILED at 382.
1 out of 2 hunks FAILED
dpkg-source: info: the patch has fuzz which is not allowed, or is malformed


I'm afraid this won't be merged for bookworm and will have to wait
until Debian gets 6.5 or later.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Markus Koschany]

Control: reassign -1 shrinksafe
Control: severity -1 serious

Hi,

I uploaded a new version of rhino a while ago and it seems this bug is still
relevant. I have rebuilt dojo with rhino 1.7.14 and all shrinksafe tests pass.
However the same tests fail with autopkgtest and block the migration of rhino
to testing. Could you take a look at that please?

Regards,

Markus


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

Bug#1031800: mmdebstrap: --keyring doesn't work properly

[Dima Kogan]

Johannes Schauer Marin Rodrigues  writes:

> The weirdest thing about your bug is that copying your key to
> /etc/apt/trusted.gpg.d/ makes it work for you because when you changed the
> location of Dir::Etc::TrustedParts it just pointed to a different directory.
> Apt should not treat keys differently just because the path to them looks
> different...

Hi Josch. Thanks for looking into this. You're right, it sounds weird
that apt would care about the name of the directory, so I just poked at
it again.

It's not actually that weird; I just wasn't looking at the error
messages closely enough. The /etc/apt/sources.list has two repos:

- main bookworm repo. Signed with the Debian keys
- my repo. Signed with its own key

If I "mmdebstrap --keyring MY-KEY-DIRECTORY" then apt actually does find
the keys to my repo, and it's happy about it. The problem is that it
then doesn't look in /etc/apt/trusted.gpg.d and it thinks the main
bookworm repo is unverifiable. So there's no mystery here, but my use
case still doesn't work. Some questions, if I may:

- By default apt has /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/*.
  Which of these is expected to contain the keys for Debian?

- I want mmdebstrap to use the extra repo and the keys, so what's the
  right way to do that? I guess I need to:

  - Create new key directory

  - Copy /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/* and my new
keys into it

  - Pass that to mmdebstrap --keyring

  - Add my new keys into the chroot with an mmdebstrap hook so that
these are available inside the chroot

Is that right? If so, can we make this explicit in the manpage?

Thank you very much!

Bug#1031863: libqt5sql5-mysql: incompatible change in libmariadb3 breaks kontact, needs upstream fix in libqt5sql5-mysql

[Paul Boddie]

On Tuesday, 28 February 2023 22:35:35 CET Lisandro Damián Nicanor Pérez Meyer 
wrote:
> 
> On Tue, 28 Feb 2023 at 18:31, Paul Boddie  wrote:
> > So, to summarise:
> > 
> > Standard libqt5sql5-mysql plus standard libmariadb3 breaks
> > Akonadi/Kontact.
> > Revised libqt5sql5-mysql plus standard libmariadb3 fixes Akonadi/Kontact.
> > Standard libqt5sql5-mysql plus revised libmariadb3 breaks Akonadi/Kontact.
> > 
> > But as I noted, since the fix to libqt5sql5-mysql involves interpretation
> > of the version identifier, I wonder whether I am really building a fixed
> > libmariadb3 package.
> 
> If by "standard" you mean "what was shipped with buster" I'm pretty
> sure it should work, else we would have tons of users telling us :-D
> Now if you mean something different I did not get the real meaning :-)

I mean standard as in the most recent versions:

libqt5sql5-mysql:amd64 5.11.3+dfsg1-1+deb10u5
libmariadb3:amd64 1:10.3.38-0+deb10u1

As in the combination which caused my mail client to stop working last week, 
possibly when this package update rolled in...

2023-02-21 10:26:08 upgrade libmariadb3:amd64 1:10.3.36-0+deb10u2 
1:10.3.38-0+deb10u1

Source: /var/log/dpkg.log

Paul

Bug#1032169: pipewire: lineout device missing on login. killing pipewire restores all devices

[lachlan-00]

Package: pipewire
Version: 0.3.66-1
Severity: normal

Dear Maintainer,

When i log into my desktop using pipewire I should have 3 audio output devices
but i'm only shown 2

lspci | grep -i audio
0b:00.1 Audio device: NVIDIA Corporation GP106 High Definition Audio Controller
(rev a1)
0d:00.4 Audio device: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD
Audio Controller

The Starship/Matisse device has an 'SPDIF' and 'line out' outputs.

To restore this 3rd device i need to kill pipewire after i've logged in and
then let it restart.

After killing the process the SPDIF is recreated (dupe devices in the list) and
then the line out is restored

I use the lineout for all audio and for my headset microphone so i don't have
audio until killing the pipewire process.

I have pipewire-pulse running but don't need to kill that process.

This also affects the microphone lineout which i assume is the same device as
the lineout output.

This has only happened after the transition from pulseaudio to pipewire.

I haven't changed any config to try and rectify this. initially i thought that
as a user my desktop was starting audio processes before pipewire was fully
started but it seems to never find this line out device until the process is
killed while the desktop is running.

I've added this info to a bug on the pipewire project as well in case it's not
debian related.

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3056


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

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

Versions of packages pipewire depends on:
ii  adduser  3.131
ii  init-system-helpers  1.65.2
ii  libpipewire-0.3-modules  0.3.66-1
ii  pipewire-bin 0.3.66-1

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

Bug#1021664: vlc: Automatic hardware acceleration drops most frames

[Leandro Ramos]

Package: vlc
Version: 3.0.18-2
Followup-For: Bug #1021664
X-Debbugs-Cc: leandrora...@disroot.org

Dear Maintainer,

I confirm this bug. The only workaround is to disable the hardware
acceleration.

With hardware acceleration the video is too slow, really.

VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
[56046af5a550] main libvlc: Executando o VLC com a interface padrão. Use
'cvlc' para usar o VLC sem interface.
[56046b003f80] main playlist: playlist is empty
[7fb670004990] gl gl: Initialized libplacebo v4.208.0 (API v208)
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
[7fb670004990] gl gl: Initialized libplacebo v4.208.0 (API v208)
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
[7fb688d24a60] avcodec decoder: Using OpenGL/VAAPI backend for VDPAU for
hardware decoding

Thank you.


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

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

Versions of packages vlc depends on:
ii  vlc-bin  3.0.18-2
ii  vlc-plugin-base  3.0.18-2
ii  vlc-plugin-qt3.0.18-2
ii  vlc-plugin-video-output  3.0.18-2

Versions of packages vlc recommends:
ii  vlc-l10n   3.0.18-2
ii  vlc-plugin-access-extra3.0.18-2
ii  vlc-plugin-notify  3.0.18-2
ii  vlc-plugin-samba   3.0.18-2
ii  vlc-plugin-skins2  3.0.18-2
ii  vlc-plugin-video-splitter  3.0.18-2
ii  vlc-plugin-visualization   3.0.18-2

Versions of packages vlc suggests:
pn  vlc-plugin-fluidsynth  
pn  vlc-plugin-jack
pn  vlc-plugin-pipewire
pn  vlc-plugin-svg 

Versions of packages libvlc-bin depends on:
ii  libc62.36-8
ii  libvlc5  3.0.18-2

Versions of packages libvlc5 depends on:
ii  libc62.36-8
ii  libvlccore9  3.0.18-2

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.18-2

Versions of packages vlc-bin depends on:
ii  libc6   2.36-8
ii  libvlc-bin  3.0.18-2
ii  libvlc5 3.0.18-2

Versions of packages vlc-plugin-access-extra depends on:
ii  libc62.36-8
ii  libsrt1.5-gnutls 1.5.1-1
ii  libvlccore9 [vlc-plugin-abi-3-0-0f]  3.0.18-2
ii  libvncclient10.9.14+dfsg-1
ii  libxcb-composite01.15-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4 0.7.4-20
ii  libarchive13 3.6.2-1
ii  libaribb24-0 1.0.3-2
ii  libasound2   1.2.8-1+b1
ii  libass9  1:0.17.0-2
ii  libavahi-client3 0.8-9
ii  libavahi-common3 0.8-9
ii  libavc1394-0 0.5.4-5
ii  libavcodec59 7:5.1.2-3
ii  libavformat597:5.1.2-3
ii  libavutil57  7:5.1.2-3
ii  libbluray2   1:1.3.4-1
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libcddb2 1.3.2-7
ii  libchromaprint1  1.5.1-2+b1
ii  libdav1d61.0.0-2
ii  libdbus-1-3  1.14.6-1
ii  libdc1394-25 2.2.6-4
ii  libdca0  0.0.7-2
ii  libdvbpsi10  1.3.3-1
ii  libdvdnav4   6.1.1-1
ii  libdvdread8  6.1.3-1
ii  libebml5 1.4.4-1
ii  libfaad2 2.10.1-1
ii  libflac121.4.2+ds-2
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-4
ii  libfribidi0  1.0.8-2.1
ii  libgcc-s112.2.0-14
ii  

Bug#1032140: [External] Re: Bug#1032140: Lenovo Z16 Install issue

[Cyril Brulebois]

David Ober  (2023-02-28):
> Happy to test it 

Great!

Here's a minimal netboot-gtk mini.iso, to test just the loading aspect:
  https://people.debian.org/~kibi/bug-1032140/

It adds qrtr-mhi (and its dependency qrtr), and both can be loaded just
fine in QEMU (manually).

This should help ath11k_pci work better (probing shouldn't fail, at
least), and the next step is probably getting an error about missing
firmware. That's expected with this small build, but once we make sure
ath11k_pci loads and probes fine, I'm happy to build a full netinst if
you want to go through the whole installation process. Otherwise, we can
stash the change in linux.git and that should get included in the next
Debian Installer release.


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


signature.asc
Description: PGP signature

Bug#1031863: libqt5sql5-mysql: incompatible change in libmariadb3 breaks kontact, needs upstream fix in libqt5sql5-mysql

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Tue, 28 Feb 2023 at 18:31, Paul Boddie  wrote:
> So, to summarise:
>
> Standard libqt5sql5-mysql plus standard libmariadb3 breaks Akonadi/Kontact.
> Revised libqt5sql5-mysql plus standard libmariadb3 fixes Akonadi/Kontact.
> Standard libqt5sql5-mysql plus revised libmariadb3 breaks Akonadi/Kontact.
>
> But as I noted, since the fix to libqt5sql5-mysql involves interpretation of
> the version identifier, I wonder whether I am really building a fixed
> libmariadb3 package.

If by "standard" you mean "what was shipped with buster" I'm pretty
sure it should work, else we would have tons of users telling us :-D
Now if you mean something different I did not get the real meaning :-)

Cheers, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#971345: libwebkit2gtk: The Epiphany doesn't work anymore after the libwebkit2gtk-4.0

[Andreas Kohlbach]

Package: libwebkit2gtk-4.0-37
Version: 2.38.5-1~deb11u1
Followup-For: Bug #971345
X-Debbugs-Cc: a...@spamfence.net

Dear Maintainer,

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

   * What led up to the situation?

Staring the Epiphany browser.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Just starting the browser.

   * What was the outcome of this action?

Browser hangs and the console logs

(WebKitWebProcess:2): GLib-GIO-CRITICAL **: 12:46:14.244: 
g_dbus_connection_get_unique_name: assertion 'G_IS_DBUS_CONNECTION 
(connection)' failed

(epiphany:7717): epiphany-WARNING **: 12:46:14.258: Web process crashed

Please note the last update on Stable was the 17.02.2023, the day it stopped 
working. This was 11 days ago.

Same problem on Debian Testing.

This might also just be an incompability on Epiphany after the 
lib-webkit-update, so the browser is the problem instead?

   * What outcome did you expect instead?

A working browser.

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


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

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

Versions of packages libwebkit2gtk-4.0-37:amd64 depends on:
ii  bubblewrap  0.4.1-3
ii  gstreamer1.0-plugins-base   1.18.4-2
ii  gstreamer1.0-plugins-good   1.18.4-2+deb11u1
ii  libatk1.0-0 2.36.0-2
ii  libatomic1  10.2.1-6
ii  libc6   2.31-13+deb11u5
ii  libcairo-gobject2   1.16.0-5
ii  libcairo2   1.16.0-5
ii  libegl1 1.3.2-1
ii  libenchant-2-2  2.2.15-1
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.4+dfsg-1+deb11u1
ii  libgcc-s1   10.2.1-6
ii  libgcrypt20 1.8.7-6
ii  libgdk-pixbuf-2.0-0 2.42.2+dfsg-1+deb11u1
ii  libglib2.0-02.66.8-1
ii  libglx0 1.3.2-1
ii  libgpg-error0   1.38-2
ii  libgstreamer-gl1.0-01.18.4-2
ii  libgstreamer-plugins-base1.0-0  1.18.4-2
ii  libgstreamer1.0-0   1.18.4-2.1
ii  libgtk-3-0  3.24.24-4+deb11u2
ii  libharfbuzz-icu02.7.4-1
ii  libharfbuzz0b   2.7.4-1
ii  libhyphen0  2.8.8-7
ii  libicu6767.1-7
ii  libjavascriptcoregtk-4.0-18 2.38.5-1~deb11u1
ii  libjpeg62-turbo 1:2.0.6-4
ii  liblcms2-2  2.12~rc1-2
ii  libmanette-0.2-00.2.5-1
ii  libopengl0  1.3.2-1
ii  libopenjp2-72.4.0-3
ii  libpango-1.0-0  1.46.2-3
ii  libpangocairo-1.0-0 1.46.2-3
ii  libpng16-16 1.6.37-3
ii  libseccomp2 2.5.1-1+deb11u1
ii  libsecret-1-0   0.20.4-2
ii  libsoup2.4-12.72.0-2
ii  libsqlite3-03.34.1-3
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-7+deb11u1
ii  libtasn1-6  4.16.0-2+deb11u1
ii  libwayland-client0  1.18.0-2~exp1.1
ii  libwayland-egl1 1.18.0-2~exp1.1
ii  libwayland-server0  1.18.0-2~exp1.1
ii  libwebp60.6.1-2.1
ii  libwebpdemux2   0.6.1-2.1
ii  libwoff11.0.2-1+b1
ii  libwpe-1.0-11.10.0-2
ii  libwpebackend-fdo-1.0-1 1.8.0-1
ii  libx11-62:1.7.2-1
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.5-2
ii  libxml2 2.9.10+dfsg-6.7+deb11u3
ii  libxrender1 1:0.9.10-1
ii  libxslt1.1  1.1.34-4+deb11u1
ii  libxt6  1:1.2.0-1
ii  xdg-dbus-proxy  0.1.2-2
ii  zlib1g  1:1.2.11.dfsg-2+deb11u2

Versions of packages libwebkit2gtk-4.0-37:amd64 recommends:
ii  gstreamer1.0-gl   1.18.4-2
ii  gstreamer1.0-libav1.18.4-3
ii  gstreamer1.0-plugins-bad  1.18.4-3
ii  libgl1-mesa-dri   20.3.5-1
ii  xdg-desktop-portal-gtk1.8.0-1

Versions of packages libwebkit2gtk-4.0-37:amd64 suggests:
pn  gstreamer1.0-alsa  

-- no debconf information

Bug#1031863: libqt5sql5-mysql: incompatible change in libmariadb3 breaks kontact, needs upstream fix in libqt5sql5-mysql

[Paul Boddie]

On Monday, 27 February 2023 12:07:27 CET Paul Boddie wrote:
> 
> I think I already established the origin of the problem:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031770#25
> 
> For some reason, someone decided to merge an incompatible change to the 10.3
> branch of the MariaDB library code, breaking the API.
> 
> I suppose I could restore my libqt5sql5-mysql package to the standard one,
> reverting the upstream workaround, then I could revert this incompatible
> test in libmariadb3, and then I could see if I can still read my mail
> messages. Would that help?

Well, I tried to build a libmariadb3 package using the delightful gbp tool, 
then I restored the standard version of the libqt5sql5-mysql package and 
installed this revised libmariadb3 package, but either reverting the upstream 
change made no difference within libmariadb3 or I failed to introduce the 
change and gbp just built the standard package all over again.

So, to summarise:

Standard libqt5sql5-mysql plus standard libmariadb3 breaks Akonadi/Kontact.
Revised libqt5sql5-mysql plus standard libmariadb3 fixes Akonadi/Kontact.
Standard libqt5sql5-mysql plus revised libmariadb3 breaks Akonadi/Kontact.

But as I noted, since the fix to libqt5sql5-mysql involves interpretation of 
the version identifier, I wonder whether I am really building a fixed 
libmariadb3 package.

Paul

Bug#1032168: meson: autopkgtest fills disk completely

[Paul Gevers]

Source: meson
Version: 1.0.1-1
Severity: serious

Dear Jussi,

With your last upload of meson, we're seeing issues on
ci.debian.net. It turns out that the autopkgtest of meson is using so
much disk space that the most of our hosts runs out of it when meson
is tested.

See e.g. the history (look for the tmpfails for 1.0.1-1) of armhf,
ppc64el and s390x:
https://ci.debian.net/packages/m/meson/testing/armhf/
https://ci.debian.net/packages/m/meson/testing/arm64/
https://ci.debian.net/packages/m/meson/testing/ppc64el/
https://ci.debian.net/packages/m/meson/testing/s390x/

Particularly s390x was bad, as we only have one host, so it took down
all capacity.

Paul

Bug#1032165: gcc-12-cross-ports: not binNMU safe

[Sebastian Ramacher]

Control: clone -1 -2
Control: reassign -2 gcc-11-cross-mipsen 5+c3
Control: retitle -2 gcc-11-cross-mipsen: not binNMU-safe

On 2023-02-28 22:13:59 +0100, Sebastian Ramacher wrote:
> Source: gcc-12-cross-ports
> Version: 12
> Severity: serious
> 
> The method to compute the version of the binary packages is not
> binNMU-safe. This can be seen from the latest round of binNMUs to
> rebuild for outdated Built-Using fields. See
> https://buildd.debian.org/status/fetch.php?pkg=gcc-12-cross-ports=amd64=12%2Bb1=1677602107=0
> 
> As it can be seen from the log, the version computed for the binary
> packages is the same as the one of the build of the initial upload of
> version 12. The binNMU version -- b1 in this case -- is missing.

gcc-11-cross-mipsen is affected by the same issue. Cloning and
reassigning.

Cheers
-- 
Sebastian Ramacher

Bug#1032166: do not release in bookworm

[Ana Guerrero Lopez]

Source: debian-timeline
Version: 45
Severity: serious
X-Debbugs-Cc: debian-public...@lists.debian.org

Please, keep debian-timeline out of bookworm, the installed HTML doesn't
show the timeline like it should so the package is useless.

Bug#1032162: RM: debian-timeline/45

[Paul Gevers]

Hi Ana,

On 28-02-2023 21:57, Ana Guerrero Lopez wrote:

Please, keep debian-timeline out of bookworm, the installed HTML doesn't
show the timeline like it should so the package is useless.


The recommended way to achieve that is by filing an RC bug against the 
package and let autoremoval take care of it. That way you are in control 
and you can lift the block once the package is ready again (in some future).


If instead you want the package removed from Debian, the bug should be 
reassigned to ftp.debian.org.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032165: gcc-12-cross-ports: not binNMU safe

[Sebastian Ramacher]

Source: gcc-12-cross-ports
Version: 12
Severity: serious

The method to compute the version of the binary packages is not
binNMU-safe. This can be seen from the latest round of binNMUs to
rebuild for outdated Built-Using fields. See
https://buildd.debian.org/status/fetch.php?pkg=gcc-12-cross-ports=amd64=12%2Bb1=1677602107=0

As it can be seen from the log, the version computed for the binary
packages is the same as the one of the build of the initial upload of
version 12. The binNMU version -- b1 in this case -- is missing.

Cheers
-- 
Sebastian Ramacher

Bug#1032164: bouncycastle: inconsistency in debian/rules?

[Thomas Uhle]

Source: bouncycastle
Version: 1.72-1
Severity: normal

Dear maintainers,

I wonder why in debian/rules the pom files were synchronized with the 
ones from Maven having the suffix "-jdk18on" while for building the binary 
packages still "ant/jdk15+.xml" is used instead of "ant/jdk18+.xml".


On Maven Central, the two versions of BouncyCastle jar files with the 
suffices "-jdk18on" and "-jdk15to18" differ in the point that unlike the 
latter the ones with the suffix "-jdk18on" are multi-release jar files 
which also support some features that have been introduced in newer Java 
releases (9, 11 and 15), and so could speed up some computations.


Debian's versions of the jar files seem to match the ones from Maven with 
the suffix "-jdk15to18" but the pom files in 
/usr/share/maven-repo/org/bouncycastle/*/1.72/ claim that they match the 
ones with the suffix "-jdk18on".  This seems to be inconsistent.


Could this be or become a problem?

Best regards,

Thomas Uhle

Bug#1032136: installation-reports: Touchpad does not work during a graphical installation

[Cyril Brulebois]

Caleb McKay  (2023-02-28):
> Here ya go! If you need anything, just let me know.

OK, so the input device is definitely not seen in d-i.

Let me guess, `lsmod|grep lpss` returns stuff in your installed system?

I think that's something I've already seen during a BSP, but we got
side-tracked by falling into various other rabbit holes, something like
LPSS behind missing in d-i, which means some devices aren't seen. My
vague recollection around LPSS seems to be confirmed by things like
these:
  
https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/servers/platforms/intel-pentium-silver-and-intel-celeron-processors-datasheet-volume-1-of-2/005/intel-lpss-inter-integrated-circuit-i2c-controllers/

which are about those, found on Celeron…
  Intel® LPSS Inter-Integrated Circuit (I2C) Controllers


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


signature.asc
Description: PGP signature

Bug#1032163: sudo: CVE-2023-27320

[Salvatore Bonaccorso]

Source: sudo
Version: 1.9.13p1-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for sudo, filling as RC
aiming to have it fixed before bookworm release.

CVE-2023-27320[0]:
| Sudo before 1.9.13p2 has a double free in the per-command chroot
| feature.


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-2023-27320
https://www.cve.org/CVERecord?id=CVE-2023-27320
[1] https://www.openwall.com/lists/oss-security/2023/02/28/1

Regards,
Salvatore

Bug#1032162: RM: debian-timeline/45

[Ana Guerrero Lopez]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-Cc: debian-timel...@packages.debian.org, 
debian-public...@lists.debian.org
Control: affects -1 + src:debian-timeline

Please, keep debian-timeline out of bookworm, the installed HTML doesn't
show the timeline like it should so the package is useless.

Thank you,
Ana

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Sam Hartman]

>> Moreover, I suspect in a number of the cases related to this
>> current bug, replaces will be likely.  I suspect that in some of
>> the cases where units have been introduced that are disabled
>> currently, but will be enabled by the dh_installsystemd change,
>> we will discover we'd like those units disabled in some
>> configurations.  A logical way to handle that may be to split out
>> the units into separate packages.  That makes the replaces
>> interacts with file moves class of bugs more likely in this
>> situation than average.

Sebastian> The TC advice refers to files moving between packages
Sebastian> which wouldn't be the case here (at least not in
Sebastian> general).

Not in general, but I think that these  systemd units will be more
likely than average to move packages.

These units have been sitting around more or less doing nothing for
months.
And in most cases we don't have bugs.

I'm imagining the  following situation:

* We make the debhelper change

* unit b in package a starts running

* Users complain that they don't really always want that.

* We release

* unit b is moved back to /lib/systemd/system

* Later the complaints get serious enough that package a splits into a
  and a-daemon, a-daemon replaces/breaks a<< version-of-split.  a-daemon
  now has b.

* Now we have a potential problem where we have both a file move and a
  replaces, and b can disappear on an upgrade from a pre-split a to
  a+a-daemon after the split.
  Whether that happens depends on dpkg's order of operations

The nasty thing about this situation is that moving b from /usr to /
can happen at very different points in the release cycle from doing the
split and adding the replaces.
You need to remember whether during the release cycle you've had any
moves that can involve aliased paths.
If you have, you must not later in the release cycle introduce replaces.

So, in general, we'll be fine.  But in specific I don't think we'll be
fine that removing the debhelper code will be a sane thing to do.


signature.asc
Description: PGP signature

Bug#1017436: meson: deprecation warning when cross-compiling: foo_args in the [properties] section of the machine file is deprecated

[Helmut Grohne]

Hi Jussi,

On Mon, Feb 27, 2023 at 12:53:16AM +0200, Jussi Pakkanen wrote:
> I filed an MR upstream with all changes that should go in the next
> release (which is to say they won't make it to bookworm):
> 
> https://github.com/mesonbuild/meson/pull/11464

This all looks good to me.

> I also uploaded a new version to experimental that removes the test
> patch and adds the ppc64 patch to debcrossgen. If people want to do
> test it, go ahead, but after a few days I'll reupload that to
> unstable. That will be the final version in bookworm unless major bugs
> are found.

The -3 upload looks suitable for bookworm to me. Unfortunately, it
misses the PR, so if I were to locally patch debcrossgen to use the
env2mfile implementation, it would pass --debarch=auto, but env2mfile
would consider auto as an architecture name (given that your PR is
missing) and fail.

Would you agree to either include the PR in your upload or pass
--debarch=$DEB_HOST_ARCH instead of --debarch=auto in debcrossgen?

Doing so would allow me to switch my local autobuilder to env2mfile with
a one line patch:

sbuild ... '--chroot-setup-commands='sed -i -e "/revert_to_internal 
=/s/True/False" /usr/share/meson/debcrossgen || :'

I still think that revert_to_internal should keep being True for
bookworm and given what I've seen, please flip it to False in the trixie
cycle.

Helmut

Bug#1032161: gcc-12 FTCBFS: -gm2 not found

[Helmut Grohne]

Source: gcc-12
Version: 12.2.0-14
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Hi Matthias,

gcc-12 fails to cross build since gm2 was introduced as a frontend due
to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92336 and we cannot make
a dent on it, but recently it started failing way earlier. It now fails
finding -gm2 (the cross compiler). This is due to Build-Depends
relying on a particular gcc version (which is good) but failing to
supply the version suffix to the build. As with many other frontends, we
need to pass GM2_FOR_TARGET to the build. I'm attaching a patch for this
particular issue and that moves us back to the previous one.

Helmut
diff --minimal -Nru gcc-12-12.2.0/debian/changelog 
gcc-12-12.2.0/debian/changelog
--- gcc-12-12.2.0/debian/changelog  2023-01-08 10:12:42.0 +0100
+++ gcc-12-12.2.0/debian/changelog  2023-02-27 13:33:34.0 +0100
@@ -1,3 +1,10 @@
+gcc-12 (12.2.0-14.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: Pass GM2_FOR_TARGET. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 27 Feb 2023 13:33:34 +0100
+
 gcc-12 (12.2.0-14) unstable; urgency=medium
 
   * Update to git 20230108 from the gcc-12 branch.
diff --minimal -Nru gcc-12-12.2.0/debian/rules2 gcc-12-12.2.0/debian/rules2
--- gcc-12-12.2.0/debian/rules2 2022-10-31 14:42:14.0 +0100
+++ gcc-12-12.2.0/debian/rules2 2023-02-27 13:33:34.0 +0100
@@ -125,7 +125,8 @@
GFORTRAN_FOR_TARGET=$(DEB_TARGET_GNU_TYPE)-gfortran-$(BASE_VERSION) \
GOC_FOR_TARGET=$(DEB_TARGET_GNU_TYPE)-gccgo-$(BASE_VERSION) \
GNAT_FOR_TARGET=$(DEB_TARGET_GNU_TYPE)-gnat-$(BASE_VERSION) \
-   GDC_FOR_TARGET=$(DEB_TARGET_GNU_TYPE)-gdc-$(BASE_VERSION)
+   GDC_FOR_TARGET=$(DEB_TARGET_GNU_TYPE)-gdc-$(BASE_VERSION) \
+   GM2_FOR_TARGET=$(DEB_TARGET_GNU_TYPE)-gm2-$(BASE_VERSION)
 endif
 
 ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_TARGET_GNU_TYPE))

Bug#1032160: tfortune FTCBFS: multiple reasons

[Helmut Grohne]

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

tfortune fails to cross build from source. The immediate failure is
failing to find the lopsub library since it configures for the build
architecture. This happens as no --build nor --host is passed which
would have happened automatically if dh_auto_configure could be used.
Thus it'll have to be passed manually. Then configure fails finding
config.h.in, which for some reason is not created (nor asked for) by the
override_dh_autoreconf. And finally, the actual Makefile does not pick
up the compiler detected by configure and rather uses plain cc, so we'll
have to tell it as well. All in all, the build system is quite arcane
and requires many fiddles to make it work properly. I'm attaching a
patch for your convenience and generally recommend using something more
standard if possible.

Helmut
diff --minimal -Nru tfortune-1.0.1/debian/changelog 
tfortune-1.0.1/debian/changelog
--- tfortune-1.0.1/debian/changelog 2019-09-05 12:21:38.0 +0200
+++ tfortune-1.0.1/debian/changelog 2023-02-28 05:42:58.0 +0100
@@ -1,3 +1,14 @@
+tfortune (1.0.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Also ask for generating config.h.in, which otherwise goes missing in
+  cross builds.
++ Pass --build and --host to configure as we cannot use dh_auto_configure.
++ Also export cross tools for make.
+
+ -- Helmut Grohne   Tue, 28 Feb 2023 05:42:58 +0100
+
 tfortune (1.0.1-1) unstable; urgency=low
 
   * No changes relative to 1.0.0-2.
diff --minimal -Nru tfortune-1.0.1/debian/rules tfortune-1.0.1/debian/rules
--- tfortune-1.0.1/debian/rules 2019-09-05 12:21:38.0 +0200
+++ tfortune-1.0.1/debian/rules 2023-02-28 05:42:58.0 +0100
@@ -1,13 +1,18 @@
 #!/usr/bin/make -f
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+
+include /usr/share/dpkg/architecture.mk
+DPKG_EXPORT_BUILDTOOLS=1
+include /usr/share/dpkg/buildtools.mk
+
 %:
dh "$@"
 
 # plain dh_auto_configure uses options which configure does not understand
 override_dh_auto_configure:
./configure --prefix=/usr --bindir=/usr/games \
-   --datadir=/usr/share/games
+   --datadir=/usr/share/games --build=$(DEB_BUILD_GNU_TYPE) 
--host=$(DEB_HOST_GNU_TYPE)
 # needed because dh_autoreconf overwrites our configure wrapper
 override_dh_autoreconf:
-   $(MAKE) configure.sh
+   $(MAKE) config.h.in configure.sh

Bug#1032159: libbsd FTBFS for musl: libbsd-ctor.a not built

[Helmut Grohne]

Source: libbsd
Version: 0.11.7-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libbsd fails to build on/for musl-linux-any, because the libbsd-ctor.a
library isn't build (for lack of libc features). I think we vaguely
agreed that the best solution would be to not install it in that case.
I'm attaching a patch for your convenience. And yeah, this obviously
isn't meant for bookworm.

Helmut
diff --minimal -Nru libbsd-0.11.7/debian/changelog 
libbsd-0.11.7/debian/changelog
--- libbsd-0.11.7/debian/changelog  2023-01-29 19:26:48.0 +0100
+++ libbsd-0.11.7/debian/changelog  2023-02-28 08:20:33.0 +0100
@@ -1,3 +1,10 @@
+libbsd (0.11.7-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Skip installing libbsd-ctor.a on musl. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 28 Feb 2023 08:20:33 +0100
+
 libbsd (0.11.7-2) unstable; urgency=medium
 
   * Change License name to match newly introduced SPDX name.
diff --minimal -Nru libbsd-0.11.7/debian/libbsd-dev.install 
libbsd-0.11.7/debian/libbsd-dev.install
--- libbsd-0.11.7/debian/libbsd-dev.install 2023-01-29 19:26:48.0 
+0100
+++ libbsd-0.11.7/debian/libbsd-dev.install 2023-02-28 08:20:28.0 
+0100
@@ -1,4 +1,3 @@
-usr/lib/*/libbsd-ctor.a
 usr/lib/*/libbsd.a
 usr/lib/*/libbsd.so
 usr/lib/*/pkgconfig/*.pc
diff --minimal -Nru libbsd-0.11.7/debian/rules libbsd-0.11.7/debian/rules
--- libbsd-0.11.7/debian/rules  2023-01-29 19:26:48.0 +0100
+++ libbsd-0.11.7/debian/rules  2023-02-28 08:20:31.0 +0100
@@ -6,8 +6,15 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_CFLAGS_MAINT_PREPEND = -Wall
 
+include /usr/share/dpkg/architecture.mk
+
 %:
dh $@
 
 override_dh_installchangelogs:
dh_installchangelogs --no-trim
+
+ifneq ($(DEB_HOST_ARCH_LIBC),musl)
+execute_after_dh_install:
+   dh_install -plibbsd-dev usr/lib/*/libbsd-ctor.a
+endif

Bug#1032158: mplayer FTCBFS: multiple reasons

[Helmut Grohne]

Source: mplayer
Version: 2:1.5+svn38408-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

mplayer fails to cross build from source for quite a number of reasons.
It has a quite unique configure script that doesn't work with standard
cross compilation flags. I figured that you need --target,
--enable-cross-compile, --cc, and --host-cc (with a meaning that differs
from dpkg's meaning of "host"). Beyond that, it hard codes the build
architecture pkg-config in really a lot of places. Instead of adding a
gigantic patch for this, I opt for adding a wrapper script. It also
requires libavutil-dev for the build architecture. I'm attaching a patch
for your convenience. Note that you must chmod +x
debian/devbin/pkg-config after applying it for it to work.

Helmut
diff --minimal -Nru mplayer-1.5+svn38408/debian/changelog 
mplayer-1.5+svn38408/debian/changelog
--- mplayer-1.5+svn38408/debian/changelog   2023-01-26 20:14:25.0 
+0100
+++ mplayer-1.5+svn38408/debian/changelog   2023-02-28 21:19:56.0 
+0100
@@ -1,3 +1,13 @@
+mplayer (2:1.5+svn38408-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Pass cross compilation flags to configure.
++ Inject a pkg-config for host into $PATH.
++ Missing Build-Depends: libavutil-dev:native.
+
+ -- Helmut Grohne   Tue, 28 Feb 2023 21:19:56 +0100
+
 mplayer (2:1.5+svn38408-1) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --minimal -Nru mplayer-1.5+svn38408/debian/control 
mplayer-1.5+svn38408/debian/control
--- mplayer-1.5+svn38408/debian/control 2023-01-26 20:14:25.0 +0100
+++ mplayer-1.5+svn38408/debian/control 2023-02-28 21:19:56.0 +0100
@@ -22,6 +22,7 @@
  libavcodec-dev,
  libavformat-dev,
  libavutil-dev,
+ libavutil-dev:native,
  libbluray-dev,
  libbs2b-dev,
  libcaca-dev,
diff --minimal -Nru mplayer-1.5+svn38408/debian/devbin/pkg-config 
mplayer-1.5+svn38408/debian/devbin/pkg-config
--- mplayer-1.5+svn38408/debian/devbin/pkg-config   1970-01-01 
01:00:00.0 +0100
+++ mplayer-1.5+svn38408/debian/devbin/pkg-config   2023-02-28 
21:19:56.0 +0100
@@ -0,0 +1,2 @@
+#!/bin/sh
+exec "${DEB_HOST_GNU_TYPE}-pkg-config" "$@"
diff --minimal -Nru mplayer-1.5+svn38408/debian/rules 
mplayer-1.5+svn38408/debian/rules
--- mplayer-1.5+svn38408/debian/rules   2023-01-26 20:14:25.0 +0100
+++ mplayer-1.5+svn38408/debian/rules   2023-02-28 21:19:56.0 +0100
@@ -8,6 +8,7 @@
 .NOTPARALLEL:
 
 include /usr/share/dpkg/architecture.mk
+include /usr/share/dpkg/buildtools.mk
 
 CFLAGS +=$(CPPFLAGS)
 
@@ -74,6 +75,17 @@
 sound_backend := alsa,oss
 endif
 
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+ifeq ($(archconf),)
+   archconf += --target=$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_OS)
+endif
+   archconf += \
+   --enable-cross-compile \
+   --cc=$(CC) \
+   --host-cc=$(CC_FOR_BUILD)
+   export PATH:=$(CURDIR)/debian/devbin:$(PATH)
+endif
+
 %:
dh $@
 

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Sebastian Ramacher]

On 2023-02-28 10:26:07 -0700, Sam Hartman wrote:
> > "Sebastian" == Sebastian Ramacher  writes:
> 
> Sebastian> Can you expand your concern? I expect that this issue
> Sebastian> goes away as soon as we can assume that all systems are
> Sebastian> /usr-merged. At that point I expect that we are able to
> Sebastian> drop the workaround from debhelper and packages can move
> Sebastian> the files to the expected location without issues.
> 
> Quoting the TC advice:
> 
> > 
> > - On merged-/usr systems, there is a possible failure mode involving
> >   files being moved between packages (with Replaces) during the same
> >   release cycle that their logical location is changed from the root
> >   filesystem to the corresponding aliased directory in /usr, which
> > can
> >   result in the affected file disappearing. This can be avoided by
> > not
> >   changing the file's logical location until the beginning of the
> > Debian
> >   13 development cycle, after the transition to merged-/usr is
> > complete.
> 
> 
> I think it is only true that files can move in the Debian 13 cycle if
> the dpkg issues are fixed.
> If dpkg is not fixed, then the issue with replaces interacting badly
> with file moves will still exist.
> 
> Moreover, I suspect in a number of the cases related to this current
> bug, replaces will be likely.  I suspect that in some of the cases where
> units have been introduced that are disabled currently, but will be
> enabled by the dh_installsystemd change, we will discover we'd like
> those units disabled in some configurations.  A logical way to handle
> that may be to split out the units into separate packages.
> That makes the replaces interacts with file moves class of bugs more
> likely in this situation than average.

The TC advice refers to files moving between packages which wouldn't be
the case here (at least not in general).

Cheers
-- 
Sebastian Ramacher

Bug#1032157: obs-command-source: Sending Signal seems not working

[Joao Eriberto Mota Filho]

Package: obs-command-source
Version: 0.3.2-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: Norihiro Kamae 

Control: forwarded -1 https://github.com/norihiro/obs-command-source/issues/22

I added "xcalc" to "Activated" and I set "Send signal to the command at
activated when deactivating". I am using "SIGTERM". The xcalc is shown after
the transition from "Preview" to "Program". However, the process keeps alive
when the transition is made again and the scene returns to Preview.

A workaround is add a "killall xcalc" to "Deactivated" field.

Eriberto

Bug#1032140: [External] Re: Bug#1032140: Lenovo Z16 Install issue

[David Ober]

Happy to test it 

David

-Original Message-
From: Cyril Brulebois  
Sent: Tuesday, February 28, 2023 12:52 PM
To: Steve McIntyre ; 1032...@bugs.debian.org
Cc: David Ober ; debian-ker...@lists.debian.org
Subject: [External] Re: Bug#1032140: Lenovo Z16 Install issue

Hi David,

and thanks for your installation report.

David Ober  (2023-02-28):
> Related dmesg Logs
> [   30.324093] ath11k_pci :04:00.0: BAR 0: assigned [mem 
> 0xb000-0xb01f 64bit]
> [   30.324449] ath11k_pci :04:00.0: MSI vectors: 32
> [   30.324454] ath11k_pci :04:00.0: wcn6855 hw2.1
> [   30.325448] ath11k_pci :04:00.0: failed to initialize qmi handle: -517
> [   30.325450] ath11k_pci :04:00.0: failed to initialize qmi :-517
> [   30.325450] ath11k_pci :04:00.0: failed to create soc core: -517
> [   30.325451] ath11k_pci :04:00.0: failed to init core: -517

Steve McIntyre  (2023-02-28):
> If possible, could you also please grab a full copy of the file 
> /var/log/syslog from the installer? That should help us more...

I don't think we actually need it, given this:
  
https://patchwork.kernel.org/project/linux-wireless/patch/20221202130600.883174-1-...@lst.de/

This doesn't seem to have been reviewed at all, let alone made its way into 
mainline master… and I can't check latest sid branch on 
https://salsa.debian.org/kernel-team/linux since GitLab won't let me, but what 
I have locally doesn't mention anything qrtr-mhi related at the moment. Maybe 
something we could stash in the wireless nic udeb, which ships a lot from 
drivers but also bits of crypto, math, etc. (in addition to the obvious 80211 
parts).

David, are you happy to run a test using a minimal, patched image I'd build 
locally?


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

Bug#1032065: ola: request RT acknowledgement for update to upstream version 0.10.9

[Paul Gevers]

Hi Wouter,

On 27-02-2023 23:37, Wouter Verhelst wrote:

To be clear: this would require a pass through NEW, for the RDM tester
package ("ola-rdm-tester"). That's okay then? If so, can you add the
unblock? If not, I'll leave the rdm-tester for after the release.


No, adding new binaries is not OK.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032122: chkrootkit: bad redirection creating file '1'?

[Richard Lewis]

>
>
> The regular running chkrootkit apparently creates a file '1' in the
> directory /usr/lib/chkrootkit.  Checking for a supposed bad redirection
> in the scripts of the package of chkrootkit (with "grep -n '> *1'
> /etc/cron.daily/chkrootkit /usr/sbin/chkrootkit") found the following:
>
> /usr/sbin/chkrootkit:1423:
> ${echo} >1 "$ROOTDIRproc/syslogk" > /dev/null 2>&1
>
> This looks very strange, especially as I don't see a variable echo being
> assigned anywhere.  I'm not quite sure what is intended here so I don't
> try to speculate about a correct patch, sorry.
>

yes, ive spotted this one - i am working on a fix. and will be done soon,
but every time i look at the code i spot something else that is wrong.

this line is meant to be more along the lines of

${echo} 1 > "${ROOTDIR}proc/syslogk 2>/dev/null

($echo is defined by the main loop, although im sceptical it is actually
used given echo is a builtin)

( i am writing from memory and there is another
"redirection" that is even worse thsn this one so i may be misremebering)


... i will include some code to remove the "1" -.didnt think of this!

but at least you confirmed that this test was never working as intended!


>
>

Bug#1032093: jameica: missing dependencies

[Thomas Uhle]

Hello Jochen,

thank you for the immediate response.  Please find my answers below.


On Tue, 28 Feb 2023, Jochen Sprickerhof wrote:


* Thomas Uhle  [2023-02-27 20:58]:
> Jameica dies with the following messages if it is started for the very 
> first time, i.e., with an empty user profile directory $HOME/.jameica:
> 
> [Mon Feb 27 18:48:06 CET 2023][INFO][main][de.willuhn.jameica.gui.SplashScreen$3.run]  generating new keys and certificates ...

> [Mon Feb 27 18:48:06 CET 
2023][INFO][main][de.willuhn.jameica.security.SSLFactory.init]   generating rsa 
keypair
> [Mon Feb 27 18:48:09 CET 
2023][INFO][main][de.willuhn.jameica.security.SSLFactory.init]   generating 
selfsigned x.509 certificate
> [Mon Feb 27 18:48:09 CET 
2023][INFO][main][de.willuhn.jameica.security.SSLFactory.init]   using hostname: 
localhost
> Exception in thread "main" java.lang.NoClassDefFoundError: 
org/bouncycastle/asn1/cms/CMSObjectIdentifiers
>at org.bouncycastle.operator.DefaultSignatureNameFinder.(Unknown 
Source)
>at org.bouncycastle.operator.jcajce.OperatorHelper.(Unknown Source)
>at org.bouncycastle.operator.jcajce.JcaContentSignerBuilder.(Unknown 
Source)
>at de.willuhn.jameica.security.SSLFactory.init(SSLFactory.java:291)
>at de.willuhn.jameica.services.SSLService.init(SSLService.java:45)
>at de.willuhn.boot.BootLoader.resolve(BootLoader.java:139)
>at de.willuhn.boot.BootLoader.resolve(BootLoader.java:119)
>at de.willuhn.boot.BootLoader.resolve(BootLoader.java:119)
>at de.willuhn.boot.BootLoader.getBootable(BootLoader.java:72)
>at de.willuhn.jameica.system.Application.init(Application.java:103)
>at de.willuhn.jameica.system.Application.newInstance(Application.java:87)
>at de.willuhn.jameica.Main.main(Main.java:78)
> Caused by: java.lang.ClassNotFoundException: 
org.bouncycastle.asn1.cms.CMSObjectIdentifiers
>at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
>... 12 more

I was not able to reproduce this. On an up to date Debian unstable I tried:

$ sudo apt install debvm
# create a Debian unstable VM
$ debvm-create --size=10G -- --include=task-gnome-desktop 
--aptopt='Apt::Install-Recommends "true"' --include=linux-image-amd64 
--hook-dir=/usr/share/mmdebstrap/hooks/useradd

# run it with qemu
$ debvm-run -g -- -m 4G
# inside the VM install hibiscus
$ sudo apt install --no-install-recommends hibiscus
# run it
$ jameica

Can you try this and maybe check the difference to your system?


I cannot do this, I am on an ARMv9 platform (Debian's arm64 architecture).

However, I still had bcpkix.jar linking to bcpkix-jdk18on-1.72.jar as well 
as bcprov.jar and bcputil.jar linking to bcprov-jdk18on-1.72.jar and 
bcutil-jdk18on-1.72.jar resp. which I had been downloading from Maven 
Central before I prepared the pull request for Olaf Willuhn (upstream). 
Although I thought they were basically the same, there have to be 
differences.  After reverting the links to the jar files that are provided 
by Debian, there is no such issue indeed.  So I tried to track this down 
to bcpkix.jar.  If only this jar file is exchanged by the one from Maven 
Central, then it doesn't matter whether the other two are from Debian or 
Maven Central.  Then this issue is happening.  So the difference must be 
within bcpkix.jar.  I had a look into both versions and saw that the 
manifest in Debian's bcpkix.jar specifies


  Class-Path: bcprov.jar bcutil.jar

whereas the manifest in Maven's bcpkix.jar has no class path specified. 
I guess this is the reason why it works with Debian's BouncyCastle jar 
files even if the manifest of jameica.jar does not specify a class path 
with bcutil.jar.



I've added this to follow upstream but even when I remove the bcutil-1.72.jar 
it works fine, so not sure what is going on.


I cannot confirm this.  After removing both bcutil-1.72.jar and 
bcutil.jar, (even with the other two libraries taken from Debian) I run 
into this issue when Jameica tries to generate the self-signed 
certificate for a new user profile.  It does not quit after the exception 
but seems to hang forever, the splash screen stays open saying "generating 
new keys and certificates ..." for minutes.  Eventually I have yet lost my 
patience and killed the process.




Anyway, I've added both jars and uploaded a new version.

Cheers Jochen


Thank you!

Cheers,

Thomas

Bug#1032156: gnome-multi-writer does not show connected USB sticks in LXDE on Debian

[Jan Girke]

Package: gnome-multi-writer
Version: 3.32.1-1
Severity: important
X-Debbugs-Cc: jangi...@gmail.com

Dear Maintainer,

* What led up to the situation?
I was trying to make a bootable USB stick.
* What exactly did you do (or not do) that was effective (or
ineffective)?
It just flat out would not work. No USB stick detection, I tried several.
The system detects them and even gnome-disk-utiliti has no problem finding
them.
* What outcome did you expect instead?
That the program shows the USB files.

Just drop me an email if you need more info like a screenshot.
It was a netinstall of debian 11 with LXDE as a desktop environment.


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

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
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 gnome-multi-writer depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  libc62.31-13+deb11u5
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libgudev-1.0-0   234-1
ii  libgusb2 0.3.5-1
ii  libpolkit-gobject-1-00.105-31+deb11u1
ii  libudisks2-0 2.9.2-2+deb11u1

gnome-multi-writer recommends no packages.

gnome-multi-writer suggests no packages.

-- no debconf information

Bug#1032155: gnome-multi-writer: Settings button not displayed in LXDE

[Jan Girke]

Package: gnome-multi-writer
Version: 3.32.1-1
Severity: important
X-Debbugs-Cc: jangi...@gmail.com

Dear Maintainer,

* What led up to the situation?
I was trying to make a bootable USB stick.
* What exactly did you do (or not do) that was effective (or
ineffective)?
It just flat out would not work. No settings button to choose an image file
like an ISO and no USB stick detection, but that is the other bug.
* What was the outcome of this action?
NA
* What outcome did you expect instead?
That the program shows the gearwheel menu to choose the file.

Just drop me an email if you need more info like a screenshot.
It was a netinstall of debian 11 with LXDE as a desktop environment.

Best, Jan Girke

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

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
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 gnome-multi-writer depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  libc62.31-13+deb11u5
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libgudev-1.0-0   234-1
ii  libgusb2 0.3.5-1
ii  libpolkit-gobject-1-00.105-31+deb11u1
ii  libudisks2-0 2.9.2-2+deb11u1

gnome-multi-writer recommends no packages.

gnome-multi-writer suggests no packages.

-- no debconf information

Bug#1032154: ITP: ruby-google-apis-storage-v1 -- Simple REST client for Google Cloud Storage JSON API V1

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

Packaging https://rubygems.org/gems/google-apis-storage_v1

This is the simple REST client for Cloud Storage JSON API V1. Simple 
REST
clients are Ruby client libraries that provide access to Google 
services

via their HTTP REST API endpoints. These libraries are generated and
updated automatically based on the discovery documents published by the
service, and they handle most concerns such as authentication,
pagination, retry, timeouts, and logging. You can use this client to
access the Cloud Storage JSON API, but note that some services may 
provide

a separate modern client that is easier to use.

This gem is a dependency of ruby-fog-google 1.19

Bug#1032153: pbuilder: noninteractive pbuilder install loops infinitely when system has no sources.list file

[Henning]

Package: pbuilder
Version: 0.231
Severity: normal
X-Debbugs-Cc: henning.spr...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?

Building a docker image with pbuilder installed with debconf
frontend non-interactive

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

When pbuilder is to be installed via apt in the Dockerfile, it's
configuration process apprently tries to puzl some configuration
out of /etc/apt/sources.list - but this file does not exist on
bookworm docker images (and presumeably on other systems,
neither).

At least in the bookworm docker image, the apt sources are
configured via /etc/apt/sources.list.d/debian.sources file, and
I assume its the same for systems installed "normally" with the
debian installer. 

But pbuilder apparently relies on the "traditional"
/etc/apt/sources.list file, and otrherwise keeps looping through
an interactive question for the user to input a default mirror
manually. 

   * What was the outcome of this action?
The interactive question, at least in a docker build run, can not
be answered as the text just keeps looping.
The process must be exited with ctrl-c.

   * What outcome did you expect instead?
I expect that pbuilder does not resort to interactive user input
when  DEBIAN_FRONTEND=noninteractive and some default is used,
and the pbuilder instal script do not rely on a file that cannot
be guranteed to exist.


*** 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)

Kernel: Linux 5.15.0-60-lowlatency (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages pbuilder depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  debootstrap1.0.128+nmu2
ii  dpkg-dev   1.21.20

Versions of packages pbuilder recommends:
ii  devscripts  2.22.2
ii  eatmydata   130-2
ii  fakeroot1.29-1
ii  net-tools   2.10-0.1
ii  sudo1.9.13p1-1

Versions of packages pbuilder suggests:
pn  cowdancer   
pn  gdebi-core  

-- debconf information:
* pbuilder/mirrorsite: dölkvsmlskmvs
* pbuilder/nomirror:
  pbuilder/rewrite: false

Bug#1032152: pcmanfm: Silent fail rightclick on ISO file "Disk Image Writer"

[Jan Girke]

Package: pcmanfm
X-Debbugs-Cc: jangi...@gmail.com
Version: 1.3.2-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
I right clicked an ISO file and it did nothing.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
See above
   * What was the outcome of this action?
Nothing
   * What outcome did you expect instead?
At least an error messagebox that tells me what's wrong.
Are permissions missing? Where and how can I add them? gnome-disk-utility
just works even in userspace.

This package is part of the bigger seudo package lxde the LXDE desktop
environment for Debian 11 something see below.
If you need more information write an email to me.

Best, Jan Girke

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

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
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 pcmanfm depends on:
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u5
ii  libcairo21.16.0-5
ii  libfm-gtk4   1.3.2-1
ii  libfm4   1.3.2-1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libglib2.0-0 2.66.8-1
ii  libgtk2.0-0  2.24.33-2
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libx11-6 2:1.7.2-1
ii  shared-mime-info 2.0-1

Versions of packages pcmanfm recommends:
ii  gnome-icon-theme 3.12.0-3
ii  gvfs-backends1.46.2-1
ii  gvfs-fuse1.46.2-1
ii  lxde-icon-theme  0.5.1-2.1
ii  lxpolkit [polkit-1-auth-agent]   0.5.5-2
ii  policykit-1-gnome [polkit-1-auth-agent]  0.105-7

pcmanfm suggests no packages.

-- no debconf information

Bug#1032151: gnome-shell: window animation bug

[Mirosław Leśniak]

Package: gnome-shell
Version: 43.3-1
Severity: normal
X-Debbugs-Cc: mir.lesn...@gmail.com

Dear Maintainer,

Sometimes if i hover mouse over a window in expose and then switch to another
window the previously selected window remains on top until animation finishes.
I hear from gnome community that it's a known bug:
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4638
This can't be like that when bookworm stabilizes.

Best wishes, have a great time.


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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-accountsservice-1.0   22.08.8-6
ii  gir1.2-adw-1 1.2.2-1
ii  gir1.2-atk-1.0   2.46.0-5
ii  gir1.2-atspi-2.0 2.46.0-5
ii  gir1.2-freedesktop   1.74.0-3
ii  gir1.2-gcr-3 3.41.1-1+b1
ii  gir1.2-gdesktopenums-3.0 43.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1
ii  gir1.2-gdm-1.0   43.0-3
ii  gir1.2-geoclue-2.0   2.6.0-2
ii  gir1.2-glib-2.0  1.74.0-3
ii  gir1.2-gnomebluetooth-3.042.5-3
ii  gir1.2-gnomedesktop-3.0  43.2-1
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.22.0-2
ii  gir1.2-gtk-3.0   3.24.36-4
ii  gir1.2-gtk-4.0   4.8.3+ds-2
ii  gir1.2-gweather-4.0  4.2.0-1
ii  gir1.2-ibus-1.0  1.5.27-5
ii  gir1.2-mutter-11 43.2-6
ii  gir1.2-nm-1.01.42.0-1
ii  gir1.2-nma-1.0   1.10.6-1
ii  gir1.2-pango-1.0 1.50.12+ds-1
ii  gir1.2-polkit-1.0122-3
ii  gir1.2-rsvg-2.0  2.54.5+dfsg-1
ii  gir1.2-soup-3.0  3.2.2-1
ii  gir1.2-upowerglib-1.00.99.20-2
ii  gir1.2-webkit2-4.1   2.38.5-1
ii  gnome-backgrounds43.1-1
ii  gnome-settings-daemon43.0-4
ii  gnome-shell-common   43.3-1
ii  gsettings-desktop-schemas43.0-1
ii  gstreamer1.0-pipewire0.3.65-3
ii  libatk-bridge2.0-0   2.46.0-5
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libecal-2.0-23.46.4-1
ii  libedataserver-1.2-273.46.4-1
ii  libgcr-base-3-1  3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgirepository-1.0-11.74.0-3
ii  libgjs0g 1.74.1-1
ii  libgles2 1.6.0-1
ii  libglib2.0-0 2.74.5-1
ii  libglib2.0-bin   2.74.5-1
ii  libgnome-autoar-0-0  0.4.3-1
ii  libgnome-desktop-3-2043.2-1
ii  libgraphene-1.0-01.10.8-1
ii  libgtk-3-0   3.24.36-4
ii  libgtk-4-1   4.8.3+ds-2
ii  libical3 3.0.16-1+b1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmutter-11-0   43.2-6
ii  libnm0   1.42.0-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpolkit-agent-1-0  122-3
ii  libpolkit-gobject-1-0122-3
ii  libpulse-mainloop-glib0  16.1+dfsg1-2+b1
ii  libpulse016.1+dfsg1-2+b1
ii  libsecret-1-00.20.5-3
ii  libsystemd0  252.5-2
ii  libwayland-server0   1.21.0-1
ii  libx11-6 2:1.8.3-3
ii  libxfixes3   1:6.0.0-2
ii  python3  3.11.2-1

Versions of packages gnome-shell recommends:
ii  bolt  

Bug#1031839: network devices do not work after kernel upgrade

[Daniel Baumann]

On 2/28/23 18:58, Thorsten Alteholz wrote:
> which one would you recommend?

we use those extensively (several thousands), ymmv:
https://www.flexoptix.net/de/p-8596-02.html

Regards,
Daniel

Bug#1031839: network devices do not work after kernel upgrade

[Thorsten Alteholz]

On 27.02.23 18:05, Diederik de Haas wrote:


There have been quite a few Debian kernel between those version and it would
be useful to narrow that range. You can find various deb files for amd64 here:
https://snapshot.debian.org/binary/linux-image-amd64/


Ok, I will try other kernels ...

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[James Addison]

On Tue, Feb 28, 2023, 17:55 Thorsten Glaser  wrote:

> Can you test it? I don’t have the bandwidth for that right now…


Should be able to, yep - I seem to remember seeing some repro instructions
from you on the GitHub thread and will give those a try in an emulator/vm.

Bug#1032150: ITP: wolfram-engine -- A local Wolfram Engine to put computational intelligence into your applications

[Connor Gray]

Package: wnpp
Severity: wishlist
Owner: Connor Gray 

Package name: wolfram-engine
Version : 13.2.0
Upstream Author : Wolfram Research mailto:supp...@wolfram.com>>
URL : https://wolfram.com/engine
License : commercial
Programming Lang: Wolfram Language
Description : A local Wolfram Engine to put computational intelligence into 
your applications

Wolfram Engine is a standalone installation of the Wolfram Language, the same 
language that powers Mathematica and Wolfram|Alpha.

Wolfram Engine can be used to write and run Wolfram Language programs and 
scripts.

Wolfram Engine can be freely used for pre-production software development under 
the Wolfram Engine Community Edition license.

We're looking for a sponsor to help us through the process of including this 
package in the Debian non-free repository. Maintenance of the wolfram-engine 
.deb package will be provided by Wolfram Research.

The latest version of our existing wolfram-engine .deb package is available for 
download and review from:


https://files.wolframcdn.com/packages/Debian/13.2.0.0/wolfram-engine_13.2.0_amd64.deb

We're open to feedback and suggestions on how this .deb package might be 
improved.

Contact Connor Gray  and Todd Gayley  
with any questions or concerns about the .deb package.

Please let us know what additional information or help we can provide.

Thanks,
Connor

Bug#1032136: installation-reports: Touchpad does not work during a graphical installation

[Cyril Brulebois]

Hi Caleb,

Caleb McKay  (2023-02-28):
> Laptop touchpad not working during install. Once installation completed and I
> booted into the new install, it worked without issue. So for whatever reason,
> the driver is just not being loaded during the graphical installation, even
> though the touchpad is supported.
> 
> 
> I: Bus=0018 Vendor=04f3 Product=3157 Version=0100
> N: Name="ASUE1409:00 04F3:3157 Touchpad"
> P: Phys=i2c-ASUE1409:00
> S:
> Sysfs=/devices/pci:00/:00:17.1/i2c_designware.1/i2c-2/i2c-ASUE1409:00/0018:04F3:3157.0001/input/input10
> U: Uniq=
> H: Handlers=mouse1 event5
> B: PROP=5
> B: EV=1b
> B: KEY=e520 1 0 0 0 0
> B: ABS=2e08003
> B: MSC=20

Alright, this is behind i2c/i2c_hid, and relevant modules seem to be
included in the installer environment. Please attach the complete
/var/log/installer/syslog (compressed) for further investigation. :)


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


signature.asc
Description: PGP signature

Bug#1032131: deb822-style sources.list

[Cyril Brulebois]

Hi,

David Prévot  (2023-02-28):
> I may be late to the bookworm party but… It would be nice if d-i could
> provide deb822-style sources.list (by default) for newly installed
> machines.

This seems late indeed.


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


signature.asc
Description: PGP signature

Bug#1031839: network devices do not work after kernel upgrade

[Thorsten Alteholz]

Hi Daniel,

On 27.02.23 15:45, Daniel Baumann wrote:

On 2/27/23 15:25, Daniel Baumann wrote:

   ixgbe.allow_unsupported_sfp=1


yes, I tried it this way and as option in the module configuration.



Any chance you could confirm it by testing with an Intel-branded SFP?


I haven't one yet. As they look a bit expensive, which one would you 
recommend?


  Thorsten

Bug#1032140: Lenovo Z16 Install issue

[Cyril Brulebois]

Hi David,

and thanks for your installation report.

David Ober  (2023-02-28):
> Related dmesg Logs
> [   30.324093] ath11k_pci :04:00.0: BAR 0: assigned [mem 
> 0xb000-0xb01f 64bit]
> [   30.324449] ath11k_pci :04:00.0: MSI vectors: 32
> [   30.324454] ath11k_pci :04:00.0: wcn6855 hw2.1
> [   30.325448] ath11k_pci :04:00.0: failed to initialize qmi handle: -517
> [   30.325450] ath11k_pci :04:00.0: failed to initialize qmi :-517
> [   30.325450] ath11k_pci :04:00.0: failed to create soc core: -517
> [   30.325451] ath11k_pci :04:00.0: failed to init core: -517

Steve McIntyre  (2023-02-28):
> If possible, could you also please grab a full copy of the file
> /var/log/syslog from the installer? That should help us more...

I don't think we actually need it, given this:
  
https://patchwork.kernel.org/project/linux-wireless/patch/20221202130600.883174-1-...@lst.de/

This doesn't seem to have been reviewed at all, let alone made its way
into mainline master… and I can't check latest sid branch on
https://salsa.debian.org/kernel-team/linux since GitLab won't let me,
but what I have locally doesn't mention anything qrtr-mhi related at the
moment. Maybe something we could stash in the wireless nic udeb, which
ships a lot from drivers but also bits of crypto, math, etc. (in
addition to the obvious 80211 parts).

David, are you happy to run a test using a minimal, patched image I'd
build locally?


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


signature.asc
Description: PGP signature

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[Thorsten Glaser]

James Addison dixit:

>Hi - what do you both think of the attached patch, which brings the ARM stack
>size into line with almost all other architectures (= 984 KB)?

It might do the job unless arm64 for some reason uses more stack
elsewhere as well.

Can you test it? I don’t have the bandwidth for that right now…

Thanks,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Bug#1032149: criterion: U+FFFC OBJECT REPLACEMENT CHARACTER in package descriptions

[Jakub Wilk]

Source: criterion
Version: 2.4.1-1
Severity: minor

The lists in the package descriptions are indented with object 
replacement characters (U+FFFC). This is weird. Please replace them with 
spaces:


   sed -i -e 's/\xEF\xBF\xBC/ /' debian/control

--
Jakub Wilk

Bug#1032120: tiledb: uses atomic operations, but is not linked to libatomic

[Graham Inggs]

Hi Dirk

Thanks for the quick upload!
Already got a successful build of tiledb-py on riscv64[1].

On Tue, 28 Feb 2023 at 17:14, Dirk Eddelbuettel  wrote:
> TileDB upstream does everything in CMake (which I do not fully speak) so
> "eventually" it would be nice to port this.

After testing the patch which I eventually submitted, I found a bug[2]
that in message #5, discusses a way to automatically link libatomic
when required by calling the linker with -pthread, instead of linking
with -lpthread.

Then, in message #25, the way to do this in CMake is shown:

set(THREADS_PREFER_PTHREAD_FLAG ON)
find_package(Threads REQUIRED)

I tried applying this patch to TileDB, but it did not work for me.
Perhaps upstream can make more sense of what is suggested in that bug
report and in the linked cmake issue[3].

Regards
Graham


[1] https://buildd.debian.org/status/logs.php?pkg=tiledb-py=riscv64
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895969
[3] https://cmake.org/Bug/view.php?id=14767

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Sam Hartman]

> "Sebastian" == Sebastian Ramacher  writes:

Sebastian> Can you expand your concern? I expect that this issue
Sebastian> goes away as soon as we can assume that all systems are
Sebastian> /usr-merged. At that point I expect that we are able to
Sebastian> drop the workaround from debhelper and packages can move
Sebastian> the files to the expected location without issues.

Quoting the TC advice:

> 
> - On merged-/usr systems, there is a possible failure mode involving
>   files being moved between packages (with Replaces) during the same
>   release cycle that their logical location is changed from the root
>   filesystem to the corresponding aliased directory in /usr, which
> can
>   result in the affected file disappearing. This can be avoided by
> not
>   changing the file's logical location until the beginning of the
> Debian
>   13 development cycle, after the transition to merged-/usr is
> complete.


I think it is only true that files can move in the Debian 13 cycle if
the dpkg issues are fixed.
If dpkg is not fixed, then the issue with replaces interacting badly
with file moves will still exist.

Moreover, I suspect in a number of the cases related to this current
bug, replaces will be likely.  I suspect that in some of the cases where
units have been introduced that are disabled currently, but will be
enabled by the dh_installsystemd change, we will discover we'd like
those units disabled in some configurations.  A logical way to handle
that may be to split out the units into separate packages.
That makes the replaces interacts with file moves class of bugs more
likely in this situation than average.

--Sam


signature.asc
Description: PGP signature

Bug#1032148: debian-installer: when installing debian bookworm via the netinstaller even though non free firmware is included it still tells you that some of your hardware requires it and that you can

[jordan]

Package: debian-installer
Severity: minor
X-Debbugs-Cc: jordanlives...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
   * 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?

*** 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)

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

Bug#1032147: mumble: Unnecessary use of perl in postinst

[Gioele Barabucci]

Package: mumble-server
Version: 1.3.4-1.1
Tags: patch

Dear mumble maintainers,

`mumble-server.postinst` uses Perl to replace occurrences of 
`MURMUR_USE_CAPABILITIES` in `/etc/default/mumble-server`.


Such simple processing can be achieved also with a very similar sed
invocation.

You can find a 1-line patch to fix this problem at 
https://salsa.debian.org/gioele/mumble/-/commits/no-perl-maintscripts


--
Gioele Barabucci

Bug#1027337: [debian-mysql] Bug#1027337: Bug#1027337: mariadb-server-10.5: Huge increase in memory consumption (leak?) since upgrade from 10.5.15 to 10.5.18

[Faustin Lammler]

Hi Matteo!
I am not in charge of doing uploads to Debian FTP so, I don't know.

@Otto do you know when 10.5.19 will be uploaded?

Regards,

-- 
Faustin
GPG: F652 BCD1 1AA8 8975 F010 48A5 390A 2F27 832A 5C79


signature.asc
Description: PGP signature

Bug#1032110: [Pkg-swan-devel] Bug#1032110: Apparmor denies access to /etc/ipsec.secrets.d/

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2023-02-28 at 16:44 +1100, James Lownie wrote:
> I then modified /etc/apparmor.d/usr.lib.ipsec.charon as follows, after which
> IPSec was able to load the secrets file and authenticate incoming
> connections:

Hi James, thanks for the report. Just to be sure: you *only* moved the lines
from the end of the file to the top?

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmP+M/8ACgkQ3rYcyPpX
RFsi+gf+JXmA+xT5Zau+0HmVq6DtlRynpOpMmldyN9ntg2GdbYWP+e44E40vZuPZ
BWZ1nm2UwCOlKT5uzE7r7JDpKkHIF15LucBR5qwr3GJuP1apaxsxtWMfthORDLyJ
TER7qUlYv8vSTeHSVGZQsLLVaaB2JPIjo1cF6nmpCnV/CsfKxy9Pc0NSkUKb2U4G
thp3DQkBYVBZx9gzMgXDKjZyy3zvqTLxc3gLhqwfMd5VRjElMARtMkpFL+8s0rac
ybofdTcGi9ORL5ipiiQnbF3urJHrR/zDHJrZEBMpeEszdtPWHs9WoYtJiqZjwniA
/2RePmWB61iGiRWmxicD4gNY02jMng==
=Eup3
-END PGP SIGNATURE-

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Sebastian Ramacher]

On 2023-02-28 07:28:18 -0700, Sam Hartman wrote:
> > "Sebastian" == Sebastian Ramacher  writes:
> 
> Sebastian> On 2023-02-23 11:12:00 -0700, Sam Hartman wrote:
> >> > "Sean" == Sean Whitton  writes:
> >> 
> Sean> Hello,
> Sean> On Wed 22 Feb 2023 at 09:55AM +01, Sebastian Ramacher wrote:
> >> 
> >> >> Unless I am missing something, having dh_installsystemd look
> >> at >> the service files in /usr/lib is the only viable solution
> >> for >> bullseye -> bookworm. We could fix individual packages
> >> that >> didn't include those files in bullseye, but for all the
> >> others we >> are unable to move the files from /usr/lib to /lib.
> >> 
> Sean> You're saying we can't move them in that case because the TC
> Sean> resolution says no moving /usr/lib->/lib ?  Or some other
> Sean> reason?  I thought we only said that files couldn't move in
> Sean> the other direction.
> >> 
> >> Well, there is the underlying technical issue that made the TC
> >> resolution reasonable.  Moving paths between aliased locations
> >> plus replaces will always produce behavior that is predictable
> >> and potentially bad with the current dpkg.  It's independent on
> >> whether it's /usr/lib or /lib on source or destination.
> >> 
> >> I agree with the analysis and believe that having
> >> dh_installsystemd look in /usr/lib/systemd is the option least
> >> likely to create breakage.
> 
> Sebastian> As there were no follow ups to this message, I think we
> Sebastian> reached concensus on the issue. Thus, let's have that
> Sebastian> implemented in dh_installsystemd for bookworm and the
> Sebastian> affected packages binNMUs.
> 
> I agree roughly with this part.
> We may run into bugs where it turns out having a particular unit enabled
> doesn't actually provide the behavior we were looking for.
> I.E. we've been happy without the unit for a while now, and it turns out
> that was the right state.
> I suspect the number of such bugs will be small, and we'll just have to
> find them through testing.
> 
> Sebastian> Once the release cycle of
> Sebastian> trixie starts, the workaround for bookworm can be
> Sebastian> dropped.
> 
> I don't think that's correct unless dpkg is fixed.
> Once we've shipped with the unit in /usr/lib/systemd, we cannot move to
> /lib/systemd without potentially triggering the dpkg situation.
> So, I don't see how we can ever remove this.

Can you expand your concern? I expect that this issue goes away as soon
as we can assume that all systems are /usr-merged. At that point I
expect that we are able to drop the workaround from debhelper and
packages can move the files to the expected location without issues.

Cheers
-- 
Sebastian Ramacher

Bug#1030048: pgpool2: CVE-2023-22332

[Adrian Bunk]

On Mon, Jan 30, 2023 at 06:47:23PM +0100, Moritz Mühlenhoff wrote:
> Source: pgpool2
> X-Debbugs-CC: t...@security.debian.org
> Severity: grave
> Tags: security
> 
> Hi,
> 
> The following vulnerability was published for pgpool2.
> 
> CVE-2023-22332[0]:
> | Information disclosure vulnerability exists in Pgpool-II 4.4.0 to
> | 4.4.1 (4.4 series), 4.3.0 to 4.3.4 (4.3 series), 4.2.0 to 4.2.11 (4.2
> | series), 4.1.0 to 4.1.14 (4.1 series), 4.0.0 to 4.0.21 (4.0 series),
> | All versions of 3.7 series, All versions of 3.6 series, All versions
> | of 3.5 series, All versions of 3.4 series, and All versions of 3.3
> | series. A specific database user's authentication information may be
> | obtained by another database user. As a result, the information stored
> | in the database may be altered and/or database may be suspended by a
> | remote attacker who successfully logged in the product with the
> | obtained credentials.
> 
> Quoting from https://www.pgpool.net/mediawiki/index.php/Main_Page#News :
> 
> (I have no idea how common that is, feel free to downgrade as necessary)
> 
> --
> This release contains a security fix.
> 
> If following conditions are all met, the password of "wd_lifecheck_user" is 
> exposed by "SHOW POOL STATUS" command. The command can be executed by any 
> user who can
> connect to Pgpool-II. (CVE-2023-22332)
> 
> • Version 3.3 or later
> • use_watchdog = on
> • wd_lifecheck_method = 'query'
> • A plain text password is set to wd_lifecheck_password
> --
>...

Christoph, is there a reason why this cannot be fixed with a backport
or an upgrade to 4.3.5?

cu
Adrian

Bug#1032146: Boot problem Debian 12 Testing

[G M]

Package: installation-reports

Boot method: CD/USB stick
Image version: 
https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
Date: 28.02.2023

Machine1: Virtual Machine
Processor: AMD Ryzen 5 1600x
Memory: host 16 Gb, VM - 2GB
Partitions: SCSI 20GB, Default partition layout for BIOS systems.


Machine2: Laptop HP Envy x360
Processor: AMD Ryzen 5 5500u
Memory: 32 Gb
Partitions: NVMe 1Tb, UEFI 512Mb, Windows 70 GB, Debian 30GB, all
other space for Data.

Output of lspci -knn (or lspci -nn):

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

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

Comments/Problems:



Hello,
I have already tried several times to install both on real iron and on the
virtual machine Debian 12 testing.
Loading from ISO, installation - everything goes without errors.
Loading OS falls with this error.

[image: 2023-02-28_194021.png]

Interesting that the same errors I had on weekly and daily ISO files.
If I install the OS from Debian-Bookworm-di-alpha2-amd64-Netinst.iso, then
the installation is perfect.

Best regards,
Guram