Bug#1068168: python3-telethon: New version (1.30) available

[Ferran Jorba]

Package: python3-telethon
Version: 1.25.1-1
Severity: wishlist

Dear Maintainer,

Telethon releases are no longer announced at its Github page
(https://github.com/LonamiWebs/Telethon/releases), but rather, as they
explain, at https://docs.telethon.dev/en/stable/misc/changelog.html.

I don't know if it is the reason you haven't noticed newer releases, but an
upgrade will be very welcome, as there are some funcionalities not found in
current Debian packaged version.

Thanks for your work,

Ferran

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

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

Versions of packages python3-telethon depends on:
ii  python33.11.2-1+b1
ii  python3-pyaes  1.6.1-4
ii  python3-rsa4.8-1

python3-telethon recommends no packages.

python3-telethon suggests no packages.

-- no debconf information

Bug#1060128: ITP: python-sphinxcontrib-github-alt -- Sphinx extension for easy GitHub links

[Julian Gilbey]

On Fri, Mar 22, 2024 at 07:42:12AM +, Julian Gilbey wrote:
> [...]
> Thanks for this ITP!  Two things:
> 
> (1) I recommend that this package is called
> python-sphinxcontrib.github-alt with a dot after "sphinxcontrib" to
> keep it in line with the names of all the other sphinxcontrib packages
> in Debian.

Ah, it turns out that I'm wrong about this; the other packages are
called "sphinxcontrib.foo" because that is the name of the Python
module; here the module is literally called sphinxcontrib_github_alt,
so your proposed package name is correct.

I'm planning to package it today.

Best wishes,

   Julian

Bug#1068164: bart: please add support for loong64

[Andreas Tille]

Hi Martin,

can you please comment on this?

Kind regards
Andreas.

Am Mon, Apr 01, 2024 at 01:22:03AM + schrieb wuruilong:
> Source: bart
> Severity: normal
> User: debian-loonga...@lists.debian.org
> Usertags: loong64
> X-Debbugs-Cc: wuruil...@loongson.cn
> 
> Dear Maintainer,
> 
> bart failed to compile on loongarch, the attachment fixes the bug
> 
> wuruilong
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unreleased
>   APT policy: (500, 'unreleased'), (500, 'unstable')
> Architecture: loong64 (loongarch64)
> 
> Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect

> --- bart-0.9.00/debian/rules  2024-03-30 06:12:54.235656645 +
> +++ bart-0.9.00/debian/rules  2023-12-11 17:42:37.0 +
> @@ -12,7 +12,7 @@
>  export PARALLEL_NJOBS=1
>  
>  # some archs require turning of some optimizations
> -NOEXPOPT_ARCHS=arm64 ppc64el s390x ia64 powerpc ppc64 riscv64 loong64
> +NOEXPOPT_ARCHS=arm64 ppc64el s390x ia64 powerpc ppc64 riscv64
>  
>  # turn off hanging tests on i386
>  ifeq ($(DEB_BUILD_ARCH), i386)

> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
https://fam-tille.de

Bug#1068166: manpages-dev: Fails to upgrade due to file conflict

[Sven Joachim]

Control: notfound -1 6.05.01-1
Control: found -1 6.7-1

On 2024-04-01 06:17 +0200, Bas Couwenberg wrote:

> Source: manpages
> Version: 6.05.01-1
> Severity: serious
> Justification: makes the package in question unusable or mostly so
>
> Dear Maintainer,
>
> manpages-dev failed to upgrade due to a conflict with glibc-doc:
>
>  Unpacking manpages-dev (6.7-1) over (6.05.01-1) ...
>  dpkg: error processing archive 
> /var/cache/apt/archives/manpages-dev_6.7-1_all.deb (--unpack):
>   trying to overwrite '/usr/share/man/man3/pthread_cond_init.3.gz', which is 
> also in package glibc-doc 2.37-15.1
>  Errors were encountered while processing:
>   /var/cache/apt/archives/manpages-dev_6.7-1_all.deb
>  E: Sub-process /usr/bin/dpkg returned an error code (1)

There are a few more conflicting files:

,
| # dpkg -i --force-overwrite /var/cache/apt/archives/manpages-dev_6.7-1_all.deb
| (Reading database ... 15705 files and directories currently installed.)
| Preparing to unpack .../manpages-dev_6.7-1_all.deb ...
| Unpacking manpages-dev (6.7-1) ...
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite 
'/usr/share/man/man3/pthread_cond_init.3.gz', which is also in package 
glibc-doc 2.37-15.1
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite 
'/usr/share/man/man3/pthread_condattr_init.3.gz', which is also in package 
glibc-doc 2.37-15.1
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite 
'/usr/share/man/man3/pthread_key_create.3.gz', which is also in package 
glibc-doc 2.37-15.1
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite 
'/usr/share/man/man3/pthread_mutex_init.3.gz', which is also in package 
glibc-doc 2.37-15.1
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite 
'/usr/share/man/man3/pthread_mutexattr_setkind_np.3.gz', which is also in 
package glibc-doc 2.37-15.1
| dpkg: warning: overriding problem because --force enabled:
| dpkg: warning: trying to overwrite '/usr/share/man/man3/pthread_once.3.gz', 
which is also in package glibc-doc 2.37-15.1
`

> Breaks/Replaces will need to be added if the file was moved, but it
> seems that only one of these packages should include this manpage.

There is a script debian/check-conflicts in the manpages source package
which is supposed to detect such clashing files, but it is buggy because
it only scans the contents of amd64 packages, while glibc-doc is an
arch:all package.

Cheers,
   Sven

Bug#1068167: manpages-dev: Update to 6.7-1 fails

[sidt]

Package: manpages-dev
Version: 6.05.01-1
Severity: important
X-Debbugs-Cc: sidto...@gmail.com

Dear Maintainer,

System update failed due to this.

Preparing to unpack .../03-manpages_6.7-1_all.deb ...
Unpacking manpages (6.7-1) over (6.05.01-1) ...
Preparing to unpack .../04-manpages-dev_6.7-1_all.deb ...
Unpacking manpages-dev (6.7-1) over (6.05.01-1) ...
dpkg: error processing archive /tmp/apt-dpkg-install-oRcZxm/04-manpages-
dev_6.7-1_all.deb (--unpack):
 trying to overwrite '/usr/share/man/man3/pthread_cond_init.3.gz', which is
also in package glibc-doc 2.37-15.1


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

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

Versions of packages manpages-dev depends on:
iu  manpages  6.7-1

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
it  man-db [man-browser]  2.12.0-4

-- no debconf information

Bug#1068166: manpages-dev: Fails to upgrade due to file conflict

[Bas Couwenberg]

Source: manpages
Version: 6.05.01-1
Severity: serious
Justification: makes the package in question unusable or mostly so

Dear Maintainer,

manpages-dev failed to upgrade due to a conflict with glibc-doc:

 Unpacking manpages-dev (6.7-1) over (6.05.01-1) ...
 dpkg: error processing archive 
/var/cache/apt/archives/manpages-dev_6.7-1_all.deb (--unpack):
  trying to overwrite '/usr/share/man/man3/pthread_cond_init.3.gz', which is 
also in package glibc-doc 2.37-15.1
 Errors were encountered while processing:
  /var/cache/apt/archives/manpages-dev_6.7-1_all.deb
 E: Sub-process /usr/bin/dpkg returned an error code (1)

Breaks/Replaces will need to be added if the file was moved, but it seems that 
only one of these packages should include this manpage.

Kind Regards,

Bas

Bug#1065222: O: pychm -- Python binding for CHMLIB - Python 3

[yokota]

Hello,

I want to maintain pychm because it's required by Debian Calibre package.

--
YOKOTA

Bug#1066674: gramophone2: FTBFS: GRAMophone.c:94:9: error: implicit declaration of function ‘usageError’; did you mean ‘strerror’? [-Werror=implicit-function-declaration]

[Ying-Chun Liu (PaulLiu)]

Hi,

I've fixed the bug. I plan to do NMU to fix this bug.

I'll wait for 10 days if no one says no.
And I'll upload it to delay/10 queue.

The attachment is the debdiff and build log.

Yours,
Paul
diff -Nru gramophone2-0.8.13a/debian/changelog 
gramophone2-0.8.13a/debian/changelog
--- gramophone2-0.8.13a/debian/changelog2022-12-13 05:48:33.0 
+0800
+++ gramophone2-0.8.13a/debian/changelog2024-04-01 05:23:29.0 
+0800
@@ -1,3 +1,14 @@
+gramophone2 (0.8.13a-3.3) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix FTBFS caused by -Werror=implicit-function-declaration
+(Closes: #1066674)
+- Add debian/patches/fix-ftbfs-implicit-function-declaration.patch
+- Update debian/patches/clang_FTBFS.patch
+- Update debian/patches/GRAMophone.y.diff
+
+ -- Ying-Chun Liu (PaulLiu)   Mon, 01 Apr 2024 05:23:29 
+0800
+
 gramophone2 (0.8.13a-3.2) unstable; urgency=low
 
   [ Ying-Chun Liu (PaulLiu)  ]
diff -Nru gramophone2-0.8.13a/debian/patches/clang_FTBFS.patch 
gramophone2-0.8.13a/debian/patches/clang_FTBFS.patch
--- gramophone2-0.8.13a/debian/patches/clang_FTBFS.patch2022-12-13 
05:48:33.0 +0800
+++ gramophone2-0.8.13a/debian/patches/clang_FTBFS.patch2024-04-01 
05:23:29.0 +0800
@@ -1,9 +1,29 @@
 Description: fix FTBFS with clang [-Wreturn-type]
 Author: Nicolas Sévelin-Radiguet 
 Last-Update: 2014-09-06
 a/midifile.c
-+++ b/midifile.c
-@@ -156,7 +156,7 @@
+Index: gramophone2-0.8.13a/midifile.c
+===
+--- gramophone2-0.8.13a.orig/midifile.c
 gramophone2-0.8.13a/midifile.c
+@@ -78,6 +78,17 @@ static int read16bit();
+ static int to16bit();
+ static char *msg();
+ 
++int mferror(char *);
++int readheader();
++int readtrack();
++int chanmessage(int, int, int);
++int msginit();
++int msgadd(int);
++int metaevent(int);
++int sysex();
++int msgleng();
++int badbyte(int);
++
+ /*
+  * Write multi-length bytes to MIDI format files
+  */
+@@ -156,7 +167,7 @@ readheader()   /* read a header chunk */
int format, ntrks, division;
  
if ( readmt("MThd") == EOF )
diff -Nru 
gramophone2-0.8.13a/debian/patches/fix-ftbfs-implicit-function-declaration.patch
 
gramophone2-0.8.13a/debian/patches/fix-ftbfs-implicit-function-declaration.patch
--- 
gramophone2-0.8.13a/debian/patches/fix-ftbfs-implicit-function-declaration.patch
1970-01-01 08:00:00.0 +0800
+++ 
gramophone2-0.8.13a/debian/patches/fix-ftbfs-implicit-function-declaration.patch
2024-04-01 05:23:29.0 +0800
@@ -0,0 +1,84 @@
+Description: Fix FTBFS caused by -Werror=implicit-function-declaration
+ In dpkg 1.22.6, it enabled -Werror=implicit-function-declaration.
+ Thus we need to make sure every function has its definition.
+Bug-Debian: http://bugs.debian.org/1066674
+Author: Ying-Chun Liu (PaulLiu) 
+Last-Update: 2024-04-01
+Index: gramophone2-0.8.13a/midifile.h
+===
+--- gramophone2-0.8.13a.orig/midifile.h
 gramophone2-0.8.13a/midifile.h
+@@ -32,6 +32,11 @@ extern int (*Mf_writetempotrack)();
+ float mf_ticks2sec();
+ unsigned long mf_sec2ticks();
+ void mfwrite();
++int mf_write_midi_event(unsigned long, unsigned int, unsigned int, unsigned 
char *, unsigned long);
++int mf_write_meta_event(unsigned long, unsigned char, unsigned char *, 
unsigned long);
++void mf_write_tempo(unsigned long);
++int eputc(unsigned char);
++int biggermsg();
+ 
+ /* MIDI status commands most significant bit is 1 */
+ #define note_off  0x80
+Index: gramophone2-0.8.13a/global.h
+===
+--- gramophone2-0.8.13a.orig/global.h
 gramophone2-0.8.13a/global.h
+@@ -181,3 +181,33 @@ typedef struct macro_data {
+ } macro;
+ 
+ macro macros[NUM_MACRO];
++
++void usageError(void);
++unsigned int hash(char *v, unsigned char sentinel);
++void initGRAMophone(void);
++void init_local_flag(void);
++void init_player(void);
++int grammyvm();
++void print_local_params(unsigned char i);
++void print_composition_info();
++void print_global_params();
++void sntx_err(unsigned int error, char *msg);
++void dhInsert(pnote_var noteVar, char *text, unsigned char sentinel, unsigned 
char created_by_body);
++pnote_var dhSearch(char *v, unsigned char sentinel);
++char *dhSearch2(char *v);
++void code_update(unsigned int cc, unsigned int _goto);
++void gen_code(unsigned int op, unsigned int op1);
++void gen_code2(unsigned int op);
++void gen_code3(unsigned int op, unsigned type, unsigned op1);
++void gen_code4(unsigned int op, unsigned op1, unsigned op2, unsigned type);
++void gen_note_code(unsigned int op, unsigned int note, unsigned int type1,
++ unsigned int op1, unsigned int type2, unsigned int op2,
++ unsigned int type3, unsigned int op3, unsigned int type4,
++ unsigned int op4);
++void gen_exp1_code(unsigned int op, unsigned int 

Bug#1065768: libauthen-krb5-perl: FTBFS on arm{el,hf}: Krb5.xs:1040:17: error: implicit declaration of function ‘krb5_free_address’; did you mean ‘krb5_free_addresses’? [-Werror=implicit-function-dec

[Russ Allbery]

gregor herrmann  writes:

> I'm by far not any expert on C code and gcc flags; but yes, given the
> above findings and unless someone more knowledgeable steps up in the
> next couple of week, I think we have to remove libauthen-krb5-perl (and
> libauthen-krb5-admin-perl).

Authen::Krb5 has a bunch of stuff that dates from the pre-GSS-API era of
Kerberos, and there were other things that at one point got me to start
writing my own version of the same idea (although alas I never finished).
In theory, one could delete the pieces of the module that try to do things
that no one should really be doing from Perl and the rest of it remains
somewhat useful, but given that upstream has archived the project, I would
go ahead and remove it.

Maybe someday I'll dust off and finish a proper Kerberos Perl module that
uses the modern C API.  In my copius free time.  :)

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

Bug#1068165: prads: please add support for loong64

[wuruilong]

Source: prads
Severity: normal
User: debian-loonga...@lists.debian.org
Usertags: loong64
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

prads failed to compile on loongarch, the attachment fixes the bug.

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
The Debian packaging of prads is maintained in git, using the merging
workflow described in dgit-maint-merge(7). There isn't a patch queue
that can be represented as a quilt series.

A detailed breakdown of the changes is available from their canonical
representation - git commits in the packaging repository. For example,
to see the changes made by the Debian maintainer in the first upload
of upstream version 0.3.3, you could use:

% git clone https://git.dgit.debian.org/prads
% cd prads
% git log --oneline 0.3.3..debian/0.3.3-1 -- . ':!debian'

(If you have dgit, use `dgit clone prads`, rather than plain `git clone`.)

A single combined diff, containing all the changes, follows.
--- prads-0.3.3.orig/src/dump_dns.c
+++ prads-0.3.3/src/dump_dns.c
@@ -98,7 +98,7 @@ void printchars(char buf[NS_MAXDNAME], u
(cp) += INT32SZ; \
 } while (0)
 
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__loongarch__)
 const char *_res_opcodes[] = {
 "QUERY",
 "IQUERY",

Bug#1065768: libauthen-krb5-perl: FTBFS on arm{el,hf}: Krb5.xs:1040:17: error: implicit declaration of function ‘krb5_free_address’; did you mean ‘krb5_free_addresses’? [-Werror=implicit-function-dec

[gregor herrmann]

On Fri, 29 Mar 2024 13:08:43 +0100, Sebastian Ramacher wrote:

> > Not sure there are many chances to fix this (short of disabling
> > -Werror=implicit-function-declaration). Cf. also in Fedora:
> > https://src.fedoraproject.org/rpms/perl-Authen-Krb5/commits/rawhide
> > https://bugzilla.redhat.com/show_bug.cgi?id=2172836
> 
> So should it be removed?

I'm by far not any expert on C code and gcc flags; but yes, given the
above findings and unless someone more knowledgeable steps up in the
next couple of week, I think we have to remove libauthen-krb5-perl
(and libauthen-krb5-admin-perl).

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1068164: bart: please add support for loong64

[wuruilong]

Source: bart
Severity: normal
User: debian-loonga...@lists.debian.org
Usertags: loong64
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

bart failed to compile on loongarch, the attachment fixes the bug

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
--- bart-0.9.00/debian/rules2024-03-30 06:12:54.235656645 +
+++ bart-0.9.00/debian/rules2023-12-11 17:42:37.0 +
@@ -12,7 +12,7 @@
 export PARALLEL_NJOBS=1
 
 # some archs require turning of some optimizations
-NOEXPOPT_ARCHS=arm64 ppc64el s390x ia64 powerpc ppc64 riscv64 loong64
+NOEXPOPT_ARCHS=arm64 ppc64el s390x ia64 powerpc ppc64 riscv64
 
 # turn off hanging tests on i386
 ifeq ($(DEB_BUILD_ARCH), i386)

Bug#1051496: mailgraph: does not support the new syslog format

[Michael Rasmussen]

Hi all,

I can confirm what Michael in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051496#22 writes
that that mailgraph neither works in 1.14.20 nor in 1.14.21 the patch
provided by Vincent Lefevre is not added to mailgraph so this bug so be
raised to 'package unusable' accordingly.

Proof:
Apply patch provided by Vincent Lefevre to /usr/sbin/mailgraph which
will be applied cleanly. This proofs that the patch is not applied and
never have been applied to the file. 

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael  rasmussen  cc
https://keys.openpgp.org/vks/v1/by-fingerprint/A1306C5094B5E31B7721A3A66F4844C7CA7501AA
mir  datanom  net
https://keys.openpgp.org/vks/v1/by-fingerprint/0C14CD9479667E848770C8F98417B6C5E1BB093F
mir  miras  org
https://keys.openpgp.org/vks/v1/by-fingerprint/5F71405B571CB8EE2A414A4FC77C11E049A06E66
--

'During times of universal deceit, telling the truth becomes a
revolutionary act.' -George Orwell

/usr/games/fortune -es says:
Q: What's the big deal about rm, I have been deleting stuff for years?
And never lost anything.. oops!
A: ...
-- From the Frequently Unasked Questions


pgpZpA02zGUXU.pgp
Description: OpenPGP digital signature

Bug#1068163: glade: please do not B-D on webkit on m68k

[Thorsten Glaser]

Source: glade
Version: 3.40.0-5
X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org

As hinted in another ticket, please extend the exclusion of
webkit [not ia64 kfreebsd-any] to also exclude m68k. (You
probably can remove kfreebsd-any at the same time.)

I’m still looking into the B-D of src:webkit2gtk, but the
build logs of that package itself also don’t look promising¹,
and glade is in some dependency chains.

① as in, needs lots of manual effort to fix its assumptions
  that aren’t guaranteed by C/POSIX (and don’t hold true on
  all architectures, m68k in this case)

Thanks,
//mirabilos

Bug#1068091: dh-make-perl: Build fails with invalid git tag when using manual version and epoch

[gregor herrmann]

On Sat, 30 Mar 2024 12:46:46 +, Andy Beverley wrote:

> When specifying a version with an epoch, and when a tag is used with
> a git repo, the build fails with an invalid tag error.
> 
> For example:
> 
>   cpan2deb --version=1:1.006 --revision=1  PDF::Table
> 
> Fails with:
> 
>   fatal: 'upstream/1:1.006' is not a valid tag name.

Nice find :)

I guess this is a bit of a corner case, as there probably is no
upstream version with a ':' anywhere, but I see why you would be
doing something like this.
 
> The problem appears to be caused by this line in DhMakePerl::Command::make
>   $git->command( 'tag', "upstream/".$self->version, 'upstream/latest' )
> I assume a fix would simply be to replace all occurences of a colon with
> another suitable character?

Thanks for pointing out the relevant line in the code, and yes,
replacing the colon with something git-compatible sounds right.

It looks like some tools use '%' as a replacement, maybe dh-make-perl
should adopt this precedence.

Do you fancy to provide and test a patch? I'd be happy tp
review/merge/upload.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1068024:

[Jeffrey Walton]

An important comment from oss-security mailing list message,
:

commit f9cf4c05edd14dedfe63833f8ccbe41b55823b00 (HEAD -> master,
origin/master, origin/HEAD)
Author: Lasse Collin 
Date:   Sat Mar 30 14:36:28 2024 +0200

CMake: Fix sabotaged Landlock sandbox check.

It never enabled it.

Bug#1068162: Please consider adding MP-TCP support

[Juliusz Chroboczek]

Package: openssh-server
Version: 1:9.6p1-4
Severity: wishlist

Hi,

Please consider applying the following patch:

  https://github.com/openssh/openssh-portable/pull/335

MP-TCP support allows moving from one IP address to another without
breaking connections, and does so in a way that remains compatible with
existing clients and servers.  It solves the main issue that causes people
to prefer mosh to ssh.

Thanks,

-- Juliusz Chroboczek

Bug#1026877: opari2: please make the build reproducible

[Samuel Thibault]

James Addison, le dim. 31 mars 2024 23:44:20 +0100, a ecrit:
> Source: opari2
> Followup-For: Bug #1026877
> Control: close -1 2.0.7-2

Thanks!

Bug#1026877: opari2: please make the build reproducible

[James Addison]

Source: opari2
Followup-For: Bug #1026877
Control: forwarded -1 
https://salsa.debian.org/debian/opari2/-/commit/1cc9b96544cdf1e8cbc733584b3ff1a4109b89e6
 
https://salsa.debian.org/debian/opari2/-/commit/15155c97944b7c17bc481ff91261d8191f81ae6f

Bug#1026877: opari2: please make the build reproducible

[James Addison]

Source: opari2
Followup-For: Bug #1026877
Control: close -1 2.0.7-2

Bug#1067582: gnuplot: please provide a profile to break B-D cycle

[Dima Kogan]

I added the requested profile, and fixed a few build bugs I encountered
in the process. The patch series is here:

  https://salsa.debian.org/science-team/gnuplot/-/commits/bug-1067582

Anton: can you please review and upload, if it looks good? Or let me
know, and I'll make a Team upload.

Bug#1065157: cups-core-drivers: Filters ignore cupsManualCopies

[Paul Szabo]

> Where did you report them?

As mentioned:
https://github.com/OpenPrinting/cups/issues/917
https://github.com/OpenPrinting/cups/issues/918
https://github.com/OpenPrinting/cups/issues/919
and also
https://github.com/OpenPrinting/cups/issues/916

Cheers, Paul
-- 
Paul Szabo   p...@maths.usyd.edu.au   www.maths.usyd.edu.au/u/psz
School of Mathematics and Statistics   University of SydneyAustralia

Join the Union and fight for a better University: www.nteu.au/join

Bug#1068161: Video playback regression

[Daniel Richard G.]

Package: chromium
Version: 123.0.6312.86-1~deb12u1
Severity: important

Video playback worked fine in the previous version,
122.0.6261.128-1~deb12u1

In the current version, when I attempt to play a video, the visual
portion is completed whited out. The playback controls are present,
playback position advances, audio can be heard, but the video is just a
solid, constant white (regardless of the site's background color).

During playback, the following pair of error messages are printed
repeatedly to the terminal:

[179003:179003:0331/180459.326096:ERROR:raster_decoder.cc(2407)] 
[.RenderCompositor-0x38dc004ddc00]GL ERROR :GL_INVALID_OPERATION : 
glWritePixelsYUV: Failed to upload pixels to dest shared image

[179003:179003:0331/180459.385907:ERROR:shared_image_representation.cc(478)] 
Attempt to read from an uninitialized SharedImage. Initialized region: (0, 0, 
0, 0) Size: (544, 360)

I have downloaded the previous 122.0.6261.128-1~deb12u1 package, and
run it to confirm that it can still play video correctly. In fact, I
have 122 and 123 running side by side, with one working and the other
spewing errors.


--Daniel

Bug#1068160: haskell-gi-glib: FTBFS on mips64el: couldn't find API description for GLib.time_t

[Sebastian Ramacher]

Source: haskell-gi-glib
Version: 2.0.29-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=haskell-gi-glib=mips64el=2.0.29-1%2Bb2=1711923103=0

Running debian/hlibrary.setup configure --ghc -v2 
--package-db=/var/lib/ghc/package.conf.d --prefix=/usr 
--libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib 
--builddir=dist-ghc --ghc-option=-optl-Wl,-z,relro 
--haddockdir=/usr/lib/ghc-doc/haddock/gi-glib-2.0.29/ --datasubdir=gi-glib 
--htmldir=/usr/share/doc/libghc-gi-glib-doc/html/ --enable-library-profiling
Non-zero exit code 1.
Using Parsec parser
␛[1;91mERROR: ␛[97mcouldn't find API description for GLib.time_t␛[22;94m
Please report this at https://github.com/haskell-gi/haskell-gi/issues␛[0m
CallStack (from HasCallStack):
  error, called at lib/Data/GI/CodeGen/Util.hs:126:6 in 
haskell-gi-0.26.7-9datlXCg7xu2gIby3le2Cx:Data.GI.CodeGen.Util
  terror, called at lib/Data/GI/CodeGen/Code.hs:556:13 in 
haskell-gi-0.26.7-9datlXCg7xu2gIby3le2Cx:Data.GI.CodeGen.Code
  findAPIByName, called at lib/Data/GI/CodeGen/GObject.hs:17:44 in 
haskell-gi-0.26.7-9datlXCg7xu2gIby3le2Cx:Data.GI.CodeGen.GObject
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 109.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 133

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 637
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: configure-ghc-stamp] Error 1

Cheers
-- 
Sebastian Ramacher

Bug#1068159: openjfx: FTBFS on arm{el,hf}: /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"

[Sebastian Ramacher]

Source: openjfx
Version: 11.0.11+1-3.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=openjfx=armel=11.0.11%2B1-3.1%2Bb2=1711746481=0

gcc -fPIC -Wformat -Wextra -Wformat-security -fstack-protector 
-Werror=implicit-function-declaration -Werror=trampolines -D_GNU_SOURCE 
-DGST_REMOVE_DEPRECATED -DGSTREAMER_LITE -DHAVE_CONFIG_H -DOUTSIDE_SPEEX 
-DLINUX -DGST_DISABLE_GST_DEBUG -DGST_DISABLE_LOADSAVE -ffunction-sections 
-fdata-sections -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 
-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>/modules/javafx.media/src/main/native/gstreamer/projects/linux/gstreamer-lite=.
 -fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -Wall -I../../../plugins 
-I../../../gstreamer-lite/projects/build/linux/common 
-I../../../gstreamer-lite/gstreamer -I../../../gstreamer-lite/gstreamer/libs 
-I../../../gstreamer-lite/gstreamer/gst/parse 
-I../../../gstreamer-lite/gst-plugins-base 
-I../../../gstreamer-lite/gst-plugins-base/gst-libs 
-I../../../gstreamer-lite/projects/plugins 
-I../../../gstreamer-lite/gst-plugins-base/gst-libs 
-I../../../gstreamer-lite/gst-plugins-good/gst-libs 
-I../../../gstreamer-lite/gst-plugins-good/gst/isomp4 
-I../../../gstreamer-lite/gst-plugins-bad/gst-libs -I/usr/include/glib-2.0 
-I/usr/lib/arm-linux-gnueabi/glib-2.0/include  -c 
../../../gstreamer-lite/gstreamer/gst/gst.c -o 
/<>/modules/javafx.media/build/native/linux/Release/obj/gstreamer-lite/gstreamer/gst/gst.o
In file included from /usr/include/features.h:393,
 from 
/usr/include/arm-linux-gnueabi/bits/libc-header-start.h:33,
 from /usr/include/limits.h:26,
 from /usr/lib/gcc/arm-linux-gnueabi/13/include/limits.h:205,
 from /usr/lib/gcc/arm-linux-gnueabi/13/include/syslimits.h:7,
 from /usr/lib/gcc/arm-linux-gnueabi/13/include/limits.h:34,
 from 
/usr/lib/arm-linux-gnueabi/glib-2.0/include/glibconfig.h:11,
 from /usr/include/glib-2.0/glib/gtypes.h:34,
 from /usr/include/glib-2.0/glib/galloca.h:34,
 from /usr/include/glib-2.0/glib.h:32,
 from ../../../gstreamer-lite/gstreamer/gst/gst_private.h:36,
 from ../../../gstreamer-lite/gstreamer/gst/gst.c:94:
/usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed 
only with _FILE_OFFSET_BITS=64"
   26 | #   error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
  | ^
gcc -fPIC -Wformat -Wextra -Wformat-security -fstack-protector 
-Werror=implicit-function-declaration -Werror=trampolines -D_GNU_SOURCE 
-DGST_REMOVE_DEPRECATED -DGSTREAMER_LITE -DHAVE_CONFIG_H -DOUTSIDE_SPEEX 
-DLINUX -DGST_DISABLE_GST_DEBUG -DGST_DISABLE_LOADSAVE -ffunction-sections 
-fdata-sections -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 
-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>/modules/javafx.media/src/main/native/gstreamer/projects/linux/gstreamer-lite=.
 -fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -Wall -I../../../plugins 
-I../../../gstreamer-lite/projects/build/linux/common 
-I../../../gstreamer-lite/gstreamer -I../../../gstreamer-lite/gstreamer/libs 
-I../../../gstreamer-lite/gstreamer/gst/parse 
-I../../../gstreamer-lite/gst-plugins-base 
-I../../../gstreamer-lite/gst-plugins-base/gst-libs 
-I../../../gstreamer-lite/projects/plugins 
-I../../../gstreamer-lite/gst-plugins-base/gst-libs 
-I../../../gstreamer-lite/gst-plugins-good/gst-libs 
-I../../../gstreamer-lite/gst-plugins-good/gst/isomp4 
-I../../../gstreamer-lite/gst-plugins-bad/gst-libs -I/usr/include/glib-2.0 
-I/usr/lib/arm-linux-gnueabi/glib-2.0/include  -c 
../../../gstreamer-lite/gstreamer/gst/gstallocator.c -o 
/<>/modules/javafx.media/build/native/linux/Release/obj/gstreamer-lite/gstreamer/gst/gstallocator.o
../../../gstreamer-lite/gstreamer/gst/gst.c: In function ‘gst_init_check’:
../../../gstreamer-lite/gstreamer/gst/gst.c:411:22: warning: unused parameter 
‘argc’ [-Wunused-parameter]
  411 | gst_init_check (int *argc, char **argv[], GError ** err)
  | ~^~~~
../../../gstreamer-lite/gstreamer/gst/gst.c:411:35: warning: unused parameter 
‘argv’ [-Wunused-parameter]
  411 | gst_init_check (int *argc, char **argv[], GError ** err)
  |~~~^~
../../../gstreamer-lite/gstreamer/gst/gst.c:411:53: warning: unused parameter 
‘err’ [-Wunused-parameter]
  411 | gst_init_check (int *argc, char **argv[], GError ** err)
make[2]: Leaving directory 
'/<>/modules/javafx.media/src/main/native/gstreamer/projects/linux/gstreamer-lite'
  |   ~~^~~

Bug#1068158: python-escript: FTBFS: RuntimeError: We do not current support different different dpkg-buildflags for C vs C++:

[Sebastian Ramacher]

Source: python-escript
Version: 5.6-6
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=python-escript=arm64=5.6-6%2Bb3=1711889068=0

mkdir -p /<>/debian/stage3
scons  -j4   cc_optim=' -O3  '  build_dir=/<>/debian/tmp3 
verbose=on prefix=/<>/debian/stage3 
options_file=debian/sid_options.py docs
scons: Reading SConscript files ...
3.11.8 (main, Mar 26 2024, 12:04:57) [GCC 13.2.0]
RuntimeError: We do not current support different different dpkg-buildflags for 
C vs C++:
  File "/<>/SConstruct", line 172:
env = Environment(tools = ['default'], options = vars,
  File "/usr/lib/python3/dist-packages/SCons/Environment.py", line 1231:
variables.Update(self)
  File "/usr/lib/python3/dist-packages/SCons/Variables/__init__.py", line 187:
exec(contents, {}, values)
  File "", line 84:

  File "/<>/site_scons/extractdebbuild.py", line 61:
raise RuntimeError("We do not current support different different 
dpkg-buildflags for C vs C++")
make[1]: *** [debian/rules:65: override_dh_auto_build] Error 2

Cheers
-- 
Sebastian Ramacher

Bug#1068156: RM: tk707 -- RoQA; unmainained, RC-buggy, dead upstream

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: tk...@packages.debian.org, sramac...@debian.org
Control: affects -1 + src:tk707
User: ftp.debian@packages.debian.org
Usertags: remove

tk707 is orphaned for many years (#831657) and dead upstream (last
commit 15 years ago). It also fails to build (#1066230), so please
remove it from the archive.

Cheers
-- 
Sebastian Ramacher

Bug#1068157: siridb-server: FTBFS on armhf: ./test.sh: line 18: 3276877 Segmentation fault valgrind --tool=memcheck --error-exitcode=1 --leak-check=full -q ./$OUT

[Sebastian Ramacher]

Source: siridb-server
Version: 2.0.51-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=siridb-server=2.0.51-2%2Bb3=armhf=1711922161

Testing 
expr␛[32mOK␛[0m 
(8.519 ms)
==3276877== 
==3276877== Process terminating with default action of signal 11 (SIGSEGV)
==3276877==  Access not within mapped region at address 0xFEC4F704
==3276877==at 0x495F6F0: pcre2_compile_8 (in 
/usr/lib/arm-linux-gnueabihf/libpcre2-8.so.0.11.2)
==3276877==  If you believe this happened as a result of a stack
==3276877==  overflow in your program's main thread (unlikely but
==3276877==  possible), you can try to increase the size of the
==3276877==  main thread stack using the --main-stacksize= flag.
==3276877==  The main thread stack size used in this run was 8388608.
./test.sh: line 18: 3276877 Segmentation fault  valgrind --tool=memcheck 
--error-exitcode=1 --leak-check=full -q ./$OUT

Cheers
-- 
Sebastian Ramacher

Bug#1056893: uvloop: diff for NMU version 0.19.0+ds1-2.1

[Sebastian Ramacher]

Control: tags 1056893 + pending

Dear maintainer,

I've prepared an NMU for uvloop (versioned as 0.19.0+ds1-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru uvloop-0.19.0+ds1/debian/changelog uvloop-0.19.0+ds1/debian/changelog
--- uvloop-0.19.0+ds1/debian/changelog	2023-11-16 13:16:10.0 +0100
+++ uvloop-0.19.0+ds1/debian/changelog	2024-03-31 23:47:16.0 +0200
@@ -1,3 +1,14 @@
+uvloop (0.19.0+ds1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+
+  [ Graham Inggs ]
+  * Include proposed patch for compatibility with Cython 3 (Closes: #1056893)
+(LP: #2051150)
+  * Skip tests failing with libuv 1.48.0
+
+ -- Sebastian Ramacher   Sun, 31 Mar 2024 23:47:16 +0200
+
 uvloop (0.19.0+ds1-2) unstable; urgency=medium
 
   * Add 0003-Fix-unit-tests-on-IPv6-only-hosts patch. Thanks to Dale Richards!
diff -Nru uvloop-0.19.0+ds1/debian/patches/cython3.patch uvloop-0.19.0+ds1/debian/patches/cython3.patch
--- uvloop-0.19.0+ds1/debian/patches/cython3.patch	1970-01-01 01:00:00.0 +0100
+++ uvloop-0.19.0+ds1/debian/patches/cython3.patch	2024-03-26 18:29:47.0 +0100
@@ -0,0 +1,556 @@
+Description: Updates for Cython3
+ Remove SSL depreciation warnings
+Forwarded: https://github.com/MagicStack/uvloop/pull/587
+Author: Alan Brooks <12380017+alan-bro...@users.noreply.github.com>
+Last-Update: 2023-12-28
+
+--- a/Makefile
 b/Makefile
+@@ -9,7 +9,7 @@
+ 
+ 
+ clean:
+-	rm -fr dist/ doc/_build/ *.egg-info uvloop/loop.*.pyd
++	rm -fr dist/ doc/_build/ *.egg-info uvloop/loop.*.pyd uvloop/loop_d.*.pyd
+ 	rm -fr uvloop/*.c uvloop/*.html uvloop/*.so
+ 	rm -fr uvloop/handles/*.html uvloop/includes/*.html
+ 	find . -name '__pycache__' | xargs rm -rf
+--- a/setup.py
 b/setup.py
+@@ -144,7 +144,9 @@
+ self.distribution.ext_modules[:] = cythonize(
+ self.distribution.ext_modules,
+ compiler_directives=directives,
+-annotate=self.cython_annotate)
++annotate=self.cython_annotate,
++compile_time_env=dict(DEFAULT_FREELIST_SIZE=250, SSL_READ_MAX_SIZE=256 * 1024),
++emit_linenums=True)
+ 
+ super().finalize_options()
+ 
+--- a/tests/test_process.py
 b/tests/test_process.py
+@@ -912,7 +912,7 @@
+ stdin=subprocess.PIPE,
+ stdout=subprocess.PIPE,
+ stderr=subprocess.PIPE,
+-__uvloop_sleep_after_fork=True))
++uvloop_sleep_after_fork=True))
+ self.assertIsNot(transport, None)
+ self.assertEqual(transport.get_returncode(), 0)
+ self.assertEqual(
+@@ -931,7 +931,7 @@
+ stdin=None,
+ stdout=subprocess.PIPE,
+ stderr=subprocess.PIPE,
+-__uvloop_sleep_after_fork=True))
++uvloop_sleep_after_fork=True))
+ self.assertIsNot(transport, None)
+ self.assertEqual(transport.get_returncode(), 0)
+ self.assertEqual(
+--- a/tests/test_tcp.py
 b/tests/test_tcp.py
+@@ -1630,17 +1630,22 @@
+ self.fail("unexpected call to connection_made()")
+ 
+ def test_ssl_connect_accepted_socket(self):
+-if hasattr(ssl, 'PROTOCOL_TLS'):
+-proto = ssl.PROTOCOL_TLS
++if hasattr(ssl, 'PROTOCOL_TLS_SERVER'):
++server_proto = ssl.PROTOCOL_TLS_SERVER
++client_proto = ssl.PROTOCOL_TLS_CLIENT
+ else:
+-proto = ssl.PROTOCOL_SSLv23
+-server_context = ssl.SSLContext(proto)
++if hasattr(ssl, 'PROTOCOL_TLS'):
++client_proto = server_proto = ssl.PROTOCOL_TLS
++else:
++client_proto = server_proto = ssl.PROTOCOL_SSLv23
++
++server_context = ssl.SSLContext(server_proto)
+ server_context.load_cert_chain(self.ONLYCERT, self.ONLYKEY)
+ if hasattr(server_context, 'check_hostname'):
+ server_context.check_hostname = False
+ server_context.verify_mode = ssl.CERT_NONE
+ 
+-client_context = ssl.SSLContext(proto)
++client_context = ssl.SSLContext(client_proto)
+ if hasattr(server_context, 'check_hostname'):
+ client_context.check_hostname = False
+ client_context.verify_mode = ssl.CERT_NONE
+@@ -2233,7 +2238,7 @@
+ sslctx.use_privatekey_file(self.ONLYKEY)
+ sslctx.use_certificate_chain_file(self.ONLYCERT)
+ client_sslctx = self._create_client_ssl_context()
+-if hasattr(ssl, 'OP_NO_TLSv1_3'):
++if sys.version_info < (3, 8) and hasattr(ssl, 'OP_NO_TLSv1_3'):
+ client_sslctx.options |= ssl.OP_NO_TLSv1_3
+ 
+ def server(sock):
+@@ -2592,7 +2597,7 @@
+ sslctx_openssl.use_privatekey_file(self.ONLYKEY)
+ sslctx_openssl.use_certificate_chain_file(self.ONLYCERT)
+ client_sslctx = self._create_client_ssl_context()
+-if hasattr(ssl, 

Bug#1068155: lmms: FTBFS on i386: dh_install: warning: Cannot find (any matches for) "usr/lib/*/lmms/libvestige.so" (tried in ., debian/tmp)

[Sebastian Ramacher]

Source: lmms
Version: 1.2.2+dfsg1-6
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=lmms=i386=1.2.2%2Bdfsg1-6%2Bb3=1711724261=0

-- Installing: /<>/debian/tmp/usr/share/lmms/wavetables/tri.bin

Installing bash completion...

Bash completion for lmms has been installed to 
/<>/debian/tmp/usr/share/bash-completion/completions/lmms
make[1]: Leaving directory '/<>/obj-i686-linux-gnu'
   dh_install -a
dh_install: warning: Cannot find (any matches for) 
"usr/lib/*/lmms/libvestige.so" (tried in ., debian/tmp)

dh_install: warning: lmms-vst-server missing files: usr/lib/*/lmms/libvestige.so
dh_install: warning: Cannot find (any matches for) "usr/lib/*/lmms/libvst*" 
(tried in ., debian/tmp)

dh_install: warning: lmms-vst-server missing files: usr/lib/*/lmms/libvst*
dh_install: warning: Cannot find (any matches for) 
"usr/lib/*/lmms/RemoteVstPlugin*" (tried in ., debian/tmp)

dh_install: warning: lmms-vst-server missing files: 
usr/lib/*/lmms/RemoteVstPlugin*
dh_install: error: missing files, aborting

Cheers
-- 
Sebastian Ramacher

Bug#1068154: ITP: poke-elf -- GNU Poke pickle for editing ELF object files

[Sergio Durigan Junior]

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

* Package name: poke-elf
  Version : 1.0
  Upstream Author : Jose E. Marchesi 
* URL : http://www.jemarch.net/poke-elf
* License : GPL-3+ and others
  Programming Lang: C
  Description : GNU Poke pickle for editing ELF object files

 poke-elf is a GNU poke pickle for editing ELF object files,
 executables, shared libraries and core dumps.  It supports many
 architectures and extensions.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#967840: xsystem35: depends on deprecated GTK 2

[Alexandre Detiste]

Hi  Ying-Chun Liu

Could this fork replace the original xsystem35 ?

https://github.com/kichikuou/xsystem35-sdl2

Greetings

Bug#1068153: cimg: CVE-2024-26540

[Salvatore Bonaccorso]

Source: cimg
Version: 3.2.1+dfsg-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/GreycLab/CImg/issues/403
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for cimg.

CVE-2024-26540[0]:
| A heap-based buffer overflow in Clmg before 3.3.3 can occur via a
| crafted file to cimg_library::CImg::_load_analyze.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-26540
https://www.cve.org/CVERecord?id=CVE-2024-26540
[1] https://github.com/GreycLab/CImg/issues/403

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1068024: revert to version that does not contain changes by bad actor

[Joey Hess]

> The situation is being analysed by a cross-team taskforce,
> please let them do the already-stressing job ☻

Sorry, didn't see that before sending my previous message.
I'll leave it to you guys.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1068024: revert to version that does not contain changes by bad actor

[Joey Hess]

Since there's been some discussion about versions, the version in my
xz-unscathed git repository is the same as xz 5.3.2alpha, with the
addition of a fix for CVE-2022-1271 that did not make it into that
version. (It was fixed in 5.2.6, but 5.3.2alpha was diverged from
5.2.5. Jia Tan was involved in 5.2.6.)

5.2.5 might be a more stable version to revert to; it also predates
Jia Tan's involvement. The CVE-2022-1271 fix would need to be included.

Note that erofs-utils apparently had a reason to need the 5.3.2alpha
release, so reverting to 5.2.5 would probably cause difficulty with that
package. That dependency versioning information is not included in the
debian sources for erofs-utils BTW. I have not checked compatability
with other packages except for dpkg.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1065157: cups-core-drivers: Filters ignore cupsManualCopies

[Till Kamppeter]

On 31/03/2024 22:23, Paul Szabo wrote:

(Sadly, my other issues were "declined" upstream. Maybe they know what
they are doing...)


Where did you report them?

   Till

Bug#1068152: Pre-installed vendors list contains broken links

[Justin Bax]

Package: www.debian.org
Severity: normal

Dear www team,

The list of computer vendors that pre-install Debian found at
/distrib/pre-installed [1] contains broken links and outdated entries
of companies that do not exist anymore. Specifically, here is a list
of entries I suggest be *removed*, grouped by region as they appear on
the page (note that all of these links are broken in some way):

- Canada: JCCSS (Jeremy Carter's Computer Service and Sales)
Reason: website is down
- Costa Rica: Luis-Alberto Montero
Reason: domain was sold to another party
- Germany: Sanux.de
Reason: website seems to have been lost
- Germany: Xtops.DE
Reason: website is not functional
- Italy: Binario Etico
Reason: website down
- Mexico: GOLIARDOS TECHNOLOGY S.A. de C.V.
Reason: website down
- Poland: Scrascom Komputery Poleasingowe
Reason: website down
- Switzerland: FOX Elektronix - Fux
Reason: website down
- United States: Psychsoftpc
Reason: website down


Additionally, here is a list of entries I suggest be *modified*, along
with their modification and justification:

- India: NaveenGanesan.com
Change: Update link to https://naveenganesan.com/naveenlinux
Reason: Old link leads to a 404; website owner updated the
location of their Debian page from /computing to /naveenlinux
- Netherlands: SnaakSystems
Changes:
1) Update link to https://novacustom.com
2) Update email to i...@novacustom.com
3) Update 1st line of address to NovaCustom (the rest of the
address is still valid)
Reason: rebranding (domain was updated from
laptopzelfsamenstellen.nl to novacustom.com)

[1] https://www.debian.org/distrib/pre-installed

Cheers,

Justin

Bug#1060724: meteo-qt: Please remove python3-sip Depends

[Dmitry Shachnev]

Control: tags -1 + pending

Dear Maintainer,

On Sat, Jan 13, 2024 at 03:13:33PM +0300, Dmitry Shachnev wrote:
> Package: meteo-qt
> Version: 3.3-2
> Severity: important
> Usertags: sip6
> 
> Dear Maintainer,
> 
> Your package depends on python3-sip, which belongs to the deprecated sip4
> source package.
> 
> The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages
> in Debian are built with that modern version.
> 
> python3-pyqt5 already depends on its SIP run-time module, python3-pyqt5.sip,
> so there is no need to depend on it explicitly.

I have uploaded a trivial fix for this to DELAYED/5.

The NMU diff is available here:
https://salsa.debian.org/lxqt-team/meteo-qt/-/merge_requests/3

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1065157: cups-core-drivers: Filters ignore cupsManualCopies

[Paul Szabo]

Dear Till,

Thanks for the pointer to libcupsfilters, now that issue reported also:
https://github.com/OpenPrinting/libcupsfilters/issues/53

(Sadly, my other issues were "declined" upstream. Maybe they know what
they are doing...)

Thanks, Paul
-- 
Paul Szabo   p...@maths.usyd.edu.au   www.maths.usyd.edu.au/u/psz
School of Mathematics and Statistics   University of SydneyAustralia

Bug#1068151: Pre-installed vendors list contains broken links

[Justin Bax]

Package: www.debian.org Severity: normal Dear www team, The list of computer 
vendors that pre-install Debian found at /distrib/pre-installed [1] contains 
broken links and outdated entries of companies that do not exist anymore. 
Specifically, here is a list of entries I suggest be *removed*, grouped by 
region as they appear on the page (note that all of these links are broken in 
some way): - Canada: JCCSS (Jeremy Carter's Computer Service and Sales) Reason: 
website is down - Costa Rica: Luis-Alberto Montero Reason: domain was sold to 
another party - Germany: Sanux.de Reason: website seems to have been lost - 
Germany: Xtops.DE Reason: website is not functional - Italy: Binario Etico 
Reason: website down - Mexico: GOLIARDOS TECHNOLOGY S.A. de C.V. Reason: 
website down - Poland: Scrascom Komputery Poleasingowe Reason: website down - 
Switzerland: FOX Elektronix - Fux Reason: website down - United States: 
Psychsoftpc Reason: website down Additionally, here is a list of entries I 
suggest be *modified*, along with their modification and justification: - 
India: NaveenGanesan.com Change: Update link to 
https://naveenganesan.com/naveenlinux Reason: Old link leads to a 404; website 
owner updated the location of their Debian page from /computing to /naveenlinux 
- Netherlands: SnaakSystems Changes: 1) Update link to https://novacustom.com 
2) Update email to i...@novacustom.com 3) Update 1st line of address to 
NovaCustom (the rest of the address is still valid) Reason: rebranding (domain 
was updated from laptopzelfsamenstellen.nl to novacustom.com ) [1] 
https://www.debian.org/distrib/pre-installed Cheers, Justin

Bug#1068150: ruby-carrierwave: CVE-2023-49090

[Salvatore Bonaccorso]

Source: ruby-carrierwave
Version: 1.3.2-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ruby-carrierwave.

CVE-2023-49090[0]:
| CarrierWave is a solution for file uploads for Rails, Sinatra and
| other Ruby web frameworks. CarrierWave has a Content-Type allowlist
| bypass vulnerability, possibly leading to XSS. The validation in
| `allowlisted_content_type?` determines Content-Type permissions by
| performing a partial match. If the `content_type` argument of
| `allowlisted_content_type?` is passed a value crafted by the
| attacker, Content-Types not included in the `content_type_allowlist`
| will be allowed. This issue has been patched in versions 2.2.5 and
| 3.0.5.

While the upstream commit will not simply apply due to other
refactoring at least upstream claima as well that earlier verisons
thatn 2.2.5 are affected. Note that the issue needs to be fixed
completely to not open up another CVE. See the security-tracker notes
for the details.


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-49090
https://www.cve.org/CVERecord?id=CVE-2023-49090
[1] 
https://github.com/carrierwaveuploader/carrierwave/security/advisories/GHSA-gxhx-g4fq-49hj

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1068149: FTBFS: Error: symbol `open64' is already defined

[Andrey Rakhmatullin]

Source: porg
Version: 2:0.10-1.2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=porg=armel=2%3A0.10-1.2%2Bb2=1711746873=0

/bin/bash ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
-I../..   -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-
time -D_FORTIFY_SOURCE=2 -W -ansi -Wshadow -Wmissing-declarations -Wall -g -O2
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=.
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-
security -c -o libporg_log_la-log.lo `test -f 'log.c' || echo './'`log.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -W -ansi
-Wshadow -Wmissing-declarations -Wall -g -O2 -Werror=implicit-function-
declaration -ffile-prefix-map=/<>=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -c log.c  -fPIC -DPIC
-o .libs/libporg_log_la-log.o
log.c: In function ‘open’:
log.c:281:27: warning: ‘nonnull’ argument ‘path’ compared to NULL [-Wnonnull-
compare]
  281 | if (!porg_tmpfile && path && !strncmp(path, "/proc/", 6))
  | ~~^~~
log.c: In function ‘open64’:
log.c:385:27: warning: ‘nonnull’ argument ‘path’ compared to NULL [-Wnonnull-
compare]
  385 | if (!porg_tmpfile && path && !strncmp(path, "/proc/", 6))
  | ~~^~~
log.c: In function ‘porg_get_absolute_path’:
log.c:106:17: warning: ‘__builtin_strncpy’ output may be truncated copying 4095
bytes from a string of length 4095 [-Wstringop-truncation]
  106 | strncpy(abs_path, aux, PORG_BUFSIZE - 1);
  | ^
log.c:100:17: warning: ‘__builtin_strncpy’ output may be truncated copying 4095
bytes from a string of length 4095 [-Wstringop-truncation]
  100 | strncpy(abs_path, cwd, PORG_BUFSIZE - 1);
  | ^
/tmp/cc7rmZAz.s: Assembler messages:
/tmp/cc7rmZAz.s:2214: Error: symbol `open64' is already defined
/tmp/cc7rmZAz.s:2581: Error: symbol `openat64' is already defined
/tmp/cc7rmZAz.s:3220: Error: symbol `creat64' is already defined
/tmp/cc7rmZAz.s:3296: Error: symbol `fopen64' is already defined
/tmp/cc7rmZAz.s:3380: Error: symbol `freopen64' is already defined


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

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

Bug#1067582: gnuplot: please provide a profile to break B-D cycle

[Dima Kogan]

OK. I see what you're saying. I can do this today or tomorrow. Anton:
are you good with that? I'd make a profile "nox-only" that elides the
gnuplot-x11 and gnuplot-qt packages.

Bug#1066760: xine-ui: FTBFS: dh_install: error: missing files, aborting

[Andrey Rakhmatullin]

On Wed, Mar 13, 2024 at 03:54:42PM +0100, Lucas Nussbaum wrote:
> >dh_install
> > dh_install: warning: Cannot find (any matches for) "usr/bin/aaxine" (tried 
> > in ., debian/tmp)
The reason for this:

checking for AALIB version >= 1.2.0... no
*** Could not run AALIB test program, checking why...
*** The test program compiled, but did not run. This usually means
*** that the run-time linker is not finding AALIB or finding the wrong
*** version of AALIB. If it is not finding AALIB, you'll need to set your
*** LD_LIBRARY_PATH environment variable, or edit /etc/ld.so.conf to point
*** to the installed location  Also, make sure you have run ldconfig if that
*** is required on your system
***
*** If you have an old version installed, it is best to remove it, although
*** you may also be able to get things to work by modifying LD_LIBRARY_PATH
***

libaa1-dev is installed but I suspect the test fails with
-Werror=implicit-declaration.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1068148: minidlna: CVE-2023-47430

[Salvatore Bonaccorso]

Source: minidlna
Version: 1.3.3+dfsg-1
Severity: important
Tags: security upstream
Forwarded: https://sourceforge.net/p/minidlna/bugs/361/
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for minidlna.

CVE-2023-47430[0]:
| Stack-buffer-overflow vulnerability in ReadyMedia (MiniDLNA) v1.3.3
| allows attackers to cause a denial of service via via the
| SendContainer() function at tivo_commands.c.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-47430
https://www.cve.org/CVERecord?id=CVE-2023-47430
[1] https://sourceforge.net/p/minidlna/bugs/361/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2

[Sebastian Andrzej Siewior]

On 2024-03-31 19:42:24 [+], tony mancill wrote:
> Given what has unfolded over the past few days regarding xz-utils and
> CVE-2024-3094 [0], should we revisit the patches applied here and for
> #1063252?  Are they still needed?

Not with the fallback to pre 5.4.x series but *I* don't think this will
remain forever.
The requirement for the change was different default value for the -T
parameter. Recording the -T parameter by default and relying on
defaults is good.

> Thank you,
> tony

Sebastian

Bug#1068147: FTBFS: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘__time64_t’ {aka ‘long long int’}

[Andrey Rakhmatullin]

Source: pesign
Version: 116-6
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=pesign=armhf=116-6%2Bb2=1711718501=0

In file included from pesign.h:18,
 from cms_common.c:21:
cms_common.c: In function ‘cms_set_pw_data’:
util.h:275:23: error: format ‘%ld’ expects argument of type ‘long int’, but
argument 2 has type ‘__time64_t’ {aka ‘long long int’} [-Werror=format=]
  275 | warnx("%ld.%lu %s:%s():%d: " fmt,   \
  |   ^~
util.h:286:25: note: in expansion of macro ‘dbgprintf_’
  286 |
dbgprintf_(CAT(CAT(CAT(tv_,__COUNTER__),__LINE__),_),   \
  | ^~
util.h:292:19: note: in expansion of macro ‘dbgprintf’
  292 | #define ingress() dbgprintf("ingress");
  |   ^
cms_common.c:302:9: note: in expansion of macro ‘ingress’
  302 | ingress();
  | ^~~


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

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

Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2

[tony mancill]

On Wed, Mar 13, 2024 at 01:50:47PM -0400, Jeremy Bícha wrote:
> The 3 test cases pass for me now with the uploaded 1.50+nmu2. Maybe my
> earlier test build used the old version of xz-utils. Thank you for
> your upload!

Given what has unfolded over the past few days regarding xz-utils and
CVE-2024-3094 [0], should we revisit the patches applied here and for
#1063252?  Are they still needed?

I'm not making any assertions about the validity of the changes, only
suggesting that we should review changes made to accommodate the
xz-utils versions related to the CVE.

(It is still not clear why some gbp workflows using pristine-tar started
failing [1] around the same time that changes were being introduced to
xz-utils and pristine-tar.  Perhaps it is a coicidence, but it seems
potentially related.)

Thank you,
tony

[0] https://security-tracker.debian.org/tracker/CVE-2024-3094
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065445


signature.asc
Description: PGP signature

Bug#1068145: FTBFS: chmod: cannot access 'debian/python-mpltoolkits.basemap-data/usr/share/basemap/data/*': No such file or directory

[Andrey Rakhmatullin]

Source: basemap
Version: 1.2.2+dfsg-4
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=basemap=amd64=1.2.2%2Bdfsg-4=1711493603=0

   debian/rules override_dh_python3
make[1]: Entering directory '/<>'
dh_python3
chmod -x debian/python-mpltoolkits.basemap-data/usr/share/basemap/data/*
chmod: cannot access 'debian/python-mpltoolkits.basemap-
data/usr/share/basemap/data/*': No such file or directory


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

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

Bug#1068146: FTBFS: tests failed

[Andrey Rakhmatullin]

Source: dipy
Version: 1.9.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=dipy=armel=1.9.0-1=1711658317=0

=== short test summary info

FAILED dipy/reconst/tests/test_shore.py::test_shore_fitting_no_constrain_e0
FAILED dipy/viz/tests/test_util.py::test_check_img_shapes -
numpy.core._excep...


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

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

Bug#1067561: FTBFS: Error: symbol `open64' is already defined

[Andrey Rakhmatullin]

On Sat, Mar 23, 2024 at 09:56:58PM +0500, Andrey Rakhmatullin wrote:
> /bin/bash ../../libtool  --tag=CC   --mode=link gcc -Wall
> -Wstrict-prototypes  -Wnested-externs
> -Werror=missing-prototypes  -Werror=implicit-function-
> declaration  -Werror=pointer-arith
> -Werror=init-self  -Werror=format-security
> -Werror=format=2  -Werror=missing-include-dirs
> -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabi/glib-2.0/include
> -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabi/glib-2.0/include
> -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabi/glib-2.0/include -pthread
> -I/usr/include/libmount -I/usr/include/blkid  -I/usr/include/gio-unix-2.0
> -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabi/glib-2.0/include -pthread
> -I/usr/include/libmount -I/usr/include/blkid  -g -O2 
> -Werror=implicit-function-
> declaration -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -O0  -Wl,-z,relro
> -Wl,-z,now -Wl,-O1 -o Xvnc Xvnc-Xvnc.o Xvnc-x-authority.o Xvnc-x-common.o 
> Xvnc-
> x-server.o Xvnc-status.o -lgobject-2.0 -lglib-2.0  -lglib-2.0  -lgio-2.0
> -lgobject-2.0 -lglib-2.0  -lgio-2.0 -lgobject-2.0 -lglib-2.0
> /tmp/ccCHYR2t.s: Assembler messages:
> /tmp/ccCHYR2t.s:2779: Error: symbol `open64' is already defined
> /tmp/ccCHYR2t.s:3181: Error: symbol `creat64' is already defined
> /tmp/ccCHYR2t.s:3508: Error: symbol `__stat64_time64' is already defined
I assume the following patch from Ubuntu fixes this:

--- a/tests/src/libsystem.c
+++ b/tests/src/libsystem.c
@@ -1,6 +1,9 @@
 #define _GNU_SOURCE
 #define __USE_GNU

+#undef _FILE_OFFSET_BITS
+#undef _TIME_BITS
+
 #include 

 #include 

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1068144: slang2: CVE-2023-45927 CVE-2023-45929

[Moritz Mühlenhoff]

Source: slang2
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerabilities were published for slang2. From my perspective
they have no real security impact, but we can still treat/fix them as regular
bugs:

CVE-2023-45927[0]:
| S-Lang 2.3.2 was discovered to contain an arithmetic exception via
| the function tt_sprintf().
http://lists.jedsoft.org/lists/slang-users/2023/003.html

CVE-2023-45929[1]:
| S-Lang 2.3.2 was discovered to contain a segmentation fault via the
| function fixup_tgetstr().
http://lists.jedsoft.org/lists/slang-users/2023/002.html

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-45927
https://www.cve.org/CVERecord?id=CVE-2023-45927
[1] https://security-tracker.debian.org/tracker/CVE-2023-45929
https://www.cve.org/CVERecord?id=CVE-2023-45929

Please adjust the affected versions in the BTS as needed.

Bug#1068142: Build-Depends on missing librust-quick-xml-0.31+default-dev

[Andrey Rakhmatullin]

Source: rust-gsettings-macro
Version: 0.2.0-2
Severity: serious
Tags: ftbfs



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

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

Bug#1068141: ITP: python-pyzipper -- AES encryption for zipfile

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: python-pyzipper
  Version : 0.3.6
  Upstream Contact: Daniel Hillier  
* URL : https://github.com/danifus/pyzipper
* License : MIT/X
  Programming Lang: Python
  Description : AES encryption for zipfile
 PyZipper is a Python library for working with ZIP files in an efficient
 and user-friendly way. It provides a high-level interface for creating,
 reading, writing and extracting ZIP files. Additionally, it supports
 advanced functionalities such as AES encryption and LZMA updates.
 .
 Key Features:
  - Allows you to add, remove, rename and list entries in ZIP files
efficiently.
  - Provides an intuitive Python API, making ZIP archive manipulation
simple and straightforward.
  - AES (Advanced Encryption Standard) encryption support to protect ZIP
files with passwords.
  - Allows you to compress ZIP files using the LZMA compression algorithm,
which offers high compression rates.

  Note: This package is a required dependency for the TeraBoxUtility
 ITP package: #1067395

Bug#871768: (no subject)

[Tiago Bortoletto Vaz]

tags #871768 patch
thanks

See MR at
https://salsa.debian.org/nm-team/nm-templates/-/merge_requests/23

-- 
Tiago Bortoletto Vaz

Bug#1066416: granite-7: FTBFS: ./obj-x86_64-linux-gnu/lib/libgranite-7.so.7.4.0.p/Widgets/DatePicker.c:248:(.text+0x70c): undefined reference to `gtk_calendar_get_year'

[Andrey Rakhmatullin]

Control: reassign -1 valac
Control: affects -1 src:granite-7

On Wed, Mar 13, 2024 at 01:03:07PM +0100, Lucas Nussbaum wrote:
> Relevant part (hopefully):
> > /usr/bin/ld: 
> > lib/libgranite-7.so.7.4.0.p/meson-generated_Widgets_DatePicker.c.o: in 
> > function `_granite_date_picker___lambda10_':
> > ./obj-x86_64-linux-gnu/lib/libgranite-7.so.7.4.0.p/Widgets/DatePicker.c:248:(.text+0x70c):
> >  undefined reference to `gtk_calendar_get_year'
> > /usr/bin/ld: 
> > ./obj-x86_64-linux-gnu/lib/libgranite-7.so.7.4.0.p/Widgets/DatePicker.c:251:(.text+0x71a):
> >  undefined reference to `gtk_calendar_get_month'
> > /usr/bin/ld: 
> > ./obj-x86_64-linux-gnu/lib/libgranite-7.so.7.4.0.p/Widgets/DatePicker.c:254:(.text+0x727):
> >  undefined reference to `gtk_calendar_get_day'
These functions are added in Gtk4 4.14 while we have 4.12. The code is
generated from lib/Widgets/DatePicker.vala which doesn't refer to them
directly and was built successfully before so I assume it's a bug in valac
code generation.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1067237: ngircd: missing ssl security patch in debian's ngircd package

[Christoph Biedl]

Control: tags 1067237 pending

jose wrote...

> The master branch of the upstream ngircd changelog informs about an 
> SSL security related patch [1] that is missing in the -26-1 ngircd debian
> package patches.

Thanks, this is on radar and I'm in contact with upstream on how to deal
with this.

Christoph


signature.asc
Description: PGP signature

Bug#1067620: add max version to python3-ruamel.yaml dependency

[Louis-Philippe Véronneau]

retitle 1067620 whipper fails with python3-ruamel.yaml <= 0.18.0
forwarded 1067620 https://github.com/whipper-team/whipper/issues/605
thanks

Hi,

Thanks for opening this bug.

Sadly, even if we add a maximum version in the Debian packaging rules, 
the package will still FTBFS when python3-ruamel.yaml is updated.


I trust that this kind of failure will be caught by the testsuite 
if/when python3-ruamel.yaml is updated in the archive.


In the meantime, I've added more info to the bug so that we'll be 
notified if upstream comes up with a patch.


If you managed to fix this issue on your side and want me to test the 
patch in Debian, don't hesitate to send it!


Cheers,

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

Bug#1068089: FTBFS: error: cannot convert ‘long int*’ to ‘const time_t*’ {aka ‘const long long int*’}

[Andrey Rakhmatullin]

On Sat, Mar 30, 2024 at 05:25:21PM +0500, Andrey Rakhmatullin wrote:
> plugins/about/aboutinterface.cpp: In member function ‘char*
> AboutInterface::ntpdate(char*)’:
> plugins/about/aboutinterface.cpp:438:18: error: cannot convert ‘long int*’ to
> ‘const time_t*’ {aka ‘const long long int*’}
>   438 | return ctime();
The code talks to the network (implementing the NTP protocol I guess?) and
so it's probably fragile. The comment suggests tmit is explicitly not a
time_t.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1036231: mbedtls: please update to 3.4.0 for cmake support

[Andrea Pappacoda]

On Thu, 22 Feb 2024 08:05:41 +0100 Jakob Haufe  wrote:
> On Wed, 17 May 2023 21:51:44 +0200 Andrea Pappacoda  
> wrote:
> 
> > I'd love to package the 3.x branch, but there currently isn't any LTS 
> > release for it; the latest LTS is 2.28.x. I'm not going to package 
> > non-LTS versions in Debian, since they don't fit nicely with the stable 
> > release scheme.
> 
> I think that ship has sailed. According to [1], 2.28.x will be supported
> until the end of 2024, so it will be EOL during the bookworm stable period.
> 
> Would you be open to package 3.x for experimental so ITPs depending on it can
> progress?
> 
> If you intend to have 2.x around for longer, maybe a separate source package
> (mbedtls3 ?) is necessary to allow packaging them in parallel.

Hi Jakob, thanks for your interest!

Luckily upstream has just released version 3.6 LTS, so I'll package that
as soon as possible, just after uploading the last 2.28.8 release.

I'll need help from a Debian Developer though, since I cannot upload
packages to NEW myself (which would be required due to SONAME changes).

Bye :D

P.S. please always CC me in replies, as my mail server discards emails
without proper DKIM signatures, like emails from the BTS.

Bug#1068140: polymake: FTBFS: dpkg-shlibdeps: error: no dependency information found for /lib/x86_64-linux-gnu/libflint.so.19 (used by debian/libpolymake4.11/usr/lib/libpolymake.so.4.11)

[Sebastian Ramacher]

Source: polymake
Version: 4.11-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=polymake=amd64=4.11-2%2Bb4=1711743555=0

dpkg-shlibdeps: error: no dependency information found for 
/lib/x86_64-linux-gnu/libflint.so.19 (used by 
debian/libpolymake4.11/usr/lib/libpolymake.so.4.11)
Hint: check if the library actually comes from a package.
dh_shlibdeps: error: dpkg-shlibdeps -Tdebian/libpolymake4.11.substvars 
debian/libpolymake4.11/usr/lib/polymake/lib/libpolymake-apps.so.4.11 
debian/libpolymake4.11/usr/lib/polymake/lib/libpolymake-apps-rt.so.4.11 
debian/libpolymake4.11/usr/lib/libpolymake.so.4.11 returned exit code 25
dpkg-shlibdeps: error: no dependency information found for 
/lib/x86_64-linux-gnu/libflint.so.19 (used by 
debian/polymake/usr/lib/polymake/perlx/5.38.2/x86_64-linux-gnu-thread-multi/auto/Polymake/Ext/Ext.so)
Hint: check if the library actually comes from a package.
dh_shlibdeps: error: dpkg-shlibdeps -Tdebian/polymake.substvars 
debian/polymake/usr/lib/polymake/lib/tropical.so 
debian/polymake/usr/lib/polymake/lib/topaz.so 
debian/polymake/usr/lib/polymake/lib/polytope.so 
debian/polymake/usr/lib/polymake/lib/matroid.so 
debian/polymake/usr/lib/polymake/lib/ideal.so 
debian/polymake/usr/lib/polymake/lib/group.so 
debian/polymake/usr/lib/polymake/lib/graph.so 
debian/polymake/usr/lib/polymake/lib/fulton.so 
debian/polymake/usr/lib/polymake/lib/fan.so 
debian/polymake/usr/lib/polymake/lib/common.so 
debian/polymake/usr/lib/polymake/perlx/5.38.2/x86_64-linux-gnu-thread-multi/auto/Polymake/Ext/Ext.so
 returned exit code 25
dh_shlibdeps: error: Aborting due to earlier error
make: *** [debian/rules:35: binary-arch] Error 25

Cheers
-- 
Sebastian Ramacher

Bug#1068139: miniflux: [L10N,DE] miniflux_2.1.1-1: german translation

[Christoph Brinkhaus]

Package: miniflux
Version: miniflux 2.1.2-1
Severity: wishlist
X-Debbugs-Cc: maytha8the...@gmail.com

Dear Maintainer,

please find attached the german translation of the miniflux_2.1.1-1 template.
Thank you for taking care of the package!

Kind regards,
Christoph Brinkhaus
# German translation of manpages
# This file is distributed under the same license as the miniflux package.
# Copyright © of this file:
# Christoph Brinkhaus , 2024.
#
msgid ""
msgstr ""
"Project-Id-Version: miniflux\n"
"Report-Msgid-Bugs-To: minif...@packages.debian.org\n"
"POT-Creation-Date: 2024-03-23 15:28+0800\n"
"PO-Revision-Date: 2024-03-29 16:30+0200\n"
"Last-Translator: Christoph Brinkhaus \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Would you like to create an admin account?"
msgstr "Möchten Sie ein Administratorkonto einrichten?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"By default, miniflux comes with no user accounts. You can choose to create "
"an administrator account for miniflux here, or do it manually afterwards "
"(see /usr/share/doc/miniflux/README.Debian)."
msgstr ""
"In der Voreinstellung hat miniflux keine Benutzerkonten. Sie können jetzt "
"ein Administratorkonto einrichten, oder Sie machen das später manuell "
"(siehe /usr/share/doc/miniflux/README.Debian)."

#. Type: string
#. Description
#: ../templates:2001
msgid "Username:"
msgstr "Benutzername:"

#. Type: string
#. Description
#: ../templates:2001
msgid "Username for the new admin account on miniflux."
msgstr "Benutzername für das neue Administratorkonto von miniflux."

#. Type: password
#. Description
#: ../templates:3001
msgid "Password:"
msgstr "Passwort:"

#. Type: password
#. Description
#: ../templates:3001
msgid "Password for the new admin account on miniflux."
msgstr "Passwort für das neue Administratorkonto von miniflux."

Bug#1068138: halide: FTBFS on amd64: 676 - python_correctness_atomics (Failed)

[Sebastian Ramacher]

Source: halide
Version: 17.0.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=halide=amd64=17.0.1-1%2Bb2=1711572233=0

The following tests FAILED:
676 - python_correctness_atomics (Failed)
677 - python_correctness_autodiff (Failed)
Errors while running CTest
make[2]: *** [debian/rules:118: perform_stage_build] Error 8

Cheers
-- 
Sebastian Ramacher

Bug#1068137: Please package newer upstream

[Yuri D'Elia]

Package: olive-editor
Version: 20221024+ds-1+b2
Severity: wishlist

It would be nice to have a more current snapshop of olive-editor.

I tried the packaged version, but I run in numerious audio sync issues
and other bugs that made it hard to actually use.

A current version from the appimage though has audio that works
correctly and most of the bugs I experienced look already fixed.

Since there are no stable/official releases, I don't see a reason to
rely on snapshot from 2022 and it would be nice to update.

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

Kernel: Linux 6.7.9-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.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 olive-editor depends on:
ii  ffmpeg7:6.1.1-3
ii  frei0r-plugins1.8.0-1+b2
ii  libavcodec-extra60 [libavcodec60] 7:6.1.1-3
ii  libavfilter9  7:6.1.1-3
ii  libavformat60 7:6.1.1-3
ii  libavutil58   7:6.1.1-3
ii  libc6 2.38-6
ii  libgcc-s1 14-20240315-1
ii  libopencolorio2.1t64 [libopencolorio2.1]  2.1.3+dfsg-1.1+b1
ii  libopenexr-3-1-30 3.1.5-5.1+b2
ii  libopenimageio2.4t64 [libopenimageio2.4]  2.4.17.0+dfsg-1.1+b1
ii  libportaudio2 19.6.0-1.2+b2
ii  libqt5core5t64 [libqt5core5a] 5.15.10+dfsg-7.2+b1
ii  libqt5dbus5t64 [libqt5dbus5]  5.15.10+dfsg-7.2+b1
ii  libqt5gui5t64 [libqt5gui5]5.15.10+dfsg-7.2+b1
ii  libqt5multimedia5-plugins 5.15.10-2+b2
ii  libqt5widgets5t64 [libqt5widgets5]5.15.10+dfsg-7.2+b1
ii  libstdc++614-20240315-1
ii  libswresample47:6.1.1-3
ii  libswscale7   7:6.1.1-3

olive-editor recommends no packages.

olive-editor suggests no packages.

Bug#1068124: exec-path-from-shell-el 2.1-1 FTBFS if network is unavailable

[Xiyue Deng]

"Brendan O'Dea"  writes:

> Package: exec-path-from-shell-el
> Version: 2.1-1
> Tags: patch
>
> The upstream Makefile attempts to run some sanity checks on the
> library, including running `package-lint`, which it attempts to
> download via `package.el`.  This fails when the build daemon does not
> have network access:
>
>  * 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/exec-path-from-shell-el.html
>  * 
> https://bugs.launchpad.net/ubuntu/+source/exec-path-from-shell-el/+bug/2034630
>
> Given that the Makefile doesn't actually do anything useful to anyone
> other than the upstream maintainer (package-lint, byte compile, remove
> byte compile output), the attached patch disables the build entirely.
>
> --bod
>
>

Thanks Brendan for filing the tracking bug!  I happened to be
investigating the same issue as well.  I initially intend to convert the
build process to use elpa-package-lint as a dependency, but it turned
out that package-lint stable releases might be broken for each Emacs
release and this happened for 29.3 as well.  Currently I'm discussing
this with upstream[1].  If that turns out to be in feasible, I'll
fallback to what you proposed.

Stay tuned.

-- 
Xiyue Deng

[1] https://github.com/purcell/package-lint/issues/269

Bug#1030150: freeplane fails to start with java 18 (openJDK 18) and openJDK 17.

[debian]

Hi Felix,

as Debian (and many derivates) still ship with old JDK, there is in my eyes no 
reason to remove
Freeplane because of that. Also it would be a shame if it maybe would vanish 
from it, in that way.

FTR: I am tunning OpenJDK 1.17.10 on Devuan, and Freeplane 1.7.0 runs fine 
(also still a 32bit
system)

Best,
Alex

Felix Natter  
am Sonntag, 31. März 2024, 17:11:02:

> Dear users,
> 
> you can download and install the .deb version that upstream provides:
> - https://sourceforge.net/projects/freeplane/
> - select "Files"
> - select "freeplane stable"
> - select freeplane_1.11.11~upstream-1_all.deb
> - install with "sudo apt install 
> /path/to/freeplane_1.11.11~upstream-1_all.deb"
> 
> (the file name of the stable version may change over time!)
> 
> Note this bug related to ibus:
> https://github.com/freeplane/freeplane/issues/1069
> 
> You can also, as the reporter noted, switch to an old JRE (mind security
> issues though!), either through JAVA_CMD or FREEPLANE_JAVA_HOME.
> 
> I cannot package freeplane-1.11.x for Debian because it requires
> gradle >= 7.x.
> 
> I am discussing with the debian-java team whether to remove freeplane
> from Debian/Ubuntu for security reasons (old JRE versions...), unless
> you disagree strongly [1]!
> 
> [1] https://lists.debian.org/debian-java/2024/03/msg00016.html
> 
> Cheers and Best Regards,
> Felix
> --
> Felix Natter
> 

Bug#1068136: Accepted golang-google-protobuf 1.33.0-1 (source) into unstable

[Reinhard Tartler]

Package: golang-google-protobuf
Version: 1.33.0-1

Hey Anthony,

I noticed that this upload breaks autopkgtest
for golang-github-golang-protobuf-1-5, cf.
https://tracker.debian.org/pkg/golang-google-protobuf

40s # github.com/golang/protobuf/protoc-gen-go/descriptor
682

40s src/
github.com/golang/protobuf/protoc-gen-go/descriptor/descriptor.pb.go:106:61:
undefined: descriptorpb.Default_FileOptions_PhpGenericServices
683

40s google.golang.org/protobuf/reflect/protodesc
684

do you know what's going on here?

This seems to block migration of quite a few other packages, including
security updates for buildah and libpod.

-rt



On Tue, Mar 26, 2024 at 8:21 PM Debian FTP Masters <
ftpmas...@ftp-master.debian.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Tue, 26 Mar 2024 17:49:06 -0600
> Source: golang-google-protobuf
> Architecture: source
> Version: 1.33.0-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Go Packaging Team 
> Changed-By: Anthony Fok 
> Closes: 1065684
> Changes:
>  golang-google-protobuf (1.33.0-1) unstable; urgency=medium
>  .
>* New upstream version 1.33.0
>  .
>  encoding/protojson, internal/encoding/json: handle missing object
> values
>  .
>  In internal/encoding/json, report an error when encountering a }
>  when we are expecting an object field value. For example, the input
>  `{"":}` now correctly results in an error at the closing } token.
>  .
>  In encoding/protojson, check for an unexpected EOF token in
>  skipJSONValue. This is redundant with the check in
> internal/encoding/json,
>  but adds a bit more defense against any other similar bugs that
>  might exist.
>  .
>  Fixes CVE-2024-24786 (Closes: #1065684)
>  .
>* DH_GOLANG_INSTALL_EXTRA: Update path to editions_defaults.binpb
>  which was moved from reflect/protodesc/ to internal/editiondefaults/
> Checksums-Sha1:
>  b4aaad31d00d1ab4eccdbf8624d3b7831a3ab61a 2381
> golang-google-protobuf_1.33.0-1.dsc
>  9673951a743296d76d1a474871c2443f7a449ffc 812348
> golang-google-protobuf_1.33.0.orig.tar.xz
>  5a249134d9e0c499bd70f8978155a5ccd2573eaf 4060
> golang-google-protobuf_1.33.0-1.debian.tar.xz
>  d65004dfe310321fe0bfacd5a7a9ff8f2bcf15bd 6838
> golang-google-protobuf_1.33.0-1_amd64.buildinfo
> Checksums-Sha256:
>  1274db27a31a56d97a94efd04ed288922bbe8dcc46cf2e805ced2cd423bb8a01 2381
> golang-google-protobuf_1.33.0-1.dsc
>  40d83211cdfc25e1c13c6de527b33516c21d6ef48188070ff22f29330abe4f84 812348
> golang-google-protobuf_1.33.0.orig.tar.xz
>  9469684733b7810b2a382ea2c0e801c4b0b4bd90bc41399e3a76d8760996ac03 4060
> golang-google-protobuf_1.33.0-1.debian.tar.xz
>  ce0906317aab1c72969211523151d466ac98416e798139c8a7eec0eacefb6aa7 6838
> golang-google-protobuf_1.33.0-1_amd64.buildinfo
> Files:
>  9f76d0ea63ae9eb01ff3917847cd8ebc 2381 golang optional
> golang-google-protobuf_1.33.0-1.dsc
>  e102870db4b3dfb32af3ee85f427acad 812348 golang optional
> golang-google-protobuf_1.33.0.orig.tar.xz
>  b7485bec7ce51cb4b820b7c0df1c3a6e 4060 golang optional
> golang-google-protobuf_1.33.0-1.debian.tar.xz
>  1e8b2ecc9959e7a38402e295616a05ef 6838 golang optional
> golang-google-protobuf_1.33.0-1_amd64.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQJEBAEBCAAuFiEEFCQhsZrUqVmW+VBy6iUAtBLFms8FAmYDYDAQHGZva2FAZGVi
> aWFuLm9yZwAKCRDqJQC0EsWazzzsD/sGWkFsY9HxvjV+I3uOVIJFVNXno5jjvq+K
> r4gn+iZeL6lXXZEUe5i0o+qBAoLdTCQ0e7LYnDLxQVrlWi7NgVvME75O0TjsMX3s
> F+eevszYhb0MKeXq0VFmBDv+ZHVQoVgsom/2QDzJ9G70M1FIYc4QjQ/cQZ3DtyLc
> SOf6J/520TdIIx4SC8ht54874GVxehBCSBk+ZRh4qnJc8OZfgg6qISEy3zhzov12
> AEPc7E2mmjZJwF16V9X6MMRJteEy4j4fTfEQ9GpQ+Gg9rnXwYSupuSINISQ8adiV
> t8K7NCy9SZh/SIkUjTXcHskobTlUmajpBzDfJvl/W/1+nnZKjcHfMq9JcS0T7pyf
> Nee3zubnjdIA9212hO27ygJcoQrPNsZ2yhLEn74NMY8W+z5u15qtqi6qlQ/xVcb3
> kwvOtzd3pIUcD+RbN4w1tKcD5ATW5Tlo2awt7DkKHOAtbXNf42N2/jlJbHWeMjgB
> wDHFH0lVs7mZQT16glt8cvSZPjJyqPKzeVfAR2rnkBz162qjNLndeycyyGGXS9Wd
> gWvu/Yk3VJyf8N5g8Qb+EVJQxX6XPXSaWWMaxaSaJ8PBVW1V2+hPEuseuLY0sZHV
> 4kk0e4GtlzbMRDuDTm3Yq4XWVFiwLbtl4kw07u0QpHW9vRmLwClnDa0REJ4aGtih
> idTusSuIxg==
> =Ph/5
> -END PGP SIGNATURE-
>
>

-- 
regards,
Reinhard

Bug#1055599: dh_installsystemd tries to start static unit which deb-systemd-invoke rejects

[Niels Thykier]

Hi Michael and Luca

Is this a bug you have an opinion on?

Best regards,
Niels

Daniel Carpenter:

Package: debhelper
Version: 13.11.4

If I include this static (i.e. no [Install] section) systemd service:

# debian/debhelper-example.service
[Service]
Type=oneshot
ExecStart=true

then dh_installsystemd will insert this snippet in postinst:

if [ -n "$2" ]; then
 _dh_action=restart
else
 _dh_action=start
fi
deb-systemd-invoke $_dh_action 'debhelper-example.service' >/dev/null ||
true

When I install the package, deb-systemd-invoke issues a warning:

debhelper-example.service is a disabled or a static unit, not starting it.

Indeed, such a unit should not be started on package installation (but
rather by a path, socket or timer unit). I notice that dh_installsystemd
produces another snippet which enables the unit if it contains an [Install]
section. I think both snippets should be omitted for static units.

On upgrades, the restart part makes more sense, but for type=oneshot I
think that's only relevant if RemainAfterExit=true.

As a workaround, I can write:

override_dh_installsystemd:
 dh_installsystemd --no-start

in debian/rules, but that prevents any units from being started, not just
the static ones. I assume you have to list the static units with
--no-start, and the others without it, but that's more error prone than
letting debhelper handle it.

Bug#1067785: pipx : modifies the wrong zsh init files.

[Stefano Rivera]

Control: reassign -1 python3-userpath
Control: found -1 python3-userpath/1.9.1-1
Control: affects -1 pipx
Control: tag -1 + upstream

Hi Erwan (2024.03.26_14:55:30_-0400)

Thanks for the bug report.

This sounds like an upstream bug in userpath.
Would you mind filing it there? I'm not a zsh user, so I can't advocate
for correct zsh configuration as well as you can.

https://github.com/ofek/userpath/issues

The relevant line is:
https://github.com/ofek/userpath/blob/981085be7669815a186420e1211ed9944ab928ba/userpath/shells.py#L98

Stefano

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

Bug#1068135: gtk-sharp3: arch:all package depends on pre-t64 library

[Sebastian Ramacher]

Source: gtk-sharp3
Version: 2.99.3-4.1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

gtk-sharp3 builds an Architecture: all packages depending on a  


library package involved in the time_t 64 transition. This dependency   

   
needs to be updated. 

Cheers
-- 
Sebastian Ramacher

Bug#1068134: globus-gram-job-manager-scripts: arch:all package depends on pre-t64 library

[Sebastian Ramacher]

Source: globus-gram-job-manager-scripts
Version: 7.3-2
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

globus-gram-job-manager-scripts builds an Architecture: all packages
depending on a library package involved in the time_t 64 transition.
This dependency needs to be updated. 

Cheers
-- 
Sebastian Ramacher

Bug#1068133: globus-gram-audit: arch:all package depends on pre-t64 library

[Sebastian Ramacher]

Source: globus-gram-audit
Version: 5.1-3
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

globus-gram-audit builds an Architecture: all packages depending on a
library package involved in the time_t 64 transition. This dependency
needs to be updated.

Cheers
-- 
Sebastian Ramacher

Bug#1068130: xdg-desktop-portal-gnome cause slow start up time in some application

[Gaston Gonzalez]

On Sun, Mar 31, 2024 at 10:35:04AM -0400, Jeremy Bícha wrote:
> On Sun, Mar 31, 2024 at 10:31 AM Gaston Gonzalez  wrote:
> > On Sun, Mar 31, 2024 at 10:11:37AM -0400, Jeremy Bícha wrote:
> > > Which desktop are you using?
> >
> > Budgie desktop (10.8.2-3)
> 
> If you don't use GNOME, you don't need xdg-desktop-portal-gnome
> installed. xdg-desktop-portal-gtk is probably fine until the Budgie
> developers create their own portal backend.
>

Yes, I just became aware of it after the upgrade and this issue got
triggered.

If any test or info is needed, please let me know.

thank you,

Gaston

> Thank you,
> Jeremy Bícha

Bug#1068122: My thoughts on the possible problem

[Antti-Pekka Känsälä]

Sorry for the amount of text that follows:

MY MONOLOGUE ON FACEBOOK 30.-31.3.2024

Antti-Pekka Känsälä
antti.pekka.kans...@iki.fi

If it's not in Debian, but it's because of my activity, I'm somewhat
out of ideas.

Out of ideas concerning my own data security.

In that case, I better move on, and focus on something else.

(The problem has persisted for some time. I have quietly assumed
my machine has been breached, by legal (not to say legitimate) means
(in short, I've been under the "official eye"), that the Debian
project has been forced to comply to, or by means that are beyond
software. Thus my helplessness continues.)

Frequent reinstallations of the system clearly won't help, I have
tried that.

Is it possible, that I have bogus installation media, and
cryptographical verification fails in my case?

Just my thoughts.

I think this is the second time I'm in this kind of despair with
Debian. However, I know of no other way to use a computer,
that would come even close in quality for my needs. Thanks.

The GNU/Linux Debian distribution of Linux is the basis for most
other distributions. It affects the entire digital world, that
it works correctly. Their security team I believe includes the best.
I think they have a public disclosure policy, once they discover
a problem. If there is a problem here, I may never even find out
where it was, but it will be fixed, by the best.

You should use Debian too.

The USB stick problem is not the only symptom. The other is
complete lockups, that may well be just because of old hardware.
However, if the system is breached, the lockups could be intentional.
The problem could be somewhere completely elsewhere from USB sticks,
it's just that someone's playing interested in my sticks on
a breached system.

Haha... So it's ok, if it's just the corrupted officials monitoring
me, so long as the problem is not in Debian, God forbid!

It's quite the system. No systems limps on quite as well, even when
completely breached...

Things sure happen fast, when a computer most likely is breached.
Nearly all of the attack tools targeted at my machine must be fully
automated.

Not much use being even the best sysadmin on a breached machine,
it's people elsewhere who investigate.

Why would Gmail running in Firefox be interested in 128 files
on my USB stick, in addition to the 1 that I have just uploaded
as an e-mail attachment? Good question.

Because they are not, but running Gmail in Firefox reveals
something about how the system is compromised.

There was news just today, I think, of a major backdoor problem,
that was discovered. They suspect it was definitely by a
governmental level actor. What is happening on my machine could
be a consequence of the backdoor problem, but I'm just one
of the God knows how many affected, and my case may or may not
be relevant at all to figuring out what else has become corrupted.

What is worrisome however, is that this seems to be happening
on several versions of recently, freshly-reinstalled Debian
stable. I saw someone writing that "no version of Debian stable
is known to be affected", but this could change.

I got some very professional help, quickly, from the debian-user
mailing list. Being worried about USB stick security must be
well-known. I have been aware of the "lsof" command before,
to display open files, and I think I may have even tried it to
investigate this problem, but have given up, for the reason
that there's not really anything I can do if my activity
is just being "legally" monitored by officials.

I'm really annoyed by what I gather, that the Debian project
is legally obliged to allow such official monitoring. On the
other hand, the situation is no different from phones, which
the police (at least) can tap.

My understanding is, that Debian is close to a system, that
not even the authorities would be able to monitor, were it not
for their "legal" intervention in the system's development.

I do feel a bit digitally raped here.

With Windows it would be constantly in bed with Bill Gates?

With Apple... Well.

You hear of Windows computers getting slow with age? Well,
I got alarmed when on Linux an action started to take
two seconds on this old machine!

You just kind of have to settle with something, that you assume
is a noticeable tap on your system, from month to month,
by the officials, legally?

The backdoor I mentioned has been fixed now, and possibly
did not affect my suspected problem. I have some ideas though,
why Gmail "might" be interested in USB sticks... Enough so
to break out of Firefox?

In that case, what I'm experiencing could just be a minor
problem. Maybe just in Firefox, but is it really being
exploited by our honest friend Google?!

I have nowhere near complete evidence, under which conditions
can the system try to steal files off my USB sticks.

I just know I can't use USB sticks securely here.

To some people, that might sound surprising, if you read what
they say about malware, etc., and warn about unknown 

Bug#1068132: O: cciss-vol-status -- HP SmartArray RAID Volume Status Checker

[Chris Hofstaedtler]

Package: wnpp
Severity: normal
X-Debbugs-Cc: cciss-vol-sta...@packages.debian.org
Control: affects -1 + src:cciss-vol-status

I intend to orphan the cciss-vol-status package.

I no longer have hardware to use with this package. Upstream might also
be abandoned.

The package description is:
 A RAID monitor for HP SmartArray Controllers, as supported by the "cciss",
 "hpsa", "hpahcisr" kernel drivers.
 It will check for problems on your configured logical drives, without relying
 on the controller's event log.
 .
 It also supports MSA500 and MSA1000 controllers.

Bug#1030150: freeplane fails to start with java 18 (openJDK 18) and openJDK 17.

[Felix Natter]

Dear users,

you can download and install the .deb version that upstream provides:
- https://sourceforge.net/projects/freeplane/
- select "Files"
- select "freeplane stable"
- select freeplane_1.11.11~upstream-1_all.deb
- install with "sudo apt install /path/to/freeplane_1.11.11~upstream-1_all.deb"

(the file name of the stable version may change over time!)

Note this bug related to ibus:
https://github.com/freeplane/freeplane/issues/1069

You can also, as the reporter noted, switch to an old JRE (mind security
issues though!), either through JAVA_CMD or FREEPLANE_JAVA_HOME.

I cannot package freeplane-1.11.x for Debian because it requires
gradle >= 7.x.

I am discussing with the debian-java team whether to remove freeplane
from Debian/Ubuntu for security reasons (old JRE versions...), unless
you disagree strongly [1]!

[1] https://lists.debian.org/debian-java/2024/03/msg00016.html

Cheers and Best Regards,
Felix
--
Felix Natter

Bug#1068131: ITP: bootterm -- simple terminal to ease connections with SBCs

[Faidon Liambotis]

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

* Package name: bootterm
  Version : 0.4+git2023013
  Upstream Contact: Willy Tarreau 
* URL : https://github.com/wtarreau/bootterm
* License : Expat
  Programming Lang: C
  Description : simple terminal to ease connections with SBCs

Bootterm is a simple, reliable and powerful terminal designed to ease
connection to ephemeral serial ports as found on various SBCs, and typically
USB-based ones.
.
Main features:
 * automatic port detection (uses the most recently registered one by default)
 * enumeration of available ports with detected drivers and descriptions
 * wait for a specific, a new, or any port to appear (convenient with USB
   ports)
 * support for non-standard baud rates (e.g. 74880 bauds for ESP8266)
 * can send a Break sequence and toggling RTS/DTR for various reset sequences,
   even on startup
 * fixed/timed captures to files (may be enabled at run time)
 * optionally time-stamped captures (relative/absolute dates)
 * reliable with proper error handling
 * single binary without annoying dependencies, builds out of the box
 * supports stdin/stdout to inject/download data
 * configurable escape character and visible character ranges

Note that upstream has chosen /usr/bin/bt for the binary's name, but I'm
trying to persuade them to use /usr/bin/bootterm instead, in order to
avoid taking up a two-letter name in Debian's shared $PATH namespace,
for what is intended to be a binary for a niche audience. At minimum I'd
expect us to carry a Debian-specific patch.

Bug#1068130: xdg-desktop-portal-gnome cause slow start up time in some application

[Jeremy Bícha]

On Sun, Mar 31, 2024 at 10:31 AM Gaston Gonzalez  wrote:
> On Sun, Mar 31, 2024 at 10:11:37AM -0400, Jeremy Bícha wrote:
> > Which desktop are you using?
>
> Budgie desktop (10.8.2-3)

If you don't use GNOME, you don't need xdg-desktop-portal-gnome
installed. xdg-desktop-portal-gtk is probably fine until the Budgie
developers create their own portal backend.

Thank you,
Jeremy Bícha

Bug#819342: More brokenness in date(1) around DST

[Andras Korn]

Hi,

my timezone is CEST; we switched from CET today.

% TZ=Europe/Budapest LC_TIME=C date --date 'tomorrow 2:30'
date: invalid date ‘tomorrow 2:30’

2:30 would be invalid today (2:00am became 3:00am), but it exists tomorrow, and 
date(1) can print that date if I request it in a different way:

% TZ=Europe/Budapest LC_TIME=C date --date 'now+10 hours+30 minutes'
Mon Apr  1 02:30:51 CEST 2024

This also works:

% TZ=Europe/Budapest LC_TIME=C date --date @1711931400
Mon Apr  1 02:30:00 CEST 2024

Best regards,

András

-- 
To shoot a mime, do you use a silencer?

Bug#1068130: xdg-desktop-portal-gnome cause slow start up time in some application

[Gaston Gonzalez]

Hi Jeremy,

On Sun, Mar 31, 2024 at 10:11:37AM -0400, Jeremy Bícha wrote:
> On Sun, Mar 31, 2024 at 9:57 AM Gaston Gonzalez  wrote:
> > After some digging, it seems that the issue is related to the
> > applications using xdg-desktop-portal-gnome. After uninstalling it, the
> > problem is solved.
> 
> Which desktop are you using?

Budgie desktop (10.8.2-3)

> 
> xdg-desktop-portal-gnome is the preferred portal backend for GNOME and
> you need a portal backend installed.
> 
> There are important improvements we need in xdg-desktop-portal-gnome
> 46 but this is blocked on getting GNOME Shell 46 into Unstable (and
> Testing) which we expect to happen soon after the 32-bit time_t
> transition is resolved.
> 
> Thank you,
> Jeremy Bícha

thanks !

Gaston

Bug#1068130: xdg-desktop-portal-gnome cause slow start up time in some application

[Jeremy Bícha]

On Sun, Mar 31, 2024 at 9:57 AM Gaston Gonzalez  wrote:
> After some digging, it seems that the issue is related to the
> applications using xdg-desktop-portal-gnome. After uninstalling it, the
> problem is solved.

Which desktop are you using?

xdg-desktop-portal-gnome is the preferred portal backend for GNOME and
you need a portal backend installed.

There are important improvements we need in xdg-desktop-portal-gnome
46 but this is blocked on getting GNOME Shell 46 into Unstable (and
Testing) which we expect to happen soon after the 32-bit time_t
transition is resolved.

Thank you,
Jeremy Bícha

Bug#1068130: xdg-desktop-portal-gnome cause slow start up time in some application

[Gaston Gonzalez]

Package: xdg-desktop-portal-gnome
Version: 44.2-4
Severity: normal

After upgrading from Bookworm to testing some applications are taking
too long to launch. This happens in applications such as evince, eog,
thunderbird.

The delay comes from a timeout during the program start-up.

For instance, evince seems to timeout in the poll line:

futex(0x55f4aef70878, FUTEX_WAKE_PRIVATE, 1) = 1
eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK)   = 10
write(7, "\1\0\0\0\0\0\0\0", 8) = 8
futex(0x55f4aef764f0, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=10, events=POLLIN}], 1, 25000)

Other programs like xpdf or ristretto do not show the same behaviour.

After some digging, it seems that the issue is related to the
applications using xdg-desktop-portal-gnome. After uninstalling it, the
problem is solved.

I am using Debian testing, kernel 6.7.0.

Bug#1067660: wireplumber: Wireplumber 0.5.0 breaks asahi-audio 1.x

[Andreas Henriksson]

Control: fixed -1 1.7-2

On Mon, Mar 25, 2024 at 10:13:57AM +0100, Dylan Aïssi wrote:
> Control: reassign -1 asahi-audio
> Control: notfound -1 0.4.17-1
> Control: found -1 1.7-1
    why this version? Every asahi-audio version ever
   uploaded to the archive is only compatible with
   wireplumber << 0.5.0.
> Control: affects -1 wireplumber
> 
> Hello,
> Thanks for this bug report, I reassign it to asahi-audio since the versioned
> dependency is on it and not on wireplumber.
[...]

Hmm... wireplumber was the one who changed the configuration language
and thus broke everything using the existing config language. I thus
think it should declare Breaks against everything shipping old config
language files (as well as warn users via debian/NEWS about needing
to manually fix custom config).

FWIW I've just uploaded asahi-audio 1.7-2 with "wireplumber (<< 0.5.0)".
We'll make sure to upload asahi-audio 2.x (with
"wireplumber (>= 0.5.0)") to EXPERIMENTAL as soon as an upstream release
is available.

PLEASE NOTIFY US WHEN YOU UPLOAD wireplumber 0.5.x to UNSTABLE, so we
can do a coordinated transition (uploading asahi-audio 2.x to unstable).
(You might also want to contact release-team to set up a transition
tracker, even if this might not be a normal transition where binNMUs are
useful etc.)

For the future, if you still think it's asahi-audio which should have
strict dependencies on wireplumber - please help figure out which
version we should put in (<< x.y.z) for future breakage. How long does
wireplumber intend to keep compatibility with 0.5.0 config language (or
make other breaking/incompatible changes)?

Regards,
Andreas Henriksson

Bug#1068129: RFP: redict -- Distributed key/value store - forked from Redis

[Federico Ceratto]

Package: wnpp
Severity: wishlist

* Package name: redict
  Version : TBD
  Upstream Contact: 2024 Salvatore Sanfilippo
* URL : https://redict.io/
* License : LGPL
  Programming Lang: C
  Description : Distributed key/value store

Distributed key/value store started as a fork of Redis

Can be useful as a replacement for Redis due to changes in Redis licensing

Bug#1067238: Add support for man preprocessors, like tbl

[Faidon Liambotis]

On Sun, Mar 31, 2024 at 06:52:23PM +1100, Brendan O'Dea wrote:
> > help2man does not output any tables by default (AIUI) but in case one
> > adds text e.g. in their DESCRIPTION that includes tables, it won't work.
> 
> help2man is intended to take `--help` output and massage it into a
> manual page.  The `--help` output still needs to be readable however,
> since people do invoke `foo --help` from the command line.  One option
> would be to have help2man recognize markdown-format tables, which
> would preserve the property of the `--help` output being readable.  A
> simpler option would be to add the table to an include file:
> https://www.gnu.org/software/help2man/#Including-text

Sorry I probably wasn't clear: that's exactly what I meant. I added a
table in the DESCRIPTION through --include and a [DESCRIPTION] section,
that includes a table.

> > While my issue is specific to the "tbl" preprocessor, man(1) supports
> > other preprocessors, including eqn (e), grap (g), pic (p), tbl (t),
> > vgrind (v), refer (r). See the `-p` argument. Perhaps help2man should
> > just gain an argument to support adding arbitrary preprocessors to its
> > output?
> 
> I will look into that.

#1049968 may also be useful context, in particular G. Branden Robinson's
comments.

Thanks,
Faidon

Bug#1066964: ITA: newlib -- C library and math library for embedded systems

[Petter Reinholdtsen]

[Petter Reinholdtsen]
> I suspect so, but not sure how.  I doubt I have more privileges than you
> in this regard, but could give it a try if you want me to.

I believe I found the correct locatoin in
https://salsa.debian.org/debian/newlib/edit>, where a new path for
the project can be specified.  I did not test it yet.  Do you want to
move it, or should I give it a try?

-- 
Happy hacking
Petter Reinholdtsen

Bug#1060407: gtkwave update for {bookworm,bullseye,buster}-security

[Moritz Mühlenhoff]

Hi Adrian,

> attached are proposed debdiffs for updating gtkwave to 3.3.118 in
> {bookworm,bullseye,buster}-security for review for a DSA
> (and as preview for buster).

Thanks!

> General notes:
> 
> I checked a handful CVEs, and they were also present in buster.
> If anyone insists that I check for every single CVE whether it is also
> in buster I can do that, but that would be a lot of work.

Nah, no need.

> As mentioned in #1060407 there are different tarballs for GTK 2 and GTK 3.
> Looking closer I realized that this is actually one tarball that 
> supports GTK 1+2, and one tarball that supports GTK 2+3.
> I did stay at the GTK 1+2 tarball that was already used before 
> for bullseye and buster since there was anyway a different upstream 
> tarball required for the +really version that is required to avoid 
> creating file conflicts with ghwdump when upgrading to bookworm.
> 
> What does the security team consider the best versioning for bullseye?
> In #1060407 I suggested 3.3.104+really3.3.118-0.1, but now I ended up
> preferring 3.3.104+really3.3.118-0+deb11u1

That's fine.

> debdiffs contain only changes to debian/

The bookworm/bullseye debdiffs looks good, please upload to security-master, 
thanks!

Note that both need -sa, but dak needs some special attention when
uploading to security-master. You'll need to wait for the ACCEPTED mail
before you can upload the next one.

Cheers,
Moritz

Bug#1039701: [Pkg-electronics-devel] Bug#1039701: libsigrok4: Built-in driver list is empty when compiled with LTO

[Victor Westerhuis]

On Sun, 31 Mar 2024 11:42:33 +0100 Jonathan McDowell  wrote:
> Version: 0.5.2-5
> 
> This was included in the 0.5.2-5 upload, but the MR didn't update the
> changelog so we missed closing out this bug.
My apologies. I usually use gbp-dch when releasing, so I didn't think to 
include a line in d/changelog.  
> 
> On Wed, Jun 28, 2023 at 01:40:32PM +0200, Victor Westerhuis wrote:
> > Package: libsigrok4
> > Version: 0.5.2-4
> > Severity: normal
> > Tags: patch upstream
> > 
> > This bug only shows up when libsigrok is compiled with LTO and was reported 
> > (https://sigrok.org/bugzilla/show_bug.cgi?id=1433) and fixed 
> > (http://sigrok.org/gitweb/?p=libsigrok.git;a=commit;h=da5286bfa5d2dad1e24b9c9442c9875332d84e64)
> >  upstream. 
> > 
> > I have opened a MR on 
> > https://salsa.debian.org/electronics-team/sigrok/libsigrok/-/merge_requests/3.
> 
> J.
> 
> -- 
> /-\ |  Does Barry Manilow know you raid
> |@/  Debian GNU/Linux Developer |his wardrobe?
> \-  |
> 
> 

Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

[Dirk Eddelbuettel]

Julian,

Arrow is a complicated and large package. We use it at work (where there is a
fair amount of Python, also to Conda etc) and do have issues with more
complex builds especially because it is 'data infrastructure' and can come in
from different parts. I would recommend against packaging at old one -- we
also have seen issues with different (py)arrow version biting.

Have you seen https://github.com/apache/arrow-nanoarrow ?

It works via the C API to Arrow which interchanges data via two void* to the
the two structs for arrow array and schema -- and avoids linkage issue. (In
user space the pyarrow or R arrow packages can still be used also interfacing
via these.)  I have been using it for R package bindings for some time and we
plan to expand that (again, at work) -- as do others. It is already use by
duckdb, by the Arrow 'ADBC' interfaces (which are generic in the ODBC/JDBC
sense but for Arrow, and also by a python interface to snowflake.

Dirk

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

Bug#1068128: nmu: opencolorio_2.1.3+dfsg-1.1

[Andrey Rakhmatullin]

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

nmu opencolorio_2.1.3+dfsg-1.1 . armel armhf . unstable . -m "Rebuild on
buildds"

Bug#1065445: pristine-tar: fails if upstream tarball top directory name is capitalised

[Julian Gilbey]

severity 1065445 important
thanks

On Tue, Mar 05, 2024 at 05:08:27PM +, Julian Gilbey wrote:
> [...]
> 
> I have reported this as a severity "important" bug because it may
> silently (or not so silently) affect many packages.

Well, I thought I'd reported this as "important", but it seems I
forgot to actually do so.  Raising the severity now.

Best wishes,

   Julian

Bug#1063678: libmrss0: Memory leak while parsing an RSS2 feed

[Mikhail Kot]

Good day!

I can confirm that the bug is fixed in upstream, thanks.
Unfortunately, neither on Debian packages https://tracker.debian.org/pkg/libmrss
nor on Ubuntu packages https://packages.ubuntu.com/noble/libmrss0
I can't see the updated version. The one present (0.19.2-7) still contains a 
bug.

--
Mikhail :з

Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

[Julian Gilbey]

Hi Diane,

On Sat, Mar 30, 2024 at 08:59:39PM -0700, Diane Trout wrote:
> Hi Julian,
> 
> On Sat, 2024-03-30 at 20:22 +, Julian Gilbey wrote:
> > Lovely to hear from you, and oh wow, that's amazing, thank you!
> > 
> > I can't speak for anyone else, but I suggest that pushing your
> > updates
> > to the science-team package would be very sensible; it would be silly
> > for someone else to have to redo your work.
> > 
> > What more is needed for it to be ready for unstable?
> 
> 
> The things I think are kind of broken are:
> 
> We've got 7.0.0 and upstreams current version is 15.0.2.

Yes, that does seem a little less than ideal!

> the pyarrow 7.0.0 tests fail because it depends on a python test
> library that breaks with pytest 8.0. Either I need to disable the
> python tests or upgrade to a newer version.

It may well be that newer versions would work with pytest 8.x.  I
don't think it's worth spending time trying to patch such a relatively
old version.

> My upgrade didn't go smoothly because uscan found also upstreams debian
> watch file which is too loose and matches some other tar balls on their
> distribution site.
> 
> (Though I don't know why uscan keeps looking for watch files after
> finding one in debian/watch)

Oh dear.  uscan(1) does say:

   Unless --watchfile is given, uscan looks recursively for valid source
   trees starting from the current directory (see the below section
   "Directory name checking" for details).

and then:

   For each valid source tree found, typically the following happens:
   [...]

so yes, it will look at more than one location.

> And you were probably right in that arrow needs to be a team, because I
> have no idea how to get other the other languages interfaces packaged.

I suggest that without anyone else volunteering to do those other
language interfaces (perhaps it's not a pressing need for people
working with language X), I wonder whether it's worth just packaging
the Python (and presumably C++) interfaces for now, and then if others
want to join the effort to support language X later on, a new version
of the Debian package can be uploaded with a new binary package for
language X.  It does mean more trips through the NEW queue if and when
that happens, but given that no-one's shown interest in language X for
the last several years, this is unlikely to be much of an issue.

Version 7.0 provided support (it seems) for: GLib (seems that a draft
framework for building this is already in the Debian package, and it
can then be used in lots of languages), C++ (this is the core
libraries), C# (not of interest to us), Go, Java, JavaScript, Julia,
Matlab (not of interest to us), Python, R, Ruby.

> Oh and I probably need to get the pyarrow installed somewhere, since it
> was stopping at the tests I hadn't run into dh_missing errors yet.

Oh.  Would pybuild do that automatically (perhaps specifying
PYBUILD_PACKAGE)?

Best wishes,

   Julian

Bug#1068127: plasma-desktop: Plantage répétitif de Plasma au démarrage qui finit par se stabiliser

[mickey]

Package: plasma-desktop
Version: 4:5.27.5-2
Severity: important
X-Debbugs-Cc: mickael...@yahoo.fr

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: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages plasma-desktop depends on:
ii  accountsservice  22.08.8-6
ii  breeze   4:5.27.5-2
ii  kactivitymanagerd5.27.5-2
ii  kde-cli-tools4:5.27.5.1-2
ii  kded55.103.0-1
ii  kio  5.103.0-1
ii  kpackagetool55.103.0-1
ii  layer-shell-qt   5.27.5-2
ii  libaccounts-qt5-11.16-2
ii  libc62.36-9+deb12u4
ii  libglib2.0-0 2.74.6-2
ii  libibus-1.0-51.5.27-5
ii  libkaccounts24:22.12.3-1
ii  libkf5activities55.103.0-1
ii  libkf5activitiesstats1   5.103.0-1
ii  libkf5authcore5  5.103.0-1
ii  libkf5baloo5 5.103.0-2
ii  libkf5bookmarks5 5.103.0-1
ii  libkf5codecs55.103.0-1
ii  libkf5completion55.103.0-1
ii  libkf5configcore55.103.0-2
ii  libkf5configgui5 5.103.0-2
ii  libkf5configwidgets5 5.103.0-1
ii  libkf5coreaddons55.103.0-1
ii  libkf5crash5 5.103.0-1
ii  libkf5dbusaddons55.103.0-1
ii  libkf5globalaccel-bin5.103.0-1
ii  libkf5globalaccel5   5.103.0-1
ii  libkf5guiaddons5 5.103.0-1
ii  libkf5i18n5  5.103.0-1
ii  libkf5iconthemes55.103.0-1
ii  libkf5itemviews5 5.103.0-1
ii  libkf5jobwidgets55.103.0-1
ii  libkf5kcmutils5  5.103.0-3
ii  libkf5kcmutilscore5  5.103.0-3
ii  libkf5kdelibs4support5   5.103.0-1
ii  libkf5kiocore5   5.103.0-1
ii  libkf5kiofilewidgets55.103.0-1
ii  libkf5kiogui55.103.0-1
ii  libkf5kiowidgets55.103.0-1
ii  libkf5newstuffcore5  5.103.0-1
ii  libkf5notifications5 5.103.0-1
ii  libkf5notifyconfig5  5.103.0-1
ii  libkf5package5   5.103.0-1
ii  libkf5plasma55.103.0-1+deb12u1
ii  libkf5plasmaquick5   5.103.0-1+deb12u1
ii  libkf5quickaddons5   5.103.0-1
ii  libkf5runner55.103.0-1
ii  libkf5service-bin5.103.0-1
ii  libkf5service5   5.103.0-1
ii  libkf5solid5 5.103.0-1
ii  libkf5sonnetcore55.103.0-1
ii  libkf5sonnetui5  5.103.0-1
ii  libkf5widgetsaddons5 5.103.0-1
ii  libkf5windowsystem5  5.103.0-1
ii  libkf5xmlgui55.103.0-1
ii  libkworkspace5-5 4:5.27.5-2+deb12u1
ii  libnotificationmanager1  4:5.27.5-2+deb12u1
ii  libpackagekitqt5-1   1.1.1-1
ii  libphonon4qt5-4  4:4.11.1-4
ii  libprocesscore9  4:5.27.5-2
ii  libqt5concurrent55.15.8+dfsg-11
ii  libqt5core5a 5.15.8+dfsg-11
ii  libqt5dbus5  5.15.8+dfsg-11
ii  libqt5gui5   5.15.8+dfsg-11
ii  libqt5network5   5.15.8+dfsg-11
ii  libqt5qml5   5.15.8+dfsg-3
ii  libqt5quick5 5.15.8+dfsg-3
ii  libqt5quickwidgets5  5.15.8+dfsg-3
ii  libqt5sql5   5.15.8+dfsg-11
ii  libqt5waylandclient5 5.15.8-2
ii  libqt5widgets5   5.15.8+dfsg-11
ii  

Bug#1068126: firefox: No video, no codecs found

[Eduard Bloch]

Package: firefox
Version: 124.0.1-1
Severity: important

Dear Maintainer,

   * What led up to the situation?

Last week's dist-upgrade, including ffmpeg and libavcodec and related
libs.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?

Observed that ALL video playback (with HTML5 tech) ceased to work,
either no video starting at all or some error report, depending on the
page. YT can generate a debug report, I could add it but there is not
much to see, the main info is:

  "debug_error": "{\"errorCode\":\"html5.missingapi\",\"errorMessage\":\"This 
video format is not 
supported.\",\"SN\":\"HTML5_NO_AVAILABLE_FORMATS_FALLBACK\",\"yn\":\"\",\"wK\":\"nocodecs.1;a6s.0\"

 - next experiment: try firefox-esr. Result: no problem there, videos do work 
as usual

 - next experiment: download the upstream build and unpack it. Result: works as 
supposed. Also tried the 125-beta, also works there

 - next experiments: reinstall ffmpeg, reinstall libavcodec60, also
   tried libavcode-extra60, restarting firefox inbetween. Does not cure
   the problem, remains broken.
 
 - next experiment: did a strace on firefox, checking for libav... and
   yes, it loads the latest versions of that libs. And remains broken.

 - next experiment: double-checking the ArchLinux guide,
   https://wiki.archlinux.org/title/Firefox section 4.2.3. Tried setting
   and unsetting (to defaults) of those variables, and restarting. Did
   not change a thing, remains broken. Also tried removing the profile
   and starting with fresh settings, and even that remains broken (unlike
   with upstream build or ESR version in the same situation).

 - more digging: tried to observe error output. It prints something to
   STDERR but that isn't helpful. vainfo... lines are the same as from
   players like vlc, the other errors: no idea, maybe this is the
   culprit?
 
 - more digging: tried to generate debug output, like:
   MOZ_LOG_FILE=/tmp/upstream_log MOZ_LOG="FFmpegVideo:5" ./firefox
   That works just fine, those files (with ...child-number... extension)
   are created and in the one for the playback window, I can find lots
   of sensible codec log printing.

   BUT: when I do the same with our version, that also creates log files
   but they have zero size, nothing is even printed into them.

   So, is this maybe some internal failure in our build, which aborts
   the video engine loading early on without telling the user?

   * What outcome did you expect instead?

A non-broken Debian package, at least SOME useful MOZ_LOG information in
case when someone tries to debug issues.

strace:

112061 openat(AT_FDCWD, "/usr/lib/firefox/libavcodec.so.60", O_RDONLY|O_CLOEXEC 

112061 sendmsg(22, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="\0\0\0\0\0\0\10\0\0\0\0\0\0\0\0\0", iov_len=16}, 
{iov_base="/usr/lib/firefox/libavcodec.so.6"..., iov_len=34}, {iov_base=NULL, 
iov_len=0}], msg_iovlen=3, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, 
cmsg_type=SCM_RIGHTS, cmsg_data=[21]}], msg_controllen=24, msg_flags=0}, 
MSG_NOSIGNAL 
112064 <... recvmsg resumed>{msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="\0\0\0\0\0\0\10\0\0\0\0\0\0\0\0\0", iov_len=16}, 
{iov_base="/usr/lib/firefox/libavcodec.so.6"..., iov_len=8194}], msg_iovlen=2, 
msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, 
cmsg_data=[112]}], msg_controllen=24, msg_flags=MSG_CMSG_CLOEXEC}, 
MSG_CMSG_CLOEXEC) = 50
112064 openat(AT_FDCWD, "/usr/lib/firefox/libavcodec.so.60", 
O_RDONLY|O_NOCTTY|O_CLOEXEC 
112061 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libavcodec.so.60", 
O_RDONLY|O_CLOEXEC 
112061 sendmsg(22, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="\0\0\0\0\0\0\10\0\0\0\0\0\0\0\0\0", iov_len=16}, 
{iov_base="/lib/x86_64-linux-gnu/libavcodec"..., iov_len=39}, {iov_base=NULL, 
iov_len=0}], msg_iovlen=3, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, 
cmsg_type=SCM_RIGHTS, cmsg_data=[21]}], msg_controllen=24, msg_flags=0}, 
MSG_NOSIGNAL 
112064 <... recvmsg resumed>{msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="\0\0\0\0\0\0\10\0\0\0\0\0\0\0\0\0", iov_len=16}, 
{iov_base="/lib/x86_64-linux-gnu/libavcodec"..., iov_len=8194}], msg_iovlen=2, 
msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, 
cmsg_data=[112]}], msg_controllen=24, msg_flags=MSG_CMSG_CLOEXEC}, 
MSG_CMSG_CLOEXEC) = 55
112064 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libavcodec.so.60", 
O_RDONLY|O_NOCTTY|O_CLOEXEC 
112061 openat(AT_FDCWD, "/usr/lib/firefox/libavutil.so.58", O_RDONLY|O_CLOEXEC 

112061 sendmsg(22, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="\0\0\0\0\0\0\10\0\0\0\0\0\0\0\0\0", iov_len=16}, 
{iov_base="/usr/lib/firefox/libavutil.so.58"..., iov_len=33}, {iov_base=NULL, 
iov_len=0}], msg_iovlen=3, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, 
cmsg_type=SCM_RIGHTS, cmsg_data=[21]}], msg_controllen=24, msg_flags=0}, 
MSG_NOSIGNAL 
112064 <... recvmsg resumed>{msg_name=NULL, 

Bug#1068123: Breaks phosh << 0.37.0-2

[Guido Günther]

On Sun, Mar 31, 2024 at 11:59:24AM +0200, Guido Günther wrote:
> Package: gnome-session
> Version: 46.0-1
> Severity: important
> 
> gnome-session 46 dropped `--builtin` and `--systemd`. This breaks phosh <
> 0.37.0-2. Would be great to have a proper `Breaks: ` relationship
> to ease upgrades.

Hi,
I just noticed that gnome-session 46 isn't in testing yet so bumping
severity to not break the current installations. A fixed phosh is about
to be uploade too:

   https://gitlab.gnome.org/World/Phosh/phosh/-/merge_requests/1387

Cheers,
 -- Guido

Bug#1068124: exec-path-from-shell-el 2.1-1 FTBFS if network is unavailable

[Brendan O'Dea]

Package: exec-path-from-shell-el
Version: 2.1-1
Tags: patch

The upstream Makefile attempts to run some sanity checks on the
library, including running `package-lint`, which it attempts to
download via `package.el`.  This fails when the build daemon does not
have network access:

 * 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/exec-path-from-shell-el.html
 * 
https://bugs.launchpad.net/ubuntu/+source/exec-path-from-shell-el/+bug/2034630

Given that the Makefile doesn't actually do anything useful to anyone
other than the upstream maintainer (package-lint, byte compile, remove
byte compile output), the attached patch disables the build entirely.

--bod


rules.patch
Description: Binary data

Bug#1068106: bookworm-pu: package libarchive/3.6.2-1+deb12u1

[Peter Pentchev]

On Sat, Mar 30, 2024 at 08:51:10PM +0200, Peter Pentchev wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bookworm
> X-Debbugs-Cc: libarch...@packages.debian.org, r...@debian.org
> Control: affects -1 + src:libarchive
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> [ Reason ]
> Revert a change made by the same person that smuggled
> the backdoor into xz. See #1068047 for more details.
> 
> [ Impact ]
> In the discussion in the upstream bugtracker, the consensus is that
> the reverted change may not really introduce any vulnerability, but
> still some concerns were expressed regarding some unlikely scenarios.
> It might be a safer bet to revert it, just in case.

Right, so it seems that I was a bit impatient filing this bug, right
after I got the "processing" e-mail from the archive for libarchive-3.7.2-2
in unstable, but before I got the "accepted" one... and before I had
noticed the d-d-a e-mail about the paused archive processing.

So yeah, this is still a pre-upload approval request, but it will
apparently need to wait until 3.7.2-2 makes it into unstable :)

Thanks in advance, and sorry for the bother!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#1068123: Breaks phosh << 0.37.0-2

[Guido Günther]

Package: gnome-session
Version: 46.0-1
Severity: important

gnome-session 46 dropped `--builtin` and `--systemd`. This breaks phosh <
0.37.0-2. Would be great to have a proper `Breaks: ` relationship
to ease upgrades.
Cheers,
 -- Guido

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

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

Versions of packages gnome-session depends on:
ii  adwaita-icon-theme 46~rc-1
ii  fonts-cantarell0.303.1-1
ii  gnome-session-bin  46.0-1
ii  gnome-session-common   46.0-1
ii  gnome-settings-daemon  46~beta-2
ii  gnome-shell44.9-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]1.15.1-1
ii  xdg-desktop-portal-phosh [xdg-desktop-portal-backend]  0.0.0
ii  xdg-desktop-portal-wlr [xdg-desktop-portal-backend]0.7.1-1

gnome-session recommends no packages.

Versions of packages gnome-session suggests:
ii  desktop-base   12.0.6+nmu1
ii  gnome-keyring  42.1-1+b2

-- no debconf information

Bug#1068122: /usr/bin/firefox: clings to USB stick, Debian 12.5 up-to-date, Xfce

[Antti-Pekka Johannes Känsälä]

Package: firefox-esr
Version: 115.9.1esr-1~deb12u1
Severity: normal
File: /usr/bin/firefox
X-Debbugs-Cc: antti.pekka.kans...@iki.fi

Dear Maintainer, please consider

https://lists.debian.org/debian-user/2024/03/msg00721.html

I am worried Gmail in a Firefox tab is able to break out of Firefox
somehow, gaining unauthorized access to 128 files on a mounted USB stick.

The desired behavior is that stick can be unmounted cleanly right after
a single attached file is uploaded in Gmail.  (In my test case an
encrypted binary of no importance to the issue.)

Clinging problem persists with full Debian reinstalls of recent stable
minor versions.


-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils  5.7-0.5~deb12u1
ii  fontconfig   2.14.1-4
ii  libasound2   1.2.8-1+b1
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9+deb12u4
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.10-1~deb12u1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-5
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libnspr4 2:4.35-1
ii  libnss3  2:3.87.1-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libstdc++6   12.2.0-14
ii  libvpx7  1.12.0-1+deb12u2
ii  libx11-6 2:1.8.4-2+deb12u2
ii  libx11-xcb1  2:1.8.4-2+deb12u2
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  procps   2:4.0.2-3
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages firefox-esr recommends:
ii  libavcodec59  7:5.1.4-0+deb12u1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-10
ii  libgssapi-krb5-2   1.20.1-2+deb12u1
ii  pulseaudio 16.1+dfsg1-2+b1

-- no debconf information