date:20240401


Package: chatty
Version: 0.8.2-1
Severity: serious
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, chatty depends
on both libpurple0 and libpurple0t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
archictures).

Bug#1066248: librnd: FTBFS: ../src/librnd/plugins/hid_lesstif/main.c:261:25: error: implicit declaration of function ‘lesstif_attr_sub_update_hidlib’ [-Werror=implicit-function-declaration]


tags 1066248 +patch
thanks

The functions in question are defined in 
src/librnd/plugins/hid_lesstif/dialogs.c

and used in src/librnd/plugins/hid_lesstif/main.c

My first attempt at fixing the issue was to declare the functions in 
dialogs.h

and include dialogs.h in main.c, however doing so caused errors with
conflicting type definitions, so I just defined them directly in main.c 
instead.


while working on this issue I discovered that the clean target was not
cleaning up properly, so I fixed that too.

A debdiff is attatched.

Review and upload would be appreciated since this blocks the time_t
transition
diff -Nru librnd-4.1.1/debian/changelog librnd-4.1.1/debian/changelog
--- librnd-4.1.1/debian/changelog   2024-02-28 17:20:34.0 +
+++ librnd-4.1.1/debian/changelog   2024-04-02 04:43:46.0 +
@@ -1,3 +1,11 @@
+librnd (4.1.1-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add missing function declarations.
+  * Fix clean target.
+
+ -- Peter Michael Green   Tue, 02 Apr 2024 04:43:46 +
+
 librnd (4.1.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru librnd-4.1.1/debian/patches/add-missing-function-declaration.patch 
librnd-4.1.1/debian/patches/add-missing-function-declaration.patch
--- librnd-4.1.1/debian/patches/add-missing-function-declaration.patch  
1970-01-01 00:00:00.0 +
+++ librnd-4.1.1/debian/patches/add-missing-function-declaration.patch  
2024-04-02 04:42:54.0 +
@@ -0,0 +1,14 @@
+Index: librnd-4.1.1/src/librnd/plugins/hid_lesstif/main.c
+===
+--- librnd-4.1.1.orig/src/librnd/plugins/hid_lesstif/main.c
 librnd-4.1.1/src/librnd/plugins/hid_lesstif/main.c
+@@ -51,6 +51,9 @@
+ 
+ #include 
+ 
++void lesstif_attr_dlg_free_all(void);
++void lesstif_attr_sub_update_hidlib(void *hid_ctx, rnd_design_t *new_dsg);
++
+ const char *lesstif_cookie = "lesstif HID";
+ 
+ rnd_design_t *ltf_hidlib;
diff -Nru librnd-4.1.1/debian/patches/series librnd-4.1.1/debian/patches/series
--- librnd-4.1.1/debian/patches/series  2024-01-13 09:12:54.0 +
+++ librnd-4.1.1/debian/patches/series  2024-04-02 04:21:58.0 +
@@ -0,0 +1 @@
+add-missing-function-declaration.patch
diff -Nru librnd-4.1.1/debian/rules librnd-4.1.1/debian/rules
--- librnd-4.1.1/debian/rules   2024-01-13 09:12:54.0 +
+++ librnd-4.1.1/debian/rules   2024-04-02 04:43:46.0 +
@@ -21,6 +21,10 @@
 override_dh_auto_clean:
# only try to run dh_auto_clean if configure has been run
test -f Makefile.conf && dh_auto_clean || true
+   find . -name *.o -delete
+   find . -name *.so.* -delete
+   rm -f scconfig/aru
+   rm -f doc/conf/tree/editor_global_grid.html 
doc/conf/tree/editor_local_grid.html src/librnd/plugins/lib_hid_gl/draw_INIT.h 
src/librnd/poly/polyconf.h src/librnd/polybool/polyconf.h
 
 override_dh_auto_configure:
./configure \

Bug#1068218: RM: chipmunk/experimental -- ROM; cruft from the 64-bit time_t transition

2024-04-01 Thread Stephen Kitt

Package: ftp.debian.org
Severity: normal

Dear FTP team,

Please remove chipmunk from experimental.

Regards,

Stephen

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

2024-04-01 Thread Matthias Klose


On 01.04.24 20:14, Petter Reinholdtsen wrote:


[Petter Reinholdtsen]

I believe I found the correct location 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?


Another and slightly related question, as I suspect moving the git repo
will remove my write access to it.  Do you want to take over my plan to
fix the security problem in stable as described in
https://bugs.debian.org/1066965 >?


not at all, please go ahead with it.

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free

Hi,

On 2024-04-02 09:21, Sean Whitton wrote:
> Hello,
> 
> On Mon 01 Apr 2024 at 05:29pm +02, Aurelien Jarno wrote:
> 
> > Package: debian-policy
> > Version: 4.6.2.1
> > Severity: normal
> > X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
> > Control: affects -1 buildd.debian.org
> >
> > Hi,
> >
> > The debian policy, section 4.9, forbids network access for packages in
> > the main archive, which implicitly means they are authorized for
> > packages in contrib and non-free (and non-free-firmware once #1029211 is
> > fixed).
> >
> > This gives constraints on the build daemons infrastructure and also
> > brings some security concerns. Would it be possible to extend this
> > restriction to all archives?
> 
> We need to know if this is going to break existing packages and allow
> some input from their maintainers.  Are you able to prepare a list of
> the affected packages?

Fair enough. I can work on that, but help would be welcome as my
resources are limited.

Regards
Aurelien

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

Bug#1068189: debhelper: --link-doc checking for known packages makes linux-signed build FTBFS

2024-04-01 Thread Salvatore Bonaccorso

Control: reassign -1 src:linux 6.7.9-2

Hi Niels,

On Mon, Apr 01, 2024 at 05:19:43PM +0200, Niels Thykier wrote:
> Salvatore Bonaccorso:
> > Source: debhelper
> > Version: 13.15
> > Severity: serious
> > Tags: ftbfs
> > Justification: Regression for other package builds, FTBFS
> > X-Debbugs-Cc: car...@debian.org,debian-ker...@lists.debian.org
> > Control: affects -1 + 
> > src:linux,src:linux-signed-amd64,src:linux-signed-arm64
> > 
> > Hi Niels,
> > 
> > Not fully investigated, but starting to fill a bugreport. I noticed
> > that the src:linux pipeline on salsa started to fail for the
> > jobs in th build-signed stage (in the build-signed job).
> > 
> > https://salsa.debian.org/carnil/linux/-/jobs/5527774
> > 
> > (and for saving the output):
> > 
> > [...]
> > 
> > (attached as well the raw log)
> > 
> > I'm not 100% sure yet, this might be a problem in our packaging in
> > which case we can re-eassign. But it only got triggered with the
> > change recently in debhelper:
> > 
> > https://salsa.debian.org/debian/debhelper/-/commit/dec5cfad00e2abd9ee3594f90c93f3fa42bb73ff
> > 
> > Regards,
> > Salvatore
> 
> Hi Salvatore
> 
> It was a suggestion raised (I think on IRC) to have debhelper explicitly
> check these parameters, because a lot of t64 breakage was "unnoticed" by
> debhelper. That is, when people forgot to update --link-doc parameters
> (etc.).
> 
> The code for `--link-doc` uses `${binary:Version}` for the dependency, so
> the package should really be from the same source[1]. In my view, it was
> never a case that was expected to work between source packages.
> 
> I think `linux` with `linux-signed` is doing something really special here
> (especially considering it has worked so far), and I think the question is
> whether `linux`/`linux-signed` should get a special-case or concluding that
> the `--link-doc` is not suitable for the `linux`/`linux-signed` case.
> 
> I would like to hear your case for what makes `--link-doc` sensible for the
> `linux-signed` case. I know of `linux-signed`, but I have no idea what you
> are dealing with in practice, so it is hard for me to make a judgement call
> on this (other than my biased gut feeling of wanting to minimize
> special-cases).

Thanks for your very quick reply, this is much appreicated.

I understand the reason and src:linux should not get really to be
exceptionally handled. So for now I will re-assign it to src:linux
and we can search for a solution in our package.

Thanks a lot for your work on debhelper!

Regards,
Salvatore

Bug#1064598: [3dprinter-general] Bug#1064598: yagv: crashes with "module 'pyglet.graphics' has no attribute 'vertex_list'"

2024-04-01 Thread Chow Loong Jin

On Thu, Mar 28, 2024 at 09:37:18AM +0100, Petter Reinholdtsen wrote:
> [Gregor Riepl 2024-02-26]
> > Unfortunately, it appears that upstream project is dead.
> > The last commit was in 2017, and any requests by @pere on their bug tracker
> > fell on deaf ears: [2]
> > 
> > It's regrettable, but I don't think yagv can be kept with the current
> > situation.
> 
> I agree.  Someone need to take over yagl upstream development for it to
> be sustainable in Debian.  Time to file for removal?
> 
> See https://bugs.debian.org/877377 > for my tries to find a new
> upstream.

Agreed. It's been a while and there are superior alternatives to yagv
now.

-- 
Kind regards,
Loong Jin


signature.asc
Description: PGP signature

Bug#1068215: ITP: python-undetected-chromedriver -- test undetected chromedrive

2024-04-01 Thread weepingclown

Hi,

undetected-chromedriver has already been packaged and is in the new queue, fyi.

- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067181
- https://ftp-master.debian.org/new/python-undetected-chromedriver_3.5.5-1.html

Best,
Ananthu

On 2 April 2024 2:09:26 am UTC, Josenilson Ferreira da Silva 
 wrote:
>Package: wnpp
>Severity: wishlist
>Owner: Josenilson Ferreira da Silva 
>X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com
>
>* Package name: python-undetected-chromedriver
>  Version : 3.5.5
>  Upstream Contact: UltrafunkAmsterdam 
>* URL : 
>https://github.com/ultrafunkamsterdam/undetected-chromedriver
>* License : GPL3
>  Programming Lang: Python
>  Description : test undetected chromedrive
>
>  "undetected-chromedriver" is a project that offers a solution to a common
> problem among developers working on browser test automation using Selenium
> WebDriver.
> .
> The project aims to overcome problems related to test failures when websites
> detect the use of "WebDriver. The module provides a wrapper around
> ChromeDriver (the driver for controlling the Google Chrome browser vi
> a Selenium), which implements several techniques to avoid detection and
> ensure your automated tests run without interruption.
> .
> With an easy-to-use interface, undetected-chromedriver" enables integration
> with existing automation projects, supporting a variety of platforms and
> development environments, making it a versatile tool for developers seeking
> stability and reliability in automated testing
> .
> Note: This package is a required dependency for the TeraBoxUtility
> ITP package: #1067395
>

Bug#1063772: postfix-mysql upgrade add map in dynamicmaps.cf after postfix restart

2024-04-01 Thread Scott Kitterman

The next postfix upload to unstable should address this by using a trigger to 
restart postfix any time one of the map type packages is configured.

Scott K

Bug#1067391: bitlbee-facebook: redundant dependency on libglib2.0-0


severity 1067391 serious
thanks

After rebuilding for the time64 transition, bitlbee-facebook depends on
both libglib2.0-0 and libglib2.0-0t64. As a result it is uninstallable on
architectures affected by the time64 transition (armel, armhf and
several unofficial ports).

Bug#1068204: pdl: FTBFS on i386: Failed 1/45 test programs. 2/2262 subtests failed.

2024-04-01 Thread Sebastiaan Couwenberg


Control: tags -1 upstream
Control: forwarded -1 https://github.com/PDLPorters/pdl/issues/469

On 4/1/24 10:47 PM, Sebastian Ramacher wrote:

https://buildd.debian.org/status/fetch.php?pkg=pdl=i386=1%3A2.086-1=1712002199=0


Salsa CI also caught that which triggered the upstream issue.

Kind Regards,

Bas

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

Bug#1068217: atomes, dependencies unsatisfiable on 32-bit non-i386 architectures.


Package: atomes
Version: 1.1.12+repack-2
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, atomes depends
on both libgtk-3-0t64 and .libgtk-3-0t64 As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
archictures).

This applies to both versions 1.1.12+repack-2 and 1.1.14-1

Bug#1066392: gtk2-engines-murrine: FTBFS: ./src/murrine_style.c:133:30: error: implicit declaration of function ‘murrine_widget_is_ltr’; did you mean ‘murrine_widget_is_rgba’? [-Werror=implicit-functi


tags 1066392 +patch
thanks

I've whipped up a patch that adds the missing function declarations to
the headers.

Review and upload would be appreciated as this is needed for the
time64 transition (and is a key package, so can't simply be autoremoved).
diff -Nru gtk2-engines-murrine-0.98.2/debian/changelog 
gtk2-engines-murrine-0.98.2/debian/changelog
--- gtk2-engines-murrine-0.98.2/debian/changelog2019-11-18 
08:32:18.0 +
+++ gtk2-engines-murrine-0.98.2/debian/changelog2024-04-02 
02:51:30.0 +
@@ -1,3 +1,11 @@
+gtk2-engines-murrine (0.98.2-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add declarations for functions to fix implicit function declaration
+errors.
+
+ -- Peter Michael Green   Tue, 02 Apr 2024 02:51:30 +
+
 gtk2-engines-murrine (0.98.2-3) unstable; urgency=medium
 
   [ Mike Gabriel ]
diff -Nru 
gtk2-engines-murrine-0.98.2/debian/patches/add-missing-function-declarations.patch
 
gtk2-engines-murrine-0.98.2/debian/patches/add-missing-function-declarations.patch
--- 
gtk2-engines-murrine-0.98.2/debian/patches/add-missing-function-declarations.patch
  1970-01-01 00:00:00.0 +
+++ 
gtk2-engines-murrine-0.98.2/debian/patches/add-missing-function-declarations.patch
  2024-04-02 02:51:30.0 +
@@ -0,0 +1,31 @@
+Description: Add declarations for functions to fix implicit function 
declaration errors.
+Author: Peter Michael Green 
+
+--- gtk2-engines-murrine-0.98.2.orig/src/murrine_rc_style.h
 gtk2-engines-murrine-0.98.2/src/murrine_rc_style.h
+@@ -155,4 +155,6 @@ struct _MurrineRcStyleClass
+ 
+ GType murrine_rc_style_get_type   (void);
+ 
++void murrine_rc_style_register_types (GTypeModule *module);
++
+ #endif /* MURRINE_RC_STYLE_H */
+--- gtk2-engines-murrine-0.98.2.orig/src/murrine_style.h
 gtk2-engines-murrine-0.98.2/src/murrine_style.h
+@@ -102,5 +102,6 @@ struct _MurrineStyleClass
+ };
+ 
+ GType murrine_style_get_type (void);
++void murrine_style_register_types (GTypeModule *module);
+ 
+ #endif /* MURRINE_STYLE_H */
+--- gtk2-engines-murrine-0.98.2.orig/src/support.h
 gtk2-engines-murrine-0.98.2/src/support.h
+@@ -149,4 +149,7 @@ G_GNUC_INTERNAL void murrine_get_noteboo
+ gboolean  *start,
+ gboolean  *end);
+ 
++gboolean murrine_object_is_a (const GObject * object, const gchar * 
type_name);
++gboolean murrine_widget_is_ltr (GtkWidget *widget);
++
+ #endif /* SUPPORT_H */
diff -Nru gtk2-engines-murrine-0.98.2/debian/patches/series 
gtk2-engines-murrine-0.98.2/debian/patches/series
--- gtk2-engines-murrine-0.98.2/debian/patches/series   2019-11-12 
09:31:57.0 +
+++ gtk2-engines-murrine-0.98.2/debian/patches/series   2024-04-02 
02:51:30.0 +
@@ -1,2 +1,3 @@
 02_fix-linking-lm.patch
 pango_cairo_update_layout.patch
+add-missing-function-declarations.patch

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

2024-04-01 Thread Maytham Alsudany

Control: owner -1 !
Control: retitle -1 ITP: redict -- Distributed key/value store - forked from 
Redis

On Sun, 31 Mar 2024 15:27:29 +0200, Federico Ceratto wrote:
> 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

Hi,

I'd like to work on this package, and I'm excited to get my hands dirty working
on a more complex piece of software.

CC'ing Chris for the same reasons as Guillem at [1]. I'm probably going to end
up creating a redict-team to set as the Maintainer of this package.

For now, I want to see if I can get the latest release candidate into a working
package (and I've started with copying the debian/ directory from redis).

Kind regards,
Maytham

[1]: ITP for keydb
 https://bugs.debian.org/1067413

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

Bug#1068216: aqemu, dependencies unsatisfiable on 32-bit non-i386 architectures.


Package: aqemu
Version: 0.9.2-3
Severity: serious
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, aqemu still
depends on libqt5dbus5. As a result it is uninstallable on
architectures that are undergoing the time64 transition
(armel, armhf and some debian-ports archictures).

Bug#1064593: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

2024-04-01 Thread Sean Whitton

Hello,

On Mon 01 Apr 2024 at 02:50pm +02, Holger Wansing wrote:

> I now tend to switch to another approach (also proposed similarly by Adam):
>
> instead of relying on the rtd-theme package in the default install path of the
> package installed by DSA, I will use the infrastructure in 1ftpfiles and
> 7doc of webmaster's cron repo, to (always) fetch the latest version of that
> package (and two more packages, which the former depends on: 
> fonts-font-awesome
> and fonts-lato, to get the needed fonts) and unpack+copy them into
> a dedicated path inside the www build tree.
>
> That path will be synced to the static www mirrors, and we can symlink
> to it from the manuals.
> (And the content of that path will automatically be kept up-to-date on
> the unstable version of packages, so we don't get outdated/orphaned
> copies of that packages in the isolated path.)
> I want the unstable version of that packages here, since they need to
> incorporate with the unstable version of the different manuals (like
> debian-policy), and those packages are built by buildd, so unstable.
>
> How does that sound in the light of Debian guidelines and best practice?
>
> Is it ok, to have such "isolated copies" of packages as described above?
>
> I have not much experience in similar things, so I would like to get
> some comments here, please.

I mean, it seems okay to me, but it's up to the web team really.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#966249: appstream-generator FTBFS with gdc


severity 966249 serious
thanks


That's actually an issue with GDC, it only supports a really old
standard library version currently (will be resolved with GDC 11,
apparently), and supporting multiple standard library versions is a
massive pain. I lowered the issue priority to wishlist, since GDC has
never built this package successfully on the platforms where it is
default so far - maybe GCC 11 will resolve this for good :-)

Versions 0.8.8-1 and versions 0.9.0-1 built successfully with
gdc on armel, armhf and s390x.

However 0.9.1-1 failed to build with an internal compiler
error on those architectures.

Either a fix/workaround needs to be found for the internal
compiler error, or if this is not possible the outdated
binaries need to be removed.

Bug#1068215: ITP: python-undetected-chromedriver -- test undetected chromedrive

2024-04-01 Thread 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-undetected-chromedriver
  Version : 3.5.5
  Upstream Contact: UltrafunkAmsterdam 
* URL : 
https://github.com/ultrafunkamsterdam/undetected-chromedriver
* License : GPL3
  Programming Lang: Python
  Description : test undetected chromedrive

  "undetected-chromedriver" is a project that offers a solution to a common
 problem among developers working on browser test automation using Selenium
 WebDriver.
 .
 The project aims to overcome problems related to test failures when websites
 detect the use of "WebDriver. The module provides a wrapper around
 ChromeDriver (the driver for controlling the Google Chrome browser vi
 a Selenium), which implements several techniques to avoid detection and
 ensure your automated tests run without interruption.
 .
 With an easy-to-use interface, undetected-chromedriver" enables integration
 with existing automation projects, supporting a variety of platforms and
 development environments, making it a versatile tool for developers seeking
 stability and reliability in automated testing
 .
 Note: This package is a required dependency for the TeraBoxUtility
 ITP package: #1067395

Bug#1064708: pygame: FTBFS: AssertionError: "No video mode" does not match "Parameter 'surface' is invalid"


severity 1064708 important

Can you explain why you downgraded this bug? it looks rc to me
and is blocking the time_t transition.

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free

2024-04-01 Thread Sean Whitton

Hello,

On Mon 01 Apr 2024 at 05:29pm +02, Aurelien Jarno wrote:

> Package: debian-policy
> Version: 4.6.2.1
> Severity: normal
> X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
> Control: affects -1 buildd.debian.org
>
> Hi,
>
> The debian policy, section 4.9, forbids network access for packages in
> the main archive, which implicitly means they are authorized for
> packages in contrib and non-free (and non-free-firmware once #1029211 is
> fixed).
>
> This gives constraints on the build daemons infrastructure and also
> brings some security concerns. Would it be possible to extend this
> restriction to all archives?

We need to know if this is going to break existing packages and allow
some input from their maintainers.  Are you able to prepare a list of
the affected packages?

-- 
Sean Whitton

Bug#1065034: The courier packages on debian are ripe for a hostile takeover: An xz project compromise digression

2024-04-01 Thread J Mo




Hello!

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

This bug was filed with Debian a little over a month ago.

Unfortunately, the courier packages on Debian have long been poorly 
maintained. Nobody seems to be willing to step up and help out. I know 
Markus Wanner is/was doing his best and he deserves praise for helping 
out rather than bitching by a do-nothing pleb like me, but the last two 
package updates have been NMUs. He put out a Request For Help a long 
time ago and nobody ever stepped up.


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

We had an incompetent and disinterested maintainer in the form of Ondřej 
Surý some time back. He really had no idea what he was doing, didn't 
care, and f**ked s**t up real good.


An even larger threat would be if someone malicious were to come along 
and adopt the packages. Courier may not be the most popular MTA, but if 
I were a nation state actor or malware peddler looking for a reasonably 
popular Well-Known sub-1024 socketed daemon, this Debian package would 
be a prime candidate for take-over.


Finally, I realize I am creating a perfect opportunity for a bike shed, 
and there's been a lot of that going around on the xz compromise issue. 
I'm sorry. Also, just don't.


Thanks for reading



On 2/28/24 10:04 PM, ZHAO, fei wrote:

Package: courier
Severity: important

If the maintainer is unable to keep up with courier related packages, he
should orphan it.
Courier version outdated long.
courier-maildrop related questions not resolved for years and years.


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

Kernel: Linux 6.6.13-amd64 (SMP w/2 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

Bug#976196: clickhouse LTS 2024

2024-04-01 Thread William Desportes

Control: retitle -1 clickhouse: Please package ClickHouse 
v24.3.1.2672-lts


4 years later, the LTS version currently is (reading the releases page: 
v..):


https://github.com/ClickHouse/ClickHouse/releases/tag/v24.3.1.2672-lts

I am not sure why the ClickHouse package has not got new versions in 
Debian.
It got very small updates that did not change the currently packaged 
version.

Bug#1068213: gnome-remote-desktop: hard-coded dependency on pre-t64 library

Source: gnome-remote-desktop
Version: 44.2-7
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

gnome-remote-desktop builds a binary pckage with a hard-coded dependy on
libmutter-12-0. This library was renamed as part of the time_t 64
transition. Please update the dependencies accordingly.

Cheers
-- 
Sebastian Ramacher

Bug#1068199: librocfft0: callback test failures on gfx900 and gfx1030

2024-04-01 Thread Cordell Bloor

I tried to reproduce the rocfft callback bug with a W6800 (gfx1030). I 
used a Debian Unstable docker container on an Ubuntu Noble host, but the 
tests all passed. This made me realize that the test failure pattern on 
the CI is that all the qemu-based workers are failing and all the 
podman-based workers are passing.


This issue seems to be somehow related to the qemu+rocm autopkgtest 
environment.


Sincerely,
Cory Bloor

Bug#1064810: Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'

On 2024-04-01 12:05:30 +0100, Alastair McKinstry wrote:
> 
> On 23/03/2024 01:58, Thorsten Glaser wrote:
> > Andrey Rakhmatullin dixit:
> > 
> > > OPAL_THREAD_ADD_FETCH64 is defined under #if OPAL_HAVE_ATOMIC_MATH_64
> > > And I assume this arch doesn't have 64-bit atomics.
> > No native ones, yes.
> > 
> > I *think* either libatomic or libatomic_ops(?) make them
> > available, but very slowly, using a syscall to guarantee
> > atomicity (those systems are normally uniprocessor) on
> > m68k.
> > 
> > If possible, avoiding them would be preferrable. (For
> > example, in some cases, like reading a 64-bit timestamp,
> > if the writing direction is known and stable, reading
> > twice then comparing is a possible alternative at least
> > for some architectures (e.g. I know BSD code for sparc
> > does it that way).
> > 
> > I guess you’ll have to ask the porters of 32-bit arches
> > with no native 64-bit atomics for details.
> > 
> > Though I had thought GCC’s builtin atomics use the
> > aforementioned kernel-based workaround from that library
> > these days?
> 
> There is a transition to openmpi-5 / mpi-defaults which is stalled by the
> t64 transition.
> 
> It drops 32-bit support from OpenMPI.
> 
> Because of this, I don't think the solution is to  port 32-bit atomics for
> armel/armhf, as it will be removed in a few weeks/months.
> 
> While we didn't want the transitions to be done simultaneously, it might be
> the best answer.
> 
> 
> What does the release team think?

Adding another transition on top will just delay the time_t transition
even more. So if we can avoid that, I'd prefer to not do this transition
now. Unfortunately, uploads such as the one of pmix that no dropped
support for 32 bit architectures (#1068211) are not really helpful.

Also, #1064810 has no information on test builds with the new
mpi-defaults on a 32 bit architecture. So has this transition been
tested?

Cheers
-- 
Sebastian Ramacher

Bug#1068212: ITP: python-grpcio-status -- Status proto mapping for gRPC

2024-04-01 Thread Yogeswaran Umasankar

Package: wnpp
Severity: wishlist
Owner: Yogeswaran Umasankar 
X-Debbugs-Cc: debian-de...@lists.debian.org, kd8...@gmail.com

* Package name: python-grpcio-status
  Version : 1.62.1
  Upstream Contact: The gRPC Authors 
* URL : https://github.com/OctopusAI/grpcio-status
* License : Apache-2.0
  Programming Lang: Python
  Description : Status proto mapping for gRPC

gRPC Python Status Proto is a reference package for GRPC Python
 status proto mapping. Planned to maintain it under DPT, and need
 a sponsor.

Bug#1068211: pmix: FTBFS on 32 bit architectures: configure: WARNING: PMIx does not support 32 bit builds.

Source: pmix
Version: 5.0.2-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=pmix=armel=5.0.2-1=1711406265=0

checking size of _Bool... 1
checking size of short... 2
checking size of int... 4
checking size of long... 4
checking size of void *... 4
configure: WARNING: PMIx does not support 32 bit builds.
configure: error: Cannot continue
-- 
Sebastian Ramacher

Bug#1068210: fricas: FTBFS on arm{el,hf}: /<>/src/lisp/fricas-lisp.c:1750:10: error: implicit declaration of function ‘sock_get_string_buf’; did you mean ‘sock_send_string_len’? [-Werror=

Source: fricas
Version: 1.3.10-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=fricas=armhf=1.3.10-1%2Bb2=1711729211=0

/<>/src/lisp/fricas-lisp.c: In function 
‘sock_get_string_buf_wrapper’:
/<>/src/lisp/fricas-lisp.c:1750:10: error: implicit declaration of 
function ‘sock_get_string_buf’; did you mean ‘sock_send_string_len’? 
[-Werror=implicit-function-declaration]
 1750 |   return sock_get_string_buf(i, x->st.st_self, j); }
  |  ^~~
  |  sock_send_string_len
cc1: some warnings being treated as errors

Correctable error: 
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by COMPILE-FILE.
If continued: Continues anyway.SIMPLE-ERROR: (SYSTEM "/usr/bin/gcc  -c -g 
-Werror=implicit-function-declaration 
-ffile-prefix-map=/<>/gcl-2.6.14=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fsigned-char -pipe 
-fcommon -fno-builtin-malloc -fno-builtin-free -fno-PIE -fno-pie -fno-PIC 
-fno-pic -Wall -Wno-empty-body -Wno-unused-but-set-variable 
-fdollars-in-identifiers -g -I/usr/include/tirpc -D_TIME_BITS=64 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2  
-I/usr/lib/gcl-2.6.14/unixport/../h  -O2  -c 
/<>/src/lisp/fricas-lisp.c -o 
/<>/src/lisp/fricas-lisp.o ") returned a non-zero value 1 0.

Broken at COMPILE-FILE.  Type :H for Help.
1 (continue) Continues anyway. 
2  Return to top level. 
BOOTTRAN>>
The compiler was called recursively.
Cannot compile primitives.lisp.
NIL
NIL
NIL
BOOTTRAN>>make[3]: *** [Makefile:249: do_it.gcl] Error 255

Cheers
-- 
Sebastian Ramacher

Bug#1068209: libgtkada: FTBFS on all: dh_ada_library: error: debian/tmp/usr/lib/x86_64-linux-gnu/ada/adalib/gtkada/*.ali are missing

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

mkdir -p debian/tmp/usr/share/doc/gtkada/gtkada_ug
cp --reflink=auto -aftdebian/tmp/usr/share/doc/gtkada/gtkada_ug \
  docs/gtkada_ug/_build/html/* \
  docs/gtkada_ug/_build/latex/GtkAda.pdf
make[1]: Leaving directory '/<>'
   dh_install -i
   dh_installdocs -i
   dh_sphinxdoc -i
   dh_installchangelogs -i
   dh_installexamples -i
   dh_installman -i
   dh_ada_library -i
dh_ada_library: error: 
debian/tmp/usr/lib/x86_64-linux-gnu/ada/adalib/gtkada/*.ali are missing

Cheers
-- 
Sebastian Ramacher

Bug#1068203: spectrwm: hard-coded dependency on pre-t64 library

Hi

On 2024-04-01 23:39:37 +0200, Andrea Bolognani wrote:
> On Mon, Apr 01, 2024 at 10:37:03PM +0200, Sebastian Ramacher wrote:
> > Source: spectrwm
> > Version: 3.5.1-1
> > Severity: serious
> > X-Debbugs-Cc: sramac...@debian.org
> > 
> > spectrwm builds a packages with a hard-coded dependency on a library
> > package involved in the time_t 64 transition. This dependency needs to
> > be updated.
> 
> It would be useful if you could be more specific. I guess you're
> talking about the dependency on libxt6?

Yes.

> 
> The problem with it, and the reason why a manual dependency is used
> in that case, is that ${shlib:Depends} will not pick it up, since
> it's dlopen()ed rather than linked against.
> 
> Do you have any suggestions on how to handle this in a way that plays
> well with the 64-bit time_t transition?

You could derive it from the the dependencies of libxt-dev during the
build or for the time being simply change the dependency based on the
rename of the libxt6 -- provided that spectrwm is compatible with the
new ABI.

Cheers
-- 
Sebastian Ramacher

Bug#1067364: Probably bug is elsewhere

2024-04-01 Thread Ervin Hegedüs

I made an investigation and maybe the problem is in another package:
libnginx-mod-http-ndk-dev 1:0.3.3-1.

The report is here:

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

I'll inform you here about the result of the investigation.

Regards,


a.

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

2024-04-01 Thread Andreas Beckmann

Followup-For: Bug #1068166
Control: notfoud -1 6.07-1
Control: found -1 6.7-1

There are also a few manpages that moved from manpages (6.05.01-1) to 
manpages-dev (6.7-1):

usr/share/man/man3/sigevent.3type.gz
usr/share/man/man3/sigval.3type.gz
usr/share/man/man7/sigevent.7.gz

resulting in another file conflict:

  Preparing to unpack .../manpages-dev_6.7-1_all.deb ...
  Unpacking manpages-dev (6.7-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/manpages-dev_6.7-1_all.deb (--unpack):
   trying to overwrite '/usr/share/man/man3/sigevent.3type.gz', which is also 
in package manpages 6.05.01-1
  Errors were encountered while processing:
   /var/cache/apt/archives/manpages-dev_6.7-1_all.deb

Therefore manpages-dev needs to add/bump
  Breaks+Replaces: manpages (<< 6.7)
too.


Andreas

Bug#1068208: python-tinyrpc: please package a new version

2024-04-01 Thread Alexandre Detiste

Source: python-tinyrpc
Version: 0.6-5
Severity: normal

Dear Maintainer,

Please package a new version so the obsolete
python3-mock & python3-six dependencies can be removed.

Greetings

Bug#1068207: Missing header from ngx_feature_test='printf("hello");'

2024-04-01 Thread Ervin Hegedüs

Package: libnginx-mod-http-ndk-dev
Version: 1:0.3.3-1

There is a module package for Nginx, which worked as well since
this FTBFS bug:

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

The upstream contains this section in config:

https://github.com/owasp-modsecurity/ModSecurity-nginx/blob/master/config#L15

ngx_feature_test='printf("hello");'

The problem is when the buildpackage process starts, I got this
error:

hecking for ModSecurity library ... not found
checking for ModSecurity library in /usr/local/modsecurity ... not found
 ./configure: error: ngx_http_modsecurity_module requires the ModSecurity 
library.

see sbuild.log:

http://qa-logs.debian.net/2024/03/19/libnginx-mod-http-modsecurity_1.0.3-1_unstable.log

I investigated the root issue, and I found this message in
obj-x86_64-linux-gnu/autoconf.err:

/home/airween/src/libnginx-mod-http-modsecurity-1.0.3/obj-x86_64-linux-gnu/autotest.c:7:5:
 note: include '' or provide a declaration of 'printf'
cc1: some warnings being treated as errors
--

#include 
#include 
#include 

int main(void) {
printf("hello");;
return 0;
}
...
checking for ModSecurity library in /usr/local/modsecurity

/home/airween/src/libnginx-mod-http-modsecurity-1.0.3/obj-x86_64-linux-gnu/autotest.c:
 In function 'main':
/home/airween/src/libnginx-mod-http-modsecurity-1.0.3/obj-x86_64-linux-gnu/autotest.c:7:5:
 error: implicit declaration of function 'printf' 
[-Werror=implicit-function-declaration]
7 | printf("hello");;
  | ^~
/home/airween/src/libnginx-mod-http-modsecurity-1.0.3/obj-x86_64-linux-gnu/autotest.c:5:1:
 note: include '' or provide a declaration of 'printf'
4 | #include 
  +++ |+#include 
5 | 
/home/airween/src/libnginx-mod-http-modsecurity-1.0.3/obj-x86_64-linux-gnu/autotest.c:7:5:
 warning: incompatible implicit declaration of built-in function 'printf' 
[-Wbuiltin-declaration-mismatch]
7 | printf("hello");;
  | ^~
/home/airween/src/libnginx-mod-http-modsecurity-1.0.3/obj-x86_64-linux-gnu/autotest.c:7:5:
 note: include '' or provide a declaration of 'printf'
cc1: some warnings being treated as errors
--

#include 
#include 
#include 

int main(void) {
printf("hello");;
return 0;
}

If I add a patch (via d/series) which adds this header correctly,
then everything is fine, the package builds as well.

The upstream isn't touched since 6 years (the mentioned file), so
I guess something is changed in libnginx-mod-http-ndk-dev (if it
is responsible to produce the test codes - I guess).

Note, that there isn't any user report in upstream regarding this
problem, actually I can reproduce this only in Debian.


Sorry if I'm wrong.


Thanks,


a.

Bug#1068203: spectrwm: hard-coded dependency on pre-t64 library

2024-04-01 Thread Andrea Bolognani

On Mon, Apr 01, 2024 at 10:37:03PM +0200, Sebastian Ramacher wrote:
> Source: spectrwm
> Version: 3.5.1-1
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
> 
> spectrwm builds a packages with a hard-coded dependency on a library
> package involved in the time_t 64 transition. This dependency needs to
> be updated.

It would be useful if you could be more specific. I guess you're
talking about the dependency on libxt6?

The problem with it, and the reason why a manual dependency is used
in that case, is that ${shlib:Depends} will not pick it up, since
it's dlopen()ed rather than linked against.

Do you have any suggestions on how to handle this in a way that plays
well with the 64-bit time_t transition?

Thanks.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.

signature.asc
Description: PGP signature

Bug#1068104: pandas: FTBFS on 32-bit architectures with -D_TIME_BITS=64

2024-04-01 Thread Rebecca N. Palmer


Thanks - I plan to look at this tomorrow.

Bug#1067207: mesa: switch statement too large, might need -mlong-jump-table-offsets

2024-04-01 Thread Thorsten Glaser

retitle 1067207 mesa: [m68k] switch statement too large, needs 
-mlong-jump-table-offsets
tags 1067207 + patch
thanks

>Adding the -mlong-jump-table-offsets flag to CFLAGS on m68k should

That did it. I built with…

APPEND CFLAGS -mlong-jump-table-offsets
APPEND CXXFLAGS -mlong-jump-table-offsets

… in /etc/dpkg/buildflags.conf in the chroot. An equivalent patch
for d/rules would be:

--- debian/rules~   2024-04-01 23:29:11.0 +0200
+++ debian/rules2024-04-01 23:31:39.379936168 +0200
@@ -18,7 +18,11 @@

 export DEB_BUILD_MAINT_OPTIONS=optimize=-lto

-ifeq (,$(filter $(DEB_HOST_ARCH), armhf ppc64el sh3 sh4))
+ifneq (,$(filter $(DEB_HOST_ARCH), m68k))
+# This library has huge jump tables: Debian #1067207
+buildflags = \
+   $(shell DEB_CFLAGS_MAINT_APPEND='-Wall -mlong-jump-table-offsets' 
DEB_CXXFLAGS_MAINT_APPEND='-Wall -mlong-jump-table-offsets' dpkg-buildflags 
--export=configure)
+else ifeq (,$(filter $(DEB_HOST_ARCH), armhf ppc64el sh3 sh4))
 buildflags = \
$(shell DEB_CFLAGS_MAINT_APPEND=-Wall DEB_CXXFLAGS_MAINT_APPEND=-Wall 
dpkg-buildflags --export=configure)
 else

While there, you might want to consider changing these
nested ifs to the new gmake else-if model or perhaps
sorting it, or even changing to something like:

--- debian/rules~   2024-04-01 23:29:11.0 +0200
+++ debian/rules2024-04-01 23:36:10.368947470 +0200
@@ -18,20 +18,25 @@
 
 export DEB_BUILD_MAINT_OPTIONS=optimize=-lto
 
-ifeq (,$(filter $(DEB_HOST_ARCH), armhf ppc64el sh3 sh4))
-buildflags = \
-   $(shell DEB_CFLAGS_MAINT_APPEND=-Wall DEB_CXXFLAGS_MAINT_APPEND=-Wall 
dpkg-buildflags --export=configure)
-else
-  ifneq (,$(filter $(DEB_HOST_ARCH), armhf))
-  # Workaround for a variant of LP: #725126
-  buildflags = \
-   $(shell DEB_CFLAGS_MAINT_APPEND="-Wall -fno-optimize-sibling-calls" 
DEB_CXXFLAGS_MAINT_APPEND="-Wall -fno-optimize-sibling-calls" dpkg-buildflags 
--export=configure)
-  else
-# Workaround for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
-buildflags = \
-   $(shell DEB_CFLAGS_MAINT_APPEND="-Wall -O1" 
DEB_CXXFLAGS_MAINT_APPEND="-Wall -O1" dpkg-buildflags --export=configure)
-  endif
+DEB_CFLAGS_MAINT_APPEND := -Wall
+DEB_CXXFLAGS_MAINT_APPEND := -Wall
+ifneq (,$(filter $(DEB_HOST_ARCH), armhf))
+# Workaround for a variant of LP: #725126
+DEB_CFLAGS_MAINT_APPEND += -fno-optimize-sibling-calls
+DEB_CXXFLAGS_MAINT_APPEND += -fno-optimize-sibling-calls
+else ifneq (,$(filter $(DEB_HOST_ARCH), m68k))
+# This library has huge jump tables: Debian #1067207
+DEB_CFLAGS_MAINT_APPEND += -mlong-jump-table-offsets
+DEB_CXXFLAGS_MAINT_APPEND += -mlong-jump-table-offsets
+else ifneq (,$(filter $(DEB_HOST_ARCH), ppc64el sh3 sh4))
+# Workaround for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
+DEB_CFLAGS_MAINT_APPEND += -O1
+DEB_CXXFLAGS_MAINT_APPEND += -O1
 endif
+buildflags = $(shell \
+   DEB_CFLAGS_MAINT_APPEND='$(DEB_CFLAGS_MAINT_APPEND)' \
+   DEB_CXXFLAGS_MAINT_APPEND='$(DEB_CXXFLAGS_MAINT_APPEND)' \
+   dpkg-buildflags --export=configure)
 
 EGL_PLATFORMS = x11
 GALLIUM_DRIVERS = swrast

bye,
//mirabilos
-- 
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package

2024-04-01 Thread Luca Boccassi

On Mon, 1 Apr 2024 at 21:49, Bastian Blank  wrote:
>
> Control: tags -1 wontfix
>
> On Thu, Feb 29, 2024 at 01:38:12PM +0100, Bastian Blank wrote:
> > On Thu, Feb 29, 2024 at 12:12:21PM +, Luca Boccassi wrote:
> > > With the new vmlinux.h shipped in the headers package, the BTF case
> > > should be covered.
>
> As said, this dependency is to make sure kernel modules are properly
> built.  vmlinux.h is not for kernel modules.

Why do dkms modules need the image installed to be built? At the very
least they didn't use to, the headers were enough last time I had to
deal with that stuff for the nvidia drivers

Bug#1068191: RM: jam -- obsolete, bug, (almost) not used anymore

2024-04-01 Thread Yann Dirson

> Package: jam
> Version: 2.6.1-2
> Severity: normal
> X-Debbugs-Cc: Dmitry Smirnov ,
> debian...@lists.debian.org, Yann Dirson , Graeme
> W. Gill 
> 
> Dear Maintainers, Dear Author,
> 
> After I've finished the packaging of lincity-ng later today;
> 'argyll' will be the very last piece of software needing
> unmaintained 'jam' to build.
> 
> Would it be possible, in two steps:
>  - to have argyll build with something else (CMake, meson...?)
>  - drop jam package

I've not been using Jam myself for a few years now, but it is not
very costly to maintain.

-- 
Yann

Bug#1068206: ITP: jolt -- A multi core friendly rigid body physics and collision detection library, written in C++, suitable for games and VR applications.

2024-04-01 Thread Bret Curtis

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

* Package name: jolt
  Version : 4.0.2
  Upstream Contact: Jorrit Rouwe 
* URL : https://github.com/jrouwe/JoltPhysics
* License : MIT
  Programming Lang: C++
  Description : A multi core friendly rigid body physics and collision 
detection library, written in C++, suitable for games and VR applications.

A multi core friendly rigid body physics and collision detection library 
suitable for games and VR applications, used by Horizon Forbidden West.

Extra Info:
This is already in use by several other project, of which is OpenMW which will 
eventually require this physics library.

Bug#1067010: squashfuse: diff for NMU version 0.5.2-0.1

Control: tags 1067010 + patch
Control: tags 1067010 + pending

Dear maintainer,

I've prepared an NMU for squashfuse (versioned as 0.5.2-0.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru squashfuse-0.5.0/.cirrus.yml squashfuse-0.5.2/.cirrus.yml
--- squashfuse-0.5.0/.cirrus.yml	2023-09-13 16:50:21.0 +0200
+++ squashfuse-0.5.2/.cirrus.yml	2024-02-22 16:19:33.0 +0100
@@ -3,12 +3,12 @@
 
 freebsd_task:
   freebsd_instance:
-image_family: freebsd-12-3
+image_family: freebsd-14-0
   setup_script:
 - pkg install -y autoconf automake libtool pkgconf fusefs-libs
 - pkg install -y lzo2 liblz4 zstd
 - pkg install -y squashfs-tools coreutils
-- kldload fuse
+- kldload fusefs
 - sysctl vfs.usermount=1
   build_script:
 - ./autogen.sh
diff -Nru squashfuse-0.5.0/configure.ac squashfuse-0.5.2/configure.ac
--- squashfuse-0.5.0/configure.ac	2023-09-13 16:50:21.0 +0200
+++ squashfuse-0.5.2/configure.ac	2024-02-22 16:19:33.0 +0100
@@ -1,4 +1,4 @@
-AC_INIT([squashfuse], [0.5.0], [d...@vasilevsky.ca])
+AC_INIT([squashfuse], [0.5.2], [d...@vasilevsky.ca])
 AC_CONFIG_MACRO_DIR([m4])
 AC_CONFIG_AUX_DIR([build-aux])
 AC_CONFIG_HEADERS([config.h])
@@ -91,6 +91,7 @@
 
 AC_SUBST([sq_mksquashfs_compressors])
 AC_CONFIG_FILES([tests/ll-smoke.sh],[chmod +x tests/ll-smoke.sh])
+AC_CONFIG_FILES([tests/ll-smoke-singlethreaded.sh],[chmod +x tests/ll-smoke-singlethreaded.sh])
 AC_CONFIG_FILES([tests/umount-test.sh],[chmod +x tests/umount-test.sh])
 
 
diff -Nru squashfuse-0.5.0/debian/changelog squashfuse-0.5.2/debian/changelog
--- squashfuse-0.5.0/debian/changelog	2023-11-02 09:42:28.0 +0100
+++ squashfuse-0.5.2/debian/changelog	2024-04-01 23:02:32.0 +0200
@@ -1,3 +1,11 @@
+squashfuse (0.5.2-0.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload
+  * New upstream release
+- Fix pointer types on 32 bit architectures (Closes: #1067010)
+
+ -- Sebastian Ramacher   Mon, 01 Apr 2024 23:02:32 +0200
+
 squashfuse (0.5.0-2) unstable; urgency=medium
 
   * Fix "needed headers (e.g. config.h) are not shipped"
diff -Nru squashfuse-0.5.0/.github/workflows/ci.yml squashfuse-0.5.2/.github/workflows/ci.yml
--- squashfuse-0.5.0/.github/workflows/ci.yml	2023-09-13 16:50:21.0 +0200
+++ squashfuse-0.5.2/.github/workflows/ci.yml	2024-02-22 16:19:33.0 +0100
@@ -17,6 +17,8 @@
 os: ubuntu-latest
 disable_fuse: "--disable-fuse"
 check_features: demo
+  - name: distcheck
+os: ubuntu-latest
   - name: Old distro
 os: ubuntu-20.04
   - name: Mac
@@ -29,6 +31,7 @@
 uses: actions/checkout@v2
   - name: apt dependencies
 run: > 
+  sudo apt-get update &&
   sudo apt-get install -y automake autoconf libtool pkg-config
   zlib1g-dev liblzo2-dev liblzma-dev liblz4-dev libzstd-dev
   fio
@@ -46,17 +49,20 @@
   brew install autoconf automake libtool pkgconfig squashfs coreutils
   brew install --cask macfuse
 if: runner.os == 'macOS'
-  - name: build
+  - name: configure
 run: |
   ./autogen.sh
   CPPFLAGS="-Werror" ./configure $DISABLE_FUSE
+  - name: build
+run: |
   make -j2 V=1
+if: matrix.name != 'distcheck'
   - name: test
 run: |
   make check
   diff -u ci/expected-features/${CHECK_FEATURES:-all} ci/features
-if: runner.os != 'macOS'
-  - name: test
+if: runner.os != 'macOS' && matrix.name != 'distcheck'
+  - name: test mac
 run: |
   # On macOS loading the macfuse extension is needed.  This
   # command should load it without rebooting, except System
@@ -68,8 +74,13 @@
 diff -u ci/expected-features/${CHECK_FEATURES:-all} ci/features
   fi
 if: runner.os == 'macOS'
+  - name: distcheck
+run: |
+  make distcheck
+if: matrix.name == 'distcheck'
   - name: install
 run: sudo make install
+if: matrix.name != 'distcheck'
   - name: output
 run: |
 cp /tmp/*.log . || true
diff -Nru squashfuse-0.5.0/.gitignore squashfuse-0.5.2/.gitignore
--- squashfuse-0.5.0/.gitignore	2023-09-13 16:50:21.0 +0200
+++ squashfuse-0.5.2/.gitignore	2024-02-22 16:19:33.0 +0100
@@ -33,4 +33,5 @@
 ci/features
 tests/lib.sh
 tests/ll-smoke.sh
+tests/ll-smoke-singlethreaded.sh
 tests/umount-test.sh
diff -Nru squashfuse-0.5.0/ll.c squashfuse-0.5.2/ll.c
--- squashfuse-0.5.0/ll.c	2023-09-13 16:50:21.0 +0200
+++ squashfuse-0.5.2/ll.c	2024-02-22 16:19:33.0 +0100
@@ -410,7 +410,12 @@
 }
 
 void sqfs_ll_op_forget(fuse_req_t req, fuse_ino_t ino,
-		unsigned long nlookup) {
+#ifdef HAVE_FUSE_LL_FORGET_OP_64T
+		uint64_t nlookup
+#else
+		unsigned long nlookup
+#endif
+		) {
 	sqfs_ll_i lli;

Bug#1067432: gnome-shell-pomodoro: needs update for GNOME Shell 46

2024-04-01 Thread Jeremy Bícha

Control: forwarded -1
https://github.com/gnome-pomodoro/gnome-pomodoro/issues/693

Please package version 0.25.1 to fix this issue. The new version drops
support for GNOME Shell 45 but that's ok because Debian Experimental
has version GNOME Shell 46.

Thank you,
Jeremy Bícha

Bug#1068205: gauche: FTBFS on arm{el,hf}: "list.c", line 827 (Scm__GetExtendedPairDescriptor): Assertion failed: (z->hiddenTag&0x7) == 0x7

Source: gauche
Version: 0.9.14-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=gauche=armhf=0.9.14-2=1711974534=0

gcc -DHAVE_CONFIG_H -I. -I. -I./../gc/include -I../gc/include 
`./get-atomic-ops-flags.sh .. .. --cflags`  -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=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -Wall -Wextra -Wno-unused-label -fPIC 
-fomit-frame-pointer  -c test-extra.c
gcc -DHAVE_CONFIG_H -I. -I. -I./../gc/include -I../gc/include 
`./get-atomic-ops-flags.sh .. .. --cflags`  -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=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -Wall -Wextra -Wno-unused-label -fPIC 
-fomit-frame-pointer  -c libextra.c
TARGETLIB="`pwd`"  gcc -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -Wall -Wextra 
-Wno-unused-label -fPIC -Wl,--rpath="`pwd`" -L. -Wl,-z,relro  -rdynamic -o 
test-extra test-extra.o libextra.o -lgauche-0.98 -lmbedtls -lcrypt -lrt -lm  
-lpthread
make[3]: Leaving directory '/<>/src'
make[3]: Entering directory '/<>/lib'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/<>/lib'
make[3]: Entering directory '/<>/ext'
(cd util; make default)
make[4]: Entering directory '/<>/ext/util'
"../../src/gosh" -ftest "../../lib/tools/precomp" -e -P -o util--match 
../../libsrc/util/match.scm
"list.c", line 827 (Scm__GetExtendedPairDescriptor): Assertion failed: 
(z->hiddenTag&0x7) == 0x7
make[4]: *** [Makefile:26: util--match.c] Error 1
make[4]: Leaving directory '/<>/ext/util'
make[3]: *** [Makefile:38: util] Error 2
make[3]: Leaving directory '/<>/ext'
make[2]: *** [Makefile:47: all] Error 1
make[2]: Leaving directory '/<>'
dh_auto_build: error: make -j1 returned exit code 2
make[1]: *** [debian/rules:23: override_dh_auto_build] Error 255

Cheers
-- 
Sebastian Ramacher

Bug#1064976: marked as done (linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package)

2024-04-01 Thread Bastian Blank

On Mon, Apr 01, 2024 at 08:39:06PM +, Debian Bug Tracking System wrote:
> No.  We need to make sure someone installing linux-image-bla and
> linux-headers-bla have the same version, so the modules are compatible.

Revisiting this bug, I might have been not explicit enough.  This
dependency is needed, so headers and kernel will be available in the
same version and dkms is able to build modules for the just installed
kernel.

dkms will check that and break installation if this precondition is not
provided.  And no better solution is known to make sure we can build
those modules.

It however have nothing to do with vmlinux.h, which is not for kernel
modules.

Bastian

-- 
We have phasers, I vote we blast 'em!
-- Bailey, "The Corbomite Maneuver", stardate 1514.2

Bug#1068204: pdl: FTBFS on i386: Failed 1/45 test programs. 2/2262 subtests failed.

Source: pdl
Version: 1:2.086-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=pdl=i386=1%3A2.086-1=1712002199=0

not ok 569 - col=0
not ok 570 - col=1

...

Test Summary Report
---
t/pdl_from_string.t  (Wstat: 0 Tests: 144 Failed: 0)
  TODO passed:   60-62
t/primitive-random.t (Wstat: 0 Tests: 3 Failed: 0)
  TODO passed:   1
t/slice.t(Wstat: 512 (exited 2) Tests: 602 Failed: 2)
  Failed tests:  569-570
  Non-zero exit status: 2
Files=45, Tests=2262, 56 wallclock secs ( 0.48 usr  0.12 sys + 54.74 cusr  5.00 
csys = 60.34 CPU)
Result: FAIL
Failed 1/45 test programs. 2/2262 subtests failed.
make[2]: *** [Makefile:1077: test_dynamic] Error 255


Cheers
-- 
Sebastian Ramacher

Bug#1068203: spectrwm: hard-coded dependency on pre-t64 library

Source: spectrwm
Version: 3.5.1-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

spectrwm builds a packages with a hard-coded dependency on a library
package involved in the time_t 64 transition. This dependency needs to
be updated.

Cheers
-- 
Sebastian Ramacher

Bug#1068202: bazel-bootstrap: FTBFS: /usr/include/absl/base/policy_checks.h:79:2: error: #error "C++ versions less than C++14 are not supported."

Source: bazel-bootstrap
Version: 4.2.3+ds-9
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=bazel-bootstrap=amd64=4.2.3%2Bds-9%2Bb2=1711976723=0

  /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall 
-Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g 
'-std=c++0x' -Wdate-time '-D_FORTIFY_SOURCE=2' -g -O2 
'-ffile-prefix-map=/<>=.' -fstack-protector-strong 
-fstack-clash-protection -Wformat '-Werror=format-security' -fcf-protection -MD 
-MF 
bazel-out/k8-dbg/bin/src/main/protobuf/_objs/command_server_cc_grpc/command_server.grpc.pb.pic.d
 
'-frandom-seed=bazel-out/k8-dbg/bin/src/main/protobuf/_objs/command_server_cc_grpc/command_server.grpc.pb.pic.o'
 -fPIC '-DGRPC_USE_PROTO_LITE=ON' -iquote . -iquote bazel-out/k8-dbg/bin 
-iquote external/debian_cc_deps -iquote 
bazel-out/k8-dbg/bin/external/debian_cc_deps -iquote external/debian_proto_deps 
-iquote bazel-out/k8-dbg/bin/external/debian_proto_deps 
-fno-canonical-system-headers -Wno-builtin-macro-redefined 
'-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c 
bazel-out/k8-dbg/bin/src/main/protobuf/command_server.grpc.pb.cc -o 
bazel-out/k8-dbg/bin/src/main/protobuf/_objs/command_server_cc_grpc/command_server.grpc.pb.pic.o)
Execution platform: //:default_host_platform
␛[32m[256 / 1,677]␛[0m 5 actions running
JavacBootstrap .../devtools/build/buildjar/libstarlark-deps.jar; 18s local
Compiling src/main/cpp/blaze.cc; 3s local
@debian_proto_deps//:descriptor_proto; 3s local
Compiling src/main/protobuf/command_server.pb.cc; 3s local
Compiling src/main/cpp/option_processor.cc; 1s local

␛[1A␛[K
␛[1A␛[K
␛[1A␛[K
␛[1A␛[K
␛[1A␛[K
␛[1A␛[KIn file included from /usr/include/absl/base/config.h:86,
 from /usr/include/absl/base/const_init.h:25,
 from /usr/include/absl/synchronization/mutex.h:67,
 from /usr/include/grpcpp/impl/codegen/sync.h:32,
 from /usr/include/grpcpp/client_context.h:46,
 from /usr/include/grpcpp/impl/call_op_set.h:29,
 from /usr/include/grpcpp/support/server_callback.h:27,
 from /usr/include/grpcpp/impl/codegen/server_callback.h:24,
 from 
/usr/include/grpcpp/impl/codegen/server_callback_handlers.h:25,
 from /usr/include/grpcpp/generic/async_generic_service.h:24,
 from 
bazel-out/k8-dbg/bin/src/main/protobuf/command_server.grpc.pb.h:31,
 from 
bazel-out/k8-dbg/bin/src/main/protobuf/command_server.grpc.pb.cc:6:
/usr/include/absl/base/policy_checks.h:79:2: error: #error "C++ versions less 
than C++14 are not supported."
   79 | #error "C++ versions less than C++14 are not supported."
  |  ^

Cheers
-- 
Sebastian Ramacher

Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package

2024-04-01 Thread Bastian Blank

Control: tags -1 wontfix

On Thu, Feb 29, 2024 at 01:38:12PM +0100, Bastian Blank wrote:
> On Thu, Feb 29, 2024 at 12:12:21PM +, Luca Boccassi wrote:
> > With the new vmlinux.h shipped in the headers package, the BTF case
> > should be covered.

As said, this dependency is to make sure kernel modules are properly
built.  vmlinux.h is not for kernel modules.

Bastian

-- 
Mind your own business, Spock.  I'm sick of your halfbreed interference.

Bug#1068191: Acknowledgement (RM: jam -- obsolete, bug, (almost) not used anymore)

2024-04-01 Thread Alexandre Detiste

I found this:

https://www.freelists.org/post/argyllcms/Status-of-Jam-build
https://www.freelists.org/post/argyllcms/Status-of-Jam-build,1

Bug#1064976: linux-headers-amd64: linux-headers-* incorrectly depends on linux-image-*

2024-04-01 Thread Luca Boccassi

Control: tags -1 patch

On Tue, 19 Mar 2024 12:32:16 + Colm Buckley 
wrote:
> Package: linux-headers-amd64
> Version: 6.6.13-1~bpo12+1
> Followup-For: Bug #1064976
> X-Debbugs-Cc: c...@tuatha.org
> 
> Can I suggest in the interim that Depends: be replaced with
Recommends:
> or Suggests: given that most installations won't actually need the
image
> package?

MR to downgrade to recommends:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/1054

-- 
Kind regards,
Luca Boccassi


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

Bug#1067829: Additional information

2024-04-01 Thread Vladimir Petko

Hi,

I have submitted the bug upstream[1] here, and the patch contains
(long long int) cast as it would not be compiled otherwise.
The Ubuntu patch also contains a cast[2].
I apologise for not forwarding the patch correctly. I have attached
the patch forwarded upstream.

Best Regards,
 Vladimir.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=218540
[2] 
https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/nfs-utils/1:2.6.4-3ubuntu4/nfs-utils_2.6.4-3ubuntu4.debian.tar.xz
Description: cast to a type with a known size to ensure sprintf works
Author: Vladimir Petko 
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=218540
Bug-Ubuntu:  https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2055349
Last-Update: 2024-02-29
--- a/support/junction/export-cache.c
+++ b/support/junction/export-cache.c
@@ -107,7 +107,7 @@
 		xlog(D_GENERAL, "%s: time(3) failed", __func__);
 		return FEDFS_ERR_SVRFAULT;
 	}
-	snprintf(flushtime, sizeof(flushtime), "%ld\n", now);
+	snprintf(flushtime, sizeof(flushtime), "%lld\n", (long long int)now);
 
 	for (i = 0; junction_proc_files[i] != NULL; i++) {
 		retval = junction_write_time(junction_proc_files[i], flushtime);

Bug#966288: [Pkg-puppet-devel] Bug#966288: mcollective - RM for bullseye?

2024-04-01 Thread Matt Taggart

The last mcollective release was v.3.1.2 tagged on Oct 14, 2018, and 
zero commits after that, so is effectively dead upstream.


Here are the popcon stats
  https://qa.debian.org/popcon.php?package=mcollective

I think it could probably be removed from debian now.

This bug mentioned "bolt" as a possible replacement, that seems to be this:
  https://www.puppet.com/docs/bolt/latest/bolt.html
  https://github.com/puppetlabs/bolt

That project has recent commits and releases.

I searched in debian and found:

bolt - system daemon to manage thunderbolt 3 devices
bolt-lmm - Efficient large cohorts genome-wide Bayesian mixed-model 
association testing

bolt-16 - Post-link optimizer
golang-github-boltdb-bolt-dev - low-level key/value database for Go

So it's a popular name it seems.

WNPP doesn't list anything related.

--
Matt Taggart
m...@lackof.org

Bug#1068201: mcollective: Homepage out of date

2024-04-01 Thread Matt Taggart


Package: mcollective
Version: 2.12.5+dfsg-1.1
Severity: minor

The listed Homepage of
  http://projects.puppetlabs.com/projects/mcollective
currently redirects to
  https://tickets-archive.ops.puppetlabs.net/projects/mcollective
which doesn't resolve.

A search for "mcollective" finds
  https://forge.puppet.com/modules/puppet/mcollective
  https://github.com/voxpupuli/puppet-mcollective

Also in the README.md in that github project there are links to things like
  https://www.puppet.com/docs/mcollective/deploy/standard.html
that are broken. But the link
  https://www.puppet.com/docs/mcollective
redirects to the above forge link.

I guess they moved stuff around but didn't setup all the needed redirects.

So I guess the debian package should update Homepage, but also look for 
any broken links and fix them (in upstream would be ok I think, no need 
for debian patch IMO).


Thanks,

--
Matt Taggart
m...@lackof.org

Bug#1067288: pulseaudio: FTBFS on x86: cpu-volume-test fails, segfault in svolume_orc_test

2024-04-01 Thread Adrian Bunk

Control: reassign -1 src:pulseaudio 16.1+dfsg1-3
Control: forwarded -1 
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/3803

On Fri, Mar 22, 2024 at 10:29:23AM +, Simon McVittie wrote:
> Control: retitle -1 pulseaudio: FTBFS on x86: cpu-volume-test fails, segfault 
> in svolume_orc_test
> Control: reassign -1 src:orc 1:0.4.38-1
> Control: forwarded -1 https://gitlab.freedesktop.org/gstreamer/orc/-/issues/66
> Control: tags 1067458 + ftbfs sid trixie
> Control: merge 1067458 -1
> Control: affects 1067458 + src:pulseaudio
> 
> On Wed, 20 Mar 2024 at 21:48:23 +0100, Lucas Nussbaum wrote:
> > > === 47/53 
> > > 
> > > test: cpu-volume-test
> > > start time:   06:46:56
> > > duration: 2.82s
> > > result:   exit status 1
> > > command:  
> > > UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
> > >  
> > > LD_LIBRARY_PATH=/<>/obj-x86_64-linux-gnu/src/pulse:/<>/obj-x86_64-linux-gnu/src/pulsecore:/<>/obj-x86_64-linux-gnu/src
> > >  MALLOC_PERTURB_=255 MAKE_CHECK=1 
> > > ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
> > > /<>/obj-x86_64-linux-gnu/src/tests/cpu-volume-test
> > > --- stdout 
> > > ---
> > > Running suite(s): CPU
> > > 66%: Checks: 3, Failures: 0, Errors: 1
> > > ../src/tests/cpu-volume-test.c:188:E:svolume:svolume_orc_test:0: (after 
> > > this point) Received signal 11 (Segmentation fault)
> > > ==
> 
> This seems to be the same issue as #1067458.
> 
> If a fix isn't obvious, could we perhaps roll back orc to 0.4.34
> (presumably versioned as 1:0.4.38+really0.4.34), or disable its use
> in PulseAudio for now?

According to the information in the upstream bug, PulseAudio has fixed 
the test now.

> Thanks,
> smcv

cu
Adrian

Bug#878599:

2024-04-01 Thread Ville Skyttä

Thanks to people who have helped out with refining the patch. Anything
I could do to help nudge this forward?

Bug#1068200: ITP: gnome-online-accounts-gtk - GNOME Online Accounts GTK

2024-04-01 Thread David Mohammed

Package: wnpp
Severity: wishlist

Owner: David Mohammed (fossfree...@ubuntu.com)

Package name : gnome-online-accounts-gtk
Version : 3.50.1
Upstream Author : Linux Mint 
URL : https://github.com/linuxmint/gnome-online-accounts-gtk
License : GPL 3+
Programming Lang: C
Description : GUI Utility for logging into online accounts
Enter login details for some online services such as Google and Facebook.
This enables applications to access online services like email,
calendars, chat and documents.
.
This is a standalone application for desktop environments where
GNOME Online Accounts capability is not integrated in their equivalent
settings utility.

Bug#1006296:

2024-04-01 Thread Ville Skyttä

Patch and implementation is being discussed in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878599

Bug#1063096: python3-webview: proxy_tools dependency not found

2024-04-01 Thread Jeremy Bícha

On Sun, Mar 17, 2024 at 3:42 AM Jochen Sprickerhof  wrote:
> you uploaded python3-webview recently which seem to be broken (see
> below). As I currently don't use the package, are you interested in
> taking over maintainership?

Sorry, the package has no reverse dependencies in Debian so I don't
have a need for the package either.

Thank you,
Jeremy Bícha

Bug#1068197: debian-installer: accesses the internet during build

2024-04-01 Thread Cyril Brulebois

[ Switching from ML to bug. ]

Hi Jonathan,

Jonathan Carter  (2024-04-01):
> On 2024/04/01 18:55, Aurelien Jarno wrote:
> > debian-installer attemps network access during build, although only to
> > the mirrors listed in /etc/apt/sources.list and in a secure way. This is
> > forbidden by Policy 4.9:
> > 
> >For packages in the main archive, required targets must not attempt
> >network access, except, via the loopback interface, to services on the
> >build host that have been started by the build.
> > 
> > In addition this brings constraints to the build daemons infrastructure.
> 
> As far as I know, this doesn't happen until after d-i asked the question "Do
> you want to use a network mirror?" and the user answered "Yes", in which
> case I think that would count as informed consent.

This isn't about d-i runtime, this is about src:debian-installer's
*build* requiring network access, which is a very well known problem
(even though there are no obvious solutions, at least that I'm aware
of), and that's now getting in the way of changes being considered 
regarding the buildd network.


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


signature.asc
Description: PGP signature

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

2024-04-01 Thread Antti-Pekka Känsälä

On Mon, 1 Apr 2024 17:57:55 +0700 Max Nikulin  wrote:
> On Sun, 31 Mar 2024 12:51:52 +0300 Antti-Pekka Johannes Känsälä wrote:
> >
> > https://lists.debian.org/debian-user/2024/03/msg00721.html
>
> Notice that this thread is broken into many part. (Perhaps because gmail
> does not support In-Reply-To in mailto: links)
>
> > 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.
>
> Output of the command to confirm the statement was not provided.
>
>  From my point of view, something close to valid behavior was described.
>
> - If a file from an external drive is chosen for 
> then it is reasonable to expect that it can be used later when a form is
> submitted or an e-mail with the attachment is sent. Users are free to
> select another file, so eagerly reading the file to memory is not always
> reasonable. As a result it may be impossible to unmount the drive
> immediately.
> - File icons should appear in the file chooser and it may assume
> determining media types of these files.
>
> So precise description of steps and observed effects is necessary to
> make this bug report convincing.

Ok, so I send Gmail to myself, with the single attached file "file4.gpg" on
a mounted USB stick
(icon menu,mount only, not opening an Xfce file browser).

Even after I've received my own Gmail, the stick is unable to unmount (icon
menu again), I get
a graphical dialog (Xfce) saying the Gmail Inbox tab blocks it, that
"there's still data that needs
to be written to the device".

Closing the Gmail tab will not help. I still get this:

appe@renaissance:~$ lsof | grep -i KINGSTON
x-www-bro 83803 appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83807 glean.dis appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83809 IPC\x20I/ appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83810 Timer appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83811 Netlink   appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83812 Socketappe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83813 IPDL\x20B appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83815 HTML5\x20 appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83817 JS\x20Wat appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83821 Cache2appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83822 Cookieappe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83824 TaskCon~l appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83825 TaskCon~l appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83826 TaskCon~l appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83827 TaskCon~l appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83834 Workerappe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83835 gmain appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83836 gdbus appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83845 x-www-b:d appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83846 GLXVsyncT appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83847 x-www-b:d appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83848 x-www-br: appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83849 CanvasRen appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83850 Renderer  appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83851 WRWorker# appe  128r  REG
  8,33  3433   6939 /media/appe/KINGSTON/noname/file4.gpg
x-www-bro 83803 83852 WRWorker# appe  128r  REG
  8,33

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

2024-04-01 Thread Petter Reinholdtsen



[Petter Reinholdtsen]
> I believe I found the correct location 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?

Another and slightly related question, as I suspect moving the git repo
will remove my write access to it.  Do you want to take over my plan to
fix the security problem in stable as described in
https://bugs.debian.org/1066965 >?

-- 
Happy hacking
Petter Reinholdtsen

Bug#1028356: procmail: Variable set with stdin pipe action fails leaving empty variable

2024-04-01 Thread Santiago Vila


Hi.

I have just reuploaded version 3.22.

This is certainly not the ideal state for this ancient
package, but I believe it's slightly better than keeping
an important regression forever.

If upstream decides to maintain procmail again (which means
addressing regressions, not merely making a new release),
it could make sense to consider the switch again.

I was about to write all this in the Debian changelog, but this
place is probably more appropriate.

Thanks a lot.

Bug#1042506: fixed in lincity-ng 2.10.1-1

2024-04-01 Thread Niels Thykier


Hi Alexandre

Looks like you typoed the bug number in lincity-ng (#1042506 was filed 
against ares).


Best regards,
Niels


On Mon, 01 Apr 2024 17:19:51 + Debian FTP Masters 
 wrote:

Source: lincity-ng
Source-Version: 2.10.1-1
Done: Alexandre Detiste 

We believe that the bug you reported is fixed in the latest version of
lincity-ng, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1042...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Alexandre Detiste  (supplier of updated lincity-ng package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 01 Apr 2024 18:58:18 +0200
Source: lincity-ng
Architecture: source
Version: 2.10.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Games Team 
Changed-By: Alexandre Detiste 
Closes: 1042506
Changes:
 lincity-ng (2.10.1-1) unstable; urgency=medium
 .
   * Team Upload
   * New upstream version 2.10.1
   * replace old autoconf+jam build with modern CMake (Closes: #1042506)
Checksums-Sha1:
 7204930ea578ea873eb362b9fe20d5f4f6825ba2 2177 lincity-ng_2.10.1-1.dsc
 cbc7e48068b762be77bfcfb8421fc685355cff2f 114742047 
lincity-ng_2.10.1.orig.tar.gz
 98e92387e23614a22b037dc36dbb8db14c48c973 8524 lincity-ng_2.10.1-1.debian.tar.xz
 753f736f5333e9e4a5c913f6b28e4f352316e8b9 15129 
lincity-ng_2.10.1-1_source.buildinfo
Checksums-Sha256:
 bdea5c39e380fc2d8238c795503b65a4624083283525297c08c96c276da0fc55 2177 
lincity-ng_2.10.1-1.dsc
 4246099f66bd7580b00c730d597d32196c5ded72d8f391cff21f8d0136e5bf7d 114742047 
lincity-ng_2.10.1.orig.tar.gz
 87ca3f86205b7df0d13d2c83d4554467a60078b01ac67d856c81a720326cde3c 8524 
lincity-ng_2.10.1-1.debian.tar.xz
 b30b015b2ebacc2837d47a893ac4e98bc00dd042b771b0b8d5b4fa109ac152bd 15129 
lincity-ng_2.10.1-1_source.buildinfo
Files:
 69a1cd7007f276adf5248ff52f0c9603 2177 games optional lincity-ng_2.10.1-1.dsc
 f4232d2b609ea510a327d0c143571cb1 114742047 games optional 
lincity-ng_2.10.1.orig.tar.gz
 892d8e0530f343a0e992c276708e65f1 8524 games optional 
lincity-ng_2.10.1-1.debian.tar.xz
 510f4a948e84ec6a7773dc71ab62d28e 15129 games optional 
lincity-ng_2.10.1-1_source.buildinfo

-BEGIN PGP SIGNATURE-

Bug#1068181: asunder: Asunder package calls wavpack version not present (5.6.0-1+b1). 5.7.0-1 in repo. Cannot install.

2024-04-01 Thread Peter Blackman


Hi Josh,

On 01/04/2024 17:33, Peter B wrote:


I have no idea where '5.6.0-1+b1' is coming from.


I do now! Its occurred to me that you need to run
  apt update

so that current packages can be installed.
wavpack was updated in testing a couple of weeks ago.


Please read
  https://wiki.debian.org/DebianTesting
carefully.


Regards,
Peter


P.S.   I'll be closing this 'bug' report.

Bug#1068198: debian-installer-netboot-images: accesses the internet during build

Source: debian-installer-netboot-images
Severity: serious
Justification: Policy 4.9
X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
Control: affects -1 buildd.debian.org

Hi,

debian-installer-netboot-images attemps network access during build,
although only to the mirrors listed in /etc/apt/sources.list and in a
secure way. This is forbidden by Policy 4.9:

  For packages in the main archive, required targets must not attempt
  network access, except, via the loopback interface, to services on the
  build host that have been started by the build.

In addition this brings constraints to the build daemons infrastructure.

Regards,
Aurelien

Bug#1068199: librocfft0: callback test failures on gfx900 and gfx1030

2024-04-01 Thread Cordell Bloor

Package: librocfft0
Version: 5.7.1-1
Severity: normal
X-Debbugs-Cc: c...@slerp.xyz

Dear Maintainer,

The rocfft callback tests were passing with rocfft 5.5.1 on hip 5.2.3,
but began failing when hip was updated to 5.7.1. These failures are
specific to gfx900 and gfx1030 to gfx1036. The failures are not observed on
gfx803, gfx906, gfx1010, gfx1100 or gfx1101. This problem remains
unchanged by the update of rocfft to 5.7.1.

This is a sample of the failing test output [1]:

161s [ RUN  ] rocfft_UnitTest.default_load_callback_complex_single
161s clients/tests/default_callbacks_test.cpp:280: Failure
161s Expected equality of these values:
161s   rocfft_execute(plan, _ptr, _ptr, info)
161s Which is: 1
161s   rocfft_status_success
161s Which is: 0
161s
161s clients/tests/default_callbacks_test.cpp:310: Failure
161s Expected: (diff.l_inf) < (type_epsilon()), actual: 
32.230823516845703 vs 3.75e-05
161s
161s [  FAILED  ] rocfft_UnitTest.default_load_callback_complex_single (349 ms)

It would be good to capture output with AMD_LOG_LEVEL=4 set in the
environment to view more information about the calls that are being made
to the HIP runtime.

Sincerely,
Cory Bloor

[1] 
https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1030/r/rocfft/9454/log.gz

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

Kernel: Linux 6.7.9-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages librocfft0 depends on:
ii  libamdhip64-5  5.7.1-3
ii  libc6  2.37-15.1
ii  libgcc-s1  14-20240330-1
ii  libsqlite3-0   3.45.2-1
ii  libstdc++6 14-20240330-1

librocfft0 recommends no packages.

librocfft0 suggests no packages.

-- no debconf information

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)

2024-04-01 Thread David Bremner

Sebastian Ramacher  writes:

> Control: affects -1 src:polymake
>
[...]
> Let's make sure that it is visible for polymake then. Otherwise I'll
> file it a third time ;)

Thanks, I thought to myself at some point this morning it should have
affects, and then, well, I didn't do it.

many hands make light-er work, I guess

David

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

2024-04-01 Thread Sven Joachim

On 2024-04-01 19:02 +0200, Alejandro Colomar wrote:

> Hi Sven,
>
> On Mon, Apr 01, 2024 at 06:38:52PM +0200, Sven Joachim wrote:
>> Makes perfect sense, but at the moment it can only be uploaded to
>> experimental.
>>
>> > We're not in a freeze, so I guess that's fair game.
>>
>> We're not in a freeze but in the middle of the largest transition in
>> Debian history[1], and during that a new major glibc version in unstable is
>> out of the question.
>>
>> >> files for now and re-include either when glibc 2.38 is in unstable or
>> >> when it is in testing.
>> >
>> > Why do we need to wait to ask for a glibc-doc_2.38-7 with the patch
>> > dropped?  Does 2.38 have any freeze at the moment?
>>
>> Yes.  Every new major glibc version requires a transition (requiring
>> rebuilds of all packages which use @GLIBC_PRIVATE symbols, among other
>> things), and the one for glibc 2.38[2] has been pending for three
>> months[3].
>
> Hmmm, I understand.  If you want to temporarily drop these pages from
> manpages-dev, go ahead.  Please undrop them when glibc-doc can make a
> new release.  BTW, I guess glibc-doc must match libc6 version?

It is built from the same source package, so yes.

Cheers,
   Sven

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

Hi Sven,

On Mon, Apr 01, 2024 at 06:38:52PM +0200, Sven Joachim wrote:
> Makes perfect sense, but at the moment it can only be uploaded to
> experimental.
> 
> > We're not in a freeze, so I guess that's fair game.
> 
> We're not in a freeze but in the middle of the largest transition in
> Debian history[1], and during that a new major glibc version in unstable is
> out of the question.
> 
> >> files for now and re-include either when glibc 2.38 is in unstable or
> >> when it is in testing.
> >
> > Why do we need to wait to ask for a glibc-doc_2.38-7 with the patch
> > dropped?  Does 2.38 have any freeze at the moment?
> 
> Yes.  Every new major glibc version requires a transition (requiring
> rebuilds of all packages which use @GLIBC_PRIVATE symbols, among other
> things), and the one for glibc 2.38[2] has been pending for three
> months[3].

Hmmm, I understand.  If you want to temporarily drop these pages from
manpages-dev, go ahead.  Please undrop them when glibc-doc can make a
new release.  BTW, I guess glibc-doc must match libc6 version?
Otherwise, you could have a more recent glibc-doc that drops these pages
without upgrading libc6.  Are documentation changes frozen in such a
transition?

> 
> >> There is also the problem that some derivatives (most notably Ubuntu)
> >> are already shipping glibc 2.39 and will have to adjust Breaks/Replaces
> >> versions in manpages-dev accordingly.
> >
> > Hmmm.  I suggest they patch glibc-doc to remove those manual pages.
> > They have been unsupported for a long time.  The last change in
> > glibc-doc is from 2013.
> 
> I guess Ubuntu can then drop the glibc-doc package entirely, as they do
> not ship the upstream changelogs in it, and after dropping the pthread_*
> manpages the package would be empty.  TBH, I do not see much value in
> these changelogs and will probably uninstall glibc-doc from my systems.

Good.

Have a lovely day!
Alex

> 
> Cheers,
>Sven
> 
> 
> 1. https://lists.debian.org/debian-devel-announce/2024/02/msg5.html
> 2. https://release.debian.org/transitions/html/glibc-2.38.html
> 3. https://bugs.debian.org/1059852

-- 

Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Bug#1068196: xdg-terminal-exec: Please update to upstream version

2024-04-01 Thread Vladimir K

Source: xdg-terminal-exec
Version: 0~20230318-1
Severity: normal

Dear Maintainer, in recent months the proposed spec was refined and the 
implementation
was subjected to intensive optimizations. It can now consume stock desktop 
entries
in most cases and supports optional cache.

Context: 
https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/3

Consistent states are now version-tagged upstream.

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

Kernel: Linux 6.7.9-amd64 (SMP w/8 CPU threads; PREEMPT)
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)

Bug#1068197: debian-installer: accesses the internet during build

Source: debian-installer
Severity: serious
Justification: Policy 4.9
X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
Control: affects -1 buildd.debian.org

Hi,

debian-installer attemps network access during build, although only to
the mirrors listed in /etc/apt/sources.list and in a secure way. This is
forbidden by Policy 4.9:

  For packages in the main archive, required targets must not attempt
  network access, except, via the loopback interface, to services on the
  build host that have been started by the build.

In addition this brings constraints to the build daemons infrastructure.

Regards,
Aurelien

Bug#1068181: asunder: Asunder package calls wavpack version not present (5.6.0-1+b1). 5.7.0-1 in repo. Cannot install.

2024-04-01 Thread Peter B


On 01/04/2024 13:07, Joshua Aspinall wrote:

Package: asunder
Version: 3.0.1+ds-1
Severity: normal
X-Debbugs-Cc: joshaspin...@member.fsf.org

Dear Maintainer,

Cannot install Asunder on testing under normal conditions due to wavpack 
version not present (reports file not found)

Looking through the packages browser can see a newer version (5.7.0-1) than 
that one it tries to grab.  Hopefully a simple fix!

Please contact me if I can help further.

Kind Regards,
Josh.


..snip


Versions of packages asunder depends on:
pn  cdparanoia   
ii  libatk1.0-0  2.50.0-1+b1
ii  libc62.37-15
ii  libcddb2 1.3.2-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  libglib2.0-0 2.78.4-1
ii  libgtk2.0-0  2.24.33-3

Versions of packages asunder recommends:
pn  flac  
pn  lame  
pn  opus-tools
pn  vorbis-tools  
pn  wavpack   

Versions of packages asunder suggests:
pn  musepack-tools  

Hi Josh,

I can see that you do not have cdparanoia installed.
Its a dependency, and you will not be able to install asunder without it.
Also none of the recommends is installed.
You need at least one for Asunder to do anything useful.

wavpack is only a recommends, not a dependency, and the recommends is 
unversioned.

I have no idea where '5.6.0-1+b1' is coming from.
Have removed wavpack here and reinstalled asunder several times without 
any problems.



What exactly is the response to
  sudo dpkg -i asunder_3.0.1+ds-1_amd64.deb
?


Also, what happens if you try to install grimripper?
(grimripper is the gtk3 version of asunder)


Regards,
Peter

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

2024-04-01 Thread Sven Joachim

On 2024-04-01 18:00 +0200, Alejandro Colomar wrote:

> Hi Sven,
>
> On Mon, Apr 01, 2024 at 05:35:18PM +0200, Sven Joachim wrote:
>> Obviously the manpages-dev package should not have shipped these files
>> as long as there are in glibc-doc; this is tracked in #1068166.
>
> I CCed back in 2023-10 the debian-glibc@ list notifying that these pages
> were absorbed into the Linux man-pages project.  They didn't respond.

Thanks.  That might have fallen through the cracks.

>> Adding a Breaks on glibc-doc (<= 2.38-6) to manpages-dev is no good,
>> because that version is only in experimental and will remain there for
>> several weeks if not months.  I think manpages-dev should drop these
>
> Why not add glibc-doc 2.38-7 dropping the patch that adds these pages?

Makes perfect sense, but at the moment it can only be uploaded to
experimental.

> We're not in a freeze, so I guess that's fair game.

We're not in a freeze but in the middle of the largest transition in
Debian history[1], and during that a new major glibc version in unstable is
out of the question.

>> files for now and re-include either when glibc 2.38 is in unstable or
>> when it is in testing.
>
> Why do we need to wait to ask for a glibc-doc_2.38-7 with the patch
> dropped?  Does 2.38 have any freeze at the moment?

Yes.  Every new major glibc version requires a transition (requiring
rebuilds of all packages which use @GLIBC_PRIVATE symbols, among other
things), and the one for glibc 2.38[2] has been pending for three
months[3].

>> There is also the problem that some derivatives (most notably Ubuntu)
>> are already shipping glibc 2.39 and will have to adjust Breaks/Replaces
>> versions in manpages-dev accordingly.
>
> Hmmm.  I suggest they patch glibc-doc to remove those manual pages.
> They have been unsupported for a long time.  The last change in
> glibc-doc is from 2013.

I guess Ubuntu can then drop the glibc-doc package entirely, as they do
not ship the upstream changelogs in it, and after dropping the pthread_*
manpages the package would be empty.  TBH, I do not see much value in
these changelogs and will probably uninstall glibc-doc from my systems.

Cheers,
   Sven

1. https://lists.debian.org/debian-devel-announce/2024/02/msg5.html
2. https://release.debian.org/transitions/html/glibc-2.38.html
3. https://bugs.debian.org/1059852

Bug#1068192: debian-policy: extend forbidden network access to contrib and non-free

On 2024-04-01 18:18, Bill Allombert wrote:
> On Mon, Apr 01, 2024 at 06:08:10PM +0200, Aurelien Jarno wrote:
> > On 2024-04-01 17:52, Bill Allombert wrote:
> > > On Mon, Apr 01, 2024 at 05:29:54PM +0200, Aurelien Jarno wrote:
> > > > Package: debian-policy
> > > > Version: 4.6.2.1
> > > > Severity: normal
> > > > X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
> > > > Control: affects -1 buildd.debian.org
> > > > 
> > > > Hi,
> > > > 
> > > > The debian policy, section 4.9, forbids network access for packages in
> > > > the main archive, which implicitly means they are authorized for
> > > > packages in contrib and non-free (and non-free-firmware once #1029211 is
> > > > fixed).
> > > > 
> > > > This gives constraints on the build daemons infrastructure and also
> > > > brings some security concerns. Would it be possible to extend this
> > > > restriction to all archives?
> > > 
> > > Does the build daemons actually build non-free ? 
> > 
> > Yes, they do, though only part of non-free, only the packages that have
> > Autobuild: yes and that have been put on an allow list after review.
> 
> Is your concern is that the package start to do network acces during build
> after it has been added to the allow list ?

Yes, this is the security concern.

> Do you need "Autobuild: yes" to preclude network access ?

Not right now, but the goal is to fully disable the network access, and
we do not want to have to special case contrib or non-free, as it just
makes things complicated.

Regards
Aurelien

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

Bug#1068192: debian-policy: extend forbidden network access to contrib and non-free

2024-04-01 Thread Bill Allombert

On Mon, Apr 01, 2024 at 06:08:10PM +0200, Aurelien Jarno wrote:
> On 2024-04-01 17:52, Bill Allombert wrote:
> > On Mon, Apr 01, 2024 at 05:29:54PM +0200, Aurelien Jarno wrote:
> > > Package: debian-policy
> > > Version: 4.6.2.1
> > > Severity: normal
> > > X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
> > > Control: affects -1 buildd.debian.org
> > > 
> > > Hi,
> > > 
> > > The debian policy, section 4.9, forbids network access for packages in
> > > the main archive, which implicitly means they are authorized for
> > > packages in contrib and non-free (and non-free-firmware once #1029211 is
> > > fixed).
> > > 
> > > This gives constraints on the build daemons infrastructure and also
> > > brings some security concerns. Would it be possible to extend this
> > > restriction to all archives?
> > 
> > Does the build daemons actually build non-free ? 
> 
> Yes, they do, though only part of non-free, only the packages that have
> Autobuild: yes and that have been put on an allow list after review.

Is your concern is that the package start to do network acces during build
after it has been added to the allow list ?

Do you need "Autobuild: yes" to preclude network access ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Bug#1067450: Not a bug, can be closed

2024-04-01 Thread Daniel Huhardeaux

The encoured error is due to a mix of ttyd from unstable with 
libwebsockets17 from bookworm.


--
Daniel

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free

2024-04-01 Thread Ansgar 

Hi,

On Mon, 2024-04-01 at 17:52 +0200, Bill Allombert wrote:
> On Mon, Apr 01, 2024 at 05:29:54PM +0200, Aurelien Jarno wrote:
> > This gives constraints on the build daemons infrastructure and also
> > brings some security concerns. Would it be possible to extend this
> > restriction to all archives?
> 
> Does the build daemons actually build non-free ? 

Yes: allowlisted non-free packages get built on buildds.

Not allowing network access for contrib and non-free as well seems
reasonable to me.

Ansgar

Bug#1068192: debian-policy: extend forbidden network access to contrib and non-free

On 2024-04-01 17:52, Bill Allombert wrote:
> On Mon, Apr 01, 2024 at 05:29:54PM +0200, Aurelien Jarno wrote:
> > Package: debian-policy
> > Version: 4.6.2.1
> > Severity: normal
> > X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
> > Control: affects -1 buildd.debian.org
> > 
> > Hi,
> > 
> > The debian policy, section 4.9, forbids network access for packages in
> > the main archive, which implicitly means they are authorized for
> > packages in contrib and non-free (and non-free-firmware once #1029211 is
> > fixed).
> > 
> > This gives constraints on the build daemons infrastructure and also
> > brings some security concerns. Would it be possible to extend this
> > restriction to all archives?
> 
> Does the build daemons actually build non-free ? 

Yes, they do, though only part of non-free, only the packages that have
Autobuild: yes and that have been put on an allow list after review.

Regards
Aurelien

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

Bug#1068195: USB keyboard unusable when booting with init=/bin/bash

2024-04-01 Thread Vangelis Koukis

Package: initramfs-tools
Version: 0.142
Severity: normal
X-Debbugs-Cc: vkou...@gmail.com

Hello,

Thank you for your work on initramfs-tools.

I have just installed Debian bookworm on a new machine.
I am using a USB keyboard, which works fine when the system boots normally, but
was unusable when booting with init=/bin/bash.

I had to add usbhid, hid-generic to /etc/initramfs-tools/modules and rebuild
initramfs to fix this.  This doesn't align with
https://wiki.debian.org/Keyboard, which seems to imply that everything would
just work since in my case I was running with MODULES=most, and I shouldn't
have to add anything to /etc/initramfs-tools/modules.

Also noting that the suggested modules in /etc/initramfs-tools/modules should
include hid-generic anyway.

It's not obvious to me why I had to update /etc/initramfs-tools/modules. I
understand that listing modules in /etc/initramfs-tools/modules asks initramfs
to load them explicitly.

While looking into the problem, I verified that MODULES=most and lsinitramfs
showed both modules present in the initramfs. But it seems somehow they weren't
loaded into the kernel, so the device was unusable.

One more thing that may be relevant:
When booting, it takes some time for the keyboard to be detected:
The bash prompt appears, then after 3-4 seconds the kernel logs show new USB
devices being detected, including the keyboard. Then, the keyboard is usable,
but only if I've taken care to list both usbhid, hid-generic in
/etc/initramfs-tools/modules, despite setting MODULES=most.

Could this be a funny interaction with udev? Maybe initramfs-tools runs udev
explicitly, at certain parts of the process, before the USB keyboard actually
appears, so by the time it appears there is no-one there to actually load the
necessary modules? I would have run "udevadm settle" myself to verify, but
hey, no keyboard :)

I looked at the code and saw initramfs-tools does attempt to load HID-related
modules early on when breaking early, since udev does not yet run. Why not do
it anyway, since a keyboard is critical to debugging?

Looking forward to any insight you may have.

Thank you,
Vangelis.


-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 40M Apr  1 18:44 /boot/initrd.img-6.1.0-18-amd64
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.1.0-18-amd64 root=/dev/mapper/maxwellvg-root ro quiet

-- resume
RESUME=/dev/mapper/maxwellvg-swap_1
-- /proc/filesystems
ext3
ext2
ext4
fuseblk
vfat

-- lsmod
Module  Size  Used by
tls   135168  0
joydev 28672  0
uvcvideo  131072  0
videobuf2_vmalloc  20480  1 uvcvideo
videobuf2_memops   20480  1 videobuf2_vmalloc
videobuf2_v4l2 36864  1 uvcvideo
snd_usb_audio 376832  0
videobuf2_common   73728  4 
videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops
snd_usbmidi_lib45056  1 snd_usb_audio
videodev  294912  3 videobuf2_v4l2,uvcvideo,videobuf2_common
snd_rawmidi53248  1 snd_usbmidi_lib
snd_seq_device 16384  1 snd_rawmidi
mc 77824  5 
videodev,snd_usb_audio,videobuf2_v4l2,uvcvideo,videobuf2_common
binfmt_misc24576  1
snd_hda_codec_hdmi 81920  1
nls_ascii  16384  1
nls_cp437  20480  1
vfat   24576  1
fat90112  1 vfat
intel_rapl_msr 20480  0
intel_rapl_common  32768  1 intel_rapl_msr
snd_sof_pci_intel_tgl16384  0
x86_pkg_temp_thermal20480  0
intel_powerclamp   20480  0
snd_sof_intel_hda_common   188416  1 snd_sof_pci_intel_tgl
coretemp   20480  0
soundwire_intel49152  1 snd_sof_intel_hda_common
soundwire_generic_allocation16384  1 soundwire_intel
soundwire_cadence  40960  1 soundwire_intel
snd_sof_intel_hda  20480  1 snd_sof_intel_hda_common
kvm_intel 380928  0
snd_sof_pci24576  2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl
snd_sof_xtensa_dsp 16384  1 snd_sof_intel_hda_common
kvm  1142784  1 kvm_intel
i915 3055616  2
irqbypass  16384  1 kvm
snd_sof   274432  2 snd_sof_pci,snd_sof_intel_hda_common
snd_sof_utils  20480  1 snd_sof
snd_soc_hdac_hda   24576  1 snd_sof_intel_hda_common
snd_hda_ext_core   40960  2 snd_sof_intel_hda_common,snd_soc_hdac_hda
snd_soc_acpi_intel_match81920  2 
snd_sof_intel_hda_common,snd_sof_pci_intel_tgl
snd_soc_acpi   16384  2 
snd_soc_acpi_intel_match,snd_sof_intel_hda_common
ghash_clmulni_intel16384  0
sha512_ssse3   49152  0
snd_soc_core  352256  4 
soundwire_intel,snd_sof,snd_sof_intel_hda_common,snd_soc_hdac_hda
sha512_generic 16384  1 sha512_ssse3
sha256_ssse3   32768  0
snd_compress   28672  1 snd_soc_core
sha1_ssse3 32768  0
soundwire_bus 102400  3 
soundwire_intel,soundwire_generic_allocation,soundwire_cadence

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

Hi Sven,

On Mon, Apr 01, 2024 at 05:35:18PM +0200, Sven Joachim wrote:
> Obviously the manpages-dev package should not have shipped these files
> as long as there are in glibc-doc; this is tracked in #1068166.

I CCed back in 2023-10 the debian-glibc@ list notifying that these pages
were absorbed into the Linux man-pages project.  They didn't respond.

However, the original author of the pages talked to me, agreeing to
that.  Other glibc upstream maintainers also participated in the thread.

> 
> > Please, remove from glibc-doc those manual pages that conflict with
> > manpages-dev.
> 
> Considering that the manpages in glibc-doc are not included upstream and

The history is a bit more complex than that.  They were originally
written upstream.  Then glibc removed them.  A decade later, Debian
added them back via a patch, with some modifications.  I noted down the
history in the discussion linked above.

> created via a Debian patch, that makes a lot of sense.  I was not aware
> of that fact.
> 
> > Marcos, you'll also need to specify a breaks with glibc-doc versions
> > up to (and including) 6.38-6 in the next revision of manpages-dev, and
> > drop 6.7-1.
> 
> Adding a Breaks on glibc-doc (<= 2.38-6) to manpages-dev is no good,
> because that version is only in experimental and will remain there for
> several weeks if not months.  I think manpages-dev should drop these

Why not add glibc-doc 2.38-7 dropping the patch that adds these pages?
We're not in a freeze, so I guess that's fair game.

> files for now and re-include either when glibc 2.38 is in unstable or
> when it is in testing.

Why do we need to wait to ask for a glibc-doc_2.38-7 with the patch
dropped?  Does 2.38 have any freeze at the moment?

> There is also the problem that some derivatives (most notably Ubuntu)
> are already shipping glibc 2.39 and will have to adjust Breaks/Replaces
> versions in manpages-dev accordingly.

Hmmm.  I suggest they patch glibc-doc to remove those manual pages.
They have been unsupported for a long time.  The last change in
glibc-doc is from 2013.

> Thoughts?
> 
> Cheers,
>Sven

Have a lovely day!
Alex

-- 

Looking for a remote C programming job at the moment.

signature.asc
Description: PGP signature

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free

2024-04-01 Thread Bill Allombert

On Mon, Apr 01, 2024 at 05:29:54PM +0200, Aurelien Jarno wrote:
> Package: debian-policy
> Version: 4.6.2.1
> Severity: normal
> X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
> Control: affects -1 buildd.debian.org
> 
> Hi,
> 
> The debian policy, section 4.9, forbids network access for packages in
> the main archive, which implicitly means they are authorized for
> packages in contrib and non-free (and non-free-firmware once #1029211 is
> fixed).
> 
> This gives constraints on the build daemons infrastructure and also
> brings some security concerns. Would it be possible to extend this
> restriction to all archives?

Does the build daemons actually build non-free ? 

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Bug#1068194: pcsx2: FTBFS: /<>/plugins/cdvdGigaherz/src/CDVD.cpp:143:19: error: ‘system_error’ in namespace ‘std’ does not name a type

Source: pcsx2
Version: 1.6.0+dfsg-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=pcsx2=i386=1.6.0%2Bdfsg-2%2Bb10=1711729892=0

[  7%] Generating ../tr_TR__pcsx2_Main.gmo
cd /<>/obj-i686-linux-gnu/locales && /usr/bin/msgmerge --quiet 
--update --backup=none -s /<>/locales/tr_TR/pcsx2_Main.po 
/<>/locales/templates/pcsx2_Main.pot
/<>/plugins/cdvdGigaherz/src/CDVD.cpp: In function ‘bool 
StartKeepAliveThread()’:
/<>/plugins/cdvdGigaherz/src/CDVD.cpp:143:19: error: 
‘system_error’ in namespace ‘std’ does not name a type
  143 | } catch (std::system_error &) {
  |   ^~~~
/<>/plugins/cdvdGigaherz/src/CDVD.cpp: In function ‘s32 
CDVDopen(const char*)’:
/<>/plugins/cdvdGigaherz/src/CDVD.cpp:188:19: error: 
‘runtime_error’ in namespace ‘std’ does not name a type
  188 | } catch (std::runtime_error ) {
  |   ^
/<>/plugins/cdvdGigaherz/src/CDVD.cpp:22:1: note: 
‘std::runtime_error’ is defined in header ‘’; did you forget to 
‘#include ’?
   21 | #include "svnrev.h"
  +++ |+#include 
   22 | 
cd /<>/obj-i686-linux-gnu/locales && /usr/bin/msgfmt -o 
/<>/obj-i686-linux-gnu/tr_TR__pcsx2_Main.gmo 
/<>/locales/tr_TR/pcsx2_Main.po
/<>/plugins/cdvdGigaherz/src/CDVD.cpp:189:15: error: ‘ex’ was not 
declared in this scope
  189 | fputs(ex.what(), stdout);
  |   ^~
[  8%] Generating ../zh_CN__pcsx2_Main.gmo
cd /<>/obj-i686-linux-gnu/locales && /usr/bin/msgmerge --quiet 
--update --backup=none -s /<>/locales/zh_CN/pcsx2_Main.po 
/<>/locales/templates/pcsx2_Main.pot
cd /<>/obj-i686-linux-gnu/locales && /usr/bin/msgfmt -o 
/<>/obj-i686-linux-gnu/zh_CN__pcsx2_Main.gmo 
/<>/locales/zh_CN/pcsx2_Main.po
[  8%] Generating ../zh_TW__pcsx2_Main.gmo
cd /<>/obj-i686-linux-gnu/locales && /usr/bin/msgmerge --quiet 
--update --backup=none -s /<>/locales/zh_TW/pcsx2_Main.po 
/<>/locales/templates/pcsx2_Main.pot
make[3]: *** 
[plugins/cdvdGigaherz/src/CMakeFiles/cdvdGigaherz.dir/build.make:79: 
plugins/cdvdGigaherz/src/CMakeFiles/cdvdGigaherz.dir/CDVD.cpp.o] Error 1

Cheers
-- 
Sebastian Ramacher

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

2024-04-01 Thread Sven Joachim

On 2024-04-01 16:23 +0200, Alejandro Colomar wrote:

> Package: glibc-doc
> Version: 2.38-6
> Severity: serious
> Justification: Policy 7.4
> X-Debbugs-Cc: a...@kernel.org, mar...@debian.org
>
> Dear Maintainer,
>
> The Linux man-pages project has recently added the pthread_*(3) manual
> pages that were provided by glibc-doc.  The first upstream version of
> the Linux man-pages that includes these pages is man-pages-6.06.  Here's
> what was added:
>
>   $ git diff --stat b06cd070f..128a3ae35
>man3/pthread_cond_init.3| 264 
>man3/pthread_condattr_init.3|  48 
>man3/pthread_key_create.3   | 178 +
>man3/pthread_mutex_init.3   | 241 ++
>man3/pthread_mutexattr_setkind_np.3 |  52 
>man3/pthread_once.3 |  44 
>6 files changed, 827 insertions(+)
>
> Debian's manpages-dev_6.7-1_all.deb has been the first package since
> that happened, and I've noticed that dpkg(1) (via apt-get(8)) refuses to
> upgrade manpages-dev due to a conflict with glibc-doc.

>   $ sudo apt-get upgrade -V;
>   [...]
>   Do you want to continue? [Y/n] y
>   Reading changelogs... Done
>   (Reading database ... 404853 files and directories currently installed.)
>   Preparing to unpack .../manpages-dev_6.7-1_all.deb ...
>   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.38-6
>   Errors were encountered while processing:
>/var/cache/apt/archives/manpages-dev_6.7-1_all.deb
>   needrestart is being skipped since dpkg has failed
>   E: Sub-process /usr/bin/dpkg returned an error code (1)

Obviously the manpages-dev package should not have shipped these files
as long as there are in glibc-doc; this is tracked in #1068166.

> Please, remove from glibc-doc those manual pages that conflict with
> manpages-dev.

Considering that the manpages in glibc-doc are not included upstream and
created via a Debian patch, that makes a lot of sense.  I was not aware
of that fact.

> Marcos, you'll also need to specify a breaks with glibc-doc versions
> up to (and including) 6.38-6 in the next revision of manpages-dev, and
> drop 6.7-1.

Adding a Breaks on glibc-doc (<= 2.38-6) to manpages-dev is no good,
because that version is only in experimental and will remain there for
several weeks if not months.  I think manpages-dev should drop these
files for now and re-include either when glibc 2.38 is in unstable or
when it is in testing.

There is also the problem that some derivatives (most notably Ubuntu)
are already shipping glibc 2.39 and will have to adjust Breaks/Replaces
versions in manpages-dev accordingly.  Thoughts?

Cheers,
   Sven

Bug#1068193: rust-reqwest: please package 0.12

Source: rust-reqwest
Version: 0.11.24-1
Severity: wishlist
X-Debbugs-Cc: sramac...@debian.org

As $subject. rust-drt-tools will require reqest 0.12 with the next
release.

Cheers
-- 
Sebastian Ramacher

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free

Package: debian-policy
Version: 4.6.2.1
Severity: normal
X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org
Control: affects -1 buildd.debian.org

Hi,

The debian policy, section 4.9, forbids network access for packages in
the main archive, which implicitly means they are authorized for
packages in contrib and non-free (and non-free-firmware once #1029211 is
fixed).

This gives constraints on the build daemons infrastructure and also
brings some security concerns. Would it be possible to extend this
restriction to all archives?

Regards,
Aurelien

Bug#1068191: RM: jam -- obsolete, bug, (almost) not used anymore

2024-04-01 Thread Alexandre Detiste

Package: jam
Version: 2.6.1-2
Severity: normal
X-Debbugs-Cc: Dmitry Smirnov , debian...@lists.debian.org, 
Yann Dirson , Graeme W. Gill 

Dear Maintainers, Dear Author,

After I've finished the packaging of lincity-ng later today;
'argyll' will be the very last piece of software needing
unmaintained 'jam' to build.

Would it be possible, in two steps:
 - to have argyll build with something else (CMake, meson...?)
 - drop jam package

Greetings


-

Maintainer: Dmitry Smirnov 
Package: argyll

Maintainer: Debian Games Team 
Package: lincity-ng

Bug#1068189: debhelper: --link-doc checking for known packages makes linux-signed build FTBFS

2024-04-01 Thread Niels Thykier

Salvatore Bonaccorso:

Source: debhelper
Version: 13.15
Severity: serious
Tags: ftbfs
Justification: Regression for other package builds, FTBFS
X-Debbugs-Cc: car...@debian.org,debian-ker...@lists.debian.org
Control: affects -1 + src:linux,src:linux-signed-amd64,src:linux-signed-arm64

Hi Niels,

Not fully investigated, but starting to fill a bugreport. I noticed
that the src:linux pipeline on salsa started to fail for the
jobs in th build-signed stage (in the build-signed job).

https://salsa.debian.org/carnil/linux/-/jobs/5527774

(and for saving the output):

[...]

(attached as well the raw log)

I'm not 100% sure yet, this might be a problem in our packaging in
which case we can re-eassign. But it only got triggered with the
change recently in debhelper:

https://salsa.debian.org/debian/debhelper/-/commit/dec5cfad00e2abd9ee3594f90c93f3fa42bb73ff

Regards,
Salvatore

Hi Salvatore

It was a suggestion raised (I think on IRC) to have debhelper explicitly
check these parameters, because a lot of t64 breakage was "unnoticed" by
debhelper. That is, when people forgot to update --link-doc parameters
(etc.).

The code for `--link-doc` uses `${binary:Version}` for the dependency,
so the package should really be from the same source[1]. In my view, it
was never a case that was expected to work between source packages.

I think `linux` with `linux-signed` is doing something really special
here (especially considering it has worked so far), and I think the
question is whether `linux`/`linux-signed` should get a special-case or
concluding that the `--link-doc` is not suitable for the
`linux`/`linux-signed` case.

I would like to hear your case for what makes `--link-doc` sensible for
the `linux-signed` case. I know of `linux-signed`, but I have no idea
what you are dealing with in practice, so it is hard for me to make a
judgement call on this (other than my biased gut feeling of wanting to
minimize special-cases).

Best regards,
Niels

[1]: Policy also documents the "same source" requirement.

https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information

Bug#1067930: RFS: python-keep/2.10.1-1 [ITP] -- Personal shell command keeper and snippets manager

2024-04-01 Thread Shriram Ravindranathan


Dear Mentors,

This package "python-keep" is a dependency of the new upstream version 
of another package that I am adopting called "howdoi" 



Neither of these packages have salsa repositories under the debian group 
yet. Could you please create these two repositories for me?


Thanking you,

--
Shriram Ravindranathan



OpenPGP_0xFC7E951A7BEF0836.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059535: transition: abseil

On 2024-04-01 10:39:08 -0400, Benjamin Barenblat wrote:
> On Monday, April  1, 2024, at  2:57 PM +0200, Sebastian Ramacher wrote:
> > Could you please re-add the build dependency on dpkg-dev (>= 1.22.5) to
> > ensure that the build with the new armel/armhf ABI only migrates when
> > the time_t transition is ready to advance?
> 
> Yes! I am going to wait for the current upload (20230802.1-3) to finish
> building on RISC-V, just to make sure the FTBFS is fixed. (It’s already
> 11 hours in; it can’t take too much longer.) Once that’s done, I’ll
> upload a new 20230802.1-4 with a Build-Depends: dpkg-dev (>= 1.22.5).
> (If you’d prefer that I preempt the current build and upload
> 20230802.1-4 right now, just let me know.)

Sounds good. Let's wait for -3 to finish building on riscv64.

Cheers
-- 
Sebastian Ramacher

Bug#1056156: varnish: CVE-2023-44487: VSV00013 Varnish HTTP/2 Rapid Reset Attack

2024-04-01 Thread Marco d'Itri

Control: found -1 5.0.0-1
Control: fixed -1 7.4.2

On Nov 17, Salvatore Bonaccorso  wrote:

> CVE-2023-44487[0]:
> | The HTTP/2 protocol allows a denial of service (server resource
> | consumption) because request cancellation can reset many streams
> | quickly, as exploited in the wild in August through October 2023.
Fixing this issue would require backporting a significant amount of 
new features in varnish and I do not believe that it would be practical.

I am inclined to downgrade this bug because:
- this is just a DoS attack
- it only concerns people using hitch for TLS termination instead of 
  a full web server like nginx or haproxy

nginx in stable is also vulnerable, BTW.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1059535: transition: abseil

2024-04-01 Thread Benjamin Barenblat

On Monday, April  1, 2024, at  2:57 PM +0200, Sebastian Ramacher wrote:
> Could you please re-add the build dependency on dpkg-dev (>= 1.22.5) to
> ensure that the build with the new armel/armhf ABI only migrates when
> the time_t transition is ready to advance?

Yes! I am going to wait for the current upload (20230802.1-3) to finish
building on RISC-V, just to make sure the FTBFS is fixed. (It’s already
11 hours in; it can’t take too much longer.) Once that’s done, I’ll
upload a new 20230802.1-4 with a Build-Depends: dpkg-dev (>= 1.22.5).
(If you’d prefer that I preempt the current build and upload
20230802.1-4 right now, just let me know.)

Bug#1068188: glibc-doc: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

On Mon, Apr 01, 2024 at 04:23:08PM +0200, Alejandro Colomar wrote:
> The Linux man-pages project has recently added the pthread_*(3) manual
> pages that were provided by glibc-doc.  The first upstream version of
> the Linux man-pages that includes these pages is man-pages-6.06.  Here's
> what was added:
> 
>   $ git diff --stat b06cd070f..128a3ae35
>man3/pthread_cond_init.3| 264 
>man3/pthread_condattr_init.3|  48 
>man3/pthread_key_create.3   | 178 +
>man3/pthread_mutex_init.3   | 241 ++
>man3/pthread_mutexattr_setkind_np.3 |  52 
>man3/pthread_once.3 |  44 
>6 files changed, 827 insertions(+)

Here's the relevant excerpt of the git-log(1):

* 128a3ae35 pthread_key_create.3: Mention glibc instead of LinuxThreads
* 8a00cac75 pthread_*.3: ffix (semantic newlines)
* 74235f157 pthread_*.3: ffix (paragraphing)
* 13151ec52 pthread_*.3: Remove AUTHOR section; add copyright; adapt TH
* c1c253d0e pthread_cond_init.3, pthread_condattr_init.3, 
pthread_key_create.3, pthread_mutex_init.3, pthread_mutexattr_setkind_np.3, 
pthread_once.3: Update the glibc pages with the debian/glibc version of them
*   87183bb8e Import debian/local/manpages/pthread_*.3 git history from 
debian/glibc
|\  
| * 02d79c7d9   * Remove linuxthreads from the tarball: - 
rules.d/tarball.mk: don't fetech linuxthreads and linuxthreads_db. - 
rules.d/build.mk: don't build linuxthreads manpages. - rules: don't run 
make clean in linuxthreads directory. - patches/any/local-sysctl.diff: drop 
the linuxthreads part. - patches/all/local-pthread-manpages.diff: remove.   
  - local/manpages/pthread_*.3: import the few remaining linuxthreads   
manpages. - debhelper.in/glibc-doc.manpages: update manpage locations.
|/  
* a254db8b3 pthread_cond_init.3, pthread_condattr_init.3, 
pthread_key_create.3, pthread_mutex_init.3, pthread_mutexattr_setkind_np.3, 
pthread_once.3: Import pages from glibc
* 87d09778d Revert "linuxthreads, linuxthreads_db: Directories removed 
(preserved in ports repository)."
*   281f670a4 Import linuxthreads/man/ git history from glibc
|\  
| * a3db24d46 linuxthreads, linuxthreads_db: Directories removed 
(preserved in ports repository).
| * 2988d2724 (CFLAGS-tst-align.c): Add -mpreferred-stack-boundary=4.
| * f7f73b1ca 2.5-18.1
| * 67eceac09 Update.
| * 7ffaa96aa Update.
| * 869af9b6a Correct example.
| * 31b1e42d5 LinuxThreads library.
|/  

-- 

Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Bug#1068190: telegram-desktop: FTBFS with abseil 20230802: (.text+0x270): undefined reference to `absl::debian3::base_internal::ThrowStdOutOfRange(char const*)'

Source: telegram-desktop
Version: 4.14.9+ds-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=telegram-desktop=arm64=4.14.9%2Bds-1%2Bb2=1711978921=0

cd /<>/obj-aarch64-linux-gnu/Telegram && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/Telegram.dir/link.txt --verbose=1
/usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -mbranch-protection=standard 
-ftemplate-backtrace-limit=0 -Wdate-time -D_FORTIFY_SOURCE=2 
-Werror=invalid-pch -Wl,-z,relro -Wl,-z,now -Wno-alloc-size-larger-than 
-Wno-stringop-overflow -Wno-odr -Wno-inline -pthread -Wl,--as-needed 
@CMakeFiles/Telegram.dir/objects1.rsp -o ../telegram-desktop  
liblib_tgcalls_legacy.a liblib_tgcalls.a lib_base/liblib_base.a 
lib_ui/liblib_ui.a lib_spellcheck/liblib_spellcheck.a 
lib_webview/liblib_webview.a liblib_tgvoip_bundled.a 
/usr/lib/aarch64-linux-gnu/libminizip.so liblib_tgcalls.a 
/usr/lib/aarch64-linux-gnu/libopenal.so /usr/lib/aarch64-linux-gnu/libtg_owt.a 
/usr/lib/aarch64-linux-gnu/libsrtp2.so 
/usr/lib/aarch64-linux-gnu/libprotobuf.so /usr/lib/aarch64-linux-gnu/libssl.so 
/usr/lib/aarch64-linux-gnu/libcrypto.so /usr/lib/aarch64-linux-gnu/libopus.so 
/usr/lib/aarch64-linux-gnu/libabsl_flags_parse.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_flags_usage.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_flags_usage_internal.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_flags_internal.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_flags_marshalling.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_flags_reflection.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_cord.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_cordz_info.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_cord_internal.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_cordz_functions.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_cordz_handle.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_crc_cord_state.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_crc32c.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_str_format_internal.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_crc_internal.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_crc_cpu_detect.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_raw_hash_set.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_hash.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_city.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_low_level_hash.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_hashtablez_sampler.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_exponential_biased.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_flags_config.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_flags_private_handle_accessor.so.20230802.0.1
 /usr/lib/aarch64-linux-gnu/libabsl_flags_commandlineflag.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_flags_commandlineflag_internal.so.20230802.0.1
 /usr/lib/aarch64-linux-gnu/libabsl_flags_program_name.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_bad_optional_access.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_synchronization.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_graphcycles_internal.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_kernel_timeout_internal.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_stacktrace.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_symbolize.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_malloc_internal.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_debugging_internal.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_demangle_internal.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_time.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_strings.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_string_view.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_throw_delegate.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_strings_internal.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_base.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_spinlock_wait.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_int128.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_civil_time.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_time_zone.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_bad_variant_access.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_raw_logging_internal.so.20230802.0.1 
/usr/lib/aarch64-linux-gnu/libabsl_log_severity.so.20230802.0.1 
-Wl,--push-state,--as-needed -latomic -Wl,--pop-state 
/usr/lib/aarch64-linux-gnu/libvpx.so /usr/lib/aarch64-linux-gnu/libm.so 
/usr/lib/aarch64-linux-gnu/libyuv.so /usr/lib/aarch64-linux-gnu/libX11.so 
/usr/lib/aarch64-linux-gnu/libXcomposite.so 
/usr/lib/aarch64-linux-gnu/libXdamage.so /usr/lib/aarch64-linux-gnu/libXext.so 
/usr/lib/aarch64-linux-gnu/libXfixes.so

Bug#1068107: cloud.debian.org: pull images with compromised xz packages

2024-04-01 Thread Bastian Blank

On Sat, Mar 30, 2024 at 12:44:35PM -0700, Ross Vandegrift wrote:
> Finally, apologies for not being able to do this myself - I still do not have
> my account setup for access to core machines.

Tasks related to this incident are tracked here:
https://salsa.debian.org/ftp-team/xz-2024-incident/-/issues/8

Bastian

-- 
Another dream that failed.  There's nothing sadder.
-- Kirk, "This side of Paradise", stardate 3417.3

Bug#1068189: debhelper: --link-doc checking for known packages makes linux-signed build FTBFS

2024-04-01 Thread Salvatore Bonaccorso

Source: debhelper
Version: 13.15
Severity: serious
Tags: ftbfs
Justification: Regression for other package builds, FTBFS
X-Debbugs-Cc: car...@debian.org,debian-ker...@lists.debian.org
Control: affects -1 + src:linux,src:linux-signed-amd64,src:linux-signed-arm64

Hi Niels,

Not fully investigated, but starting to fill a bugreport. I noticed
that the src:linux pipeline on salsa started to fail for the
jobs in th build-signed stage (in the build-signed job).

https://salsa.debian.org/carnil/linux/-/jobs/5527774

(and for saving the output):

dh_installdocs --link-doc=linux-headers-6.7+unreleased-cloud-amd64
dh_installdocs: error: Requested unknown package 
linux-headers-6.7+unreleased-cloud-amd64 via --link-doc, expected one of: 
linux-image-6.7+unreleased-amd64 linux-image-amd64 linux-headers-amd64 
linux-image-6.7+unreleased-cloud-amd64 linux-image-cloud-amd64 
linux-headers-cloud-amd64 linux-image-6.7+unreleased-rt-amd64 
linux-image-rt-amd64 linux-headers-rt-amd64
make[2]: *** [debian/rules.real:81: binary_meta] Error 25
make[1]: *** [debian/rules.gen:21: binary-arch_amd64_none_cloud-amd64_meta] 
Error 2
make: *** [debian/rules:19: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

(attached as well the raw log)

I'm not 100% sure yet, this might be a problem in our packaging in
which case we can re-eassign. But it only got triggered with the
change recently in debhelper:

https://salsa.debian.org/debian/debhelper/-/commit/dec5cfad00e2abd9ee3594f90c93f3fa42bb73ff

Regards,
Salvatore


5527774.log.gz
Description: application/gzip

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

Package: glibc-doc
Version: 2.38-6
Severity: serious
Justification: Policy 7.4
X-Debbugs-Cc: a...@kernel.org, mar...@debian.org

Dear Maintainer,

The Linux man-pages project has recently added the pthread_*(3) manual
pages that were provided by glibc-doc.  The first upstream version of
the Linux man-pages that includes these pages is man-pages-6.06.  Here's
what was added:

$ git diff --stat b06cd070f..128a3ae35
 man3/pthread_cond_init.3| 264 
 man3/pthread_condattr_init.3|  48 
 man3/pthread_key_create.3   | 178 +
 man3/pthread_mutex_init.3   | 241 ++
 man3/pthread_mutexattr_setkind_np.3 |  52 
 man3/pthread_once.3 |  44 
 6 files changed, 827 insertions(+)

Debian's manpages-dev_6.7-1_all.deb has been the first package since
that happened, and I've noticed that dpkg(1) (via apt-get(8)) refuses to
upgrade manpages-dev due to a conflict with glibc-doc.

$ sudo apt-get upgrade -V;
[...]
Do you want to continue? [Y/n] y
Reading changelogs... Done
(Reading database ... 404853 files and directories currently installed.)
Preparing to unpack .../manpages-dev_6.7-1_all.deb ...
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.38-6
Errors were encountered while processing:
 /var/cache/apt/archives/manpages-dev_6.7-1_all.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

Please, remove from glibc-doc those manual pages that conflict with
manpages-dev.

Marcos, you'll also need to specify a breaks with glibc-doc versions
up to (and including) 6.38-6 in the next revision of manpages-dev, and
drop 6.7-1.


Have a lovely day!
Alex


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

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

glibc-doc depends on no packages.

glibc-doc recommends no packages.

Versions of packages glibc-doc suggests:
ii  glibc-doc-reference  2.38-1

-- no debconf information

Bug#1067845: adduser: Reserving uid/gid from the uid/gid pools

2024-04-01 Thread Yair Yarom

Hi,

Attached is a patch to uidgidpool.t that tests several cases of the
reserved uids.
I'm not really proficient in these test tools, so I hope it works
properly...

BR,

On Thu, 28 Mar 2024 at 22:58, Marc Haber 
wrote:

> On Wed, Mar 27, 2024 at 04:55:35PM +0200, Yair Yarom wrote:
> > The UID_POOL (and GID_POOL) files contains UIDs that should be used for
> given
> > name. It would be helpful to reserve the UIDs for the future, so that
> the order
> > of adding users to the system won't affect the usability of the
> UIDs/names.
> >
> > I.e. if a UID is in the pool, it won't be used unless for the specific
> name in
> > the pool.
>
> That sounds sensible.
>
> Would you mind to contribute test cases as well? The canoncal place for
> those test cases would probably be debian/tests/f/uidgidpool.t
>
> Greetings
> Marc
>
>
> --
>
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
>


-- 

  /|   |
  \/   | Yair Yarom | System Group (DevOps)
  []   | The Rachel and Selim Benin School
  [] /\| of Computer Science and Engineering
  []//\\/  | The Hebrew University of Jerusalem
  [//  \\  | T +972-2-5494522 | F +972-2-5494522
  //\  | ir...@cs.huji.ac.il
 //|
--- a/debian/tests/f/uidgidpool.t
+++ b/debian/tests/f/uidgidpool.t
@@ -40,6 +40,18 @@
 'shell' => '/bin/sh',
}
 );
+my $firstuid = (sort map {$_->{id}} @uidlist)[0];
+
+my @uidreserved = (
+   {
+'name' => 'uidreserved1',
+'id' => $firstuid,
+'comment' => 'uidreserved1 pool account',
+'home' => '/home/uidreserved1',
+'ahome' => '/home/auidreserved1',
+'shell' => '/bin/sh',
+   }
+);
 
 my @gidlist = (
 {
@@ -50,6 +62,13 @@
  id => 32202,
 }
 );
+my $firstgid = (sort map {$_->{id}} @gidlist)[0];
+my @gidreserved = (
+   {
+name => 'gidreserved1',
+id => $firstgid,
+   }
+);
 
 # test creating user/group without uidpool set
 
@@ -68,11 +87,11 @@
 }
 
 sub cleanup {
-foreach my $user( @uidlist ) {
+foreach my $user( @uidlist, @uidreserved ) {
 system("/usr/sbin/deluser $quiet --remove-home $user->{name} 2>/dev/null");
 assert_user_does_not_exist($user->{name});
 }
-foreach my $group( @gidlist ) {
+foreach my $group( @gidlist, @gidreserved ) {
 system("/usr/sbin/delgroup $quiet $group->{name} 2>/dev/null");
 assert_group_does_not_exist($group->{name});
 }
@@ -160,6 +179,78 @@
 cleanup();
 }
 
+%confhash=();
+$confhash{"UID_POOL"}="$uidpoolfile";
+$confhash{"GID_POOL"}="$gidpoolfile";
+$confhash{"FIRST_UID"}="$firstuid";
+$confhash{"FIRST_GID"}="$firstgid";
+$confhash{"RESERVE_UID_POOL"}="0";
+$confhash{"RESERVE_GID_POOL"}="0";
+apply_config_hash(\%confhash);
+
+# test not reserved uid in pool
+
+foreach my $group( @gidreserved ) {
+assert_command_success('/usr/sbin/addgroup', $quiet,
+  $group->{name});
+assert_group_exists($group->{name});
+assert_group_has_gid($group->{name}, $group->{id});
+cleanup();
+
+assert_command_success('/usr/sbin/addgroup', $quiet,
+  '--gid', $agid, $group->{name});
+assert_group_exists($group->{name});
+assert_group_has_gid($group->{name}, $agid);
+cleanup();
+}
+
+foreach my $user( @uidreserved ) {
+assert_command_success('/usr/sbin/adduser', $quiet,
+  '--comment', '""', '--disabled-password', $user->{name});
+assert_user_exists($user->{name});
+assert_user_has_uid($user->{name}, $user->{id});
+cleanup();
+}
+
+%confhash=();
+$confhash{"UID_POOL"}="$uidpoolfile";
+$confhash{"GID_POOL"}="$gidpoolfile";
+$confhash{"FIRST_UID"}="$firstuid";
+$confhash{"FIRST_GID"}="$firstgid";
+$confhash{"RESERVE_UID_POOL"}="1";
+$confhash{"RESERVE_GID_POOL"}="1";
+apply_config_hash(\%confhash);
+
+# test reserved uid in pool
+
+foreach my $group( @gidreserved ) {
+assert_command_success('/usr/sbin/addgroup', $quiet,
+  $group->{name});
+assert_group_exists($group->{name});
+assert_gid_does_not_exist($group->{id});
+cleanup();
+
+assert_command_success('/usr/sbin/addgroup', $quiet,
+  '--gid', $group->{id}, $group->{name});
+assert_group_exists($group->{name});
+assert_group_has_gid($group->{name}, $group->{id});
+cleanup();
+}
+
+foreach my $user( @uidreserved ) {
+assert_command_success('/usr/sbin/adduser', $quiet,
+  '--comment', '""', '--disabled-password', $user->{name});
+assert_user_exists($user->{name});
+assert_uid_does_not_exist($user->{id});
+cleanup();
+
+assert_command_success('/usr/sbin/adduser', $quiet,
+  '--uid', $user->{id}, '--comment', '""', '--disabled-password', $user->{name});
+assert_user_exists($user->{name});
+assert_user_has_uid($user->{name}, $user->{id});
+cleanup();
+}
+
 # remove test

Bug#1068187: Session fails to start with gnome-session >= 46

2024-04-01 Thread Guido Günther

Package: phosh
Version: 0.37.1
Severity: grave

gnome-session no longer accepts the --systemd or --builtin arguments
which restults in the session failing to start.

This is already fixed in 0.37.0-2. Mostly filing this to get the version
tracking right.


-- 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_WARN, 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 phosh depends on:
ii  dconf-gsettings-backend [gsettings-bac  0.40.0-4+b1
kend]
ii  fonts-lato  2.015-1
ii  gnome-shell-common  44.9-1
ii  gsettings-desktop-schemas   46.0-1
ii  libc6   2.37-15
ii  libcairo2   1.18.0-1+b1
ii  libcallaudio-0-10.1.9-1+b1
ii  libcap2-bin 1:2.66-5
ii  libecal-2.0-2t643.50.3-2.2
ii  libedataserver-1.2-27t643.50.3-2.2
ii  libfeedback-0.0-0   0.2.1-1+b1
ii  libfribidi0 1.0.13-3+b1
ii  libgcr-base-3-1 3.41.2-1
ii  libgcr-ui-3-1   3.41.2-1
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b1
ii  libglib2.0-0t64 2.78.4-6
ii  libgnome-desktop-3-20t6444.0-5
ii  libgtk-3-0t64   3.24.41-4
ii  libgudev-1.0-0  238-3
ii  libhandy-1-01.8.3-1
ii  libical3t64 3.0.17-1.1
ii  libjson-glib-1.0-0  1.8.0-2
ii  libnm0  1.46.0-1
ii  libpam0g1.5.2-9.1+b1
ii  libpango-1.0-0  1.52.0+ds-1
ii  libpolkit-agent-1-0 124-1
ii  libpolkit-gobject-1-0   124-1
ii  libpulse-mainloop-glib0 16.1+dfsg1-3
ii  libpulse0   16.1+dfsg1-3
ii  libsecret-1-0   0.21.4-1
ii  libsystemd0 255.4-1
ii  libupower-glib3 1.90.2-8
ii  libwayland-client0  1.22.0-2.1+b1
ii  phoc0.37.0+next20240325.1905.b42258fa.1

Versions of packages phosh recommends:
ii  feedbackd  0.2.1-1+b1
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  iio-sensor-proxy   3.5-1+b1
ii  librsvg2-common2.54.7+dfsg-2
ii  phosh-mobile-tweaks0.37.0-1
hi  phosh-osk-stub 0.35.0
ii  slurp  1.5.0-1
ii  squeekboard1.24.0-1

phosh suggests no packages.

-- no debconf information

Bug#1068186: mozc: FTBFS with abseil 20230802: ../../base/init_mozc.cc:90:29: error: ‘absl::debian5::flags_internal::ArgvListAction’ has not been declared