Bug#1066645: gtkterm: FTBFS: ../src/interface.c:738:9: error: implicit declaration of function ‘g_sprintf’; did you mean ‘g_snprintf’? [-Werror=implicit-function-declaration]

[Steve Langasek]

Package: gtkterm
Followup-For: Bug #1066645
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Please find attached a patch for this issue which has been uploaded to
Ubuntu.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gtkterm-1.2.1/debian/patches/no-implicit-declarations.patch 
gtkterm-1.2.1/debian/patches/no-implicit-declarations.patch
--- gtkterm-1.2.1/debian/patches/no-implicit-declarations.patch 1969-12-31 
16:00:00.0 -0800
+++ gtkterm-1.2.1/debian/patches/no-implicit-declarations.patch 2024-04-09 
22:49:04.0 -0700
@@ -0,0 +1,28 @@
+Description: add missing includes
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1066645
+Last-Update: 2024-04-09
+Forwarded: no
+
+Index: gtkterm-1.2.1/src/interface.c
+===
+--- gtkterm-1.2.1.orig/src/interface.c
 gtkterm-1.2.1/src/interface.c
+@@ -79,6 +79,7 @@
+ #include "logging.h"
+ 
+ #include 
++#include 
+ #include 
+ 
+ guint id;
+Index: gtkterm-1.2.1/src/user_signals.c
+===
+--- gtkterm-1.2.1.orig/src/user_signals.c
 gtkterm-1.2.1/src/user_signals.c
+@@ -1,3 +1,5 @@
++#include 
++#include 
+ #include 
+ #include "interface.h"
+ 
diff -Nru gtkterm-1.2.1/debian/patches/series 
gtkterm-1.2.1/debian/patches/series
--- gtkterm-1.2.1/debian/patches/series 1969-12-31 16:00:00.0 -0800
+++ gtkterm-1.2.1/debian/patches/series 2024-04-09 22:48:12.0 -0700
@@ -0,0 +1 @@
+no-implicit-declarations.patch

Bug#1066222: gtk-chtheme: FTBFS: theme_sel.c:113:5: error: implicit declaration of function ‘gtk_timeout_add’; did you mean ‘g_timeout_add’? [-Werror=implicit-function-declaration]

[Steve Langasek]

Package: gtk-chtheme
Followup-For: Bug #1066222
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Please find attached a patch for this issue which has been uploaded to
Ubuntu.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gtk-chtheme-0.3.1/debian/patches/no-implicit-declarations.patch 
gtk-chtheme-0.3.1/debian/patches/no-implicit-declarations.patch
--- gtk-chtheme-0.3.1/debian/patches/no-implicit-declarations.patch 
1969-12-31 16:00:00.0 -0800
+++ gtk-chtheme-0.3.1/debian/patches/no-implicit-declarations.patch 
2024-04-09 22:44:20.0 -0700
@@ -0,0 +1,19 @@
+Description: don't set GTK_DISABLE_DEPRECATED, deprecated APIs in use.
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1066222
+Last-Update: 2024-04-09
+Forwarded: no
+
+Index: gtk-chtheme-0.3.1/Makefile
+===
+--- gtk-chtheme-0.3.1.orig/Makefile
 gtk-chtheme-0.3.1/Makefile
+@@ -5,7 +5,7 @@
+ 
+ LDFLAGS = $(shell $(PKG_CONFIG) --libs gtk+-2.0)
+ CFLAGS += -Wall
+-CFLAGS += $(shell $(PKG_CONFIG) --cflags gtk+-2.0) -DGTK_DISABLE_BROKEN 
-DGTK_DISABLE_DEPRECATED
++CFLAGS += $(shell $(PKG_CONFIG) --cflags gtk+-2.0) -DGTK_DISABLE_BROKEN
+ CFLAGS += -DPROJNAME='"$(PROJNAME)"' -DVERSION='"$(VERSION)"'
+ CPPFLAGS =
+ CXXFLAGS =
diff -Nru gtk-chtheme-0.3.1/debian/patches/series 
gtk-chtheme-0.3.1/debian/patches/series
--- gtk-chtheme-0.3.1/debian/patches/series 2020-03-28 16:34:21.0 
-0700
+++ gtk-chtheme-0.3.1/debian/patches/series 2024-04-09 22:43:09.0 
-0700
@@ -2,3 +2,4 @@
 deprecated-on-gtk3+.patch
 cross.patch
 fix_ftbfs.patch
+no-implicit-declarations.patch

Bug#1066463: gnome-paint: FTBFS: cv_resize.c:368:9: error: implicit declaration of function ‘undo_add_resize’ [-Werror=implicit-function-declaration]

[Steve Langasek]

Package: gnome-paint
Followup-For: Bug #1066463
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Please find attached a patch for this issue which has been uploaded to
Ubuntu.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gnome-paint-0.4.0/debian/patches/no-implicit-declarations.patch 
gnome-paint-0.4.0/debian/patches/no-implicit-declarations.patch
--- gnome-paint-0.4.0/debian/patches/no-implicit-declarations.patch 
1969-12-31 16:00:00.0 -0800
+++ gnome-paint-0.4.0/debian/patches/no-implicit-declarations.patch 
2024-04-09 22:03:59.0 -0700
@@ -0,0 +1,192 @@
+Description: Add missing includes, don't set GTK_DISABLE_DEPRECATED
+ deprecated APIs are in use.
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1066463
+Last-Update: 2024-04-09
+Forwarded: no
+
+Index: gnome-paint-0.4.0/src/Makefile.am
+===
+--- gnome-paint-0.4.0.orig/src/Makefile.am
 gnome-paint-0.4.0/src/Makefile.am
+@@ -78,7 +78,6 @@
+ gnome_paint_CFLAGS = \
+   -DG_DISABLE_DEPRECATED\
+   -DG_DISABLE_SINGLE_INCLUDES\
+-  -DGTK_DISABLE_DEPRECATED\
+   -DGDK_DISABLE_SINGLE_INCLUDES\
+   -DGTK_DISABLE_SINGLE_INCLUDES
+ 
+Index: gnome-paint-0.4.0/src/color.c
+===
+--- gnome-paint-0.4.0.orig/src/color.c
 gnome-paint-0.4.0/src/color.c
+@@ -20,6 +20,8 @@
+ #include "common.h"
+ #include "color.h"
+ #include "cv_drawing.h"
++#include "cv_eraser_tool.h"
++#include "cv_paintbrush_tool.h"
+ #include "pixbuf_util.h"
+ 
+ #include 
+Index: gnome-paint-0.4.0/src/undo.c
+===
+--- gnome-paint-0.4.0.orig/src/undo.c
 gnome-paint-0.4.0/src/undo.c
+@@ -28,7 +28,7 @@
+ #include "gp-image.h"
+ #include "gp_point_array.h"
+ #include "file.h"
+-
++#include "selection.h"
+ 
+ 
+ typedef enum
+Index: gnome-paint-0.4.0/src/cv_rectangle_tool.c
+===
+--- gnome-paint-0.4.0.orig/src/cv_rectangle_tool.c
 gnome-paint-0.4.0/src/cv_rectangle_tool.c
+@@ -25,6 +25,7 @@
+ #include 
+ 
+ #include "cv_rectangle_tool.h"
++#include "cv_drawing.h"
+ #include "file.h"
+ #include "undo.h"
+ #include "gp_point_array.h"
+Index: gnome-paint-0.4.0/src/cv_pencil_tool.c
+===
+--- gnome-paint-0.4.0.orig/src/cv_pencil_tool.c
 gnome-paint-0.4.0/src/cv_pencil_tool.c
+@@ -23,6 +23,7 @@
+  
+  #include 
+ 
++#include "cv_drawing.h"
+ #include "cv_pencil_tool.h"
+ #include "gp_point_array.h"
+ #include "undo.h"
+Index: gnome-paint-0.4.0/src/cv_resize.c
+===
+--- gnome-paint-0.4.0.orig/src/cv_resize.c
 gnome-paint-0.4.0/src/cv_resize.c
+@@ -28,6 +28,7 @@
+ #include "cv_resize.h"
+ #include "cv_drawing.h"
+ #include "file.h"
++#include "undo.h"
+ 
+ 
+ #define BOX_EDGE_SIZE 4
+Index: gnome-paint-0.4.0/src/cv_ellipse_tool.c
+===
+--- gnome-paint-0.4.0.orig/src/cv_ellipse_tool.c
 gnome-paint-0.4.0/src/cv_ellipse_tool.c
+@@ -24,6 +24,7 @@
+  
+  #include 
+ 
++#include "cv_drawing.h"
+ #include "cv_ellipse_tool.h"
+ #include "file.h"
+ #include "undo.h"
+Index: gnome-paint-0.4.0/src/cv_polygon_tool.c
+===
+--- gnome-paint-0.4.0.orig/src/cv_polygon_tool.c
 gnome-paint-0.4.0/src/cv_polygon_tool.c
+@@ -24,6 +24,7 @@
+  
+  #include 
+ 
++#include "cv_drawing.h"
+ #include "cv_polygon_tool.h"
+ #include "gp_point_array.h"
+ #include "undo.h"
+Index: gnome-paint-0.4.0/src/image_menu.c
+===
+--- gnome-paint-0.4.0.orig/src/image_menu.c
 gnome-paint-0.4.0/src/image_menu.c
+@@ -28,6 +28,7 @@
+ #include "selection.h"
+ #include "image_menu.h"
+ #include "gp-image.h"
++#include "undo.h"
+ 
+ typedef enum{
+   GP_FILP_VERT = 0,
+Index: gnome-paint-0.4.0/src/selection.h
+===
+--- gnome-paint-0.4.0.orig/src/selection.h
 gnome-paint-0.4.0/src/selection.h
+@@ -38,6 +38,10 @@
+ gbooleangp_selection_start_action   ( GdkPoint *p );
+ voidgp_selection_do_action  ( GdkPoint *p );
+ voidgp_selection_draw   ( GdkDrawable *gdkd );
++voidgp_selection_invert ( void );
++voidgp_selection_rotate ( GdkPixbufRotation 
angle );
++void

Bug#1065193: RFS: libhx/4.23-1 [RC] -- C library providing queue, tree, I/O and utility functions

[Jochen Sprickerhof]

Hi Jörg,

is there anything I can help with to get libhx updated?
(I agree with what Tobias said below.)

Cheers Jochen


* Tobias Frost  [2024-03-17 20:22]:

Control: tags -1 moreinfo

On Sun, Mar 17, 2024 at 04:57:54PM +0100, Jörg Frings-Fürst wrote:

tags 1065193 - moreinfo
thanks

Hi Tobias,



Am Sonntag, dem 17.03.2024 um 14:39 +0100 schrieb Tobias Frost:
> Hi Jörg,
>
> "debcheckout libhx" still gives me 4.17-1 as head.
>
> After looking at your repo, I think I should point you to DEP-14
> as a recommended git layout for packaging.
> As the branch name indicates you are using per-package-revision
> branches:
> IMHO It makes little sense to have one branch per debian package
> version/revision; (I had a similiar discussion on vzlogger lately,
> so to avoid repetiions: #1064344#28)
>
> Please clarify how you want to manage the package in git, as
> this needs to be reflected in d/control's VCS-* fields correctly.
> (this is now blocking the upload.)

I have been using Vincent Driessen's branching model and the corresponding git
extension gitflow-avh for at least 7 years with Debian and for a long time at
work.

The default branch is master and development takes place in the develop branch.

The release candidates are managed in the branch release. The extension
debian/debian-version is used as a tag during the transfer.

The master branch always contains the last published executable version to which
the git tag in debian/control points.


a> The procedure is described in the README.debian.

ok, won't further argue about how to organize your git repo, but I can
only tell the Debian perspective: It is breaking expectations as a
debcheckout libhx does today NOT give me a state that represents the
package in unstable. VCS-Git specifies where the (package)
development is happening [1].

[1] Policy 5.6.26

But as I am not using the git repo as base for the sponsoring, lets put
that topic to rest.


>
> (The current fields say the package is maintained in the default branch
> of your repo. I see a debian/ directory there, but that one is missing
> released (it is at 4.17-1, while unstable is at 4.19-1.1)
>
> The review is based on the .dsc, timestamped on mentors.d.n
> 2024-03-17 12:00
>
> d/changelog is *STILL* changing history for the 4.19-1 changelog
> block. (This issue must be fixed before upload.)
>

I think these were artifacts because my changes to the NMU were not adopted. Has
been corrected.


No it has not. I expect old changelog entries to be *identical* to
the ones that have been uploaded, and they still are not, so I fear
we are talking past each other. Please let me know what you think that
you have fixed, so that we can spot the different expectations.

For my perspective:
This is the diff from debian/changelog from the current
version in the archives and the dsc uploaded to mentors at 2024-03-17 14:45
You are still rewriting history (second hunk of this diff), this hunk
should not exists.

diff -Naur archive/libhx-4.19/debian/changelog 
mentors/libhx-4.23/debian/changelog
--- archive/libhx-4.19/debian/changelog 2024-02-28 13:48:09.0 +0100
+++ mentors/libhx-4.23/debian/changelog 2024-03-17 15:23:31.0 +0100
@@ -1,3 +1,17 @@
+libhx (4.23-1) unstable; urgency=medium
+
+  * New upstream release (Closes: #1064734).
+  * Add debian/.gitignore
+  * Remove not longer needed debian/libhx-dev.lintian-overrides.
+  * Fix debian/libhx32t64.lintian-overrides.
+  * debian/copyright:
+- Add 2024 to myself.
+  * debian/control:
+- Readd BD dpkg-dev (>= 1.22.5).
+  Thanks to Tobias Frost 
+
+ -- Jörg Frings-Fürst   Sun, 17 Mar 2024 15:23:31 +0100
+
libhx (4.19-1.1) unstable; urgency=medium

  * Non-maintainer upload.
@@ -9,11 +23,8 @@

  * New upstream release.
- Refresh symbols files.
-  * Remove empty debian/libhx-dev.symbols.
-  * debian/rules:
-- Remove build of libhx-dev.symbols.

- -- Jörg Frings-Fürst   Sun, 17 Dec 2023 14:44:39 +0100
+ -- Jörg Frings-Fürst   Tue, 21 Nov 2023 10:41:07 +0100

libhx (4.14-1) unstable; urgency=medium


signature.asc
Description: PGP signature

Bug#1066584: gnome-breakout: FTBFS: anim.c:58:17: error: implicit declaration of function ‘gb_error’; did you mean ‘g_error’? [-Werror=implicit-function-declaration]

[Steve Langasek]

Package: gnome-breakout
Followup-For: Bug #1066584
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Please find attached a patch for this issue, which has been uploaded to
Ubuntu.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gnome-breakout-0.5.3/debian/patches/no-implicit-declarations.patch 
gnome-breakout-0.5.3/debian/patches/no-implicit-declarations.patch
--- gnome-breakout-0.5.3/debian/patches/no-implicit-declarations.patch  
1969-12-31 16:00:00.0 -0800
+++ gnome-breakout-0.5.3/debian/patches/no-implicit-declarations.patch  
2024-04-09 21:55:20.0 -0700
@@ -0,0 +1,30 @@
+Description: fix missing gb_error() prototype
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1066584
+Last-Update: 2024-04-09
+Forwarded: no
+
+Index: gnome-breakout-0.5.3/src/anim.c
+===
+--- gnome-breakout-0.5.3.orig/src/anim.c
 gnome-breakout-0.5.3/src/anim.c
+@@ -11,6 +11,7 @@
+ #include"gui.h"
+ #include"animloc.h"
+ #include"anim.h"
++#include "util.h"
+ 
+ /* Database of all the animations */
+ static Animation *animations;
+Index: gnome-breakout-0.5.3/src/gui.c
+===
+--- gnome-breakout-0.5.3.orig/src/gui.c
 gnome-breakout-0.5.3/src/gui.c
+@@ -14,6 +14,7 @@
+ #include "gui-callbacks.h"
+ #include "game.h"
+ #include "anim.h"
++#include "util.h"
+ 
+ /* See gui.h for more info */
+ static GuiInfo *gui = NULL;
diff -Nru gnome-breakout-0.5.3/debian/patches/series 
gnome-breakout-0.5.3/debian/patches/series
--- gnome-breakout-0.5.3/debian/patches/series  2018-09-13 05:13:26.0 
-0700
+++ gnome-breakout-0.5.3/debian/patches/series  2024-04-09 21:52:53.0 
-0700
@@ -7,3 +7,4 @@
 07_fix_wformat_warnings.patch
 08_link_mathlib.patch
 09_goocanvas_port.patch
+no-implicit-declarations.patch

Bug#1068732: prometheus-ipmi-exporter: debian path patch breaks local collection with sudo

[Ross Vandegrift]

Package: prometheus-ipmi-exporter
Version: 1.8.0-1
Severity: normal
X-Debbugs-Cc: rvandegr...@debian.org

Hello,

The Debian package for prometheus-ipmi-exporter carries a patch [1] to set
freeipmi.path by default.  Due to a surprising design, this breaks the config
required to run a local exporter as an unprivileged user.

That involves using sudo as follows:
  modules:
default:
  collectors:
- bmc
- ipmi
  collector_cmd:
bmc: sudo
ipmi: sudo
  custom_args:
bmc:
  - bmc-info
ipmi:
  - ipmimonitoring

Surprisingly, freeimpi.path applies to the collect_cmd entires.  So the
exporter prepends /usr/bin to those entires, and fails to find sudo.  Since
there is no way to override this, I don't see any way to run without root.

There's an upstream report of this issue at [2].

Thanks,
Ross


[1] - 
https://salsa.debian.org/go-team/packages/prometheus-ipmi-exporter/-/blob/debian/sid/debian/patches/0001-Set-sane-defaults-for-Debian-systems.patch
[2] - https://github.com/prometheus-community/ipmi_exporter/issues/153


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

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

Versions of packages prometheus-ipmi-exporter depends on:
ii  adduser  3.137
pn  freeipmi-tools   
ii  init-system-helpers  1.66
ii  libc62.37-15
ii  systemd-sysv 255.4-1

prometheus-ipmi-exporter recommends no packages.

prometheus-ipmi-exporter suggests no packages.

Bug#1067205: tkcvs: diff for NMU version 8.2.3-2

[Boyuan Yang]

Control: tags 1067205 + patch
Control: tags 1067205 + pending

Dear maintainer,

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

Regards.

diff -u tkcvs-8.2.3/debian/changelog tkcvs-8.2.3/debian/changelog
--- tkcvs-8.2.3/debian/changelog
+++ tkcvs-8.2.3/debian/changelog
@@ -1,3 +1,9 @@
+tkcvs (8.2.3-2) unstable; urgency=medium
+
+  * Take over package maintenance via ITS process. (Closes: #1067205)
+
+ -- Boyuan Yang   Wed, 10 Apr 2024 00:00:14 -0400
+
 tkcvs (8.2.3-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u tkcvs-8.2.3/debian/control tkcvs-8.2.3/debian/control
--- tkcvs-8.2.3/debian/control
+++ tkcvs-8.2.3/debian/control
@@ -1,7 +1,7 @@
 Source: tkcvs
 Section: vcs
 Priority: optional
-Maintainer: Tim Cutts 
+Maintainer: Boyuan Yang 
 Standards-Version: 3.9.3
 Homepage: http://www.twobarleycorns.net/tkcvs.html
 Build-Depends: debhelper (>= 7.0.0)


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

Bug#1068731: falcosecurity-libs: FTBFS on riscv64 and ppc64el

[Bo YU]

Source: falcosecurity-libs
Version: 0.15.1-1
Severity: serious
Tags: ftbfs, patch

Dear Maintainer,

It seems new upstream release ftbfs on riscv64 and ppc64el due to:

```
/<>/userspace/chisel/chisel.cpp: In static member function ‘static 
bool sinsp_chisel::init_lua_chisel(chisel_desc&, const std::string&)’:
/<>/userspace/chisel/chisel.cpp:978:9: error: ‘luaL_setfuncs’ was 
not declared in this scope; did you mean ‘lua_setfenv’?
  978 | luaL_setfuncs(ls, ll_tool, 0);
  | ^
  | lua_setfenv
/<>/userspace/chisel/chisel.cpp: In member function ‘void 
sinsp_chisel::load(std::string, bool)’:
/<>/userspace/chisel/chisel.cpp:1189:9: error: ‘luaL_setfuncs’ was 
not declared in this scope; did you mean ‘lua_setfenv’?
 1189 | luaL_setfuncs(m_ls, ll_tool, 0);
  | ^
  | lua_setfenv
[ 53%] Building CXX object 
test/drivers/CMakeFiles/drivers_test.dir/test_suites/syscall_exit_suite/vfork_x.cpp.o
```

See 
https://buildd.debian.org/status/fetch.php?pkg=falcosecurity-libs=riscv64=0.15.1-1=1712602717=0
 
and 
https://buildd.debian.org/status/fetch.php?pkg=falcosecurity-libs=riscv64=0.15.1-1=1712602717=0

And there is no still luajit support for riscv64(or ppc64el?), so this[0] is 
right. but maybe we need upgrade to >liblua5.3[1].

BTW, it was build failed again with the patch on ppc64el but I tested it
on qemu-user and I ddi not have look more this.

Apart from these two architectures, FTBFS on other architectures due to
test failed[2]. But I think this is another story.

[0]: 
https://salsa.debian.org/debian/falcosecurity-libs/-/blob/master/debian/control?ref_type=heads#L24
[1]: 
https://github.com/owasp-modsecurity/ModSecurity/issues/1622#issuecomment-345841731
[2]: https://buildd.debian.org/status/package.php?p=falcosecurity-libs

-- 
Regards,
--
  Bo YU

diff -Nru falcosecurity-libs-0.15.1/debian/changelog 
falcosecurity-libs-0.15.1/debian/changelog
--- falcosecurity-libs-0.15.1/debian/changelog  2024-04-07 02:54:51.0 
+0800
+++ falcosecurity-libs-0.15.1/debian/changelog  2024-04-09 22:22:39.0 
+0800
@@ -1,3 +1,11 @@
+falcosecurity-libs (0.15.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use liblua5.3-dev instead of liblua5.1-dev to fix ftbfs 
+on riscv64 and ppc64el. (Closes: #-1)
+
+ -- Bo YU   Tue, 09 Apr 2024 22:22:39 +0800
+
 falcosecurity-libs (0.15.1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru falcosecurity-libs-0.15.1/debian/control 
falcosecurity-libs-0.15.1/debian/control
--- falcosecurity-libs-0.15.1/debian/control2024-02-03 14:44:31.0 
+0800
+++ falcosecurity-libs-0.15.1/debian/control2024-04-09 22:22:04.0 
+0800
@@ -21,7 +21,7 @@
protobuf-compiler,
protobuf-compiler-grpc,
libprotobuf-dev,
-   libluajit-5.1-dev [amd64 arm64 armel armhf i386 mips64el s390x] 
| liblua5.1-0-dev,
+   libluajit-5.1-dev [amd64 arm64 armel armhf i386 mips64el s390x] 
| liblua5.3-dev,
libelf-dev,
libre2-dev,
libcap-dev,


signature.asc
Description: PGP signature

Bug#1067629: FTBFS: Build killed with signal TERM after 150 minutes of inactivity

[Torrance, Douglas]

Control: reassign -1 gprbuild
Control: found -1 2024.1.20231009-4
Control: affects -1 src:phcpack

On Mon, 25 Mar 2024 00:49:45 +0500 Andrey Rakhmatullin  wrote:

Source: phcpack
Version: 2.4.90+dfsg-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=phcpack=armhf=2.4.90%2Bdfsg-1=1711030010=0

   debian/rules execute_after_dh_auto_clean
make[1]: Entering directory '/<>'
gprclean src/Ada/Main/main.gpr || true
E: Build killed with signal TERM after 150 minutes of inactivity


This seems to be a bug with gprclean, as we're hanging at the initial dh_clean
step when building phcpack.  I was able to reproduce this on an armhf
porterbox.  Sending an interrupt while it's hanging with gdb gives the
following.  Perhaps it's related to the t64 transition?

   Starting program: /usr/bin/gprclean -v src/Ada/Main/main.gpr
   [Thread debugging using libthread_db enabled]
   Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
   GPRCLEAN Pro 18.0w (19940713) (arm-linux-gnueabihf)
   Copyright (C) 2006-2016, AdaCore
   
   Parsing Project File "src/Ada/Main/main.gpr".
   
150 lines: No errors

   TMPDIR = "/tmp/GPR.22180"
   /usr/bin/gprconfig --batch -o /tmp/GPR.22180/GNAT-TEMP-01.TMP 
--target=armhf-linux --fallback-targets --config=c --config=ada 
--config=c++
   [Detaching after fork from child process 22185]
   Checking configuration /tmp/GPR.22180/GNAT-TEMP-01.TMP
   Setting the default project search directories
  Adding directory "/usr/armhf-linux/share/gpr"
  Adding directory "/usr/armhf-linux/lib/gnat"
  Adding directory "/usr/share/gpr"
  Adding directory "/usr/lib/gnat"
   /usr/bin/gprconfig --batch -o /tmp/GPR.22180/GNAT-TEMP-02.TMP 
--target=armhf-linux --fallback-targets --config=c --config=ada 
--config=c++
   [Detaching after fork from child process 22203]
   Checking configuration /tmp/GPR.22180/GNAT-TEMP-02.TMP
   Setting the default project search directories
  Adding directory "/usr/armhf-linux/share/gpr"
  Adding directory "/usr/armhf-linux/lib/gnat"
  Adding directory "/usr/share/gpr"
  Adding directory "/usr/lib/gnat"
150 lines: No errors
   
   Parsing of Project File "src/Ada/Main/main.gpr" is finished.
   
   Cleaning project "main"
   
   
   No file has been deleted

   ^C
   Program received signal SIGINT, Interrupt.
   0xb5f7948a in __pthread_cond_timedwait64 ()
  from /lib/arm-linux-gnueabihf/libc.so.6
   (gdb) bt
   #0  0xb5f7948a in __pthread_cond_timedwait64 ()
  from /lib/arm-linux-gnueabihf/libc.so.6
   #1  0xb5f79636 in pthread_cond_timedwait ()
  from /lib/arm-linux-gnueabihf/libc.so.6
   #2  0xb63258c6 in system.task_primitives.operations.monotonic.timed_sleep ()
  from /lib/arm-linux-gnueabihf/libgnarl-13.so
   #3  0xb6325c7a in system.task_primitives.operations.timed_sleep ()
  from /lib/arm-linux-gnueabihf/libgnarl-13.so
   #4  0xb632b820 in system.tasking.stages.finalize_global_tasks ()
  from /lib/arm-linux-gnueabihf/libgnarl-13.so
   #5  0x00553930 in ?? ()
   #6  0xb5f3b7da in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
   #7  0xb5f3b87e in __libc_start_main () from 
/lib/arm-linux-gnueabihf/libc.so.6
   #8  0x005539ac in ?? ()
   Backtrace stopped: previous frame identical to this frame (corrupt stack?)


signature.asc
Description: PGP signature

Bug#1059262: trilinos: add loongarch64 support

[zhangdandan]

Hi maintainers,

On Fri, 29 Mar 2024 09:53:53 +0800 zhangdandan wrote:

>
> The trilinos itself blocks the compilation of many packages.
> Based on the attached patch, the trilinos package was compiled
> successfully on my local loong64 rootfs environment.
> I have built 132 binary packages from trilinos on local ENV.
>
I have generated a debdiff for loong64.
Please consider the patch I have attached.
Could you enable loong64 support in debian/control in the next upload.
Looking forward to your reply.

In addition, if I need to submit a merge-request to 
https://salsa.debian.org/science-team/trilinos, please contact me in time.


Thanks,
Dandan Zhang
diff -Nru trilinos-13.2.0/debian/control trilinos-13.2.0/debian/control
--- trilinos-13.2.0/debian/control  2023-09-04 12:17:04.0 +
+++ trilinos-13.2.0/debian/control  2023-09-04 16:41:09.0 +
@@ -35,7 +35,7 @@
 Vcs-Browser: https://salsa.debian.org/science-team/trilinos
 
 Package: trilinos-all-dev
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libs
 Depends: ${misc:Depends}, ${mydevpackages}
@@ -50,7 +50,7 @@
  This package depends on all Trilinos development packages.
 
 Package: trilinos-dev
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libs
 Depends: ${misc:Depends}
@@ -65,7 +65,7 @@
  This package contains the development header and some makefile templates.
 
 Package: libtrilinos-amesos-13.2
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -77,7 +77,7 @@
  This package contains the dynamic libraries.
 
 Package: libtrilinos-amesos-dev
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libdevel
 # Manually add libtrilinos-trilinosss-dev as dependency until
@@ -92,7 +92,7 @@
  This package provides headers.
 
 Package: libtrilinos-amesos2-13.2
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -104,7 +104,7 @@
  This package contains the dynamic libraries.
 
 Package: libtrilinos-amesos2-dev
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libdevel
 # Manually add libtrilinos-trilinosss-dev as dependency until
@@ -119,7 +119,7 @@
  This package provides headers.
 
 Package: libtrilinos-anasazi-13.2
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -134,7 +134,7 @@
  This package contains the dynamic libraries.
 
 Package: libtrilinos-anasazi-dev
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libdevel
 Depends: libtrilinos-anasazi-13.2 (= ${binary:Version}), trilinos-dev, 
${misc:Depends}
@@ -150,7 +150,7 @@
  This package provides headers.
 
 Package: libtrilinos-aztecoo-13.2
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -164,7 +164,7 @@
  This package contains the dynamic libraries.
 
 Package: libtrilinos-aztecoo-dev
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libdevel
 Depends: liblapack-dev, libtrilinos-aztecoo-13.2 (= ${binary:Version}), 
trilinos-dev, ${misc:Depends}
@@ -179,7 +179,7 @@
  This package provides headers.
 
 Package: libtrilinos-belos-13.2
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -193,7 +193,7 @@
  This package contains the dynamic libraries.
 
 Package: libtrilinos-belos-dev
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libdevel
 Depends: libtrilinos-belos-13.2 (= ${binary:Version}), trilinos-dev, 
${misc:Depends}
@@ -210,7 +210,7 @@
  This package provides headers.
 
 Package: libtrilinos-epetra-13.2
-Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 ppc64el s390x ppc64 riscv64 loong64
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -222,7 +222,7 @@
  This package contains the dynamic libraries.
 
 Package: 

Bug#1067911: FTBFS: error: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is not valid for C++ [-Werror]

[Chris Knadle]

Hello Audrey.

Apparently this new bug got introduced with the time_t 64bit transition:

"abi=time64 turns on -Werror=implicit-function-declaration in 
dpkg-buildflags, which causes unrelated build failures."


See: https://wiki.debian.org/BrainDumpT64

https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=4993fe783

What I don't know is what has to be done now to get zeroc-ice fixed. 
Does this require an upload to disable the implict-function-declaration 
flag, or does this simply require a binNMU?


I need to fix this to allow zeroc-ice to transition to Testing, in order 
to allow mumble to transition to Testing.


   -- Chris

--
Chris Knadle
chris.kna...@coredump.us


Source: zeroc-ice
Version: 3.7.10-2.1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=zeroc-
ice=armhf=3.7.10-2.1=1711639887=0

arm-linux-gnueabihf-g++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-
protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -MT

modules/IcePy/build/arm-linux-gnueabihf/shared/pic/Grammar.o -MMD -MP -MF
modules/IcePy/build/arm-linux-gnueabihf/shared/pic/Grammar.Td -Wall 
-Wextra

-Wshadow -Wdeprecated -Werror -pthread -DNDEBUG -Imodules/IcePy
-I../cpp/include -I../cpp/include/generated -I../cpp/src
-I/usr/include/python3.11 -I/usr/include/python3.11 -Wsign-compare -g
-Werror=implicit-function-declaration -fstack-protector-strong 
-fstack-clash-
protection -Wformat -Werror=format-security -DNDEBUG -g -fwrapv -O2 
-Wall -Wno-

missing-field-initializers -Wno-psabi -fPIC -fvisibility=hidden
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time
-D_FORTIFY_SOURCE=2 -c ../cpp/src/Slice/Grammar.cpp -o 
modules/IcePy/build/arm-

linux-gnueabihf/shared/pic/Grammar.o
cc1plus: error: ‘-Werror=’ argument 
‘-Werror=implicit-function-declaration’ is

not valid for C++ [-Werror]
cc1plus: error: ‘-Werror=’ argument 
‘-Werror=implicit-function-declaration’ is

not valid for C++ [-Werror]
cc1plus: error: ‘-Werror=’ argument 
‘-Werror=implicit-function-declaration’ is

not valid for C++ [-Werror]
cc1plus: error: ‘-Werror=’ argument 
‘-Werror=implicit-function-declaration’ is

not valid for C++ [-Werror]

Bug#1066608: dvbstreamer: FTBFS: standard/dvb/sdtprocessor.c:299:14: error: implicit declaration of function ‘UTF8_nextchar’ [-Werror=implicit-function-declaration]

[Steve Langasek]

Package: dvbstreamer
Followup-For: Bug #1066608
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Please find attached a patch for this issue which has been uploaded to
Ubuntu.  In addition to the missing declaration of UTF8_nextchar(), this
fixes a typo which would cause one of the plugins to build, but have
unresolvable symbol references.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch 
dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch
--- dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch 
1969-12-31 16:00:00.0 -0800
+++ dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch 
2024-04-09 17:01:35.0 -0700
@@ -0,0 +1,38 @@
+Description: fix missing declaration of UTF8_nextchar() and typo
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1066608
+Last-Update: 2024-04-09
+Forwarded: no
+
+Index: dvbstreamer-2.1.0/src/standard/dvb/sdtprocessor.c
+===
+--- dvbstreamer-2.1.0.orig/src/standard/dvb/sdtprocessor.c
 dvbstreamer-2.1.0/src/standard/dvb/sdtprocessor.c
+@@ -46,6 +46,7 @@
+ #include "sdtprocessor.h"
+ #include "dvbtext.h"
+ #include "standard/dvb.h"
++#include "utf8.h"
+ 
+ 
/***
+ * Defines 
 *
+Index: dvbstreamer-2.1.0/src/plugins/cam.c
+===
+--- dvbstreamer-2.1.0.orig/src/plugins/cam.c
 dvbstreamer-2.1.0/src/plugins/cam.c
+@@ -97,7 +97,7 @@
+ 
+ if (pmt->i_program_number == service->id)
+ {
+-needs_decrypting = PMTDoesNeedDecypting(pmt);
++needs_decrypting = PMTDoesNeedDecrypting(pmt);
+ 
+ if (currentPMT)
+ {
+@@ -197,4 +197,4 @@
+ }
+ 
+ return false;
+-}
+\ No newline at end of file
++}
diff -Nru dvbstreamer-2.1.0/debian/patches/series 
dvbstreamer-2.1.0/debian/patches/series
--- dvbstreamer-2.1.0/debian/patches/series 2021-10-16 01:37:38.0 
-0700
+++ dvbstreamer-2.1.0/debian/patches/series 2024-04-09 17:00:23.0 
-0700
@@ -16,3 +16,4 @@
 
 ## does not apply, needs some care
 #svn_819.diff
+no-implicit-declarations.patch

Bug#1066286: das-watchdog: FTBFS: test_rt.c:32:33: error: implicit declaration of function ‘getpid’ [-Werror=implicit-function-declaration]

[Steve Langasek]

Package: das-watchdog
Followup-For: Bug #1066286
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Please find attached a patch for this issue, which has been uploaded to
Ubuntu.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru das-watchdog-0.9.0/debian/patches/no-implicit-declarations.patch 
das-watchdog-0.9.0/debian/patches/no-implicit-declarations.patch
--- das-watchdog-0.9.0/debian/patches/no-implicit-declarations.patch
1969-12-31 16:00:00.0 -0800
+++ das-watchdog-0.9.0/debian/patches/no-implicit-declarations.patch
2024-04-09 16:13:22.0 -0700
@@ -0,0 +1,18 @@
+Description: add missing unistd.h include
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1066286
+Last-Update: 2024-04-09
+Forwarded: no
+
+Index: das-watchdog-0.9.0/test_rt.c
+===
+--- das-watchdog-0.9.0.orig/test_rt.c
 das-watchdog-0.9.0/test_rt.c
+@@ -4,6 +4,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ int main() {
+   struct sched_param params;
diff -Nru das-watchdog-0.9.0/debian/patches/series 
das-watchdog-0.9.0/debian/patches/series
--- das-watchdog-0.9.0/debian/patches/series2023-09-19 01:59:37.0 
-0700
+++ das-watchdog-0.9.0/debian/patches/series2024-04-09 16:11:24.0 
-0700
@@ -6,3 +6,4 @@
 0001-Remove-duplicate-check-for-temp-i-0.patch
 0003-The-result-of-fgetc-is-an-int-not-a-char.patch
 fix-memory-leak-on-realloc.patch
+no-implicit-declarations.patch

Bug#1068730: Fails to build from source since removal of liblz4-tool

[Christoph Biedl]

Source: systemd
Severity: serious
Tags: patch
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Greetings,

systemd build-depends on liblz4-tool but that package is no longer build
from src:lz4 (since 1.9.4-2, uploaded about a week ago). Just replacing
the dependency with lz4 seems to fix this problem (build passes, didn't
check further).

Cheers,

Christoph

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

Kernel: Linux 6.6.23 (SMP w/8 CPU threads)
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)



signature.asc
Description: PGP signature

Bug#1068729: translate-toolkit: get_moz_enUS fails to run

[Sudip Mukherjee]

Package: translate-toolkit
Version: 3.12.2-1
Severity: normal

Dear Maintainer,

get_moz_enUS fails to run with the error:

$ get_moz_enUS
Traceback (most recent call last):
  File "/usr/bin/get_moz_enUS", line 160, in 
process_l10n_ini(product_ini)
  File "/usr/bin/get_moz_enUS", line 46, in process_l10n_ini
with open(path_neutral(inifile)) as fh:
 ^^^
FileNotFoundError: [Errno 2] No such file or directory: 
'mozilla/locales/l10n.ini'

-- 
Regards
Sudip

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

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

Versions of packages translate-toolkit depends on:
ii  python33.11.6-1
ii  python3-pkg-resources  68.1.2-2
ii  python3-translate  3.12.2-1

Versions of packages translate-toolkit recommends:
ii  translate-toolkit-doc  3.12.2-1

translate-toolkit suggests no packages.

Bug#1066887: ENhance Patch for local-gen

[M. Buecher]

On 2024-04-09 23:49, Aurelien Jarno wrote:

Hi,

On 2024-03-15 16:13, M. Buecher wrote:

Adding / back to end of the path, so that a locale file is immediately
found.
diff --git a/debian/local/usr_sbin/locale-gen b/debian/local/usr_sbin/locale-gen
index 7fa3d772..1711a4f0 100755
--- a/debian/local/usr_sbin/locale-gen
+++ b/debian/local/usr_sbin/locale-gen
@@ -23,6 +23,12 @@ is_entry_ok() {
fi
  }
  
+if [ -z "${I18NPATH:-}" ]; then

+  if [ -d "${USER_LOCALES}" ]; then
+I18NPATH="${USER_LOCALES%%/locales*}/"
+  fi
+fi
+
  echo "Generating locales (this might take a while)..."
  while read -r locale charset; do
if [ -z "$locale" ] || [ "${locale#\#}" != "$locale" ]; then continue; 
fi
@@ -46,7 +52,7 @@ while read -r locale charset; do
input="$USER_LOCALES/$input"
fi
fi
-   localedef -i "$input" -c -f "$charset" -A /usr/share/locale/locale.alias 
"$locale" || :
+   I18NPATH="${I18NPATH}" localedef -i "$input" -c -f "$charset" -A 
/usr/share/locale/locale.alias "$locale" || :
echo " done"
  done < "$LOCALEGEN"
  echo "Generation complete."

Thanks for your bug report and for even proposing a patch which looks
good to me.

That said as I18NPATH could actually contains a list of directory, I
wonder if the behaviour would be more consistent if the user locales
directory is always prepended to I18NPATH if it exists. What do you
think?

Regards
Aurelien

My thought was: if someone already specified I18NPATH explicitly, then 
he knows what he is doing and the script should not mess with his setup.


Maddes

Bug#1068728: translate-toolkit: tmserver fails to run

[Sudip Mukherjee]

Package: translate-toolkit
Version: 3.12.2-1
Severity: normal

Dear Maintainer,

tmserver fails to run with the error:

$ tmserver 
Traceback (most recent call last):
  File "/usr/bin/tmserver", line 5, in 
from translate.services.tmserver import main
  File "/usr/lib/python3/dist-packages/translate/services/tmserver.py", line 
30, in 
from translate.misc import selector, wsgi
  File "/usr/lib/python3/dist-packages/translate/misc/wsgi.py", line 23, in 

from cheroot.wsgi import Server
ModuleNotFoundError: No module named 'cheroot'

It needs a runtime dependency on python3-cheroot.

-- 
Regards
Sudip

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

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

Versions of packages translate-toolkit depends on:
ii  python33.11.6-1
ii  python3-pkg-resources  68.1.2-2
ii  python3-translate  3.12.2-1

Versions of packages translate-toolkit recommends:
ii  translate-toolkit-doc  3.12.2-1

translate-toolkit suggests no packages.

Bug#1032807: [INTL:ro] Romanian debconf templates translation of mumble

[Remus-Gabriel Chelu]

Hello Chris,

În 08.04.2024 22:22, Chris Knadle a scris:

Is it as simple as renaming the mumble_debconf_ro.po file to ro.po and 
moving it to debian/po/ro.po ?


Yes, this is the way to introduce translation within the project, or, 
even simpler:


mv mumble_debconf_ro.po debian/po/ro.po

renaming and moving into a single command.


Respects,
Remus-Gabriel

PS: Sorry for the inconvenience caused, I grouped into my machine 
several translation files (of
several programs) in the same folder, for their own convenience; so I 
had to differentiate them
somehow from each other, and I chose to prefix their names with the name 
of the program for which

they are made.

Bug#1067614: texlive-latex-extra: pdfcomment docs reference the cloud instead of local files; also font option broken

[Preuße]

Control: tags -1 + wontfix

On 24.03.2024 18:29, Manny wrote:

Hi Manny,

thanks to Norbert for explaining, why we can't solve this issue. I tag 
that bug wontfix.



If only the Debian-specific bug is worked and the rest of this report
is closed, perhaps that’s fair enough. I’ve gone as far as I’m willing
to go. I just want these problems to be recorded /somewhere/ amid the
author being unreachable.



I'm aware of a bug in our TL packages, were both (submitter and upstream 
author) are dead. Still the bug is open, I just removed the "forwarded" 
flag.



BTW, there’s perhaps a defect in the Package-specific info that the
reportbug tool prints for texlive-latex-extra. It prints this:

===8<
Please read and follow the instructions in the first lines below
the text: "-- Package-specific info:".
Thank you.

Please don't add attachments > 100KB. They won't make it through
our mailing list and we won't see the report!
===8<

Around 800k of attachments were apparently accepted okay for bug
1067612, so the above-mentioned 100k limit may not be in force.

This is explained in the text: the DBTS is able to handle these kind of 
attachments, but the mailing list server won't forward the E-Mail to my 
private E-Mail account. As I don't scan the web pages of the bug tracker 
on a regular basis, changes in bugs or new bugs may remain undiscovered 
(by me) for a while.


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065777: clblas: FTBFS on arm{el,hf}: /<>/src/library/blas/gens/symv.c:955:29: error: implicit declaration of function ‘abs’; did you mean ‘fabs’? [-Werror=implicit-function-declarati

[Steve Langasek]

Package: clblas
Followup-For: Bug #1065777
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Please find attached a patch for this issue.  This patch has been uploaded
to Ubuntu.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru clblas-2.12/debian/patches/no-implicit-declarations.patch 
clblas-2.12/debian/patches/no-implicit-declarations.patch
--- clblas-2.12/debian/patches/no-implicit-declarations.patch   1969-12-31 
16:00:00.0 -0800
+++ clblas-2.12/debian/patches/no-implicit-declarations.patch   2024-04-09 
14:41:58.0 -0700
@@ -0,0 +1,18 @@
+Description: Add missing stdlib.h include
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1065777
+Last-Update: 2024-04-09
+Forwarded: no
+
+Index: clblas-2.12/src/library/blas/gens/gemv.c
+===
+--- clblas-2.12.orig/src/library/blas/gens/gemv.c
 clblas-2.12/src/library/blas/gens/gemv.c
+@@ -21,6 +21,7 @@
+ 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
diff -Nru clblas-2.12/debian/patches/series clblas-2.12/debian/patches/series
--- clblas-2.12/debian/patches/series   2023-09-28 16:21:54.0 -0700
+++ clblas-2.12/debian/patches/series   2024-04-09 14:40:35.0 -0700
@@ -9,3 +9,4 @@
 Fix-double-literals.patch
 Fix-null-pointer-crash.patch
 Fix-local-variables-not-declared-in-outermost-scope.patch
+no-implicit-declarations.patch

Bug#1066887: ENhance Patch for local-gen

[Aurelien Jarno]

Hi,

On 2024-03-15 16:13, M. Buecher wrote:
> Adding / back to end of the path, so that a locale file is immediately
> found.

> diff --git a/debian/local/usr_sbin/locale-gen 
> b/debian/local/usr_sbin/locale-gen
> index 7fa3d772..1711a4f0 100755
> --- a/debian/local/usr_sbin/locale-gen
> +++ b/debian/local/usr_sbin/locale-gen
> @@ -23,6 +23,12 @@ is_entry_ok() {
>   fi
>  }
>  
> +if [ -z "${I18NPATH:-}" ]; then
> +  if [ -d "${USER_LOCALES}" ]; then
> +I18NPATH="${USER_LOCALES%%/locales*}/"
> +  fi
> +fi
> +
>  echo "Generating locales (this might take a while)..."
>  while read -r locale charset; do
>   if [ -z "$locale" ] || [ "${locale#\#}" != "$locale" ]; then continue; 
> fi
> @@ -46,7 +52,7 @@ while read -r locale charset; do
>   input="$USER_LOCALES/$input"
>   fi
>   fi
> - localedef -i "$input" -c -f "$charset" -A 
> /usr/share/locale/locale.alias "$locale" || :
> + I18NPATH="${I18NPATH}" localedef -i "$input" -c -f "$charset" -A 
> /usr/share/locale/locale.alias "$locale" || :
>   echo " done"
>  done < "$LOCALEGEN"
>  echo "Generation complete."

Thanks for your bug report and for even proposing a patch which looks
good to me.

That said as I18NPATH could actually contains a list of directory, I
wonder if the behaviour would be more consistent if the user locales
directory is always prepended to I18NPATH if it exists. What do you
think?

Regards
Aurelien

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

Bug#1068727: libhtml-formfu-perl: html_formfu_dumpconf.pl fails to run

[Sudip Mukherjee]

Package: libhtml-formfu-perl
Version: 2.07000-1
Severity: normal

Dear Maintainer,

html_formfu_dumpconf.pl fails to run with the error:

$ html_formfu_dumpconf.pl 
Can't locate Regexp/Assemble.pm in @INC (you may need to install the 
Regexp::Assemble module) (@INC entries checked: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.38.2 /usr/local/share/perl/5.38.2 
/usr/lib/x86_64-linux-gnu/perl5/5.38 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.38 
/usr/share/perl/5.38 /usr/local/lib/site_perl) at 
/usr/bin/html_formfu_dumpconf.pl line 7.
BEGIN failed--compilation aborted at /usr/bin/html_formfu_dumpconf.pl line 7.

It will need a runtime dependency on libregexp-assemble-perl.

-- 
Regards
Sudip

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

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

Versions of packages libhtml-formfu-perl depends on:
ii  libcgi-pm-perl 4.64-1
ii  libclone-perl  0.46-1+b1
ii  libconfig-any-perl 0.33-1
ii  libdata-visitor-perl   0.32-1
ii  libdatetime-format-builder-perl0.8300-1
ii  libdatetime-format-natural-perl1.18-1
ii  libdatetime-format-strptime-perl   1.7900-1
ii  libdatetime-locale-perl1:1.41-1
ii  libdatetime-perl   2:1.65-1+b1
ii  libemail-valid-perl1.204-1
ii  libfile-sharedir-perl  1.118-3
ii  libhash-flatten-perl   1.19-5
ii  libhtml-scrubber-perl  0.19-2
ii  libhtml-tokeparser-simple-perl 3.16-4
ii  libjson-maybexs-perl   1.004005-1
ii  liblist-moreutils-perl 0.430-2
ii  libmoose-perl  2.2207-1+b1
ii  libmoosex-aliases-perl 0.11-2
ii  libmoosex-attribute-chained-perl   1.0.3-2
ii  libnumber-format-perl  1.76-1
ii  libpath-class-perl 0.37-4
ii  libreadonly-perl   2.050-3
ii  libregexp-common-perl  2017060201-3
ii  libtask-weaken-perl1.06-2
ii  libwww-perl6.76-1
ii  libyaml-libyaml-perl   0.89+ds-1+b1
ii  perl   5.38.2-3.2+b2
ii  perl-base [libscalar-list-utils-perl]  5.38.2-3.2+b2

libhtml-formfu-perl recommends no packages.

Versions of packages libhtml-formfu-perl suggests:
pn  libcgi-simple-perl  
pn  libhtml-formfu-model-dbic-perl  

Bug#1067505: libc-bin: iconv: misleading error "illegal input sequence"

[Aurelien Jarno]

Hi,

On 2024-03-22 16:42, Frank Heckenbach wrote:
> - I tried to report it upstream, but that's also broken. According to
>   https://www.gnu.org/software/libc/manual/html_node/Reporting-Bugs.html, bugs
>   should be reported at https://www.gnu.org/software/libc/bugs.html, but this
>   page redirects to https://www.gnu.org/savannah-checkouts/gnu/libc/index.html
>   which does not mention reporting bugs.

Please see this page for reporting bug upstream:
https://sourceware.org/glibc/bugs.html

Regards
Aurelien

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

Bug#1067108: alien-arena: FTBFS with -Werror=implicit-function-declaration

[Steve Langasek]

Package: alien-arena
Followup-For: Bug #1067108
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Please find attached a fix for this bug, which has been uploaded to Ubuntu.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru alien-arena-7.71.3+dfsg/debian/patches/no-implicit-declarations.patch 
alien-arena-7.71.3+dfsg/debian/patches/no-implicit-declarations.patch
--- alien-arena-7.71.3+dfsg/debian/patches/no-implicit-declarations.patch   
1969-12-31 16:00:00.0 -0800
+++ alien-arena-7.71.3+dfsg/debian/patches/no-implicit-declarations.patch   
2024-04-09 13:53:07.0 -0700
@@ -0,0 +1,18 @@
+Description: add missing include
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1067108
+Last-Update: 2024-04-09
+Forwarded: no
+
+Index: alien-arena-7.71.3+dfsg/source/game/g_unlagged.c
+===
+--- alien-arena-7.71.3+dfsg.orig/source/game/g_unlagged.c
 alien-arena-7.71.3+dfsg/source/game/g_unlagged.c
+@@ -21,6 +21,7 @@
+ #include "config.h"
+ #endif
+ 
++#include "qcommon/qcommon.h"
+ #include "g_local.h"
+ 
+ /*
diff -Nru alien-arena-7.71.3+dfsg/debian/patches/series 
alien-arena-7.71.3+dfsg/debian/patches/series
--- alien-arena-7.71.3+dfsg/debian/patches/series   2023-02-12 
08:19:19.0 -0800
+++ alien-arena-7.71.3+dfsg/debian/patches/series   2024-04-09 
13:51:57.0 -0700
@@ -6,3 +6,4 @@
 odeconfig.patch
 irc.patch
 http11.patch
+no-implicit-declarations.patch

Bug#1066274: aa3d: FTBFS: aa3d.c:37:30: error: implicit declaration of function ‘strcmp’ [-Werror=implicit-function-declaration]

[Steve Langasek]

Package: aa3d
Version: 1.0-8.2
Followup-For: Bug #1066274
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Please find attached a fix for this bug.

This fix has been uploaded to Ubuntu.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru aa3d-1.0/debian/patches/no-implicit-declarations.patch 
aa3d-1.0/debian/patches/no-implicit-declarations.patch
--- aa3d-1.0/debian/patches/no-implicit-declarations.patch  1969-12-31 
16:00:00.0 -0800
+++ aa3d-1.0/debian/patches/no-implicit-declarations.patch  2024-04-09 
13:42:30.0 -0700
@@ -0,0 +1,18 @@
+Description: add missing string.h include
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1066274
+Last-Update: 2024-04-09
+Forwarded: no
+
+Index: aa3d-1.0/aa3d.c
+===
+--- aa3d-1.0.orig/aa3d.c
 aa3d-1.0/aa3d.c
+@@ -22,6 +22,7 @@
+  */
+ #include 
+ #include 
++#include 
+ static char data[65536 / 2];
+ int main(int argc, char **argv)
+ {
diff -Nru aa3d-1.0/debian/patches/series aa3d-1.0/debian/patches/series
--- aa3d-1.0/debian/patches/series  1969-12-31 16:00:00.0 -0800
+++ aa3d-1.0/debian/patches/series  2024-04-09 13:41:03.0 -0700
@@ -0,0 +1 @@
+no-implicit-declarations.patch

Bug#1068726: ITP: rust-csv2svg -- Take a csv as input and outputs svg

[Ananthu C V]

Package: wnpp
Severity: wishlist
Owner: Ananthu C V 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: rust-csv2svg
  Version : 0.2.1
  Upstream Contact: dystroy 
* URL : https://crates.io/crates/csv2svg
* License : MIT
  Programming Lang: Rust
  Description : Take a csv as input and outputs svg
   Build a SVG graph from a csv document.

This is a dependency needed by glassbench, which comes the zellij
dependency tree.

Bug#1066305: 3dchess: FTBFS: init.c:140:21: error: implicit declaration of function ‘time’ [-Werror=implicit-function-declaration]

[Steve Langasek]

Package: 3dchess
Version: 0.8.1-21
Followup-For: Bug #1066305
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Please find attached the fix for this bug, which has been uploaded to
Ubuntu.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru 3dchess-0.8.1/debian/patches/no-implicit-declarations.patch 
3dchess-0.8.1/debian/patches/no-implicit-declarations.patch
--- 3dchess-0.8.1/debian/patches/no-implicit-declarations.patch 1969-12-31 
16:00:00.0 -0800
+++ 3dchess-0.8.1/debian/patches/no-implicit-declarations.patch 2024-04-09 
13:23:33.0 -0700
@@ -0,0 +1,18 @@
+Description: fix missing declaration of time()
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1066305
+Last-Update: 2024-04-09
+Forwarded: no
+
+Index: 3dchess-0.8.1/src/init.c
+===
+--- 3dchess-0.8.1.orig/src/init.c
 3dchess-0.8.1/src/init.c
+@@ -29,6 +29,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include "../include/machine.h"
+ #include "../include/3Dc.h"
+ 
diff -Nru 3dchess-0.8.1/debian/patches/series 
3dchess-0.8.1/debian/patches/series
--- 3dchess-0.8.1/debian/patches/series 2022-03-26 18:33:58.0 -0700
+++ 3dchess-0.8.1/debian/patches/series 2024-04-09 13:22:34.0 -0700
@@ -4,3 +4,4 @@
 13_machine.h.patch
 hardening.patch
 wasteful-CPU-consumption.patch
+no-implicit-declarations.patch

Bug#1068586: ghc: Broken on arm{el,hf} because of time_t transition

[Adrian Bunk]

[ Steve added, for the symbol list question ]

On Tue, Apr 09, 2024 at 09:44:43PM +0300, Ilias Tsitsimpis wrote:
> On Tue, Apr 09, 2024 at 08:53PM, Adrian Bunk wrote:
> > On Tue, Apr 09, 2024 at 07:23:29PM +0300, Ilias Tsitsimpis wrote:
> > > I believe it's not. haskell-hourglass used to work on arm{el,hf} just
> > > before the time64 transition.
> > 
> > before this transition x32 was the only 32bit architecture with 64bit 
> > time_t.
> 
> Aha! Didn't know that, thanks for flagging this. I am surprised that we
> hadn't noticed this earlier (as we see now, GHC is completely broken).

I wouldn't call it "completely broken".

I'm too lazy to get exact numbers, but the arm{el,hf} situation is more 
like 1000 packages built (a large part with tests) and 10 failed.

>...
> > > We need a way to identify every package that is broken.
> > 
> > $ nm -D /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHStime-1.12.2-ghc9.4.7.so | 
> > grep gettimeofday
> >  U gettimeofday@GLIBC_2.4
> > ...
> > 
> > $ nm -D 
> > /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHSdirectory-1.3.7.1-ghc9.4.7.so | 
> > grep utimensat 
> > ...
> >  U utimensat@GLIBC_2.6
> > 
> > $ nm -D /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHStime-1.12.2-ghc9.4.7.so | 
> > grep localtime
> >  U __localtime64_r@GLIBC_2.34
> 
> Thank you! Can we maybe run this against all Haskell libraries and
> identify the ones that are currently broken? Maybe we have such a script
> already for the time64 transition.

Steve, do you have a list of all bad symbols for the time_t transition?

With this list it should be possible to just install all currently 
installable Haskell packages on a porterbox and do something like

$ for s in gettimeofday utimensat localtime localtime_r; do for f in 
/usr/lib/ghc/lib/arm-linux-ghc-9.4.7/*.so 
/usr/lib/haskell-packages/ghc/lib/arm-linux-ghc-9.4.7/*.so; do nm -D $f | grep 
$s@ && echo $f; done; done
 U gettimeofday@GLIBC_2.4
/usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHStime-1.12.2-ghc9.4.7.so
 U utimensat@GLIBC_2.6
/usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHSdirectory-1.3.7.1-ghc9.4.7.so
 U utimensat@GLIBC_2.6
/usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHSunix-2.7.3-ghc9.4.7.so
$

That last one is likely
libraries/unix/System/Posix/Files/Common.hsc:foreign import ccall unsafe 
"utimensat"

> > But the last one is the broken localtime_r one, is anything going wrong 
> > with the ccall from TimeZone.hs to cbits there?
> > 
> > get_current_timezone_seconds() returning long is wrong,
> > and might contribute to that bug:
> > 
> >   foreign import ccall unsafe "HsTime.h get_current_timezone_seconds"
> > get_current_timezone_seconds ::
> > CTime -> Ptr CInt -> Ptr CString -> IO CLong
> > ...
> >   getTimeZoneCTime ctime =
> > ...
> > secs <- get_current_timezone_seconds ctime pdst pcname
> > 
> > I don't know Haskell, but is this declaring ctime as CLong,
> > and then passing it instead of a CTime?
> 
> I believe it returns the timezone in seconds (i.e., 3600 for +1 hour
> timezone), so CLong should be large enough to hold this value. My guess
> right now is that it fails due to the bogus CTime value that we pass, we
> need to test this.

Yes, I suspect that this function with
  CTime -> Ptr CInt -> Ptr CString -> IO CLong
gets called as
  CLong -> Ptr CInt -> Ptr CString -> IO CLong
but I'm surprised if Haskell does not catch something like that at 
compile time.

> Ilias

cu
Adrian

Bug#1068725: libnginx-mod-http-js contains unnecessary dependency

[Miao Wang]

Package: libnginx-mod-http-js
Version: 0.8.2-1+b1
Severity: normal

Dear Maintainer,

libnginx-mod-http-js contains a dependency on libnginx-mod-stream, which should 
be only necessary for libnginx-mod-stream-js.

Cheers,

Miao Wang

Bug#761152: python-strict-rfc3339: changing from ITP to RFP

[Julian Gilbey]

retitle 761152 ITP: python-strict-rfc3339 -- Strict, simple, lightweight 
RFC3339 functions
owner 761152 !
thanks

On Sun, Dec 27, 2015 at 01:16:59PM +0100, Lucas Nussbaum wrote:
> retitle 761152 RFP: python-strict-rfc3339 -- Strict, simple, lightweight 
> RFC3339 functions
> noowner 761152
> tag 761152 - pending
> thanks
> [...]

I've updated Adam Cecile's packaging work on salsa for this package
and uploaded it to NEW.  (It's a test-time dependency of some of the
jupyter* packages or their dependencies.)

Bug#1068724: RFS: gensync/2.0.5-1 [ITP] -- a library for efficient synchronization of data over a network.

[Chen, Xingyu]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : gensync
   Version  : 2.0.5-1
   Upstream contact : 
 * URL  : https://github.com/nislab/gensync
 * License  : 
 * Vcs  : [fill in URL of packaging vcs]
   Section  : libs

The source builds the following binary packages:

  gensync - a library for efficient synchronization of data over a network. 
Gensync is a library that uses many different syncing algorithms to sync data 
between two nodes in a network. These algorithms include IBLTs, CPISyncs, 
HashSyncs, Cuckoo Syncs, and more.

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gensync/gensync_2.0.5-1.dsc

Changes for the initial release:

 gensync (2.0.5-1) UNRELEASED; urgency=medium
 .
   * Initial release (Closes: #)  

Regards,
--
  Kevin Chen

Bug#1068721: Depends on nonexistant librust-parking-2+std-dev

[Jonas Smedegaard]

Quoting Matthias Geiger (2024-04-09 20:12:13)
 
> parking does not have a +std feature enabled:

Whoops, sorry about that - a silly typo.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1068723: quickflux: binary-any FTBFS

[Adrian Bunk]

Source: quickflux
Version: 1.1.3+git20201110.2a37acf-1
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Debian UBports Team 

https://buildd.debian.org/status/logs.php?pkg=quickflux=1.1.3%2Bgit20201110.2a37acf-1

...
   debian/rules override_dh_installexamples
make[1]: Entering directory '/<>'
dh_installexamples
rm 
debian/quickflux-doc/usr/share/doc/quickflux-doc/examples/middleware/.gitignore
rm: cannot remove 
'debian/quickflux-doc/usr/share/doc/quickflux-doc/examples/middleware/.gitignore':
 No such file or directory
make[1]: *** [debian/rules:33: override_dh_installexamples] Error 1

Bug#1068586: ghc: Broken on arm{el,hf} because of time_t transition

[Ilias Tsitsimpis]

On Tue, Apr 09, 2024 at 08:53PM, Adrian Bunk wrote:
> On Tue, Apr 09, 2024 at 07:23:29PM +0300, Ilias Tsitsimpis wrote:
> > I believe it's not. haskell-hourglass used to work on arm{el,hf} just
> > before the time64 transition.
> 
> before this transition x32 was the only 32bit architecture with 64bit time_t.

Aha! Didn't know that, thanks for flagging this. I am surprised that we
hadn't noticed this earlier (as we see now, GHC is completely broken).

> > The fix here is to backport (at least) the following patches which
> > change these calls to use the capi calling convention:
> > 
> >   * 
> > https://gitlab.haskell.org/ghc/packages/time/-/commit/d52314edb138b6ecd7e888c588f83917b0ee2c29
> >   * 
> > https://gitlab.haskell.org/ghc/packages/directory/-/commit/f6b288bd96fba5a955d1f73663eb52c1859ee765
> 
> This localtime_r issue I mentioned is not covered in the above commit in 
> time.

Hmm true. My guess here is that GHC gets a completely bogus CTime value
back from clock_gettime() (we proved that the way we call
clock_gettime() is currently broken) and when it passes this CTime value
to localtime_r() it fails. I haven't verified any of this, just a guess.

> > We need a way to identify every package that is broken.
> 
> $ nm -D /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHStime-1.12.2-ghc9.4.7.so | 
> grep gettimeofday
>  U gettimeofday@GLIBC_2.4
> ...
> 
> $ nm -D 
> /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHSdirectory-1.3.7.1-ghc9.4.7.so | 
> grep utimensat 
> ...
>  U utimensat@GLIBC_2.6
> 
> $ nm -D /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHStime-1.12.2-ghc9.4.7.so | 
> grep localtime
>  U __localtime64_r@GLIBC_2.34

Thank you! Can we maybe run this against all Haskell libraries and
identify the ones that are currently broken? Maybe we have such a script
already for the time64 transition.

> But the last one is the broken localtime_r one, is anything going wrong 
> with the ccall from TimeZone.hs to cbits there?
> 
> get_current_timezone_seconds() returning long is wrong,
> and might contribute to that bug:
> 
>   foreign import ccall unsafe "HsTime.h get_current_timezone_seconds"
> get_current_timezone_seconds ::
> CTime -> Ptr CInt -> Ptr CString -> IO CLong
> ...
>   getTimeZoneCTime ctime =
> ...
> secs <- get_current_timezone_seconds ctime pdst pcname
> 
> I don't know Haskell, but is this declaring ctime as CLong,
> and then passing it instead of a CTime?

I believe it returns the timezone in seconds (i.e., 3600 for +1 hour
timezone), so CLong should be large enough to hold this value. My guess
right now is that it fails due to the bogus CTime value that we pass, we
need to test this.

-- 
Ilias

Bug#1068722: aapt: symbol lookup error: libandroidfw.so.0: undefined symbol: _Z18ExtractEntryToFileP10ZipArchiveP8ZipEntryi

[Hans-Christoph Steiner]

Package: aapt
Version: 1:10.0.0+r36-10
Severity: important

Dear Maintainer,

When adb/fastboot is installed from bookworm-backports, those pull in 
android-libziparchive 1:33.0.3-2~bpo12+1, which does not have the symbols that 
bookworm's aapt needs to run:


$ aapt
aapt: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libandroidfw.so.0: 
undefined symbol: _Z18ExtractEntryToFileP10ZipArchiveP8ZipEntryi/


I guess the solution would be to also backport android-platform-frameworks-base?

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (1, 'experimental'), (1, 'unstable')

Architecture: amd64 (x86_64)

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

Versions of packages aapt depends on:
ii  android-libaapt1:10.0.0+r36-10
ii  android-libandroidfw   1:10.0.0+r36-10
ii  android-libbase1:33.0.3-2~bpo12+1
ii  android-liblog 1:33.0.3-2~bpo12+1
ii  android-libutils   1:33.0.3-2~bpo12+1
ii  android-libziparchive  1:33.0.3-2~bpo12+1
ii  libc6  2.36-9+deb12u4
ii  libexpat1  2.5.0-1
ii  libgcc-s1  13.1.0-9
ii  libpng16-161.6.39-2
ii  libprotobuf-lite32 3.21.12-3
ii  libstdc++6 13.1.0-9

aapt recommends no packages.

aapt suggests no packages.

-- no debconf information

Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf

[Steven Eker]

Hi Sebastian,

The lack of long long support in GMP has been the subject of some 
discussions:


https://gmplib.org/list-archives/gmp-bugs/2020-June/thread.html#4771
https://gmplib.org/list-archives/gmp-discuss/2021-January/thread.html#6625

I don't see it happening soon - it took years for the x18 issue on Apple 
silicon to be fixed.

In my development version I've modified the code to:

  Index seconds = timeValue.tv_sec;  // this is 32-bit on 32-bit 
machines so mpz_class constuctor is defined

  mpz_class nanoSeconds(seconds);
  nanoSeconds *= BILLION;
  nanoSeconds += timeValue.tv_nsec;

This is harmless on 64-bit architectures since Index will be a signed 
64-bit integer and if it works on 32-bit architectures, it's a work 
around until GMP is fixed (hopefully before 2038).


Steven

On 4/9/24 00:01, Sebastian Ramacher wrote:

Hi Steven

On 2024-04-08 15:38:50 -0700, Steven Eker wrote:

Hi Nilish,

I don't have a 32-bit machine to test on, but my understanding is that Linux
has moved to a 64-bit signed integer for time_t and this is a long long on
32-bit machines which is explicitly not supported by GMP's C++ API.

This sounds like it needs to fixed in GMP then.


https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Year_2038_problem__;!!DZ3fjg!--tzUBTnQHRKfnkc8PqaPE5gHxPm2QWswg2_MWTbLaWxFFDXu6jiPCjltocalTdckv2oG8G8tDajml0HNO6JIFyo$
https://urldefense.com/v3/__https://gmplib.org/manual/C_002b_002b-Interface-Integers__;!!DZ3fjg!--tzUBTnQHRKfnkc8PqaPE5gHxPm2QWswg2_MWTbLaWxFFDXu6jiPCjltocalTdckv2oG8G8tDajml0HNHAQQdRg$

I'm not happy converting a signed value to an unsigned value for all
architectures. But

   mpz_class nanoSeconds(static_cast(timeValue.tv_sec));

should fix the problem, at least until 2038. Can you check that this works?
If so I'll put it in the next public alpha.

And this does not sound like a fix which we want.

Best
Sebastian

Bug#1051056: transmission-daemon: memory leaks lead to eventual memory exhaustion

[Mo Jun]

Package: transmission-daemon
Followup-For: Bug #1051056

Hi Rob,

I think this bug is a duplicate of #1015003 which is reported by me. Your
valgrind log and analysis are very similar to mine.

#1015003 was introduced by debian/patches/openssl3-compat.patch, and for
stable(bookworm) it was fixed in 3.00-2.1+deb12u1 by dropping
openssl3-compat.patch and using a simpler patch from Gentoo[1].

I see your transmission-daemon is at 3.00-2.1+b1, upgrade to
3.00-2.1+deb12u1 should fix it.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015003#84

Bug#1068721: Depends on nonexistant librust-parking-2+std-dev

[Matthias Geiger]

Package: librust-event-listener-dev
Severity: serious
X-Debbugs-Cc: werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Jonas,

thanks for updating event-listener.
However, the package is unistallable for me:

sudo apt install librust-event-listener-dev -t experimental  -s
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 librust-event-listener-dev : Depends: librust-parking-2+std-dev but it is not 
installable
E: Unable to correct problems, you have held broken packages.

parking does not have a +std feature enabled:

[...]

Provides:
  librust-parking+default-dev
  librust-parking-2+default-dev
  librust-parking-2-dev
  librust-parking-2.0+default-dev
  librust-parking-2.0-dev
  librust-parking-2.0.0+default-dev
  librust-parking-2.0.0-dev
Replaces: librust-parking-dev
[...]

best,

werdahias

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

Kernel: Linux 6.5.0-2-amd64 (SMP w/16 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: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages librust-event-listener-dev depends on:
pn  librust-concurrent-queue-2+std-dev
pn  librust-parking-2+std-dev 
pn  librust-pin-project-lite-0.2+default-dev  

librust-event-listener-dev recommends no packages.

librust-event-listener-dev suggests no packages.

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmYVhPkVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR11vMQAMBgRGPBHxDTy7893h2ovmTguPBs
1hqSiZFgZVaySLtMd0RY2MT3YlaCfUQGVMmyHMBVjHc0FLj0YZxSrSI7760bBNL7
O7binQZEl0VIGUb1TKSHNTiapo9l8xKwuwt3nG5ObttQV3cFk0vxIHgUjjpHffYE
sZOD2cLZYx5zLU29TGSDP/WIqMCaBhUwDHNqQGihpuVniRzKO9b0YTBvsNSrKy9+
+vh8CiK2sQzNcpcFgPH3nlhIDUj+XEfo4rEWBIuO7MDbuFCPehmoBGQnM7nnmB9e
3XGamSigg8+ZUJhKa5AbTppZbugLCfXW2htqaX6bVuseFmfKtGxfnXK01Xvsgi+x
7tucQpUcVEpXGh7pA2VmKNOVSvFUWH+m/QI5XN2gtnaVICe1pHpPPaIGHIdSQhyA
Ua0tSSM0MDsjJ0KUU3y+ZPW7zAfdTenSwkqCWbEyGQ0+A9xLXWhsm7zEbTyfSK+g
3SwueCajbKNFFCG71Hot/VgMyfTPQwbJcy6bQmDVWTipDGymEmwpce83tO9Ec3IW
t52ShOPUjWiKWtIeI2ScSIsesS/2XZmqAEx2LJTB5oObpJe4XIfTeG5Sm9mZrhpN
ODowu6du/WJ6vz1sM+OhawysJbM3jZFFBKEfzD+LwglN70mAfZ7f7gZfkcByc+BD
gBpcQKl3ZqfaDoPn
=ppql
-END PGP SIGNATURE-

Bug#1068719: RM: ruby-arel/9.0.0-2 -- RoQA; obsolete, integrated into ruby-activerecord, incompatible with ruby-activerecord 6.1.x

[Paul Gevers]

tags -1 bookworm

On 09-04-2024 7:23 p.m., Andreas Beckmann wrote:

Please remove the obsolete ruby-arel from bookworm.


I'm tagging it as such, so it shows up in the SRM tooling.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059503: RFS: blanket/0.6.0-1 [RFP] -- listen to relaxing sounds

[Danial Behzadi]

New version (0.7.0) has been released yesterday and it's now updated in
salsa and mentors.
Please take a look there:


 * Package name : blanket
   Version  : 0.7.0-1
   Upstream contact : Rafael Mardojai CM 
 * URL  : https://github.com/rafaelmardojai/blanket
 * License  : CC-BY-SA-3.0, CC-BY-1.0, CC-BY-3.0, GPL-3+,
Public-Domain, CC0-1.0, CC-BY-4.0
 * Vcs  : https://salsa.debian.org/danialbehzadi/blanket
   Section  : utils

The source builds the following binary packages:

  blanket - Listen to relaxing sounds

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/blanket/

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

  dget -x
https://mentors.debian.net/debian/pool/main/b/blanket/blanket_0.7.0-1.dsc

Changes for the initial release:

 blanket (0.7.0-1) unstable; urgency=medium
 .
   * Initial packaging. (Closes: #1053209)

Regards,
-- 
  Danial Behzadi

Bug#1068653: close

[Mark A. Hershberger]

close #1068653

Restarting laptop after upgrading to unstable (from stable) worked.

Bug#1061051: RFS: notes-tree/1.2-1 -- a note taking app, which organizes notes in a hierarchical structure

[ds]

Control: tags -1 - moreinfo

> There are quite a lot of issues reported by lintian so you should fix at


least those before looking for sponsorship.


Fixed at:
dget -xu 
https://gitlab.com/44100Hz/NotesTree/-/raw/deb-package/deb-pkg/notes-tree_1.2.dsc 

Bug#1068586: ghc: Broken on arm{el,hf} because of time_t transition

[Adrian Bunk]

On Tue, Apr 09, 2024 at 07:23:29PM +0300, Ilias Tsitsimpis wrote:
> Hi Adrian,

Hi Ilias,

> On Tue, Apr 09, 2024 at 12:56PM, Adrian Bunk wrote:
> > FTR, in haskell-hourglass this is #1001686 which already failed on x32 
> > for this reason.
> 
> I believe it's not. haskell-hourglass used to work on arm{el,hf} just
> before the time64 transition.

before this transition x32 was the only 32bit architecture with 64bit time_t.

> > My reading of the code is that this happens when 
> > libraries/time/lib/cbits/HsTime.c returns 0x8000 due to 
> > localtime_r() called in this function returning an error.
> > 
> > The "localtime_r failed" is from
> > libraries/time/lib/Data/Time/LocalTime/Internal/TimeZone.hs
>...
> The fix here is to backport (at least) the following patches which
> change these calls to use the capi calling convention:
> 
>   * 
> https://gitlab.haskell.org/ghc/packages/time/-/commit/d52314edb138b6ecd7e888c588f83917b0ee2c29
>   * 
> https://gitlab.haskell.org/ghc/packages/directory/-/commit/f6b288bd96fba5a955d1f73663eb52c1859ee765

This localtime_r issue I mentioned is not covered in the above commit in 
time.

>...
> We need a way to identify every package that is broken.

$ nm -D /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHStime-1.12.2-ghc9.4.7.so | 
grep gettimeofday
 U gettimeofday@GLIBC_2.4
...

$ nm -D /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHSdirectory-1.3.7.1-ghc9.4.7.so 
| grep utimensat 
...
 U utimensat@GLIBC_2.6

$ nm -D /usr/lib/ghc/lib/arm-linux-ghc-9.4.7/libHStime-1.12.2-ghc9.4.7.so | 
grep localtime
 U __localtime64_r@GLIBC_2.34


But the last one is the broken localtime_r one, is anything going wrong 
with the ccall from TimeZone.hs to cbits there?

get_current_timezone_seconds() returning long is wrong,
and might contribute to that bug:

  foreign import ccall unsafe "HsTime.h get_current_timezone_seconds"
get_current_timezone_seconds ::
CTime -> Ptr CInt -> Ptr CString -> IO CLong
...
  getTimeZoneCTime ctime =
...
secs <- get_current_timezone_seconds ctime pdst pcname

I don't know Haskell, but is this declaring ctime as CLong,
and then passing it instead of a CTime?


> Ilias

cu
Adrian

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

[Dirk Eddelbuettel]

On 9 April 2024 at 18:45, Jose Manuel Abuin Mosquera wrote:
| If possible, I would like to contribute. At work we use the Go and 
| Python implementations, also, in the short term, we will start using the 
| Rust one.

Similar for us, and we have seen plenty of build headaches across pypi or
conda ...

(Hence my earlier hint about nanoarrow. No linking, uses the C API of two
void pointers.)

| Just to point out, the Rust version has its own native implementation, 
| here: https://github.com/apache/arrow-rs .

And IIRC there is an independent Arrow implementation (in Rust) used by polars
making it two possible ITPs: vanilla Arrow from Apache and Arrow from polars.

Dirk 

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

Bug#1068720: RFS: streamlink/6.7.2-1~bpo12+1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian-backpo...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "streamlink" into Debian
bookworm-backports repository.

  * Package name: streamlink
Version : 6.7.2-1~bpo12+1
Upstream Author : Streamlink Team
  * URL : https://streamlink.github.io/
  * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
  * Vcs : https://salsa.debian.org/amurzeau/streamlink/
Section : python

It builds those binary packages:

  python3-streamlink - Python module for extracting video streams from
various websites
  streamlink - CLI for extracting video streams from various websites
to a video player


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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_6.7.2-1~bpo12+1.dsc


Differences from testing package (6.7.2-1):
  * d/control,rules: remove doc package because of missing dependencies
on bookworm.
  * d/patches: fix tests with exceptiongroup v1.1.0.


Changes since the previous backported version in bookworm:
streamlink (6.7.2-1~bpo12+1) bookworm-backports; urgency=medium

  * Rebuild for bookworm-backports.
  * d/patches: fix tests with exceptiongroup v1.1.0

 -- Alexis Murzeau   Tue, 09 Apr 2024 14:50:10 +0200

streamlink (6.7.2-1) unstable; urgency=medium

  * New upstream version 6.7.2
  * d/patches: remove trio 0.22 fix which is now also fixed upstream
  * d/patches: fix tests on testing

 -- Alexis Murzeau   Fri, 05 Apr 2024 23:37:30 +0200

streamlink (6.7.1-1) unstable; urgency=medium

  * New upstream version 6.7.1
  * d/patches: update patches
  * d/control: update dependencies (add python3-exceptiongroup)
  * Fix tests by setting rootdir when calling pytest (Closes: 1066783)

 -- Alexis Murzeau   Wed, 13 Mar 2024 00:39:57 +0100

Regards,

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F |

Bug#1068719: RM: ruby-arel/9.0.0-2 -- RoQA; obsolete, integrated into ruby-activerecord, incompatible with ruby-activerecord 6.1.x

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-Cc: Georg Faerber 
Control: block -1 with 1068715

Please remove the obsolete ruby-arel from bookworm.
The functionality is now integrated into ruby-activerecord and the
separately packaged ruby-arel is incompatible with the ruby-activerecord
version in bookworm, causing schleuder maintainer scripts to fail if
installed.

There is a superfluous build-dependency on ruby-arel in
src:ruby-premailer-rails, dropping that is handled in pu request
#1068715.

pu request #1068717 tracks adding Breaks+Replaces against ruby-arel to
ruby-activerecord to ensure removal of the obsolete and incompatible
package on upgrades.


Andreas

Bug#1068718: freeimage: consider packaging r1909?

[Santiago Ruano Rincón]

Source: freeimage
Version: 3.18
Severity: normal
X-Debbugs-Cc: t...@security.debian.org

Dear freeimage maintainers and security team,

This is a bug report to discuss if freeimage r1909 should be packaged, while
there is no official 3.19 release.
The svn is found here: https://sourceforge.net/p/freeimage/svn/HEAD/tree/

It is to note that there a some CVEs reported against that SVN revision, and
there is no clear indication they affect 3.18 or older releases. So this could
mean introducing some bugs.
See: https://github.com/Ruanxingzhi/vul-report/tree/master/freeimage-r1909

Any thoughts? 

  -- Santiago


signature.asc
Description: PGP signature

Bug#1068717: bookworm-pu: package rails/2:6.1.7.3+dfsg-2~deb12u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Georg Faerber 
Control: block -1 with 1068715

[ Reason ]
The obsolete (but unfortunately still in bookworm present) ruby-arel is
not compatible with ruby-activerecord in bookworm (which now integrates
ruby-arel functionality), causing schleuder to fail in its maintainer
scripts during upgrades.
Let's add Breaks+Replaces to ruby-activerecord to ensure ruby-arel gets
removed on upgrades from bookworm. This may make ruby-arel uninstallable
in stable, so let's follow up with a RM request for that.

[ Impact ]
Failures on some upgrade paths of schleuder if the obsolete ruby-arel is
still installed.

[ Tests ]
Local piuparts tests upgrading schleuder with old ruby-arel installed
showed proper removal of ruby-arel and no more errors.

[ Risks ]
Uninstallability of the obsolete ruby-arel which should not have been in
bookworm at all.

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

[ Changes ]
 debian/changelog | 16 
 debian/control   |  2 ++
 debian/gbp.conf  |  2 +-
 3 files changed, 19 insertions(+), 1 deletion(-)

[ Other info ]
This is a rebuild of a package that has been in sid and testing for a
long time (but is now superseded by further uploads with changes not
appropriate for stable).

Andreas
diff --git a/debian/changelog b/debian/changelog
index e0710e15..c3d33ee2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,19 @@
+rails (2:6.1.7.3+dfsg-2~deb12u1) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for bookworm.
+
+ -- Andreas Beckmann   Tue, 09 Apr 2024 18:24:31 +0200
+
+rails (2:6.1.7.3+dfsg-2) unstable; urgency=medium
+
+  * debian/control:
+- Declare that ruby-activerecord breaks and replaces ruby-arel: it was
+  merged five years ago, is therefore obsolete and to be removed.
+  (Closes: #1038935)
+
+ -- Georg Faerber   Sun, 25 Jun 2023 11:53:59 +
+
 rails (2:6.1.7.3+dfsg-1) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index fc8d64d5..9e01f2b9 100644
--- a/debian/control
+++ b/debian/control
@@ -134,6 +134,7 @@ Depends: ruby:any (>= 1:2.5.0),
 Breaks: ruby-activerecord-import (<< 1.0.5~),
 ruby-activerecord-nulldb-adapter (<< 0.8.0~),
 ruby-acts-as-taggable-on (<< 6.5~),
+ruby-arel,
 ruby-delayed-job-active-record (<< 4.1.6-3~),
 ruby-enumerize (<< 2.4.0~),
 ruby-has-secure-token (<< 1.0.0-3~),
@@ -146,6 +147,7 @@ Description: object-relational mapper framework (part of 
Rails)
  a persistent domain model by mapping database tables to Ruby classes.
  Strong conventions for associations, validations, aggregations,
  migrations, and testing come baked-in.
+Replaces: ruby-arel,
 XB-Ruby-Versions: ${ruby:Versions}
 X-DhRuby-Root: activerecord/
 
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 584b9683..1190046b 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -4,7 +4,7 @@ sign-tags = True
 upstream-tag = upstream/%(version)s
 
 upstream-branch = upstream
-debian-branch = master
+debian-branch = bookworm
 
 [pq]
 patch-numbers = False

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

[Jose Manuel Abuin Mosquera]

O 25/03/24 ás 19:17, Julian Gilbey escribiu:

Hi all,


Hi :)


[NB: sent to d-science, d-python, d-devel and the RFP bug; reply-to
set to d-science and the RFP bug only]

An update on Apache Arrow, and in particular the Python library
PyArrow.  For those who don't know:

   Apache Arrow is a development platform for in-memory analytics. It
   contains a set of technologies that enable big data systems to
   process and move data fast. It specifies a standardized
   language-independent columnar memory format for flat and
   hierarchical data, organized for efficient analytic operations on
   modern hardware.

   The project is developing a multi-language collection of libraries
   for solving systems problems related to in-memory analytical data
   processing. This includes such topics as:

   * Zero-copy shared memory and RPC-based data movement

   * Reading and writing file formats (like CSV, Apache ORC, and Apache
 Parquet)

   * In-memory analytics and query processing

   (from: https://arrow.apache.org/docs/index.html)

Pandas has announced that Pandas 3.x will depend on PyArrow
in a critical way (it will back the "string" datatype), and it is due
to be released imminently.

So this is a plea for anyone looking for something really helpful to
do: it would be great to have a group of developers finally package
this!  There was some initial work done (see the RFP bug report for
details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021),
but that is fairly old now.  As Apache Arrow supports numerous
languages, it may well benefit from having a group of developers with
different areas of expertise to build it.  (Or perhaps it would make
more sense to split the upstream source into a collection of different
Debian source packages for the different supported languages.  I don't
know.)  Unfortunately I don't have the capacity to devote any time to
it myself.

Thanks in advance for anyone who can step forward for this!

Best wishes,

Julian



If possible, I would like to contribute. At work we use the Go and 
Python implementations, also, in the short term, we will start using the 
Rust one.


Just to point out, the Rust version has its own native implementation, 
here: https://github.com/apache/arrow-rs .


Cheers,

Jose

--
José Manuel Abuín Mosquera
PhD. | Scientific Software Developer | Researcher

http://jmabuin.github.io

Bug#1068411: schleuder 4.0.3-7+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1068411 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: schleuder
Version: 4.0.3-7+deb12u1

Explanation: fix argument parsing insufficient validation; fix importing keys 
from attachments sent by Thunderbird and handle mails without further content; 
look for keywords only at the start of mail; validate downcased email addresses 
when checking subscribers; consider From header for finding reply addresses

Bug#1068654: bioawk 1.0-4+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1068654 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: bioawk
Version: 1.0-4+deb12u1

Explanation: disable parallel builds to fix random failures

Bug#1068574: icinga2 2.13.6-2+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1068574 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: icinga2
Version: 2.13.6-2+deb12u1

Explanation: fix segmentation fault on ppc64el

Bug#1068344: curl 7.88.1-10+deb12u6 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1068344 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: curl
Version: 7.88.1-10+deb12u6

Explanation: do not keep default protocols when deselected [CVE-2024-2004]; fix 
memory leak [CVE-2024-2398]

Bug#1056936: glewlwyd 2.7.5-3+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1056936 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: glewlwyd
Version: 2.7.5-3+deb12u1

Explanation: fix potential buffer overflow during FIDO2 credential validation 
[CVE-2023-49208]; fi xopen redirection via redirect_uri [CVE-2024-25715]

Bug#1068586: ghc: Broken on arm{el,hf} because of time_t transition

[Ilias Tsitsimpis]

Hi Adrian,

On Tue, Apr 09, 2024 at 12:56PM, Adrian Bunk wrote:
> FTR, in haskell-hourglass this is #1001686 which already failed on x32 
> for this reason.

I believe it's not. haskell-hourglass used to work on arm{el,hf} just
before the time64 transition.

> My reading of the code is that this happens when 
> libraries/time/lib/cbits/HsTime.c returns 0x8000 due to 
> localtime_r() called in this function returning an error.
> 
> The "localtime_r failed" is from
> libraries/time/lib/Data/Time/LocalTime/Internal/TimeZone.hs

The problem is that GHC uses the ccall calling convention in order to
call clock_gettime() [1]. GHC assumes time_t to be 64-bits, but ends up
calling the old 32-bits variant of clock_gettime(), and not the new one
__clock_gettime64().

Here is more information about GHC's FFI calling conventions[2].
Here is also an upstream issue about this[3].

[1] 
https://gitlab.haskell.org/ghc/packages/time/-/blob/baab563ee2ce547f7b7f7e7069ed09db2d406941/lib/Data/Time/Clock/Internal/CTimespec.hsc#L30
[2] https://www.haskell.org/ghc/blog/20210709-capi-usage.html
[3] https://github.com/haskell/directory/pull/145

The fix here is to backport (at least) the following patches which
change these calls to use the capi calling convention:

  * 
https://gitlab.haskell.org/ghc/packages/time/-/commit/d52314edb138b6ecd7e888c588f83917b0ee2c29
  * 
https://gitlab.haskell.org/ghc/packages/directory/-/commit/f6b288bd96fba5a955d1f73663eb52c1859ee765

Other Haskell libraries may have the same bug as GHC if they are calling
directly the C functions using the ccall calling convention. An example
is haskell-hourglass, which needs to be patched as well:

  * 
https://github.com/vincenthz/hs-hourglass/blob/36bd2e6d5d0eb316532f13285d1c533d6da297ef/Data/Hourglass/Internal/Unix.hs#L82

We need a way to identify every package that is broken.

-- 
Ilias

Bug#1068588: redesign of how autopkgtest talks to the testbed

[Paride Legovini]

Hi Paul,

On 2024-04-07 16:42, Paul Gevers wrote:
> The following issues have come up several times over the years. I
> propose to discuss them in one place (this bug report) to define the
> solution strategy. I haven't gone through all the details myself, so
> I might be thinking in the wrong direction, please correct me if you
> think so. Please also voice agreement, if not on the details, then on
> the general concept.
> 
> Problem statements
> ==
> 
> * runner/autopkgtest talks to the backend with a simple text
> protocol. While this enables users to add another backend without
> changes to the src:autopkgtest code trivially, the drawback of that
> is loosing all nuance of what really is going on on both sides of the
> communication. That is particularly bad when unexpected events
> happen. All events need handling on both sides, including unexpected
> events.

However this simple text based protocol also has advantages: it makes it
easy to repurpose the virt servers for other uses, like what sbuild does.
These other projects do not need to be written in Python, or we could in
principle have a virt-server not written in Python.

> * every backend has its own virt server that does the real
> communication with the testbed. A result of that is subtle
> differences in test results between different backends when they
> don't do exactly the same (code easily goes out of sync).
> 
> * most backends don't automatically provide a testbed as a user would
> see when working on a system. I recall smcv saying words like "user
> session", "dbus something-something" and the like.

+1 to these.

> Solution direction
> ==
> 
> * unify the communication with test beds via ssh. This ensures that
> the environment is much more likely to be the same across the
> different backends and also ensures the right session.

I agree nowadays ssh is a reasonable common denominator. As you noted
below, there are some virt servers where it doesn't apply well, but
they are probably special enough to be treated differently.

> * each virt server would only need to ensure an ssh server is setup
> and running in the testbed and leaving the rest of the communication
> to a common driver. (Maybe with the exception of the null, chroot and
> schroot virt servers, to be investigated.) Obviously it's still
> responsible for the tear down of the testbed.
And there is also autopkgtest-virt-unshare (probably falling under the
chroot category).

I think standardizing on ssh is desirable, but this implicitly means
that we'll have some more specific requirements for the testbed images
(in random order: sshd, some sort pubkey authentication, a "normal"
(non-root) user, cloud-init to initialize all these things?, ...).
We are currently shipping tools to prepare test images
(tools/autopkgtest-build*), but at the same time we are very flexible
on the image requirements. Should we accept being more strict on this,
and state that the virt server are meant to be used to purpose built
images? Or should we have a better spec on what the virt servers
expect from the image?

Currently autopkgtest-virt-ssh works around this by using the
"ssh setup" script, but my impression is that we want to move
away from that kind of approach.

> * handle communication between runner/autopkgtest and the virt
> servers and the ssh driver via Python classes instead of the text
> based protocol. Do this in a "plugin" friendly way such that backends
> can still easily be used without changes to src:autopkgtest.

> Alternatives
> 
> 
> * make the change to use ssh for communication, without a change of
> the virt server protocol.

Do you think this can be done incrementally, that is:

1. modify the virt-servers we have to use ssh for communication
with the testbed systems, keeping it in a common library.

2. keeping the implementation above, or most of it, also
reimplement the autopkgtest<->backend communication protocol.

The two problems should be quite decoupled after all, and while
I'm convinced that point 2 is good, I am less sure about point 1,
for the reasons I stated initially.

> Open Questions
> ==
> 
> * we could consider supporting the current protocol in parallel,
> which would enable us to migrate one backend at a time and enable our
> users to migrate their own backends at their own pace. However, it
> means we'd need to support two code paths. So the open question is:
> (how long) do we want to maintain the current protocol. I wonder how
> many other backends are out there.

Are we aware of any other consumer of the virt servers apart from
autopkgtest itself and sbuild?

> * we already have an ssh virtual server, is that good enough to be
> the ssh driver, or is it missing functionality and/or deserves a
> rewrite by itself? To answer the last question, probably yes if we
> want to move away from the current protocol.

I think we'll probably want a pure Python implementation of that,
written using 

Bug#1065413: bookworm-pu: package openssl/3.0.13-1~deb12u1

[Sebastian Andrzej Siewior]

On 2024-04-07 23:46:28 [+0200], To Adam D. Barratt wrote:
> On 2024-03-24 20:06:12 [+], Adam D. Barratt wrote:
> > 
> > Sorry for not getting to this sooner. Is this still the case?
> 
> So. This happened #1068045 (yapet broke with 1.0 format) due to the
> update. On the bright side it has been broken in unstable but unnoticed.
> Looking into it but also sleeping (but making progress).

yapet is fixed in unstable. My understanding is that the maintainer will
take care of it.

I've been looking at the release.d.o page and there are deb-ci failures
for nodejs. Those should be gone with nodejs/18.19.0+dfsg-6~deb12u1
which is in d-security.
So based on this I would say all good ;)

> > Regards,
> > 
> > Adam
 
Sebastian

Bug#1066396: lftp: FTBFS: ./config.h:2540:11: fatal error: trio.h: No such file or directory

[Benjamin Drung]

On Wed, 13 Mar 2024 13:03:20 +0100 Lucas Nussbaum 
wrote:
> Source: lftp
> Version: 4.9.2-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240313 ftbfs-trixie
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > /bin/bash ../libtool --silent  --tag=CC   --mode=compile gcc -
DHAVE_CONFIG_H -I.   -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 -fcf-protection -g -Wall -Wall -MT
argmatch.lo -MD -MP -MF $depbase.Tpo -c -o argmatch.lo argmatch.c &&\
> > mv -f $depbase.Tpo $depbase.Plo
> > In file included from argmatch.c:22:
> > ./config.h:2540:11: fatal error: trio.h: No such file or directory
> >  2540 | # include "trio.h"
> >   |   ^~~~
> > compilation terminated.
> > make[5]: *** [Makefile:2321: argmatch.lo] Error 1
> 
> 
> The full build log is available from:
> http://qa-logs.debian.net/2024/03/13/lftp_4.9.2-2_unstable.log
> 
> All bugs filed during this archive rebuild are listed at:
>
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240313;users=lu...@debian.org
> or:
>
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20240313=lu...@debian.org=1=1=1=1#results
> 
> A list of current common problems and possible solutions is available
at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to
contribute!
> 
> If you reassign this bug to another package, please mark it as
'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
> 
> If you fail to reproduce this, please provide a build log and diff it
with mine
> so that we can identify if something relevant changed in the meantime.

We applied following changes in Ubuntu to fix the build failure (patch
attached):

  * Fix C99 compatibility issue (patch taken from upstream)
  * configure.ac: Bump gettext version to 0.21
  * d/rules: Switch to dh to regenerate the configure script
  * Replace obsolete pkg-config build dependency by pkgconf
  * Drop obsolete debian/menu (would be installed by dh)

-- 
Benjamin Drung
Debian & Ubuntu Developer
diff --git a/debian/control b/debian/control
index cea175a..0346640 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: optional
 Maintainer: Ubuntu Developers 
 XSBC-Original-Maintainer: Noël Köthe 
 Standards-Version: 4.6.1
-Build-Depends: debhelper-compat (= 13), debhelper (>> 13.0.0), libncurses-dev, libreadline-dev, gettext, gawk, bison, libgnutls28-dev, pkg-config, libidn2-dev, zlib1g-dev
+Build-Depends: debhelper-compat (= 13), debhelper (>> 13.0.0), libncurses-dev, libreadline-dev, gettext, gawk, bison, libgnutls28-dev, pkgconf, libidn2-dev, zlib1g-dev
 Homepage: https://lftp.yar.ru
 Rules-Requires-Root: no
 
diff --git a/debian/menu b/debian/menu
deleted file mode 100644
index b0fee43..000
--- a/debian/menu
+++ /dev/null
@@ -1,4 +0,0 @@
-?package(lftp):needs="text" section="Apps/Net" \
-title="Lftp" command="/usr/bin/lftp" \
-hints="FTP" \
-description="Reliable, easy and powerful ftp command-line client"
diff --git a/debian/patches/Fix-C99-compatibility-issue.patch b/debian/patches/Fix-C99-compatibility-issue.patch
new file mode 100644
index 000..745a448
--- /dev/null
+++ b/debian/patches/Fix-C99-compatibility-issue.patch
@@ -0,0 +1,27 @@
+From: DJ Delorie 
+Date: Wed, 8 Feb 2023 23:37:37 -0500
+Subject: Fix C99 compatibility issue
+
+Related to:
+
+  
+  
+
+Closes: #1066396
+Origin: upstream, https://github.com/lavv17/lftp/commit/8af97cc255c3d2488adb107515bd1047dbedadfe
+---
+ m4/needtrio.m4 | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/m4/needtrio.m4 b/m4/needtrio.m4
+index 45478f9..8b350a8 100644
+--- a/m4/needtrio.m4
 b/m4/needtrio.m4
+@@ -9,6 +9,7 @@ AC_DEFUN([LFTP_NEED_TRIO],[
+   else
+ 
+   AC_RUN_IFELSE([AC_LANG_SOURCE([[
++	 #include 
+ 	 int main()
+ 	 {
+ 	unsigned long long x=0,x1;
diff --git a/debian/patches/configure.ac-Bump-gettext-version-to-0.21.patch b/debian/patches/configure.ac-Bump-gettext-version-to-0.21.patch
new file mode 100644
index 000..406de03
--- /dev/null
+++ b/debian/patches/configure.ac-Bump-gettext-version-to-0.21.patch
@@ -0,0 +1,44 @@
+From: Benjamin Drung 
+Date: Tue, 9 Apr 2024 15:08:22 +0200
+Subject: configure.ac: Bump gettext version to 0.21
+
+After running autoreconf and configure on Ubuntu 24.04 (noble), the
+generated `po/Makefile` will fail to run `make install`:
+
+```
+$ make install DESTDIR=debian/lftp
+[...]
+Making install in po
+make[4]: Entering directory 'po'
+debian/lftp/usr/share
+make[4]: debian/lftp/usr/share: Permission denied
+```
+
+This failure is caused by `mkdir_p` pointing to `MKDIR_P` but `MKDIR_P`
+not being defined in 

Bug#1068716: pdl: dh_pdl fails with "compilation aborted"

[Sebastiaan Couwenberg]

On 4/9/24 5:47 PM, Sudip Mukherjee wrote:

dh_pdl fails with the error:


Quite unusual to see dh_pdl used without debhelper installed.

I guess you were just trying the command instead of using it to set the 
dependencies for another package?



It will need a runtime dependency on libdebhelper-perl.


This is fixed in git.

Kind Regards,

Bas

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

Bug#1066346: sc: FTBFS: sc.c:1301:46: error: implicit declaration of function ‘list_frames’; did you mean ‘list_ranges’? [-Werror=implicit-function-declaration]

[Adam Majer]

On 2024-04-07 05:23, Ying-Chun Liu (PaulLiu) wrote:

I've fixed the bug. And I'll do NMU if no one object in 10 days.
I'll upload it to the delay/10 queue.

Attachment is the debdiff. Please review it.


Thanks, looks good

- Adam

Bug#1068674: Document pam_umask change in release notes

[Christoph Anton Mitterer]

Hey.

Also with respect to having this documented in the release note, you
may want to have a look at my comment:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065806#47

I.e. I think it might be usefull to not just indicate that/how people
may use "nousergroups" again, but also to refer to alternatives (like
setting a per-user default UMASK via GECOS) by referring to the
pam_umask(8) manpage.


Cheers,
Chris.

Bug#1068716: pdl: dh_pdl fails with "compilation aborted"

[Sudip Mukherjee]

Package: pdl
Version: 1:2.087-1
Severity: normal

Dear Maintainer,

dh_pdl fails with the error:

Can't locate Debian/Debhelper/Dh_Lib.pm in @INC (you may need to install the 
Debian::Debhelper::Dh_Lib module) (@INC entries checked: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.38.2 /usr/local/share/perl/5.38.2 
/usr/lib/x86_64-linux-gnu/perl5/5.38 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.38 
/usr/share/perl/5.38 /usr/local/lib/site_perl) at /usr/bin/dh_pdl line 12.
BEGIN failed--compilation aborted at /usr/bin/dh_pdl line 12.

It will need a runtime dependency on libdebhelper-perl.

-- 
Regards
Sudip


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

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

Versions of packages pdl depends on:
ii  libc6 2.37-15
ii  libfile-which-perl1.27-2
ii  libgd32.3.3-9+b1
ii  libgfortran5  14-20240201-3
ii  libgsl27  2.7.1+dfsg-6+b1
ii  libhdf4-0-alt 4.2.16-4+b1
ii  libncurses6   6.4+20240113-1
ii  libpod-parser-perl1.67-1
ii  libproj25 9.4.0-1+b1
ii  libterm-readkey-perl  2.38-2+b3
ii  libtinfo6 6.4+20240113-1
ii  perl [libtext-balanced-perl]  5.38.2-3.2+b2
ii  perl-base [perlapi-5.38.2]5.38.2-3.2+b2
ii  sensible-utils0.0.22

Versions of packages pdl recommends:
ii  libpgplot-perl 1:2.28-1+b3
ii  libterm-readline-gnu-perl  1.46-1+b2

Versions of packages pdl suggests:
pn  doc-base   
pn  libastro-fits-header-perl  
pn  libdevel-repl-perl 
pn  libextutils-f77-perl   
pn  libfile-map-perl   
ii  libgl1 1.7.0-1
pn  libinline-c-perl   
pn  libinline-perl 
pn  libmodule-compile-perl 
pn  libopengl-perl 
pn  netpbm | imagemagick   
pn  proj-bin   

Bug#1065806: fixed in pam 1.5.3-7

[Sam Hartman]

> "Christoph" == Christoph Anton Mitterer  writes:

Christoph> Hey Sam.
Christoph> There's a typ in the NEWS enty:
>> this user a group name that differs from the user name or add
Christoph>  |
Christoph>   should probably be "use"

Thanks, fixed on salsa for the next version.

Bug#1065806: fixed in pam 1.5.3-7

[Christoph Anton Mitterer]

My I suggest one further improvement:

I think it would be nice if there was a sentence like:

"See the pam_umask(8) manpage for alternative means to change the
UMASK, for example per-user only."


I guess there are users that would actually want to keep the new
default, but have it e.g. overridden only for their own user (like on
single user systems).

For that, setting it via the GECOS field seems a good way?

Tough unfortunately, clear documentation seems missing on how to
actually do this[0].
It seems umask= must be set in the "other" field (= the 5th) of the
GECOS field, e.g. via chfn --other .


HTH,
Chris.


[0] I've filed https://github.com/linux-pam/linux-pam/pull/786 to
improve on that.
Assuming that will be merged, it's IMO enough to just refer to the
manpage, so that people even know that there are finer grained means.

Bug#1068715: bookworm-pu: package ruby-premailer-rails/1.10.3-4~deb12u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Georg Faerber 

[ Reason ]
In order to get rid of the obsolete and incompatible ruby-arel,
ruby-premailer-rails has to drop its superfluous build dependency on it.
ruby-arel is nowadays integrated into ruby-actionmailer and the
incompatible ruby-arel version fortunately does not get used during
build.

[ Impact ]
Failures on some upgrade paths of schleuder if the obsolete ruby-arel is
still installed.

[ Tests ]
The package still builds ;-)

[ Risks ]
Low, dropping of a superfluous B-D could only cause a FTBFS and the
package would therefore be excluded from -pu.

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

[ Changes ]
 debian/.gitattributes |  3 +++
 debian/changelog  | 15 +++
 debian/control|  7 +++
 3 files changed, 21 insertions(+), 4 deletions(-)

ruby-premailer-rails (1.10.3-4~deb12u1) bookworm; urgency=medium

  * Non-maintainer upload.
  * Rebuild for bookworm.

 -- Andreas Beckmann   Tue, 09 Apr 2024 16:56:10 +0200

ruby-premailer-rails (1.10.3-4) unstable; urgency=medium

  * debian/control:
- Drop Build-Depends on ruby-arel, which is obsolete and part of rails
  since five years. (Closes: #1039035)

 -- Georg Faerber   Sat, 24 Jun 2023 22:31:11 +

It also drops the version constraint on the ruby-actionmailer
(build-)dependency which has been satisfied since jessie at least.

[ Other info ]
This is a rebuild of a package that has been in sid and testing for a
long time (but is now superseded by a new upstream release).

Andreas
diff --git a/debian/.gitattributes b/debian/.gitattributes
new file mode 100644
index 000..74e43f3
--- /dev/null
+++ b/debian/.gitattributes
@@ -0,0 +1,3 @@
+.gitattributes export-ignore
+gbp.conf export-ignore
+salsa-ci.yml export-ignore
\ No newline at end of file
diff --git a/debian/changelog b/debian/changelog
index 0ed9fdc..5e9ead3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+ruby-premailer-rails (1.10.3-4~deb12u1) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for bookworm.
+
+ -- Andreas Beckmann   Tue, 09 Apr 2024 16:56:10 +0200
+
+ruby-premailer-rails (1.10.3-4) unstable; urgency=medium
+
+  * debian/control:
+- Drop Build-Depends on ruby-arel, which is obsolete and part of rails
+  since five years. (Closes: #1039035)
+
+ -- Georg Faerber   Sat, 24 Jun 2023 22:31:11 +
+
 ruby-premailer-rails (1.10.3-3) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/control b/debian/control
index ece4ea5..9f756d7 100644
--- a/debian/control
+++ b/debian/control
@@ -1,19 +1,18 @@
 Source: ruby-premailer-rails
 Section: ruby
 Priority: optional
-Maintainer: Debian Ruby Extras Maintainers 

+Maintainer: Debian Ruby Team 

 Uploaders: Balasankar C 
 Build-Depends: debhelper-compat (= 12),
gem2deb,
rake,
-   ruby-actionmailer (>= 2:3.0~),
+   ruby-actionmailer,
ruby-byebug,
ruby-coveralls,
ruby-premailer (>= 1.11.1~),
ruby-rspec,
ruby-simplecov,
ruby-rails,
-   ruby-arel
 Standards-Version: 4.5.0
 Vcs-Git: https://salsa.debian.org/ruby-team/ruby-premailer-rails.git
 Vcs-Browser: https://salsa.debian.org/ruby-team/ruby-premailer-rails
@@ -25,7 +24,7 @@ Package: ruby-premailer-rails
 Architecture: all
 XB-Ruby-Versions: ${ruby:Versions}
 Depends: ruby | ruby-interpreter,
- ruby-actionmailer (>= 2:3.0~),
+ ruby-actionmailer,
  ruby-premailer (>= 1.11.1~),
  ${misc:Depends},
  ${shlibs:Depends}

Bug#1068714: packages.debian.org: Please make links to deb.debian.org use HTTPS instead of HTTP

[Pierre-Elliott Bécue]

Package: www.debian.org
Severity: serious
Tags: security
X-Debbugs-Cc: Debian Security Team 

Hello,

In packages.debian.org, links pointing to the different source files
useful for a package are pointing to deb.debian.org via HTTP (not HTTPS)
links.

See https://packages.debian.org/bookworm/python3-pep517, which points
for [pep517_0.13.0-2.debian.tar.xz] to
http://deb.debian.org/debian/pool/main/p/pep517/pep517_0.13.0-2.debian.tar.xz

In these times of supply chain attack reveals etc, I think we would be
best to give HTTPS links.

Regards,
-- 
PEB

Bug#1066239: gnome-system-tools: FTBFS: shares-tool.c:113:17: error: implicit declaration of function ‘table_add_share’ [-Werror=implicit-function-declaration]

[Andriy Grytsenko]

Thank you very much for the patch.
Applied it, it looks fine.

Bug#1068713: oar-common: Submitting jobs does not work on a fresh installation of OAR

[Pierre Neyron]

Package: oar-common
Version: 2.5.9-1
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: pierre.ney...@imag.fr

Hello

After a fresh install of OAR on Debian stable (bookworm), starting jobs does 
not work.

Indeed the ssh connection to nodes is forbidden because the oar user is locked, 
instead of just not accepting password connections.

It is due to a change in the way the adduser ( >= 3.130 ) `--disabled-password` 
option works (it now set `!` instead of `*` in the password hash field).
`usermod -p '*' oar` fixes the issue.

This bug is fixed in Debian testing / oar-common 2.5.10-1.

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

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

Versions of packages oar-common depends on:
ii  adduser  3.134
ii  libc62.36-9+deb12u4
ii  liboar-perl  2.5.9-1
ii  perl 5.36.0-7+deb12u1
ii  ucf  3.0043+nmu1

oar-common recommends no packages.

Versions of packages oar-common suggests:
pn  oar-doc 
pn  oar-node
pn  oar-server  
ii  oar-user2.5.9-1

-- no debconf information

Bug#1056555: thunar: segfault when ejecting drive

[Bernhard Übelacker]

Hello ng,


On Wed, 22 Nov 2023 22:47:01 -0300 ng  wrote:


[18950.426861] Thunar[3027]: segfault at 0 ip 5615a96c98cc sp 
7ffd2dbd7320 error 4 in thunar[5615a964+92000] likely on CPU 7 (core 3, 
socket 0)
[18950.426895] Code: f3 48 83 ec 38 64 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 
48 c7 44 24 20 00 00 00 00 48 85 f6 0f 84 77 02 00 00 48 8b 06 <48> 39 10 0f 84 
f1 01 00 00 4c 8b bf 28 01 00 00 4c 39 fe 0f 84 cb


This lines point to following source location:

thunar/thunar-window.c, line 4000

https://sources.debian.org/src/thunar/4.18.4-1/thunar/thunar-window.c/#L4000
3999   /* if the view already has the correct type then just return */
4000   if (view != NULL && G_TYPE_FROM_INSTANCE (view) == view_type)
4001 return;


Unfortunately this might yet not be enough for the maintainer to fix the issue.

Following link contains a few pointers how to get a backtrace of a crash:
https://wiki.debian.org/HowToGetABacktrace


Kind regards,
Bernhard


https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash


[18950.426861] Thunar[3027]: segfault at 0 ip 5615a96c98cc sp 
7ffd2dbd7320 error 4 in thunar[5615a964+92000] likely on CPU 7 (core 3, 
socket 0)
[18950.426895] Code: f3 48 83 ec 38 64 48 8b 04 25 28 00 00 00 48 89 44 24 28 
31 c0 48 c7 44 24 20 00 00 00 00 48 85 f6 0f 84 77 02 00 00 48 8b 06 <48> 39 10 
0f 84 f1 01 00 00 4c 8b bf 28 01 00 00 4c 39 fe 0f 84 cb

error 4 == 0b0100:
 *   bit 0 ==0: no page found
 *   bit 1 ==0: read access
 *   bit 2 ==1: user-mode access
.


echo -n "find /b ..., ..., 0x" && \
echo "f3 48 83 ec 38 64 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 48 c7 44 
24 20 00 00 00 00 48 85 f6 0f 84 77 02 00 00 48 8b 06 <48> 39 10 0f 84 f1 01 00 
00 4c 8b bf 28 01 00 00 4c 39 fe 0f 84 cb" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'





# Bookworm/stable amd64 qemu VM 2024-04-09

apt update
apt install gdb thunar thunar-dbgsym

gdb -q 
set width 0
set pagination off
file /usr/bin/thunar
tb main
run 
pipe info target | grep "\.text"
find /b 0x5557fdb0, 0x5560bad9, 0xf3, 0x48, 0x83, 0xec, 0x38, 
0x64, 0x48, 0x8b, 0x04, 0x25, 0x28, 0x00, 0x00, 0x00, 0x48, 0x89, 0x44, 0x24, 
0x28, 0x31, 0xc0, 0x48, 0xc7, 0x44, 0x24, 0x20, 0x00, 0x00, 0x00, 0x00, 0x48, 
0x85, 0xf6, 0x0f, 0x84, 0x77, 0x02, 0x00, 0x00, 0x48, 0x8b, 0x06, 0x48, 0x39, 
0x10, 0x0f, 0x84, 0xf1, 0x01, 0x00, 0x00, 0x4c, 0x8b, 0xbf, 0x28, 0x01, 0x00, 
0x00, 0x4c, 0x39, 0xfe, 0x0f, 0x84, 0xcb
b * (0x556038a2 + 42)
info b
disassemble /r 0x556038a2, 0x556038a2 + 62





benutzer@debian:~$ gdb -q 
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/bin/thunar
Reading symbols from /usr/bin/thunar...
Reading symbols from 
/usr/lib/debug/.build-id/1c/0053bee14d3fb731923319e68ac183a810d9db.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x2bdd0: file ./thunar/main.c, line 49.
(gdb) run 
Starting program: /usr/bin/thunar 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe4d8) at ./thunar/main.c:49
49  ./thunar/main.c: Datei oder Verzeichnis nicht gefunden.
(gdb) pipe info target | grep "\.text"
0x5557fdb0 - 0x5560bad9 is .text
...
(gdb) find /b 0x5557fdb0, 0x5560bad9, 0xf3, 0x48, 0x83, 0xec, 
0x38, 0x64, 0x48, 0x8b, 0x04, 0x25, 0x28, 0x00, 0x00, 0x00, 0x48, 0x89, 0x44, 
0x24, 0x28, 0x31, 0xc0, 0x48, 0xc7, 0x44, 0x24, 0x20, 0x00, 0x00, 0x00, 0x00, 
0x48, 0x85, 0xf6, 0x0f, 0x84, 0x77, 0x02, 0x00, 0x00, 0x48, 0x8b, 0x06, 0x48, 
0x39, 0x10, 0x0f, 0x84, 0xf1, 0x01, 0x00, 0x00, 0x4c, 0x8b, 0xbf, 0x28, 0x01, 
0x00, 0x00, 0x4c, 0x39, 0xfe, 0x0f, 0x84, 0xcb
0x556038a2 
1 pattern found.
(gdb) b * (0x556038a2 + 42)
Breakpoint 2 at 0x556038cc: file ./thunar/thunar-window.c, line 4000.
(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x556038cc in 
thunar_window_replace_view at ./thunar/thunar-window.c:4000
(gdb) disassemble /r 0x556038a2, 0x556038a2 + 62
Dump of assembler code from 0x556038a2 to 0x556038e0:
   0x556038a2 :  f3 48 83 ec 38  
repz sub $0x38,%rsp
   0x556038a7 :  64 48 8b 04 25 28 00 00 
00  mov%fs:0x28,%rax
   0x556038b0 :  48 89 44 24 28  
mov%rax,0x28(%rsp)
   0x556038b5 :  31 c0   
xor%eax,%eax
   0x556038b7 :  48 c7 44 24 20 00 00 00 
00  movq   $0x0,0x20(%rsp)
   0x556038c0 :  48 85 f6
test   %rsi,%rsi
   0x556038c3 :  0f 84 77 02 00 00   
je 0x55603b40 
   0x556038c9 :  48 8b 06
mov(%rsi),%rax
   0x556038cc :  48 39 10
cmp%rdx,(%rax)<<<
   0x556038cf :  0f 84 f1 01 00 00   
je 0x55603ac6 
   0x556038d5 :  4c 8b bf 28 01 00 00
mov

Bug#1065806: fixed in pam 1.5.3-7

[Christoph Anton Mitterer]

Hey Sam.

There's a typ in the NEWS enty:
>this user a group name that differs from the user name or add
 |
  should probably be "use"


Also, I had to think twice what's meant by "pat" ;-)
> matches their primary user name (user pat's default group is also
>called pat), then files will be group writable by default. To disable

Perhaps placing the two "pat"s in quotes?

Cheers,
Chris.

Bug#1068712: RM: ruby-arel -- RoQA; obsolete, integrated into ruby-activerecord, incompatible with ruby-activerecord 6.1.x

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: Georg Faerber 

ruby-arel is now integrated into ruby-activerecord and the obsolete
version that is packaged separately is incompatible with the current
version of ruby-activerecord. #1039034

There are no reverse (build-)depends left in sid.


Andreas

Bug#1053433: mate-panel: mate-clock segfaults on return from hibernation

[Bernhard Übelacker]

Hello Olly,



(gdb) bt
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x7fa84248315f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  0x7fa842435472 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x7fa84241f4b2 in __GI_abort () at ./stdlib/abort.c:79
#4  0x7fa84276d5dd in  ()
#5  0x in  ()

I read that as it's already aborting when it segfaults, so maybe that's
not helpful in knowing the root cause.  I'm happy to debug further if
someone tells me what to try.




This means the instruction just before 0x7fa84276d5dd
is most probably a call to function abort.
Usually this is done if some assertion fails.
Therefore there might something like "assertion failed" in the
logs at this time.

Unfortunately 0x7fa84276d5dd might be inside of a shared object.
And for it is no -dbgsym package installed.

To find out which shared object you might have a look into the
output of `info share`.

If you receive such a crash you could create a core dump with
gdb command `generate-core-file`.

Or install some core dump collector, e.g. systemd-coredump.
With this after a crash happened one can inspect it via
  coredumpctl list
  coredumpctl gdb

This link contains some more ways to debug
and to install the dbgsym packages:

https://wiki.debian.org/HowToGetABacktrace

Kind regards,
Bernhard

Bug#1068711: oar-web-status: the Monika CGI page does not work - missing dependency.

[Pierre Neyron]

Package: oar-web-status
Version: 2.5.9-1
Severity: serious
Tags: 
Justification: Monika requires libcgi-fast-perl
X-Debbugs-Cc: pierre.ney...@free.fr

Hello,

When installing the oar-web-status package only, without the oar-restful-api 
alongside (not dependency between then), the Monika CGI page does not work.

The problem does not arise when oar-restful-api is installed alongside as well, 
because it bring the required dependency: libcgi-fast-perl.

oar-web-status should require libcgi-fast-perl, like oar-restful-api.

Problem still occures in Debian testing with oar-web-status 2.5.10-1. 

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

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

Versions of packages oar-web-status depends on:
ii  apache2 [httpd-cgi]   2.4.57-2
ii  libappconfig-perl 1.71-2.2
ii  libdbd-pg-perl3.16.0-2
ii  libdbi-perl   1.643-4
ii  libsort-naturally-perl1.03-4
ii  libtie-ixhash-perl1.23-4
ii  perl  5.36.0-7+deb12u1
ii  php   2:8.2+93
ii  php-pgsql 2:8.2+93
ii  php8.2 [php]  8.2.7-1~deb12u1
ii  php8.2-pgsql [php-pgsql]  8.2.7-1~deb12u1

oar-web-status recommends no packages.

Versions of packages oar-web-status suggests:
pn  oar-doc  

-- no debconf information

Bug#1068710: tiktoken: pybuild-autopkgtest fails with ModuleNotFoundError(s)

[Nick Rosbrook]

Package: tiktoken
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Dear Maintainer,

In Ubuntu, I noticed that the autopkgtests were failing for tiktoken[1].
The failure is due to missing 'pytest' and 'hypothesis' python modules.
Looking at [2], I see the same failures in Debian. I applied this
patch in Ubuntu to fix the autopkgtest:

  * debian/control: Build-Depends: python3-{pytest,hypothesis}

Thanks for considering the patch.

-Nick

[1] https://bugs.launchpad.net/bugs/2060690
[2] https://ci.debian.net/packages/t/tiktoken/
diff -Nru tiktoken-0.6.0/debian/control tiktoken-0.6.0/debian/control
--- tiktoken-0.6.0/debian/control   2024-04-01 04:25:31.0 -0400
+++ tiktoken-0.6.0/debian/control   2024-04-09 10:23:56.0 -0400
@@ -11,6 +10,8 @@
  , python3-all
  , python3-setuptools-rust
  , python3-regex
+ , python3-hypothesis
+ , python3-pytest
  , librust-bstr-dev (>= 0.0.1~)
  , librust-fancy-regex-dev
  , librust-pyo3-dev

Bug#1004499: transmission-daemon segfault in libgnutls.so.30.13.1 and libc-2.24.so

[Alexandre Rossi]

Hi,

I have run transmission-daemon 3.x and 4.x for days without experiencing a
segfault.

Is this still current?

Thanks,

Alex

Bug#1068709: dose-extra: Typo in /usr/share/doc/dose-extra/README.architecture

[Wookey]

Package: dose-extra
Version: 7.0.0-1+b2
Severity: minor

There is a trivial typo in line 17 of
/usr/share/doc/dose-extra/README.architecture

"libcduf is the central - in memory - data structure"
libcduf->libcudf

--
Wookey

Bug#1067908: Acknowledgement (Enable I6300ESB_WDT)

[Andrew Jorgensen]

X-Debbugs-CC: debian-cl...@lists.debian.org

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

[Vincent Lefevre]

On 2024-04-09 14:09:43 +0200, Vincent Lefevre wrote:
> Some additional information: created only once, but data may be
> appended (on the creator's side, the file is created for writing,
> and data are written occasionally, and at some point, the file is
> closed). The error with "open" may occur even several hours after
> the last time data were written to the file.

This is actually reproducible with a read-only directory.
I've attached a Perl script to reproduce the issue, just
based on "stat".

The conditions seem to be:
  * The directory and the files need to be recent enough: I can't
reproduce the issue with an old directory, even if I add many
new files into it.
  * Concurrent "stat": with the attached script, the issue is
reproducible with 2 threads or more, but not with a single
thread.

Example of errors:

./dir-stat: can't stat . (x 2)
./dir-stat: can't stat 775 (x 148)
./dir-stat: can't stat 772 (x 1)
./dir-stat: can't stat 415 (x 1)
./dir-stat: can't stat 716 (x 1)
./dir-stat: can't stat 453 (x 1)
./dir-stat: can't stat 9 (x 1)
./dir-stat: can't stat 201 (x 1)
./dir-stat: can't stat 981 (x 1)
./dir-stat: can't stat 660 (x 1)
./dir-stat: can't stat 120 (x 1)
./dir-stat: can't stat 127 (x 1)
./dir-stat: can't stat 663 (x 1)

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

# Create a directory with several hundreds of files, for instance with
#   mkdir test && cd test && touch `seq 999`
# then run this Perl script with the directory name in argument.

use strict;
use threads;

my $maxthreads = 2;
my $nthreads = 0;

@ARGV == 1 or die "Usage: $0 \n";
my $dir = $ARGV[0];
-d $dir or die "$0: $dir is not a directory\n";

sub thr ($) {
  my $file = $_[0];
  my $err = 0;
  until (stat "$dir/$file")
{
  $err++;
  sleep 0.25;
}
  warn "$0: can't stat $file (x $err)\n" if $err;
}

sub join_threads () {
  my @thr;
  sleep 0.25 until @thr = threads->list(threads::joinable);
  foreach my $thr (@thr)
{ $thr->join(); }
  $nthreads -= @thr;
}

opendir DIR, $dir or die "$0: opendir failed ($!)\n";
while (my $file = readdir DIR)
  {
$nthreads < $maxthreads or join_threads;
$nthreads++ < $maxthreads or die "$0: internal error\n";
threads->create(\, $file);
  }
closedir DIR or die "$0: closedir failed ($!)\n";
join_threads while $nthreads;

Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod

[Cyril Brulebois]

Hi,

Marco d'Itri  (2024-04-09):
> Yes. Nowadays kmod has many more features related to compressed modules 
> and verification of signatures.
> Can we agree that kmod should provide these programs for d-i?
> Or can the d-i maintainers just tell us what they want?

I meant to come back to this after experimenting, then things happened…

I picked kmod at the time because it worked, and because busybox didn't
work, which I summed up in:
  
https://salsa.debian.org/installer-team/debian-installer/-/commit/450daf0bd24ee94d4f466ab65908c079ef795145

(plus follow-up commit, woopsie
  
https://salsa.debian.org/installer-team/debian-installer/-/commit/69777be465c5d0210d16159a456ab88535513a07
)

I'm fine with sticking to kmod regarding module support in d-i. I'm not
sure we should keep support in two different modules, so dropping it
from busybox would work for me. Others might have different views on
this, though.


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


signature.asc
Description: PGP signature

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Diederik de Haas]

Hi Cyril,

On Tuesday, 9 April 2024 01:06:43 CEST Cyril Brulebois wrote:
> Upgrading from linux-image-6.1.0-18-amd64 to linux-image-6.1.0-19-amd64
> leads to losing some SMART information, at least as queried by munin (in
> Debian 12) when it comes to sensors.

Does the problem go away if you revert the following commits on top of -19?

db6338f45971b4285ea368432a84033690eaf53c
scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler

1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
scsi: core: Move scsi_host_busy() out of host lock if it is for per-command

cf33e6ca12d814e1be2263cb76960d0019d7fb94
scsi: core: Add struct for args to execution functions

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

Bug#1068708: Building with EPICS fails because the compiler cannot find `compilerSpecific.h`.

[Florian Forster]

Package: epics-dev
Version: 7.0.8+dfsg1-1

Building with EPICS fails because the compiler cannot find `
compilerSpecific.h`:

```
In file included from /usr/include/epics/epicsThread.h:62,
 from /usr/include/epics/cadef.h:35,
 from src/epics.c:26:
/usr/include/epics/compilerDependencies.h:21:10: fatal error:
compilerSpecific.h: No such file or directory
  21 | #include "compilerSpecific.h"
 | ^~~~
compilation terminated.
make[1]: *** [Makefile:8195: src/epics_la-epics.lo] Error 1
```

The file exists at `/usr/include/epics/compiler/gcc/compilerSpecific.h`,
which is not a directory searched by the compiler.

`"compilerSpecific.h"` is included unconditionally, and fails when not
compiled with GCC. My recommendation is to guard the inclusion of the file
with an appropriate check, for example:

```
// /usr/include/epics/compilerDependencies.h, line 21
#if __GNUC__
# include "compiler/gcc/compilerSpecific.h"
#endif
```

Best regards
—octo

Bug#1068707: RM: concurrent-dfsg -- ROM; Obsolete, no longer used

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: concurrent-d...@packages.debian.org
Control: affects -1 + src:concurrent-dfsg
User: ftp.debian@packages.debian.org
Usertags: remove

The concurrent-dfsg package contains a very old version of the concurrent
programming framework that was eventually merged into Java 5 20 years ago.
This old version is no longer used in Debian and can be safely removed.

Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod

[Marco d'Itri]

On Jan 06, Michael Tokarev  wrote:

> Yes, some utils in busybox aren't as good as regular implementations. For
Yes. Nowadays kmod has many more features related to compressed modules 
and verification of signatures.
Can we agree that kmod should provide these programs for d-i?
Or can the d-i maintainers just tell us what they want?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye

[Holger Levsen]

package: diffoscope
version: 263

hi,

diffoscope 263 crashes on libscout 2.3.2-3 build on unstable but not bullseye:
libscout 2.3.2-3 is part of bullseye (but neither bookworm nor trixie) and
builds unreproducible there and diffoscope is able to show a diff.

when building libscout 2.3.2-3 on current unstable, the result is also 
unreproducible, but diffoscope crashes when analysing the diff.

this happens on all 4 tested archs.

I've copied the packages in question to
https://tests.reproducible-builds.org/debian/diffoscope-libscout/artifacts/r00t-me/
for further investigation. (because one .deb is 20mb and there's 16 of them.)


(someone please remind me to delete them there once this bug has been closed.)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The hardest part about defending against social engineering is that it
doesn't attack attack the weakness of a community.  It attacks its
*strengths*: trust, collaboration, and mutual assistance. (Russ Allbery)


signature.asc
Description: PGP signature

Bug#1068704: login: Wrong comment in login.defs about USERGROUPS_ENAB

[Antoine Le Gonidec]

Package: login
Version: 1:4.13+dfsg1-4
Severity: normal

>From /etc/login.defs, part of the comment above USERGROUPS_ENAB is no
longer describing the actual behaviour:

> Other former uses of this variable such as setting the umask when
> user==primary group are not used in PAM environments, such as Debian

Recent changes in src:pam made this configuration value change the
setting of umask when the user name and its primary group name are the
same, cf. https://bugs.debian.org/1065806 and https://bugs.debian.org/583958

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

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

Versions of packages login depends on:
ii  libaudit1   1:3.1.2-2.1
ii  libc6   2.37-15.1
ii  libcrypt1   1:4.4.36-4
ii  libpam-modules  1.5.3-7
ii  libpam-runtime  1.5.3-7
ii  libpam0g1.5.3-7

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#1068703: mirror submission for mirror.debian.ikoula.com

[Support Infogerance]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.debian.ikoula.com
Archive-architecture: amd64 arm64 i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Support Infogerance 
Country: FR France
Location: Grand Est
Sponsor: Ikoula https://www.ikoula.com/




Trace Url: http://mirror.debian.ikoula.com/debian/project/trace/
Trace Url: 
http://mirror.debian.ikoula.com/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.debian.ikoula.com/debian/project/trace/mirror.debian.ikoula.com

Bug#1068702: atool: use_tar_lzip_option in /etc/atool.conf breaks atool

[cacin]

Package: atool
Version: 0.39.0-14
Severity: normal

Dear Maintainer,

the manpage for atool describes the option use_tar_lzip_option

However if you add use_tar_lzip_option to /etc/atool.conf, you get the error:

atool: /etc/atool.conf:12: unrecognized directive `use_tar_lzip_option'

and atool fails to work at all.





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

Versions of packages atool depends on:
ii  perl  5.38.2-3.2

Versions of packages atool recommends:
ii  bash-completion  1:2.11-8
ii  binutils 2.42-4
ii  file 1:5.45-3
ii  lbzip2   2.5-2.3
ii  unzip6.0-28
ii  xz-utils 5.6.1+really5.4.5-1
ii  zip  3.0-13

Versions of packages atool suggests:
ii  7zip 23.01+dfsg-8
ii  arc  5.21q-12
ii  arj  3.10.22-27
ii  cpio 2.15+dfsg-1
ii  lzip 1.24.1-1
ii  lzma 9.22-2.2
ii  lzop 1.04-2
pn  nomarch  
ii  rar  2:7.00-1
pn  rpm  
ii  unace1.2b-23
ii  unalz0.65-9
ii  unrar1:7.0.7-1
ii  xz-utils [lzma]  5.6.1+really5.4.5-1
ii  zstd 1.5.5+dfsg2-2

-- Configuration Files:
/etc/atool.conf changed:
use_tar_lzip_option 1
use_rar_for_unpack  1


-- no debconf information

Bug#1068701: TypeError: cannot use a string pattern on a bytes-like object

[Timon de Groot]

Package: duplicity
Version: 0.8.22-1+b3
Severity: normal
X-Debbugs-Cc: timon.degr...@hypernode.com

Dear Maintainer,

   * What led up to the situation?
   We create write offsite backups to s3 with duply/duplicity. We run
   duplicity with the following params (from duply):
   --s3-european-buckets --s3-use-new-style --s3-multipart-chunk-size=25
   --s3-use-multiprocessing --s3-use-ia
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 When we run the duply backup, we get to see the error:
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/duplicity/backends/_boto_multi.py", line 223, 
in _upload
mp.upload_part_from_file(fd, offset + 1, cb=_upload_callback,
  File "/usr/lib/python3/dist-packages/boto/s3/multipart.py", line 257, 
in upload_part_from_file
key.set_contents_from_file(fp, headers=headers, replace=replace,
  File "/usr/lib/python3/dist-packages/boto/s3/key.py", line 1307, in 
set_contents_from_file
self.send_file(fp, headers=headers, cb=cb, num_cb=num_cb,
  File "/usr/lib/python3/dist-packages/boto/s3/key.py", line 760, in 
send_file
self._send_file_internal(fp, headers=headers, cb=cb, num_cb=num_cb,
  File "/usr/lib/python3/dist-packages/boto/s3/key.py", line 932, in 
_send_file_internal
self.content_type = mimetypes.guess_type(self.path)[0]
^^^
  File "/usr/lib/python3.11/mimetypes.py", line 307, in guess_type
return _db.guess_type(url, strict)
   ^^^
  File "/usr/lib/python3.11/mimetypes.py", line 123, in guess_type
scheme, url = urllib.parse._splittype(url)
  
  File "/usr/lib/python3.11/urllib/parse.py", line 1038, in _splittype
match = _typeprog.match(url)

TypeError: cannot use a string pattern on a bytes-like object
Giving up after 5 attempts. BackendException: Multipart upload failed. 
Aborted.
   * What outcome did you expect instead?
   Duplicity to finish the backup and upload to S3, not crash

For your info/convenience, we repackaged bookworm duplicity in our own repo 
with this patch applied:
https://gitlab.com/duplicity/duplicity/-/merge_requests/99

Our repackaged duplicity: 
https://apt.hypernode.com/pool/hypernode/d/duplicity/duplicity_0.8.22-1%2Bhypernode1_amd64.deb

Upstream issue: https://gitlab.com/duplicity/duplicity/-/issues/126
Ubuntu also has related issue: 
https://bugs.launchpad.net/ubuntu/+source/duplicity/+bug/1908971


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

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

Versions of packages duplicity depends on:
ii  gnupg  2.2.40-1.1
ii  libc6  2.36-9+deb12u4
ii  librsync2  2.3.2-1+b1
ii  python33.11.2-1+b1
ii  python3-fasteners  0.17.3-2
ii  python3-future 0.18.2-6
ii  python3-lockfile   1:0.12.2-2.2
ii  python3.11 3.11.2-6

Versions of packages duplicity recommends:
ii  python3-oauthlib  3.2.2-1
ii  python3-paramiko  2.12.0-2
ii  python3-pexpect   4.8.0-4
ii  python3-urllib3   1.26.12-1
ii  rsync 3.2.7-1

Versions of packages duplicity suggests:
pn  lftp 
pn  ncftp
pn  par2 
pn  python3-boto 
ii  python3-pip  23.0.1+dfsg-1
pn  python3-swiftclient  
pn  tahoe-lafs   

-- no debconf information

Bug#1068700: file: wrong MIME type for RAR files

[cacin]

Package: file
Version: 1:5.45-3
Severity: normal

Dear Maintainer,

`file -i archive.rar` currently reports a MIME type of: application/x-rar

However, according to sources like 
https://www.iana.org/assignments/media-types/application/vnd.rar

the correct MIME type should be application/vnd.rar

and the deprecated MIME type was application/x-rar-compressed

It has never been application/x-rar as far as I can tell.

Bug#1068699: cdebootstrap hangs while bootstrapping ubuntu lts release

[Juozas Pocius]

Package: cdebootstrap
Version: 0.7.8+b19
Severity: normal
X-Debbugs-Cc: juoza...@gmail.com

Dear Maintainer, I'm unable to bootstrap any recent ubuntu LTS release such as 
ubuntu/jammy
or ubuntu/noble while using cdebootstrap. It hangs while extracting 
init-system-helpers
ubuntu package. I didn't test non-LTS release. This bug was originally reported 
in Ubuntu bug
tracker, but while testing in Debian I also found that the Debian version is 
also affected.

The original ubuntu bug url: 
https://bugs.launchpad.net/ubuntu/+source/cdebootstrap/+bug/1969277

While running with --verbose --debug it appears cdebootstrap is hanging 
decompressing
init-system-helpers_1.66ubuntu1_all.deb when bootstrapping ubuntu/noble, while 
debian unstable
bootstraps w/o problem, trimmed down log is shown below.

D: Read suites config from /usr/share/cdebootstrap
D: Searching initial config, using origin ubuntu and codename noble
D: Found initial config, specifies keyring ubuntu-archive-keyring.gpg, mirror 
http://archive.ubuntu.com/ubuntu
D: Using mirror http://archive.ubuntu.com/ubuntu
D: Using keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg
P: Retrieving Release
D: Downloading http://archive.ubuntu.com/ubuntu/dists/noble/Release
P: Retrieving Release.gpg
D: Downloading http://archive.ubuntu.com/ubuntu/dists/noble/Release.gpg
P: Validating Release
D: Execute "gpgv …"
D: GNUPG Status: [GNUPG:] NEWSIG
gpgv: Signature made Tue Apr  9 14:09:07 2024 EEST
gpgv:using RSA key F6ECB3762474EDA9D21B7022871920D1991BC93C
D: GNUPG Status: [GNUPG:] KEY_CONSIDERED 
F6ECB3762474EDA9D21B7022871920D1991BC93C 0
D: GNUPG Status: [GNUPG:] SIG_ID D0yQ7BuuG9cHVBYXbyUtBwRyHoE 2024-04-09 
1712660947
D: GNUPG Status: [GNUPG:] KEY_CONSIDERED 
F6ECB3762474EDA9D21B7022871920D1991BC93C 0
D: GNUPG Status: [GNUPG:] GOODSIG 871920D1991BC93C Ubuntu Archive Automatic 
Signing Key (2018) 
I: Good signature from "Ubuntu Archive Automatic Signing Key (2018) 
"
gpgv: Good signature from "Ubuntu Archive Automatic Signing Key (2018) 
"
D: GNUPG Status: [GNUPG:] VALIDSIG F6ECB3762474EDA9D21B7022871920D1991BC93C 
2024-04-09 1712660947 0 4 0 1 10 00 F6ECB3762474EDA9D21B7022871920D1991BC93C
D: Status: 0
P: Parsing Release
D: Found late config, specifies no config
D: Use default config generic
D: Read suite config from /usr/share/cdebootstrap/generic
P: Retrieving Packages.xz
D: Downloading 
http://archive.ubuntu.com/ubuntu/dists/noble/main/binary-amd64/Packages.xz
P: Validating Packages.xz
D: Execute "sha256sum 
/root/test/var/cache/bootstrap/_dists_._main_binary-amd64_Packages.xz"
D: XZ decompression: New. Len: 0
D: XZ decompression: Free. Len: -1413416
P: Parsing Packages
P: Can't find package makedev
D: Include non-base edge package python3-profiler
...
D: Include non-base edge package xdg-user-dirs
P: Retrieving init-system-helpers
D: Downloading 
http://archive.ubuntu.com/ubuntu/pool/main/i/init-system-helpers/init-system-helpers_1.66ubuntu1_all.deb
P: Validating init-system-helpers
D: Execute "sha256sum 
/root/test/var/cache/bootstrap/init-system-helpers_1.66ubuntu1_all.deb"
...
P: Retrieving ncurses-bin
D: Downloading 
http://archive.ubuntu.com/ubuntu/pool/main/n/ncurses/ncurses-bin_6.4+20240113-1ubuntu1_amd64.deb
P: Validating ncurses-bin
D: Execute "sha256sum 
/root/test/var/cache/bootstrap/ncurses-bin_6.4+20240113-1ubuntu1_amd64.deb"
D: call action: essential-extract (what: (null), flags: 0)
P: Extracting init-system-helpers
D: Decompressing init-system-helpers_1.66ubuntu1_all.deb

Debian chroot running under Ubuntu 22.04 host, using schroot to enter the 
chroot environment.

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

Kernel: Linux 5.15.0-102-generic (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8), LANGUAGE=lt_LT
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages cdebootstrap depends on:
ii  debian-archive-keyring  2023.4
ii  gpgv2.2.40-3
ii  libbz2-1.0  1.0.8-5.1
ii  libc6   2.37-15.1
ii  libcurl3t64-gnutls  8.7.1-2
ii  libdebian-installer-extra4  0.124
ii  libdebian-installer40.124
ii  liblzma55.6.1+really5.4.5-1
ii  zlib1g  1:1.3.dfsg-3.1

cdebootstrap recommends no packages.

Versions of packages cdebootstrap suggests:
pn  qemu-user-static  

-- no debconf information

Bug#1068360: [Pkg-samba-maint] Bug#1068360: samba-gpupdate should be in samba-common-bin

[Patrick Hibbs]

On 4/8/24 09:15, Michael Tokarev wrote:
How would you join a computer without main samba component to a 
domain, and how

would you process group policy in this case?

/mjt 


The net command in samba-common-bin, specifically: `/usr/bin/net ads 
join`, allows joining the domain without having the main samba package 
installed.



sssd-ad with it's ad_update_samba_machine_account_password flag set to 
true in it's config will keep the machine creds up-to-date without the 
main samba package installed.



samba-gpupdate handles downloading and managing group policies on the 
domain member, just like the gpupdate utility under Windows.


samba-gpupdate is just a python script. It's dependencies are in 
python3-samba. Which samba-common-bin already depends on. That script is 
invoked either by winbind,


the alternative for sssd systems (and not packaged in Debian) 
oddjob-gpupdate (https://github.com/altlinux/oddjob-gpupdate), or 
manually by the system admin. (The script takes arguments similar to the 
Windows utility.)



Personally, I have samba-gpupdate invoked as an hourly cron job. Which 
is pushed out to the client machines via Samba's crontab group policy 
extension. (So after the initial join, I have to invoke samba-gpupdate 
myself once, but after that,


cron is configured automatically to call it based on the policy that was 
pulled.) Of course, this will break if the host gets put into an OU in 
the domain that removes the cronjob, but that can be fixed by recalling 
samba-gpupdate after fixing the policy on the domain side. (And can even 
be triggered via a script calling ssh.)

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

[Vincent Lefevre]

On 2024-04-04 14:56:47 +0200, Vincent Lefevre wrote:
> On 2023-11-29 16:19:02 +0100, Vincent Lefevre wrote:
> > I have the same kind of issue at my lab with one of my programs:
> > a readdir lists the file, but then a stat sometimes gives a
> > "No such file or directory" error. Some clients are more affected
> > that others.
> 
> And sometimes, the "stat" succeeds as expected, but the "open" that
> follows gives a "No such file or directory" error.
> 
> Also note that in my case, the file under this filename is unique:
> it is created only once (never deleted then recreated).

Some additional information: created only once, but data may be
appended (on the creator's side, the file is created for writing,
and data are written occasionally, and at some point, the file is
closed). The error with "open" may occur even several hours after
the last time data were written to the file.

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

Bug#1031928: [Pkg-mailman-hackers] Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error

[James Addison]

Control: reopen -1

Hi Pierre,

On Sun, 17 Mar 2024 at 22:14, Pierre-Elliott Bécue  wrote:
>
> Considering the version of django-compressor in bookworm, I think this
> bug can be closed.
>
> [ .. snip .. ]

Unfortunately I do not believe that this problem is resolved yet; my
understanding is that the issue appears when DEBUG mode is enabled, meaning
that compression is _disabled_, and so the dependency on django-compressor is
not directly relevant.

The problem originates from some non-well-formed HTML in the hyperkitty
templates.

Regards,
James

Bug#1068637: apt does not always install Recommends

[David Kalnischkies]

Control: reassign 1068637 debian-installer
Control: reassign 1068560 debian-installer
Control: forcemerge 931283 1068637 1068560

Summary of bug(s) so far: lvm2 installed by d-i without its Recommends
Question: Can we solve this once and for all or do we need/want a
 workaround and/or downgrade for lvm2 only to make user happy
[only pun intended]

Merging both into #931283 that seems to be about the same thing.

On Tue, Apr 09, 2024 at 02:17:18AM +0200, Vincent Lefevre wrote:
> Then, I don't know the internals. But according to Bastian Blank[*]:
> "It is installed like everything else." (but see the details below).
> 
> [*] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068560#22

He likely meant that you have installed it, "like everything else"
because that is what users usually do and you weren't particular clear
that you haven't – and what you used that did for you… lvm2 isn't
"a core package", so there are certainly ways of installing Debian
(even with d-i, which isn't the only way either) without lvm2.

d-i seems to install packages without recommends:
https://salsa.debian.org/installer-team/base-installer/-/blob/master/library.sh?ref_type=heads#L152
That is later dropped for "everything else", but I suppose lvm2 is
installed before that – but I don't know much about d-i or lvm2.


Anyway, it probably isn't a good idea to have d-i install all recommends
while it sets up the machine – better things to do and all that –, but
perhaps it can as one of the last actions (final_apt_preferences ?) run
something like:
| apt-get install --fix-policy
(after the config is removed, or add --install-recommends).

Likely involves demoting some 'Recommends' in the base set to 'Suggests'
through, but they behave like that already if installed by d-i, so that
is probably for the best for consistency alone.

In any case, I will leave d-i folks have fun with this now,
but feel free to ask apt-team if there is something we can help with.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

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

[Antti-Pekka Känsälä]

On Sat, 6 Apr 2024 21:26:25 +0700 Max Nikulin  wrote:
> On Mon, 1 Apr 2024 21:32:41 +0300 Antti-Pekka Känsälä wrote:
> > Closing the Gmail tab will not help.
>
> I rarely use gmail web UI. At least in the case of KDE, Firefox releases
> file descriptor a few seconds after compose dialog is closed. It seems
> even closing the tab is not necessary. It was a file on an internal
> drive, but I do not think it matters.
>
> > 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
> [...]
>
>  From my point of view it is in contradiction with the original complain:
>
> > 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.
>
> Isn't /media/appe/KINGSTON/noname/file4.gpg the file you attached? What
> are other 127 files?

For my initial bug report, I just quickly did a "wc -l" on a long initial
printout, so I was mistaken to claim those were distinct files, I don't
know if they were.  But now I think it is strange that the same file should
be open so many times, it is wasteful at least and could lead to a cause
for the clinging.  In the dicussion in debian-user I think I said, that the
clinging once lasted for about a minute, after which the unmounting
completed. This probably led me to suspect that other files besides a less
than 4 kB file (an earlier "file3.gpg") could have been accessed.

If the problem is real, I think it should be easy to reproduce.  Maybe it
has to do with semi-legitimate virus scanning, or semi-legitimate concerns
some might have about encrypted messages, and my data security personally
is not at risk.  If the file was on an internal drive, you would be
unlikely to unmount it anyway.

I continue to worry about my USB stick security.  I have received advice,
and have plans to improve my data security (including switching to the
Chromium browser), but I still suspect that something is not right here.

Thanks.

Bug#1067908: Acknowledgement (Enable I6300ESB_WDT)

[Andreas Steinel]

addiition for reference:

bookworm:

$ grep -i CONFIG_IE6XX_WDT /boot/config*
/boot/config-6.1.0-19-amd64:CONFIG_IE6XX_WDT=m
/boot/config-6.1.0-19-cloud-amd64:# CONFIG_IE6XX_WDT is not set

bullseye:

$ grep -i CONFIG_IE6XX_WDT /boot/config*
/boot/config-5.10.0-28-amd64:CONFIG_IE6XX_WDT=m
/boot/config-5.10.0-28-cloud-amd64:# CONFIG_IE6XX_WDT is not set

-- 
With kind regards

Andreas Steinel
M.Sc. Visual Computing
M.Sc. Informatik

Bug#1067908: Acknowledgement (Enable I6300ESB_WDT)

[Andreas Steinel]

Hi all,

TLDR: all QEMU/KVM based virtualization will profit from this.

Andrew, you beat me to it. I also need the watchdog module in the cloud kernel,
which is the only watchdog module AFAIK that KVM/QEMU supports that is not
ISA-based and therefore useable on every KVM/QEMU virtualization platform.

I seems weird to me that the module is enabled on the regular kernel, yet not
on the cloud kernel, which will be at least as useful there, as it is
in the regular
kernel. It is currently a show stopper for our kvm farm to use the cloud kernel.

I just looked today into building the module my myself via the help of DKMS
to be able to use the watchdog on cloud-kernels in Bullseye and Bookworm,
yet the best would be to just compile it upstream

So please add it to the cloud kernel image, starting in oldstable / bullseye.

-- 
With kind regards

Andreas Steinel
M.Sc. Visual Computing
M.Sc. Informatik

Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t

[Aurelien Jarno]

Hi,

On 2024-04-09 07:56, Helmut Grohne wrote:
> Hi Aurelien,
> 
> On Mon, Apr 08, 2024 at 11:24:40PM +0200, Aurelien Jarno wrote:
> > Thanks for you analysis and your patch. In short your proposal is to
> > extend the initial patch from Steve to fully hide the fact that the
> > compiler default to -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64.
> > 
> > This indeed works and fixes the FTBFS. However it seems that, at least
> > for some of the issues, it just hides them. For instance the wrong type
> > for timeval.tv_usec, reported by Simon upstream [1], was detected by the
> > conformance tests. Quoting utmpx.h/conform.out:
> 
> I think this needs a more nuanced look. From the comments in the
> conformance test suite, it is evident that it expects to be run without
> _FILE_OFFSET_BITS and _TIME_BITS. Many of the symbols it requires to
> exist only exist when these macros are unset. The conformance test suite
> has a comment saying that it should be testing the case where
> _FILE_OFFSET_BITS is defined, but it currently does not provide
> expectations for that case.
> 
> Before we can reasonably run the conformance test suite with these
> macros set (and really, the test suite should be in control of these
> macros), we cannot reasonably use it with them set. Let us now imagine a
> future where the conformance test suite has been extended to provide
> expectations (which in lots of cases means that *64 symbols disappear
> when -D_FILE_OFFSET_BITS=64). Then what still remains is Simon's issue:
> 
> > | /tmp/tmp98wzaavx/test.c:4:35: error: conflicting types for ‘b2_10’; have 
> > ‘__suseconds64_t’ {aka ‘long long int’}
> > | 4 | extern __typeof__ (a2_10.tv_usec) b2_10;
> > |   |   ^
> > | /tmp/tmp98wzaavx/test.c:3:20: note: previous declaration of ‘b2_10’ with 
> > type ‘suseconds_t’ {aka ‘long int’}
> > | 3 | extern suseconds_t b2_10;
> > |   |^
> > | FAIL: Type of member tv_usec
> 
> Indeed, this is not something that can easily be fixed and where
> upstream is still debating on what the correct solution should be. It
> also is an issue that existed for a long time. If you head over to a
> bookworm glibc and enable -D_TIME_BITS=64 there, you'll also notice that
> tv_usec and suseconds_t have different sizes. So yes, this is a bug, but
> it is not one that is directly related to Debian changing the default.
> We merely increased the visibility of this problem that existed earlier
> already.

I agree that this is an existing issue. My point there was mostly that
your solution is just hiding a real issue that is found by the
testsuite, and basically the testsuite runs in a different configuration
than the one used on the system. We might just miss new issues for new
upstream versions, which is not something very comfortable for a base
library.

> Given that
>  * the issue is already present in bookworm,
>  * there are two mutually exclusive solutions and
>  * upstream is still discussing the best solution
> I recommend deferring this aspect.

While the issue is already present in bookworm, it is not visible
because the toolchain has different defaults.

> > And we know it is the reason for the FTBFS of libflorist [2], so should
> > we just ignore that issue anyway?
> 
> The libflorist issue likely is a consequence. It arises from
> gnat_to_gnu_field where GNAT verifies that the value (of type
> suseconds_t) to be assigned to a field (tv_usec) has the matching size.
> This is directly based on the POSIX expectation and will be fixed with
> the glibc issue.
> 
> How about filing a separate bug with glibc that tracks this POSIX
> divergence and mark the libflorist bug as being blocked by this other
> glibc bug? It can be RC or not, but since it affects bookworm, it won't
> block testing migration.

Yes we can do that. That said I am not sure we can claim the issue
affects bookworm, as again the toolchain does not have the same defaults
and therefore libflorist does not FTBFS in bookworm.

Regards
Aurelien

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


signature.asc
Description: PGP signature

Bug#1068377: python-oslo.messaging: please make the build reproducible

[Chris Lamb]

Thomas Goirand wrote:

> However, a better patch would be to use the sample_default= directive of 
> oslo.config, which is printing in the generated doc, whatever the value 
> of sample_default, while continuing to keep the default= value that can 
> contain something programmatic. This avoids writing the "if blah is 
> None" as you've put it.

Ah — now I remember this was introduced a while back for precisely
this reason. Many thanks. :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t

[Helmut Grohne]

Hi Aurelien,

On Mon, Apr 08, 2024 at 11:24:40PM +0200, Aurelien Jarno wrote:
> Thanks for you analysis and your patch. In short your proposal is to
> extend the initial patch from Steve to fully hide the fact that the
> compiler default to -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64.
> 
> This indeed works and fixes the FTBFS. However it seems that, at least
> for some of the issues, it just hides them. For instance the wrong type
> for timeval.tv_usec, reported by Simon upstream [1], was detected by the
> conformance tests. Quoting utmpx.h/conform.out:

I think this needs a more nuanced look. From the comments in the
conformance test suite, it is evident that it expects to be run without
_FILE_OFFSET_BITS and _TIME_BITS. Many of the symbols it requires to
exist only exist when these macros are unset. The conformance test suite
has a comment saying that it should be testing the case where
_FILE_OFFSET_BITS is defined, but it currently does not provide
expectations for that case.

Before we can reasonably run the conformance test suite with these
macros set (and really, the test suite should be in control of these
macros), we cannot reasonably use it with them set. Let us now imagine a
future where the conformance test suite has been extended to provide
expectations (which in lots of cases means that *64 symbols disappear
when -D_FILE_OFFSET_BITS=64). Then what still remains is Simon's issue:

> | /tmp/tmp98wzaavx/test.c:4:35: error: conflicting types for ‘b2_10’; have 
> ‘__suseconds64_t’ {aka ‘long long int’}
> | 4 | extern __typeof__ (a2_10.tv_usec) b2_10;
> |   |   ^
> | /tmp/tmp98wzaavx/test.c:3:20: note: previous declaration of ‘b2_10’ with 
> type ‘suseconds_t’ {aka ‘long int’}
> | 3 | extern suseconds_t b2_10;
> |   |^
> | FAIL: Type of member tv_usec

Indeed, this is not something that can easily be fixed and where
upstream is still debating on what the correct solution should be. It
also is an issue that existed for a long time. If you head over to a
bookworm glibc and enable -D_TIME_BITS=64 there, you'll also notice that
tv_usec and suseconds_t have different sizes. So yes, this is a bug, but
it is not one that is directly related to Debian changing the default.
We merely increased the visibility of this problem that existed earlier
already.

Given that
 * the issue is already present in bookworm,
 * there are two mutually exclusive solutions and
 * upstream is still discussing the best solution
I recommend deferring this aspect.

> And we know it is the reason for the FTBFS of libflorist [2], so should
> we just ignore that issue anyway?

The libflorist issue likely is a consequence. It arises from
gnat_to_gnu_field where GNAT verifies that the value (of type
suseconds_t) to be assigned to a field (tv_usec) has the matching size.
This is directly based on the POSIX expectation and will be fixed with
the glibc issue.

How about filing a separate bug with glibc that tracks this POSIX
divergence and mark the libflorist bug as being blocked by this other
glibc bug? It can be RC or not, but since it affects bookworm, it won't
block testing migration.

Helmut