Bug#1081856: agg: FTBFS: agg_font_freetype.cpp:182:35: error: invalid conversion
Control: tags -1 patch Hi, attached patch will solve FTBFS. I hope it will help you. Regards, Description: Fix FTBFS #1081856 invalid conversion pointer Fix FTBFS #1081856 invalid conversion pointer, this error was raised from agg_font_freetype.cpp because of type mismatch with 'unsigned char*' and 'char*'. Author: HAYASHI Kentaro Origin: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081856 Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081856 Forwarded: no Last-Update: 2024-10-05 Index: agg-2.6.1-r134+dfsg1/font_freetype/agg_font_freetype.cpp === --- agg-2.6.1-r134+dfsg1.orig/font_freetype/agg_font_freetype.cpp +++ agg-2.6.1-r134+dfsg1/font_freetype/agg_font_freetype.cpp @@ -158,7 +158,7 @@ namespace agg FT_Vector* point; FT_Vector* limit; -char* tags; +unsigned char* tags; int n; // index of contour in outline int first; // index of first point in contour
Bug#1078779: ansible-core: Ansible not updating mtime on changed files, keeping old mtime!!!
Recently, I've also hit this bug. This bug was already fixed in upstream but not released yet. I hope patch was applied in Debian because it breaks idempotence. FYI: copy module: modify time on the file (mtime) is not updating https://github.com/ansible/ansible/issues/83013 Regards,
Bug#1079183: linux-image-amd64: Bluetooth is disabled
Hi, I've stepped on this bug on 6.10.6-1 and it seems that this bug was fixed by 6.10.7-1. I guess the following change affects us, but I'm not sure yet. https://tracker.debian.org/news/1561446/accepted-linux-signed-amd64-61071-source-into-unstable/ > - Bluetooth: HCI: Invert LE State quirk to be opt-out rather then > opt-in I hope that it will help. Regards,
Bug#1053061: mecab: FTBFS with default Java 21
FYI: It seems that this FTBFS issue was already fixed in master, but not released yet. https://salsa.debian.org/nlp-ja-team/mecab/-/commit/0c8c0d1b3730758ef0ea98927e25c12596e39cf9 Regards,
Bug#1078280: docker.io: FTBFS: src/github.com/docker/docker/api/server/router/grpc/grpc.go:23:49: undefined: grpc_middleware.ChainUnaryServer
On Fri, 9 Aug 2024 14:16:05 +0200 Santiago Vila wrote: > Package: src:docker.io > Version: 26.1.4+dfsg1-9 > Severity: serious > Tags: ftbfs > > Dear maintainer: > > During a rebuild of all packages in unstable, your package failed to > build: FYI: It seems that go install fails like this: go install -trimpath -v -p 6 -tags "apparmor seccomp journald" -buildmode=pie -ldflags "-w -X github.com/docker/docker/dockerversion.Version=26.1.4+dfsg1 -X github.com/docker/docker/dockerversion.GitCommit=de5c9cf -X github.com/docker/docker/dockerversion.BuildTime=2024-07-26T08:28:37.0+00:00 -X github.com/docker/docker/dockerversion.PlatformName= -X github.com/docker/docker/dockerversion.ProductName=docker -X github.com/docker/docker/dockerversion.DefaultProductLicense=" github.com/docker/docker/cmd/dockerd returned go: 'go install' requires a version when current directory is not in a module Try 'go install github.com/docker/docker/cmd/dockerd@latest returned@latest' to install the latest version
Bug#1077974: ITP: gr-framework -- Universal framework for cross-platform visualization applications
There was feedback about gr- namespace. It seems that gr- namespace is already used for GNU Radio. https://lists.debian.org/debian-devel/2024/08/msg00084.html It might better to improve short description.
Bug#1077974: ITP: gr-framework -- Universal framework for cross-platform visualization applications
Package: wnpp Severity: wishlist Owner: Kentaro Hayashi X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: gr-framework Version : 0.73.7 Upstream Contact: Josef Heinen * URL : https://github.com/sciapp/gr * License : MIT Programming Lang: C++ Description : Universal framework for cross-platform visualization applications GR is a universal framework for cross-platform visualization applications. It offers developers a compact, portable and consistent graphics library for their programs. Applications range from publication quality 2D graphs to the representation of complex 3D scenes. My collegue keen to use packaged version of gr-framework in Debian.
Bug#1040005: ITP:magpie - window manager for the budgie desktop
Hi, It seems that it becomes serious because mutter 46 was landed onto unstable. we can't fresh install bugdie-desktop anymore... Any progress?
Bug#1075044: groonga: ftbfs with GCC-14
This FTBFS was caused by rapidjson [1] and fixed-in-upstream. [2] It seems that upstream will not ship new one, so need to wait patched version of rapidjson. [1] rapidjson: FTBFS with GCC-14 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075575 [2] https://github.com/Tencent/rapidjson/pull/719/files
Bug#1073192: liblz4-dev: Request to install lz4Config.cmake
Hi, FYI: I've created MR to send this feedback. https://salsa.debian.org/debian/lz4/-/merge_requests/8 Regards,
Bug#1073192: liblz4-dev: Request to install lz4Config.cmake
Hi, On Mon, 17 Jun 2024 22:12:24 +0900 Kentaro HAYASHI wrote: > Control: tags -1 patch > > Hi, I've tried a PoC patch to build lz4 with CMake. > > It is not fully achieved yet because > it causes a diff for .symbols, that is not intended. > > In other words, it must tweak build flags further more. > I've revised the previous patch [1] to fix missing/redundant symbol issue. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073192#10 Now patch can be applied like this: $ apt source lz4 $ cd lz4-1.9.4 && quilt pop -a && patch -p1 < 0001-Use-CMake-to-build-lz4.patch && dpkg-buildpackage -us -uc With migrating to CMake, it seems that it can drop existing debian/patches. Regards, >From 0325fe841956d34e8f153e4da7032d26997d12d7 Mon Sep 17 00:00:00 2001 From: Kentaro Hayashi Date: Mon, 17 Jun 2024 21:58:30 +0900 Subject: [PATCH] Use CMake to build lz4 It can ship missing lz4Config.cmake for CMake. Based on kou's debian/rules. Closes: #1073192 Signed-off-by: Kentaro Hayashi --- debian/control| 7 +- debian/liblz4-dev.install | 1 + debian/patches/0001-Fix-static-link.patch | 62 --- .../patches/0002-Change-optimize-to-O2.patch | 157 -- debian/patches/series | 3 +- debian/patches/use-system-xxhash.patch| 78 + debian/rules | 16 +- 7 files changed, 95 insertions(+), 229 deletions(-) delete mode 100644 debian/patches/0001-Fix-static-link.patch delete mode 100644 debian/patches/0002-Change-optimize-to-O2.patch create mode 100644 debian/patches/use-system-xxhash.patch diff --git a/debian/control b/debian/control index 106eaea..cf828a2 100644 --- a/debian/control +++ b/debian/control @@ -1,7 +1,12 @@ Source: lz4 Priority: optional Maintainer: Nobuhiro Iwamatsu -Build-Depends: debhelper-compat (= 13), python3:any +Build-Depends: + debhelper-compat (= 13), + python3:any , + cmake (>= 2.8.12), + libxxhash-dev, + pkgconf Standards-Version: 4.6.1 Section: utils Rules-Requires-Root: no diff --git a/debian/liblz4-dev.install b/debian/liblz4-dev.install index 76f28fa..ef2e1d7 100644 --- a/debian/liblz4-dev.install +++ b/debian/liblz4-dev.install @@ -1,4 +1,5 @@ usr/include/* usr/lib/*/lib*.a usr/lib/*/lib*.so +usr/lib/*/cmake/* usr/lib/*/pkgconfig/* diff --git a/debian/patches/0001-Fix-static-link.patch b/debian/patches/0001-Fix-static-link.patch deleted file mode 100644 index 0b1146f..000 --- a/debian/patches/0001-Fix-static-link.patch +++ /dev/null @@ -1,62 +0,0 @@ -From 707fbfb32f82f253a1792347ce76bca98679c8d8 Mon Sep 17 00:00:00 2001 -From: Nobuhiro Iwamatsu -Date: Sun, 28 Aug 2022 09:06:14 +0900 -Subject: [PATCH 1/2] Fix static link - -Signed-off-by: Nobuhiro Iwamatsu - programs/Makefile | 6 +++--- - tests/Makefile| 4 +++- - 2 files changed, 6 insertions(+), 4 deletions(-) - -diff --git a/programs/Makefile b/programs/Makefile -index ace0d03..fc4d6f1 100644 a/programs/Makefile -+++ b/programs/Makefile -@@ -91,10 +91,10 @@ lz4-exe.o: lz4-exe.rc - $(WINDRES) -i lz4-exe.rc -o lz4-exe.o - - lz4: $(OBJFILES) lz4-exe.o -- $(CC) $(FLAGS) $^ -o $@$(EXT) -+ $(CC) $(FLAGS) $^ -o $@$(EXT) -L ../lib -llz4 - else - lz4: $(OBJFILES) -- $(CC) $(FLAGS) $(OBJFILES) -o $@$(EXT) $(LDLIBS) -+ $(CC) $(FLAGS) $(OBJFILES) -o $@$(EXT) $(LDLIBS) -L ../lib -llz4 - endif - - .PHONY: lz4-release -@@ -118,7 +118,7 @@ lz4c: lz4 - - lz4c32: CFLAGS += -m32 - lz4c32 : $(SRCFILES) -- $(CC) $(FLAGS) $^ -o $@$(EXT) -+ $(CC) $(FLAGS) $^ -o $@$(EXT) -L ../lib -llz4 - - lz4.1: lz4.1.md $(LIBVER_SRC) - cat $< | $(MD2ROFF) $(MD2ROFF_FLAGS) | $(SED) -n '/^\.\\\".*/!p' > $@ -diff --git a/tests/Makefile b/tests/Makefile -index 93a5581..b48070a 100644 a/tests/Makefile -+++ b/tests/Makefile -@@ -43,6 +43,8 @@ CFLAGS += $(DEBUGFLAGS) $(MOREFLAGS) - CPPFLAGS+= -I$(LZ4DIR) -I$(PRGDIR) -DXXH_NAMESPACE=LZ4_ - FLAGS= $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) - -+export LD_LIBRARY_PATH += $(LZ4DIR) -+ - include ../Makefile.inc - - LZ4 := $(PRGDIR)/lz4$(EXT) -@@ -62,7 +64,7 @@ all32: CFLAGS+=-m32 - all32: all - - lz4: -- $(MAKE) -C $(PRGDIR) $@ CFLAGS="$(CFLAGS)" -+ #$(MAKE) -C $(PRGDIR) $@ CFLAGS="$(CFLAGS)" - - lib liblz4.pc: - $(MAKE) -C $(LZ4DIR) $@ CFLAGS="$(CFLAGS)" --- -2.36.1 - diff --git a/debian/patches/0002-Change-optimize-to-O2.patch b/debian/patches/0002-Change-optimize-to-O2.patch deleted file mode 100644 index 6ac8f18..000 --- a/debian/patches/0002-Change-optimize-to-O2.patch +++ /dev/null @@ -1,157 +0,0 @@ -From 51bdc803b88dc76c79922f8fee2bb82f95934544 Mon Sep 17 00:00:00 2001 -From: Nobuhiro Iwamatsu -Date: Sun, 28 Aug 2022 09:10:38 +0900 -Subject: [PATCH 2/2] Change optimize to O2 - -Signed-off-by: Nobuhiro Iwamatsu - Makefile | 14 +++--- - contrib/dj
Bug#1070063: Remmina fails to connect with Windows systems: Protocol Security Negotiation Failure (older release works)
Hi, On Mon, 29 Apr 2024 15:41:02 +0200 Daniel Leidert wrote: > Package: remmina > Version: 1.4.35+dfsg-1+b1 > Severity: serious > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi, > > when I try to connect to a windows (11) system, I get errors saying > something like "check security protocol negotiation". When I set it > the security protocol negotiation to automatic detection, there is a > connection attempt, but the credentials are not accepted. As I > haven't changed anything in the RDP setup, I tried downgrading to > version 1.4.34, and everything works now as expected again. I'm not > quite sure if this issue is related > to https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/2062177 and/or > https://gitlab.com/Remmina/Remmina/-/issues/3090, or if this is a complete > different issue. > If the problem was caused by https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/2062177, it was fixed in 1.4.35+dfsg-2. [1] Is this issue reproducible with 1.4.35+dfsg-2? [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070078 Regards,
Bug#1073192: liblz4-dev: Request to install lz4Config.cmake
Control: tags -1 patch
Hi, I've tried a PoC patch to build lz4 with CMake.
It is not fully achieved yet because
it causes a diff for .symbols, that is not intended.
In other words, it must tweak build flags further more.
Here is the outcome of PoC patch:
$ dpkg-deb -c
liblz4-dev_1.9.4-2_amd64.deb
drwxr-xr-x root/root 0 2024-04-03 02:18 ./
drwxr-xr-x root/root 0 2024-04-03 02:18 ./usr/
drwxr-xr-x root/root 0 2024-04-03 02:18 ./usr/include/
-rw-r--r-- root/root 43263 2022-08-15 22:45 ./usr/include/lz4.h
-rw-r--r-- root/root 32749 2022-08-15 22:45 ./usr/include/lz4frame.h
-rw-r--r-- root/root 20179 2022-08-15 22:45 ./usr/include/lz4hc.h
drwxr-xr-x root/root 0 2024-04-03 02:18 ./usr/lib/
drwxr-xr-x root/root 0 2024-04-03 02:18
./usr/lib/x86_64-linux-gnu/
drwxr-xr-x root/root 0 2024-04-03 02:18
./usr/lib/x86_64-linux-gnu/cmake/
drwxr-xr-x root/root 0 2024-04-03 02:18
./usr/lib/x86_64-linux-gnu/cmake/lz4/
-rw-r--r-- root/root 1315 2024-04-03 02:18
./usr/lib/x86_64-linux-gnu/cmake/lz4/lz4Config.cmake
-rw-r--r-- root/root 2762 2024-04-03 02:18
./usr/lib/x86_64-linux-gnu/cmake/lz4/lz4ConfigVersion.cmake
-rw-r--r-- root/root 1439 2024-04-03 02:18
./usr/lib/x86_64-linux-gnu/cmake/lz4/lz4Targets-relwithdebinfo.cmake
-rw-r--r-- root/root 4737 2024-04-03 02:18
./usr/lib/x86_64-linux-gnu/cmake/lz4/lz4Targets.cmake
-rw-r--r-- root/root155774 2024-04-03 02:18
./usr/lib/x86_64-linux-gnu/liblz4.a
drwxr-xr-x root/root 0 2024-04-03 02:18
./usr/lib/x86_64-linux-gnu/pkgconfig/
-rw-r--r-- root/root 406 2024-04-03 02:18
./usr/lib/x86_64-linux-gnu/pkgconfig/liblz4.pc
drwxr-xr-x root/root 0 2024-04-03 02:18 ./usr/share/
drwxr-xr-x root/root 0 2024-04-03 02:18 ./usr/share/doc/
drwxr-xr-x root/root 0 2024-04-03 02:18
./usr/share/doc/liblz4-dev/
-rw-r--r-- root/root 857 2024-04-03 02:18
./usr/share/doc/liblz4-dev/changelog.Debian.gz
-rw-r--r-- root/root 3275 2024-04-03 02:18
./usr/share/doc/liblz4-dev/copyright
lrwxrwxrwx root/root 0 2024-04-03 02:18
./usr/lib/x86_64-linux-gnu/liblz4.so -> liblz4.so.1
Anyway, I hope it will help to make it forward.
>From bbd1377d5ffcc2155909a6ce22142bc23612f5e4 Mon Sep 17 00:00:00 2001
From: Kentaro Hayashi
Date: Mon, 17 Jun 2024 21:58:30 +0900
Subject: [PATCH] Use CMake to build lz4
It can ship missing lz4Config.cmake for CMake.
Based on kou's debian/rules.
Closes: #1073192
Signed-off-by: Kentaro Hayashi
---
debian/control | 2 +-
debian/liblz4-dev.install | 1 +
debian/patches/series | 3 +-
debian/patches/use-system-xxhash.patch | 72 ++
debian/rules | 12 ++---
5 files changed, 81 insertions(+), 9 deletions(-)
create mode 100644 debian/patches/use-system-xxhash.patch
diff --git a/debian/control b/debian/control
index 106eaea..87c219d 100644
--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,7 @@
Source: lz4
Priority: optional
Maintainer: Nobuhiro Iwamatsu
-Build-Depends: debhelper-compat (= 13), python3:any
+Build-Depends: debhelper-compat (= 13), python3:any , cmake (>= 2.8.12), libxxhash-dev, pkgconf
Standards-Version: 4.6.1
Section: utils
Rules-Requires-Root: no
diff --git a/debian/liblz4-dev.install b/debian/liblz4-dev.install
index 76f28fa..ef2e1d7 100644
--- a/debian/liblz4-dev.install
+++ b/debian/liblz4-dev.install
@@ -1,4 +1,5 @@
usr/include/*
usr/lib/*/lib*.a
usr/lib/*/lib*.so
+usr/lib/*/cmake/*
usr/lib/*/pkgconfig/*
diff --git a/debian/patches/series b/debian/patches/series
index 5a400cd..d763c26 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1 @@
-0001-Fix-static-link.patch
-0002-Change-optimize-to-O2.patch
+use-system-xxhash.patch
diff --git a/debian/patches/use-system-xxhash.patch b/debian/patches/use-system-xxhash.patch
new file mode 100644
index 000..b774fbe
--- /dev/null
+++ b/debian/patches/use-system-xxhash.patch
@@ -0,0 +1,72 @@
+From: Sutou Kouhei
+Date: Mon, 17 Jun 2024 22:00:07 +0900
+Subject: Use xxHash in system library
+
+
+Signed-off-by: Kentaro Hayashi
+---
+ build/cmake/CMakeLists.txt | 14 +++---
+ 1 file changed, 11 insertions(+), 3 deletions(-)
+
+diff --git a/build/cmake/CMakeLists.txt b/build/cmake/CMakeLists.txt
+index eb7007b..37b8e03 100644
+--- a/build/cmake/CMakeLists.txt
b/build/cmake/CMakeLists.txt
+@@ -87,7 +87,8 @@ set(LZ4_SOURCES
+ "${LZ4_LIB_SOURCE_DIR}/lz4hc.h"
+ "${LZ4_LIB_SOURCE_DIR}/lz4frame.c"
+ "${LZ4_LIB_SOURCE_DIR}/lz4frame.h"
+- "${LZ4_LIB_SOURCE_DIR}/xxhash.c")
++ "${LZ4_LIB_SOURCE_DIR}/lz4file.h"
++ "${LZ4_LIB_SOURCE_DIR}/lz4file.c")
+ set(LZ4_CLI_SOURCES
+ "${LZ4_PROG_SOURCE_DIR}/bench.c"
+ "${LZ4_PROG_SOURCE_DIR}/lz4cli.c"
+@@ -99,6 +100,9 @@ set(LZ4_CLI_SOURCES
+ # used.
+ option(LZ4_POSITION_INDEP
Bug#1073192: liblz4-dev: Request to install lz4Config.cmake
Source: lz4
Version: 1.9.4-2
Severity: normal
X-Debbugs-Cc: ken...@xdump.org
Dear Maintainer,
* What led up to the situation?
Currently, liblz4-dev does not ship lz4Config.cmake which is
used to find LZ4 from CMake.
* What exactly did you do (or not do) that was effective (or
ineffective)?
It may be better to build lz4 package with CMake because
it contains build/cmake/CMakeLists.txt and it will ship
lz4Config.cmake.
build/cmake/CMakeLists.txt:
install(EXPORT lz4Targets
FILE lz4Targets.cmake
NAMESPACE LZ4::
DESTINATION ${LZ4_PKG_INSTALLDIR})
install(FILES
${CMAKE_CURRENT_BINARY_DIR}/lz4Config.cmake
${CMAKE_CURRENT_BINARY_DIR}/lz4ConfigVersion.cmake
DESTINATION ${LZ4_PKG_INSTALLDIR})
It may work with --buildsystem=cmake
--sourcedir=$(CURDIR)/build/cmake, but I'm not sure.
* What was the outcome of this action?
lz4Config.cmake is bundled for liblz4-dev.
* What outcome did you expect instead?
N/A
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.8.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8
(charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1057490: Additional information
Control: tags -1 pending > [1] > https://salsa.debian.org/bazel-team/bazel-bootstrap/-/merge_requests/2 FYI: MR!2 was already merged.
Bug#1072678: : FTBFS on armel, armhf ( error: ‘QOpenGLFunctions_3_2_Core’ does not name a type;)
Source: nextpnr Severity: serious Tags: ftbfs Control: found -1 0.7-1 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, nextpnr fails to build on armel, armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=nextpnr&arch=armel&ver=0.7-1&stamp=1714863100&raw=0 https://buildd.debian.org/status/fetch.php?pkg=nextpnr&arch=armhf&ver=0.7-1&stamp=1714849886&raw=0 Regards,
Bug#1068202: bazel-bootstrap: FTBFS: /usr/include/absl/base/policy_checks.h:79:2: error: #error "C++ versions less than C++14 are not supported."
FYI: I've created MR for it. https://salsa.debian.org/bazel-team/bazel-bootstrap/-/merge_requests/3
Bug#1068202: bazel-bootstrap: FTBFS: /usr/include/absl/base/policy_checks.h:79:2: error: #error "C++ versions less than C++14 are not supported."
Control: tags -1 patch
Hi,
> bazel-out/k8-dbg/bin/src/main/protobuf/command_server.grpc.pb.cc:6:
> /usr/include/absl/base/policy_checks.h:79:2: error: #error "C++
> versions less than C++14 are not supported." 79 | #error "C++
> versions less than C++14 are not supported." | ^
>
I've attached a patch [1] to fix FTBFS.
[1] 0001-Fix-FTBFS-with-std-c-0x-C-11.patch
I'm not sure that it should be fixed with .bzl source code under tools
directory too. (I guess that generated bazel command embeds it)
so these files was not touched.
(leave it to bazel-bootstrap maintainer judge)
grep -ir "c++0x"
tools/cpp/cc_toolchain_config.bzl:flag_groups =
[flag_group(flags = ["-std=c++0x"])],
tools/cpp/cc_toolchain_config.bzl:flag_groups =
[flag_group(flags = ["-std=c++0x"])],
tools/cpp/cc_toolchain_config.bzl:flag_groups =
[flag_group(flags = ["-std=c++0x"])],
tools/cpp/cc_toolchain_config.bzl:flag_groups =
[flag_group(flags = ["-std=c++0x"])], tools/cpp/unix_cc_configure.bzl:
"-std=c++0x", tools/cpp/bsd_cc_toolchain_config.bzl:
flag_groups = [flag_group(flags = ["-std=c++0x"])],
Regards,
>From e7f756e9e328516517e7b14ad1070c41c5688d5a Mon Sep 17 00:00:00 2001
From: Kentaro Hayashi
Date: Sun, 2 Jun 2024 23:36:37 +0900
Subject: [PATCH] Fix FTBFS with std=c++0x (C++11)
It will fix the following error:
/usr/include/absl/base/policy_checks.h:79:2: error: #error "C++
versions less than C++14 are not supported."
It seems that -std=c++0x (C++11) is explicitly given in debian/rules,
so newer absl library reject it.
ref. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068202
Signed-off-by: Kentaro Hayashi
---
debian/rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/rules b/debian/rules
index 629b9caf..5cfeba6a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -22,7 +22,7 @@ export https_proxy=127.0.0.1:9
# BAZEL_CXXOPTS and BAZEL_LINKOPTS take a list of flags seperated by colon
export space = $() $()
-export BAZEL_CXXOPTS = $(subst $(space),:,-std=c++0x ${CPPFLAGS} ${CXXFLAGS})
+export BAZEL_CXXOPTS = $(subst $(space),:,-std=c++14 ${CPPFLAGS} ${CXXFLAGS})
export BAZEL_LINKOPTS = $(subst $(space),:,-lstdc++ -lm ${LDFLAGS})
# Use the local JDK
--
2.45.1
Bug#1049806: mozc: Fails to build binary packages again after successful build
Control: tags -1 - unreproducible Control: found -1 2.28.4715.102+dfsg-2.3 I've tried with newer mozc_2.28.4715.102+dfsg-2.3 again, it was reproduced. Drop unappropriate unreproducible tag. Regargs,
Bug#1045435: mozc: Fails to build source after successful build
FYI: I've also sent patch [1] as MR for mozc. [2] [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1045435#10 [2] https://salsa.debian.org/debian/mozc/-/merge_requests/11 Regards,
Bug#1057544: barrier: FTBFS: failing test
I've just tried it with debian:sid container,
it seems that there is no test failure about 4 reported failures.
[ OK ] XWindowsKeyStateTests.setActiveGroup_poll_groupIsNotSet
(21 ms) [ RUN ]
XWindowsKeyStateTests.setActiveGroup_customGroup_groupWasSet
[2024-05-27T11:26:31] DEBUG: opening display [2024-05-27T11:26:31]
DEBUG: closing display [ OK ]
XWindowsKeyStateTests.setActiveGroup_customGroup_groupWasSet (16 ms) [
RUN ] XWindowsKeyStateTests.mapModifiersFromX_zeroState_zeroMask
...
[ OK ] XWindowsKeyStateTests.mapModifiersFromX_zeroState_zeroMask
(16 ms) [ RUN ]
XWindowsKeyStateTests.mapModifiersToX_zeroMask_resultIsTrue
[2024-05-27T11:26:31] DEBUG: opening display [2024-05-27T11:26:31]
DEBUG: closing display [ OK ]
XWindowsKeyStateTests.mapModifiersToX_zeroMask_resultIsTrue (16 ms) [
RUN ] XWindowsKeyStateTests.fakeCtrlAltDel_default_returnsFalse
...
[
OK ]
XWindowsKeyStateTests.pollActiveModifiers_defaultState_returnsZero (15
ms) [ RUN ]
XWindowsKeyStateTests.pollActiveModifiers_shiftKeyDownThenUp_masksAreCorrect
[2024-05-27T11:26:31] DEBUG: opening display [2024-05-27T11:26:31]
DEBUG2: mapping state: 1 [2024-05-27T11:26:31] DEBUG2: |= modifier: 0
[2024-05-27T11:26:31] DEBUG2: mapping state: 0 [2024-05-27T11:26:31]
DEBUG: closing display [ OK ]
XWindowsKeyStateTests.pollActiveModifiers_shiftKeyDownThenUp_masksAreCorrect
(18 ms) [ RUN ]
XWindowsKeyStateTests.pollActiveGroup_defaultState_returnsZero
...
[--] 1 test from CXWindowsScreenTests
[ RUN ]
CXWindowsScreenTests.fakeMouseMove_nonPrimary_getCursorPosValuesCorrect
[2024-05-27T11:26:31] DEBUG: XOpenDisplay(":99") [2024-05-27T11:26:31]
DEBUG2: can't read property 230 on window 0x0024
[2024-05-27T11:26:31] DEBUG: xscreensaver window: 0x
[2024-05-27T11:26:31] DEBUG2: can't read property 230 on window
0x0024 [2024-05-27T11:26:31] DEBUG: screen shape: 0,0 1280x1024
[2024-05-27T11:26:31] DEBUG: window is 0x0024
Regards,
Bug#1059706: epics-base.pc is still broken
On Sat, 4 May 2024 22:53:36 +0900 Kentaro HAYASHI wrote: > Control: tags -1 patch > > I've attached PoC patches which are > based on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059706#33 > I've created MR too. https://salsa.debian.org/science-team/epics-base/-/merge_requests/2 https://salsa.debian.org/science-team/epics-base/-/merge_requests/3
Bug#1071827: mozc: Cannot find pristine tar commit for archive 'mozc_2.28.4715.102+dfsg.orig.tar.xz'
Source: mozc Version: 2.28.4715.102+dfsg-2.2 Severity: normal X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, * What led up to the situation? When try to build package from git repository, it can't be built because of missing pristine tar commmit. * What exactly did you do (or not do) that was effective (or ineffective)? $ git clone https://salsa.debian.org/debian/mozc $ cd mozc $ LANG=C gbp buildpackage * What was the outcome of this action? $ LANG=C gbp buildpackage gbp:info: Creating /debian/mozc_2.28.4715.102+dfsg.orig.tar.xz gbp:error: Cannot find pristine tar commit for archive 'mozc_2.28.4715.102+dfsg.orig.tar.xz' * What outcome did you expect instead? pristine-tar branch is updated and no missing pristine tar commit for archive 'mozc_2.28.4715.102+dfsg.orig.tar.xz'. It also succeeds to build gbp buildpackage mozc package without error. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.8.9-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1049806: mozc: Fails to build binary packages again after successful build
Control: tags -1 unreproducible Hi, > > /usr/lib/x86_64-linux-gnu/libprotobuf.a(arena.o): relocation > > R_X86_64_TPOFF32 against symbol > > `_ZN6google8protobuf8internal15ThreadSafeArena13thread_cache_E' can > > not be used when making a shared object; recompile with -fPIC > > /usr/bin/ld: failed to set dynamic section sizes: bad value > > collect2: error: ld returned 1 exit status ninja: build stopped: I've not encounted this issue during try to fix the source after build issue. [1] So, it seems that the situation was changed since then (16 Aug 2023). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1045435 Regards,
Bug#1045435: mozc: Fails to build source after successful build
Control: tags -1 patch Hi, I've attached the patch to fix double build. * 0001-Fix-source-after-successful-build.patch Regards, On Sun, 13 Aug 2023 21:21:00 +0200 Lucas Nussbaum wrote: > Source: mozc > Version: 2.28.4715.102+dfsg-2.2 > Severity: minor > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-sab-20230813 ftbfs-source-after-build > User: debian...@lists.debian.org > Usertags: qa-doublebuild > >From 987fc8f5ffe6a9bb2f9d163b557db67b0180d655 Mon Sep 17 00:00:00 2001 From: Kentaro Hayashi Date: Sun, 19 May 2024 21:49:36 +0900 Subject: [PATCH] Fix source after successful build Closes: #1045435 Use extend-diff-ignore to ignore "binary file contents changed" error with src/unix/fcitx5/po/*.mo. Signed-off-by: Kentaro Hayashi --- debian/rules | 1 + debian/source/options | 2 ++ 2 files changed, 3 insertions(+) create mode 100644 debian/source/options diff --git a/debian/rules b/debian/rules index 24402713..b0738aed 100755 --- a/debian/rules +++ b/debian/rules @@ -80,6 +80,7 @@ override_dh_auto_clean: -rm -rf src/chrome/skk/skk_util_test.target.mk -rm -f src/unix/fcitx5/org.fcitx.Fcitx5.Addon.Mozc.metainfo.xml + -rm -rf src/out_linux* dh_auto_clean override_dh_auto_install: diff --git a/debian/source/options b/debian/source/options new file mode 100644 index ..87cfd41e --- /dev/null +++ b/debian/source/options @@ -0,0 +1,2 @@ +# ignore changes on src/unix/fcitx5/po/*.mo +extend-diff-ignore = ".+\.mo$" -- 2.43.0
Bug#1068186: mozc: FTBFS with abseil 20230802: ../../base/init_mozc.cc:90:29: error: ‘absl::debian5::flags_internal::ArgvListAction’ has not been declared
Hi,
On Fri, 17 May 2024 21:16:15 +0900 Kentaro HAYASHI
wrote:
> Control: tags -1 patch
>
> On Fri, 17 May 2024 14:06:37 +0900 Kentaro HAYASHI
>
> > This issue was already fixed in upstream.
> >
> > Non-public Abseil API is used for CLI parsing
> > https://github.com/google/mozc/issues/790
> >
> > Above ftbfs error was fixed with the following commit:
> >
> >
> > https://github.com/google/mozc/commit/cad4064c8884eb711e0e19b4b79d2ff5610823dc
>
> Attached patch will solve the reported compile error in this
> bugreport, but even though it was fixed, another abseil linkage error
> occurs.
>
> /usr/bin/ld: obj/base/base_core.file_util.o: undefined reference to
> symbol '_ZN4absl7debian5lsERSoNS0_11string_viewE'
> /usr/bin/ld:
> /lib/x86_64-linux-gnu/libabsl_string_view.so.20230802: error adding
> symbols: DSO missing from command line
>
> I'm not sure how to link it correctly in appropriate way.
I've attached additional patch
(0011-Fix-missing-abseil-gyp-link-settings.patch )
to fix rest of FTBFS issues.
To build correctly, the following patch files are required.
* 0010-Fix-the-compile-error-of-ParseCommandLineFlags-with.patch [1]
* 0011-Fix-missing-abseil-gyp-link-settings.patch
Regards,
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068186#21
From: Kentaro Hayashi
Date: Sat, 18 May 2024 17:05:16 +0900
Subject: Fix missing abseil libraries
It fixes the following error:
/usr/bin/ld: obj/base/base_core.file_util.o: undefined reference to
symbol '_ZN4absl7debian5lsERSoNS0_11string_viewE'
/usr/bin/ld:
/lib/x86_64-linux-gnu/libabsl_string_view.so.20230802: error adding
symbols: DSO missing from command line
/usr/bin/ld: obj/unix/emacs/mozc_emacs_helper_lib.client_pool.o:
undefined reference to symbol
'_ZN4absl7debian516raw_log_internal21internal_log_functionB5cxx11E'
/usr/bin/ld:
/lib/x86_64-linux-gnu/libabsl_raw_logging_internal.so.20230802: error
adding symbols: DSO missing from command line collect2: error: ld
returned 1 exit status
Signed-off-by: Kentaro Hayashi
---
src/base/absl.gyp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/base/absl.gyp b/src/base/absl.gyp
index 4bacb59..6105498 100644
--- a/src/base/absl.gyp
+++ b/src/base/absl.gyp
@@ -47,7 +47,7 @@
['use_libabseil==1', {
'link_settings': {
'libraries': [
- '-latomic -labsl_base -labsl_int128 -labsl_base -labsl_hash -labsl_city -labsl_flags_reflection -labsl_raw_hash_set -labsl_str_format_internal -labsl_throw_delegate -labsl_time_zone -labsl_hashtablez_sampler -labsl_synchronization -labsl_time -labsl_strings_internal -labsl_strings -labsl_spinlock_wait -labsl_status -labsl_statusor -labsl_flags_internal -labsl_flags_usage_internal -labsl_flags_marshalling -labsl_flags_parse',
+ '-latomic -labsl_base -labsl_int128 -labsl_base -labsl_hash -labsl_city -labsl_flags_reflection -labsl_raw_hash_set -labsl_str_format_internal -labsl_throw_delegate -labsl_time_zone -labsl_hashtablez_sampler -labsl_synchronization -labsl_time -labsl_strings_internal -labsl_strings -labsl_spinlock_wait -labsl_status -labsl_statusor -labsl_flags_internal -labsl_flags_usage_internal -labsl_flags_marshalling -labsl_flags_parse -labsl_string_view -labsl_raw_logging_internal',
],
},
},],
Bug#1068186: mozc: FTBFS with abseil 20230802: ../../base/init_mozc.cc:90:29: error: ‘absl::debian5::flags_internal::ArgvListAction’ has not been declared
Control: tags -1 patch
On Fri, 17 May 2024 14:06:37 +0900 Kentaro HAYASHI
> This issue was already fixed in upstream.
>
> Non-public Abseil API is used for CLI parsing
> https://github.com/google/mozc/issues/790
>
> Above ftbfs error was fixed with the following commit:
>
>
> https://github.com/google/mozc/commit/cad4064c8884eb711e0e19b4b79d2ff5610823dc
Attached patch will solve the reported compile error in this bugreport,
but even though it was fixed, another abseil linkage error occurs.
/usr/bin/ld: obj/base/base_core.file_util.o: undefined reference to
symbol '_ZN4absl7debian5lsERSoNS0_11string_viewE'
/usr/bin/ld:
/lib/x86_64-linux-gnu/libabsl_string_view.so.20230802: error adding
symbols: DSO missing from command line
I'm not sure how to link it correctly in appropriate way.
Regards,
From: Kentaro Hayashi
Date: Fri, 17 May 2024 18:21:29 +0900
Subject: Fix the compile error of ParseCommandLineFlags with Abseil LTS
20230802.
Origin: https://github.com/google/mozc/commit/cad4064c8884eb711e0e19b4b79d2ff5610823dc
Description: Fix the compile error of ParseCommandLineFlags with Abseil LTS 20230802.
* Added the check of the Abseil version to the arguments of ParseCommandLineImpl.
* https://github.com/google/mozc/issues/790
#codehealth
PiperOrigin-RevId: 561867167
Author: Hiroyuki Komatsu
Released in 2.29.5374.102
Signed-off-by: Kentaro Hayashi
---
src/base/init_mozc.cc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/base/init_mozc.cc b/src/base/init_mozc.cc
index eee8b62..5e5b558 100644
--- a/src/base/init_mozc.cc
+++ b/src/base/init_mozc.cc
@@ -87,7 +87,9 @@ std::string GetLogFilePathFromProgramName(const std::string &program_name) {
void ParseCommandLineFlags(int argc, char **argv) {
absl::flags_internal::ParseCommandLineImpl(
argc, argv,
+#if defined(ABSL_LTS_RELEASE_VERSION) && ABSL_LTS_RELEASE_VERSION < 20230802
absl::flags_internal::ArgvListAction::kRemoveParsedArgs,
+#endif // ABSL_LTS_RELEASE_VERSION < 20230802
// Suppress help messages invoked by --help and others.
// Use UsageFlagsAction::kHandleUsage to enable it.
absl::flags_internal::UsageFlagsAction::kIgnoreUsage,
Bug#1068186: mozc: FTBFS with abseil 20230802: ../../base/init_mozc.cc:90:29: error: ‘absl::debian5::flags_internal::ArgvListAction’ has not been declared
Control: tags -1 fixed-upstream
Hi,
On Mon, 1 Apr 2024 15:35:41 +0200
Sebastian Ramacher wrote:
> Source: mozc
> Version: 2.28.4715.102+dfsg-2.2
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in
> the past) X-Debbugs-Cc: sramac...@debian.org
>
snip
> mozc::{anonymous}::ParseCommandLineFlags(int, char**)’:
> ../../base/init_mozc.cc:90:29: error:
> ‘absl::debian5::flags_internal::ArgvListAction’ has not been declared
> 90 | absl::flags_internal::ArgvListAction::kRemoveParsedArgs, |
> ^~
>
This issue was already fixed in upstream.
Non-public Abseil API is used for CLI parsing
https://github.com/google/mozc/issues/790
Above ftbfs error was fixed with the following commit:
https://github.com/google/mozc/commit/cad4064c8884eb711e0e19b4b79d2ff5610823dc
Regards,
Bug#1071048: rust-coreutils: FTBFS on armhf,armel (`timespec` with struct literal syntax due to private fields)
Source: rust-coreutils Severity: serious Tags: ftbfs Control: found -1 0.0.26-1 Dear Maintainer, rust-coreutils fails to build on armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=rust-coreutils&arch=armel&ver=0.0.26-1&stamp=1714571498&raw=0 https://buildd.debian.org/status/fetch.php?pkg=rust-coreutils&arch=armhf&ver=0.0.26-1&stamp=1714572014&raw=0 Regards,
Bug#1071046: rust-mimalloc: FTBFS on armhf (E: Build killed with signal TERM after 150 minutes of inactivity)
Source: rust-mimalloc Severity: serious Tags: ftbfs Control: found -1 0.1.29-1+b2 Dear Maintainer, rust-mimalloc fails to build on armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=rust-mimalloc&arch=armhf&ver=0.1.29-1%2Bb2&stamp=1714283560&raw=0 Regards,
Bug#1071044: rust-libmimalloc-sys : FTBFS on armhf (signal: 11, SIGSEGV: invalid memory reference)
Source: rust-libmimalloc-sys Severity: serious Tags: ftbfs Control: found -1 0.1.25-1+b2 Dear Maintainer, rust-libmimalloc-sys fails to build on armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=rust-libmimalloc-sys&arch=armhf&ver=0.1.25-1%2Bb2&stamp=1714271391&raw=0 Regards,
Bug#1059706: epics-base.pc is still broken
Control: tags -1 patch
I've attached PoC patches which are
based on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059706#33
Before:
$ pkg-config --cflags epics-base
-I/build/reproducible-path/epics-base-7.0.8+dfsg1/include
-I/build/reproducible-path/epics-base-7.0.8+dfsg1/include/os/Linux
-I/build/reproducible-path/epics-base-7.0.8+dfsg1/include/compiler/gcc
-D_GNU_SOURCE -D_DEFAULT_SOURCE -D_X86_64_ -DUNIX -Dlinux
-ffile-prefix-map=/build/reproducible-path/epics-base-7.0.8+dfsg1=.
-D_FORTIFY_SOURCE=2
-ffile-prefix-map=/build/reproducible-path/epics-base-7.0.8+dfsg1=.
-fstack-protector-strong -fstack-clash-protection -fcf-protection
-D_FORTIFY_SOURCE=2 -mtune=generic -m64
After:
$ pkg-config --cflags epics-base
-I/usr/include/epics -I/usr/include/epics/os/Linux
-I/usr/include/epics/compiler/gcc -D_GNU_SOURCE -D_DEFAULT_SOURCE
-D_X86_64_ -DUNIX -Dlinux
-ffile-prefix-map=/debian/epics-base-7.0.8+dfsg1=. -D_FORTIFY_SOURCE=2
-ffile-prefix-map=/debian/epics-base-7.0.8+dfsg1=.
-fstack-protector-strong -fstack-clash-protection -fcf-protection
-D_FORTIFY_SOURCE=2 -mtune=generic -m64
I hope it will help.
Regards,
>From 1de16ce758d013375e0bc6386e6cc23780fc85b2 Mon Sep 17 00:00:00 2001
From: Kentaro Hayashi
Date: Sat, 4 May 2024 21:39:41 +0900
Subject: [PATCH 1/2] debian/rule: fix embedded path of installed path
Without this change, build root path will be
embedded into epics-base.pc.
See documentation/RELEASE_NOTES.md.
Signed-off-by: Kentaro Hayashi
---
debian/rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/rules b/debian/rules
index 12acc51..3f2716d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -41,7 +41,7 @@ override_dh_auto_clean: debian/control
dh_auto_clean
override_dh_auto_build:
- $(MAKE) LINKER_USE_RPATH=NO
+ $(MAKE) LINKER_USE_RPATH=NO FINAL_LOCATION=/usr
override_dh_auto_install:
$(MAKE) install
--
2.43.0
>From fedbc643094254d572d941ea25b69971463f9b95 Mon Sep 17 00:00:00 2001
From: Kentaro Hayashi
Date: Sat, 4 May 2024 21:51:55 +0900
Subject: [PATCH 2/2] Add patch to fix installed epics header path
Signed-off-by: Kentaro Hayashi
---
debian/patches/fix-epics-header-path.patch | 61 ++
debian/patches/series | 1 +
2 files changed, 62 insertions(+)
create mode 100644 debian/patches/fix-epics-header-path.patch
diff --git a/debian/patches/fix-epics-header-path.patch b/debian/patches/fix-epics-header-path.patch
new file mode 100644
index 000..c14100e
--- /dev/null
+++ b/debian/patches/fix-epics-header-path.patch
@@ -0,0 +1,61 @@
+From: Kentaro Hayashi
+Date: Sat, 4 May 2024 21:45:07 +0900
+Subject: Fix installed path of epics headers
+
+Description: epics-dev installs upstream's header under
+/usr/include/epics/ explicitly, so it should be also changed.
+Without this change, pkg-config can't return correct header search path.
+Author: Kentaro Hayashi
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059706
+Forwarded: no
+---
+ modules/database/src/tools/epics-base-arch.pc@ | 9 +
+ modules/database/src/tools/epics-base.pc@ | 7 ---
+ 2 files changed, 9 insertions(+), 7 deletions(-)
+
+diff --git a/modules/database/src/tools/epics-base-arch.pc@ b/modules/database/src/tools/epics-base-arch.pc@
+index 7dde33d..e34b5ef 100644
+--- a/modules/database/src/tools/epics-base-arch.pc@
b/modules/database/src/tools/epics-base-arch.pc@
+@@ -18,10 +18,11 @@ EPICS_BASE_IOC_LIBS=@EPICS_BASE_IOC_LIBS@
+ # Directories
+
+ includedir_osi=${prefix}/include
+-includedir_osd=${prefix}/include/os/@OS_CLASS@
+-includedir_comp=${prefix}/include/compiler/@CMPLR_CLASS@
++includedir_epicsd=${prefix}/include/epics
++includedir_osd=${prefix}/include/epics/os/@OS_CLASS@
++includedir_comp=${prefix}/include/epics/compiler/@CMPLR_CLASS@
+
+-includedirs=${includedir_osi} ${includedir_osd} ${includedir_comp}
++includedirs=${includedir_osi} ${includedir_epicsd} ${includedir_osd} ${includedir_comp}
+
+ dbddir=${prefix}/dbd
+ dbdir=${prefix}/db
+@@ -37,6 +38,6 @@ LD=@LD@
+ Name: epics-base-@ARCH@
+ Version: @EPICS_VERSION@.@EPICS_REVISION@.@EPICS_MODIFICATION@.@EPICS_PATCH_LEVEL@
+ Description: EPICS Base for @ARCH@
+-Cflags: -I${includedir_osi} -I${includedir_osd} -I${includedir_comp} @C_CFLAGS@
++Cflags: -I${includedir_osi} -I${includedir_epicsd} -I${includedir_osd} -I${includedir_comp} @C_CFLAGS@
+ Libs: -L${libdir} @LDFLAGS@
+ Libs.private: @LDLIBS@
+diff --git a/modules/database/src/tools/epics-base.pc@ b/modules/database/src/tools/epics-base.pc@
+index c154066..217748d 100644
+--- a/modules/database/src/tools/epics-base.pc@
b/modules/database/src/tools/epics-base.pc@
+@@ -15,10 +15,11 @@ CMPLR_CLASS=@CMPLR_CLASS@
+ # Directories
+
+ includedir_osi=${prefix}/include
+-includedir_osd=${prefix}/include/os/@OS_CLASS@
+-includedir_comp=${prefix}/include/compiler/@CMPLR_CLASS@
++includedir_epicsd=${prefix}/include/epics
++includedir_osd=${prefix}/inclu
Bug#1059706: epics-base.pc is still broken
Hi,
On Wed, 10 Apr 2024 16:31:03 +0300 Andrius Merkys
wrote:
> control: reopen -1
> control: found -1 7.0.8+dfsg1-1
>
> Hello,
>
> As epics-base.pc still contains incorrect paths, I am reopening this
> bug.
Maybe FINAL_LOCATION=/usr must be specified in debian/rules.
override_dh_auto_build:
$(MAKE) LINKER_USE_RPATH=NO FINAL_LOCATION=/usr
Then, embedded path in .pc should be also fixed.
* modules/database/src/tools/epics-base.pc@
* modules/database/src/tools/epics-base-arch.pc@
It's because it does not match to /usr/include/epics/os/Linux or
/usr/include/epics/compiler/Linux.
includedir_osi=${prefix}/include
includedir_osd=${prefix}/include/os/@OS_CLASS@
includedir_comp=${prefix}/include/compiler/@CMPLR_CLASS@
Regards,
Bug#1069347: rust-servo-freetype-sys: FTBFS on armel,armhf CMake Error: The source directory "/<>/freetype2" does not exist.
Source: rust-servo-freetype-sys Severity: serious Tags: ftbfs Control: found -1 4.0.5-2 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, rust-servo-freetype-sys fails to build on armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=rust-servo-freetype-sys&arch=armel&ver=4.0.5-2&stamp=1688825741&raw=0 https://buildd.debian.org/status/fetch.php?pkg=rust-servo-freetype-sys&arch=armhf&ver=4.0.5-2&stamp=1688826040&raw=0 Regards,
Bug#1069345: qwinff : FTBFS on armel,armhf
Source: qwinff Severity: important Tags: ftbfs Control: found -1 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, qwinff fails to build on armhel,armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=qwinff&arch=armel&ver=0.2.1%2Bgit20201215-2&stamp=1685891638&raw=0 https://buildd.debian.org/status/fetch.php?pkg=qwinff&arch=armhf&ver=0.2.1%2Bgit20201215-2&stamp=1675408467&raw=0 NOTE: it seems that already reported for upstream, but not fixed yet. https://github.com/qwinff/qwinff/issues/35 Regards,
Bug#1069344: netgen: FTBFS on armhf [debian/rules:66: override_dh_auto_test]
Source: netgen Severity: serious Tags: ftbfs Control: found -1 6.2.2401+dfsg1-1.1+b1 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, netgen fails to build on armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=netgen&arch=armhf&ver=6.2.2401%2Bdfsg1-1.1%2Bb1&stamp=1712667539&raw=0 Regards,
Bug#1068928: lammps : FTBFS on armhf (undefined symbol: pmix_value_load or error: subprocess-exited-with-error)
Source: lammps Severity: important Tags: ftbfs Control: found -1 20240207+dfsg-1.1 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, lammps fails to build on armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=lammps&arch=armhf&ver=20240207%2Bdfsg-1.1%2Bb1&stamp=1712551793&raw=0 Note that build error message was a bit different on armhf porterbox. (attached logs) Regards, lammps.debuild.log.xz Description: application/xz
Bug#1068925: macromoleculebuilder: FTBFS on armhf (error: inconsistent deduction for auto return type: 'long int' and then 'long long int')
Source: macromoleculebuilder Severity: important Tags: ftbfs Control: found -1 4.0.0+dfsg-3.1 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, macromoleculebuilder fails to build on armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=macromoleculebuilder&arch=armhf&ver=4.0.0%2Bdfsg-3.1&stamp=1710492689&raw=0 Currently, limited architecture succeeds to build (amd64, arm64, and loong64) Regards,
Bug#1068327: flexc++: FTBFS on armel, armhf (Segmentation fault)
Source: flexc++ Severity: serious Tags: ftbfs Control: found -1 2.15.00-1 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, flexc++ fails to build on armel, armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=flexc%2B%2B&arch=armel&ver=2.15.00-1&stamp=1712127698&raw=0 https://buildd.debian.org/status/fetch.php?pkg=flexc%2B%2B&arch=armhf&ver=2.15.00-1&stamp=1712127750&raw=0 Regards,
Bug#1068325: bisonc++: FTBFS on armel, armhf (override_dh_auto_clean Segmentation fault)
Source: bisonc++ Severity: serious Tags: ftbfs Control: found -1 6.08.00-1 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, bisonc++ fails to build on armel, armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=bisonc%2B%2B&arch=armel&ver=6.08.00-1&stamp=1712127818&raw=0 https://buildd.debian.org/status/fetch.php?pkg=bisonc%2B%2B&arch=armhf&ver=6.08.00-1&stamp=1712127698&raw=0 Regards,
Bug#1068067: fpzip: FTBFS on armel, armhf, i386 (1 - compress-decompress-validate (Failed))
Source: fpzip Severity: serious Tags: ftbfs Control: found -1 1.3.0-3 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, fpzip fails to build on armel, armhf, i386. FYI: https://buildd.debian.org/status/fetch.php?pkg=fpzip&arch=armel&ver=1.3.0-3&stamp=1685884820&raw=0 https://buildd.debian.org/status/fetch.php?pkg=fpzip&arch=armhf&ver=1.3.0-3&stamp=1650541490&raw=0 https://buildd.debian.org/status/fetch.php?pkg=fpzip&arch=i386&ver=1.3.0-3&stamp=1685885227&raw=0 Regards,
Bug#1068066: docker-registry: FTBFS on armhf (test failure with DriverSuite.TestDeleteOnlyDeletesSubpaths)
Source: docker-registry Severity: serious Tags: ftbfs Control: found -1 2.8.2+ds1-1+b4 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, docker-registry fails to build on armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=docker-registry&arch=armhf&ver=2.8.2%2Bds1-1%2Bb4&stamp=1704669577&raw=0 Regards,
Bug#1068065: quorum: FTBFS on armel, armhf,i386 (error: no matching function for call to ‘min(const long long unsigned int&, unsigned int)’)
Source: quorum Severity: serious Tags: ftbfs Control: found -1 1.1.2-2 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, quorum fails to build on armel, armhf, i386. FYI: https://buildd.debian.org/status/fetch.php?pkg=quorum&arch=armel&ver=1.1.2-2&stamp=1701603381&raw=0 https://buildd.debian.org/status/fetch.php?pkg=quorum&arch=armhf&ver=1.1.2-2&stamp=1701603270&raw=0 https://buildd.debian.org/status/fetch.php?pkg=quorum&arch=i386&ver=1.1.2-2&stamp=1701603340&raw=0 Regards,
Bug#1068063: sssd: FTBFS on armel, armhf (test failures with test_pam_xxx, test_user_xxx... for 2.9.x)
Source: sssd Severity: serious Tags: ftbfs Control: found -1 2.9.4-1.1 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, sssd fails to build on armel, armhf. Though test suite failure was already reported, but target version is 1.11.5.1-1, not 2.x branch. so I've filed as a new bug to raise attension. sssd: FTBFS on many archs due to testsuite failures https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754618 FYI: https://buildd.debian.org/status/fetch.php?pkg=sssd&arch=armel&ver=2.9.4-1.1&stamp=1711454828&raw=0 https://buildd.debian.org/status/fetch.php?pkg=sssd&arch=armhf&ver=2.9.4-1.1&stamp=1711455028&raw=0 Regards,
Bug#1068058: libgtkada: FTBFS on armhf ( compilation of gtkada-canvas_view.adb failed)
Source: libgtkada Severity: serious Tags: ftbfs Control: found -1 24.0.0-2 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, libgtkada fails to build on armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=libgtkada&arch=armhf&ver=24.0.0-2&stamp=1710988310&raw=0 Regards,
Bug#1068057: libgtkada: FTBFS on armel (error: /usr/bin/gprbuild test failed at compile time! )
Source: libgtkada Severity: serious Tags: ftbfs Control: found -1 24.0.0-2 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, libgtkada fails to build on armel. FYI: https://buildd.debian.org/status/fetch.php?pkg=libgtkada&arch=armel&ver=24.0.0-2&stamp=1711025590&raw=0 Regards,
Bug#1068055: ccls: FTBFS on armel (undefined reference to symbol '__atomic_load_8@@LIBATOMIC_1.0')
Control: notfound -1 2.6.0-1
Bug#1041803: [Debian-pan-maintainers] Bug#1041803: hyperspy: FTBFS test_image fails
Control: tags -1 ftbfs
Bug#1068056: ccls: FTBFS on armhf,i386 (test_response failures)
Source: ccls Severity: serious Tags: ftbfs Control: found -1 0.20230717-1 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, ccls fails to build on armhf, i386. FYI: https://buildd.debian.org/status/fetch.php?pkg=ccls&arch=armhf&ver=0.20230717-1&stamp=1694985920&raw=0 https://buildd.debian.org/status/fetch.php?pkg=ccls&arch=i386&ver=0.20230717-1&stamp=1694985457&raw=0 Regards,
Bug#1068055: ccls: FTBFS on armel (undefined reference to symbol '__atomic_load_8@@LIBATOMIC_1.0')
Control: found -1 Control: found -1 0.20230717-1
Bug#1068055: ccls: FTBFS on armel (undefined reference to symbol '__atomic_load_8@@LIBATOMIC_1.0')
Source: ccls Severity: serious Tags: ftbfs Control: found -1 2.6.0-1 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, ccls fails to build on armel. (missing linking against with -latomic) FYI: https://buildd.debian.org/status/fetch.php?pkg=ccls&arch=armel&ver=0.20230717-1&stamp=1694985537&raw=0 Regards,
Bug#1068054: rauc: FTBFS on armel, armhf (1 test failure)
Source: rauc Severity: serious Tags: ftbfs Control: found -1 1.11.3-1 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, rauc fails to build on armel, armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=rauc&arch=armel&ver=1.11.3-1&stamp=1710786055&raw=0 https://buildd.debian.org/status/fetch.php?pkg=rauc&arch=armhf&ver=1.11.3-1&stamp=1710785845&raw=0 Regards,
Bug#1068053: postsrsd: FTBFS on armel, armhf (bats run_postsrsd_tests.bats failure)
Source: postsrsd Severity: serious Tags: ftbfs Control: found -1 1.10-2.1 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, postsrsd fails to build on armel, armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=postsrsd&arch=armel&ver=1.10-2.1&stamp=1710920668&raw=0 https://buildd.debian.org/status/fetch.php?pkg=postsrsd&arch=armhf&ver=1.10-2.1&stamp=1710920682&raw=0 Regards,
Bug#1068052: openms: FTBFS on armel,armhf (error: ‘QOpenGLFunctions_2_0’ does not name a type)
Source: openms Severity: serious Tags: ftbfs Control: found -1 2.6.0+cleaned1-4 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, openms fails to build on armel, armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=openms&arch=armel&ver=2.6.0%2Bcleaned1-4&stamp=1703355142&raw=0 https://buildd.debian.org/status/fetch.php?pkg=openms&arch=armhf&ver=2.6.0%2Bcleaned1-4&stamp=1703351084&raw=0 Regards,
Bug#1068051: tilix: FTBFS on armhf, s390x (undefined reference to `_D4core8internal5array8equality...)
Source: tilix Severity: serious Tags: ftbfs Control: found -1 1.9.6-2 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, tilix fails to build on armhf, s390x. FYI: https://buildd.debian.org/status/fetch.php?pkg=tilix&arch=armhf&ver=1.9.6-2&stamp=1711367535&raw=0 https://buildd.debian.org/status/fetch.php?pkg=tilix&arch=s390x&ver=1.9.6-2&stamp=1711187230&raw=0 Regards,
Bug#1067959: sambamba: FTBFS on armhf (supported compiler issue)
Source: sambamba Severity: serious Tags: ftbfs Control: found -1 1.0.1+dfsg-1 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, sambamba fails to build on armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=sambamba&arch=armhf&ver=1.0.1%2Bdfsg-1&stamp=1699230688&raw=0 Regards,
Bug#1067958: ruy: FTBFS on armel, armhf
Source: ruy Severity: serious Tags: ftbfs Control: found -1 0.0.0~git20230215.21a85fe-1 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, ruy fails to build on armel, armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=ruy&arch=armel&ver=0.0.0%7Egit20230215.21a85fe-1&stamp=1688810281&raw=0 https://buildd.debian.org/status/fetch.php?pkg=ruy&arch=armhf&ver=0.0.0%7Egit20230215.21a85fe-1&stamp=1688810272&raw=0 Regards,
Bug#1067956: rocalution: FTBFS on armhf (test failure with memory allocation)
Source: rocalution Severity: serious Tags: ftbfs Control: found -1 5.7.1-2 Control: user -1 debian-...@lists.debian.org Control: usertags -1 + armhf X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, rocalution fails to build on armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=rocalution&arch=armhf&ver=5.7.1-2&stamp=1708452521&raw=0 Regards,
Bug#1067954: openmesh: FTBFS on armel,armhf
Source: openmesh Severity: serious Tags: ftbfs Control: found -1 9.0-4 Control: user -1 debian-...@lists.debian.org Control: usertags -1 + armel armhf X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, openmesh fails to build on armel, armhf. FYI https://buildd.debian.org/status/fetch.php?pkg=openmesh&arch=armel&ver=9.0-4&stamp=1685890739&raw=0 https://buildd.debian.org/status/fetch.php?pkg=openmesh&arch=armhf&ver=9.0-4&stamp=1667782816&raw=0 Regards,
Bug#1067952: mes: FTBFS on armhf
Source: mes Severity: serious Tags: ftbfs Control: found -1 0.26-1 X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, mes 0.26-1 fails to build on armhf. FYI: https://buildd.debian.org/status/fetch.php?pkg=mes&arch=armhf&ver=0.26-1&stamp=1704511792&raw=0 Regards,
Bug#1067603: contextfree: FTBFS on armhf: test failure with missing codec
Hi, On Wed, 27 Mar 2024 20:58:51 -0700 John Horigan wrote: > That error message indicates that libavcodec60 does not support the > libx264 codec for encoding H.264 files. libavcodec60 lists > libx264-164 as a dependency, with no exception for armel or armhf > systems, so I don't know why the codec won't load. > > Can you run the command > > ffmpeg -codecs > > on an armhf system and report back the output? I've attached ffmepg -codecs (when ffmpeg was manually installed, not apt build-dep) It seems when ffmpeg is not installed, it causes FTBFS. After installing ffmpeg, build succeeded on armhf. Surely, it seems that libx264 was installed. (sid_armhf-dchroot)kenhys@amdahl:~$ dpkg -l |grep -E "avcodec|x264" ii libavcodec-dev:armhf 7:6.1.1-3+b1 armhfFFmpeg library with de/encoders for audio/video codecs - development files ii libavcodec60:armhf 7:6.1.1-3+b1 armhfFFmpeg library with de/encoders for audio/video codecs - runtime files ii libx264-164:armhf 2:0.164.3108+git31e19f9-1 armhfx264 video coding library ii libx264-dev:armhf2:0.164.3108+git31e19f9-1 armhfdevelopment files for libx264 ffmpeg-codecs-on-armhf.txt.gz Description: application/gzip
Bug#1067839: triton: FTBFS on armel (undefined reference to symbol '__atomic_compare_exchange_4@@LIBATO)
Control: severity -1 serious Change severity because of ftbfs.
Bug#1067841: libopenshot-audio: FTBFS on armel (error: static assertion failed)
Source: libopenshot-audio Severity: important Tags: ftbfs X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, libopenshot-audio fails to build on armel. FYI: See https://buildd.debian.org/status/fetch.php?pkg=libopenshot-audio&arch=armel&ver=0.3.2%2Bdfsg1-2.1&stamp=1709160782&raw=0 /home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/JuceLibraryCode/modules/juce_core/threads/juce_ThreadLocalValue.h:51:5: required from here /home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/JuceLibraryCode/modules/juce_core/memory/juce_Atomic.h:58:43: error: static assertion failed : This class can only be used for lock-free types /home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/JuceLibraryCode/modules/juce_core/memory/juce_Atomic.h:58:43: note: 'std::atomic::ObjectHolder*>::is_always_lock_free' evaluates to false /home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/JuceLibraryCode/modules/juce_core/memory/juce_Atomic.h: In instantiation of 'juce::Atomic::~Atomic() [with Type = unsigned int]': /home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/JuceLibraryCode/modules/juce_core/time/juce_Time.cpp:180:27: required from here /home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/JuceLibraryCode/modules/juce_core/memory/juce_Atomic.h:58:43: error: static assertion failed : This class can only be used for lock-free types /home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/JuceLibraryCode/modules/juce_core/memory/juce_Atomic.h:58:43: note: 'std::atomic::is_always_lock_free' evaluates to false make[3]: *** [CMakeFiles/openshot-audio.dir/build.make:121: CMakeFiles/openshot-audio.dir/JuceLibraryCode/include_juce_core.cpp.o] Error 1 make[3]: Leaving directory '/home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/debian/build' make[2]: *** [CMakeFiles/Makefile2:107: CMakeFiles/openshot-audio.dir/all] Error 2 make[2]: *** Waiting for unfinished jobs /home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/JuceLibraryCode/modules/juce_dsp/processors/juce_Oversampling.h:139: warning: The following parameter of juce::dsp::Oversampling::addOversamplingStage(FilterType type, float normalisedTransitionWidthUp, float stopbandAmplitudedBUp, float normalisedTransitionWidthDown, float stopbandAmplitudedBDown) is not documented: parameter 'type' /home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/JuceLibraryCode/modules/juce_dsp/frequency/juce_Windowing.h:84: warning: The following param eter of juce::dsp::WindowingFunction::fillWindowingTables(FloatType *samples, size_t size, WindowingMethod type, bool normalise=true, FloatT ype beta=0) is not documented: parameter 'type' make[3]: Leaving directory '/home/kenhys/work/libopenshot-audio-0.3.2+dfsg1/debian/build' Regards, -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: armel (armv8l) Kernel: Linux 6.1.0-18-arm64 (SMP w/8 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect
Bug#1067839: triton: FTBFS on armel (undefined reference to symbol '__atomic_compare_exchange_4@@LIBATO)
Source: triton
Version: 2.0.0.post1-4
Severity: important
Tags: ftbfs
X-Debbugs-Cc: ken...@xdump.org
Dear Maintainer,
triton fails to build on armel.
FYI:
https://buildd.debian.org/status/fetch.php?pkg=triton&arch=armel&ver=2.0.0.post1-4&stamp=1708226979&raw=0
/usr/bin/ld:
/usr/lib/llvm-14/lib/libMLIRSupport.a(StorageUniquer.cpp.o):
undefined reference to symbol '__atomic_compare_exchange_4@@LIBATO
MIC_1.0' /usr/bin/ld: /lib/arm-linux-gnueabi/libatomic.so.1: error
adding symbols: DSO missing from command line collect2: error: ld
returned 1 exit status make[3]: ***
[bin/CMakeFiles/triton-opt.dir/build.make:329: bin/triton-opt] Error
1 make[3]: Leaving directory
'/home/kenhys/work/triton-2.0.0.post1/.pybuild/cpython3_3.11_triton/build'
make[2]: *** [CMakeFiles/Makefile2:2731:
bin/CMakeFiles/triton-opt.dir/all] Error 2 make[2]: Leaving directory
'/home/kenhys/work/triton-2.0.0.post1/.pybuild/cpython3_3.11_triton/build'
make[1]: *** [Makefile:149: all] Error 2 make[1]: Leaving directory
'/home/kenhys/work/triton-2.0.0.post1/.pybuild/cpython3_3.11_triton/build'
dh_auto_build: error: cd .pybuild/cpython3_3.11_triton/build && make
-j8 "INSTALL=install --strip-program=true" VERBOSE=1 returned exit
code 2 E: pybuild pybuild:389: build: plugin cmake failed with: exit
code=25: dh_auto_build --buildsystem=cmake
--builddirectory=/home/kenhys/work/
triton-2.0.0.post1/.pybuild/cpython3_3.11_triton/build --
dh_auto_build: error: pybuild --build -i python{version} -p "3.12
3.11" returned exit code 13 make: *** [debian/rules:5: binary] Error
25 dpkg-buildpackage: error: debian/rules binary subprocess returned
exit status 2
Regards,
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: armel (armv8l)
Kernel: Linux 6.1.0-18-arm64 (SMP w/8 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Bug#1067837: tremotesf: FTBFS on armel (dh_auto_build: error: ninja -j8 -v returned exit code 1)
Source: tremotesf
Severity: serious
Tags: ftbfs
Control: found -1 2.6.0-1
X-Debbugs-Cc: ken...@xdump.org
Dear Maintainer,
tremotesf fails to build on armel.
FYI:
https://buildd.debian.org/status/fetch.php?pkg=tremotesf&arch=armel&ver=2.6.0-1&stamp=1705039418&raw=0
[96/131] /usr/bin/c++ -DFMT_SHARED -DQT_CORE_LIB -DQT_DBUS_LIB
-DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050e00
-DQT_GUI_LIB -DQT_MESSAGELOGCONTEXT -DQT_NETWORK_LIB -DQT_NO_DEBUG
-DQT_WIDGETS_LIB -DTREMOTESF_APP_ID=\"org.equeim.Tremotesf\"
-DTREMOTESF_APP_NAME=\"T remotesf\"
-DTREMOTESF_EXECUTABLE_NAME=\"tremotesf\"
-DTREMOTESF_UNIX_FREEDESKTOP -DTREMOTESF_VERSION=\"2.6.0\"
-I/home/kenhys/work/tremotes f-2.6.0/obj-arm-linux-gnueabi/src
-I/home/kenhys/work/tremotesf-2.6.0/src
-I/home/kenhys/work/tremotesf-2.6.0/obj-arm-linux-gnueabi/src/trem
otesf_objects_autogen/include
-I/usr/include/arm-linux-gnueabi/qt5/QtConcurrent -isystem
/usr/include/arm-linux-gnueabi/qt5 -isystem /usr/in
clude/arm-linux-gnueabi/qt5/QtCore -isystem
/usr/lib/arm-linux-gnueabi/qt5/mkspecs/linux-g++ -isystem
/usr/include/arm-linux-gnueabi/qt5/QtN etwork -isystem
/usr/include/arm-linux-gnueabi/qt5/QtWidgets -isystem
/usr/include/arm-linux-gnueabi/qt5/QtGui -isystem
/usr/include/KF5/KWi dgetsAddons -isystem /usr/include/KF5 -isystem
/usr/include/arm-linux-gnueabi/qt5/QtDBus -isystem
/usr/include/KF5/KWindowSystem -g -O2 -ffi
le-prefix-map=/home/kenhys/work/tremotesf-2.6.0=.
-fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -D_LARG EFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++20 -Wall
-Wextra -Wpedantic -Wcast-align -Woverl oaded-virtual -Wconversion
-Wsign-conversion -Wdouble-promotion -Wformat=2 -Werror=format
-Werror=non-virtual-dtor -Werror=return-type -Wlog ical-op -fPIC -MD
-MT
src/CMakeFiles/tremotesf_objects.dir/ui/notificationscontroller_freedesktop.cpp.o
-MF src/CMakeFiles/tremotesf_objects
.dir/ui/notificationscontroller_freedesktop.cpp.o.d -o
src/CMakeFiles/tremotesf_objects.dir/ui/notificationscontroller_freedesktop.cpp.o
-c
/home/kenhys/work/tremotesf-2.6.0/src/ui/notificationscontroller_freedesktop.cpp
ninja: build stopped: subcommand failed. dh_auto_build: error: cd
obj-arm-linux-gnueabi && LC_ALL=C.UTF-8 ninja -j8 -v returned exit
code 1 Traceback (most recent call last): File
"/usr/bin/dh_ctest_build", line 33, in
sys.exit(load_entry_point('dh-cmake==0.6.2', 'console_scripts',
'dh_ctest_build')())
^^
File "/usr/lib/python3/dist-packages/dhcmake/ctest.py", line 229, in
build dhctest.build() File
"/usr/lib/python3/dist-packages/dhcmake/common.py", line 50, in
wrapped return func(self, *args, **kargs) ^^
File "/usr/lib/python3/dist-packages/dhcmake/ctest.py", line 174, in
build self.do_ctest_step("build", "dh_auto_build") File
"/usr/lib/python3/dist-packages/dhcmake/ctest.py", line 99, in
do_ctest_step self.do_cmd([cmd, *self.parsed_args]) File
"/usr/lib/python3/dist-packages/dhcmake/common.py", line 187, in
do_cmd subprocess.run(args, stdout=self.stdout, stderr=self.stderr,
File "/usr/lib/python3.11/subprocess.py", line 571, in run raise
CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['dh_auto_build',
'-O--buildsystem=cmake+ninja']' returned non-zero exit status 25.
make: *** [debian/rules:4: build] Error 1
Regards,
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: armel (armv8l)
Kernel: Linux 6.1.0-18-arm64 (SMP w/8 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Bug#1067603: contextfree: FTBFS on armhf: test failure with missing codec
Package: contextfree Version: 3.4+dfsg-1.1 Severity: important Tags: ftbfs X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, * What led up to the situation? contextfree can't build on armel,armhf. * What exactly did you do (or not do) that was effective (or ineffective)? apt-get source contextfree cd contextfree-3.4+dfsg debuild -us -uc * What was the outcome of this action? See https://buildd.debian.org/status/fetch.php?pkg=contextfree&arch=armhf&ver=3.4%2Bdfsg-1.1&stamp=1711207519&raw=0 input/ziggy_v2.cfdg pass Reading rules file input/mtree.cfdg Restarting as a version 3 design 8 rules loaded Generating 8bit gray-scale Quicktime movie, variation FFGH... Failed to create movie file: codec not found make[1]: *** [Makefile:188: test] Error 8 make[1]: Leaving directory '/home/kenhys/work/contextfree-3.4+dfsg' dh_auto_test: error: make -j8 test returned exit code 2 make: *** [debian/rules:6: build] Error 25 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 debuild: fatal error at line 1184: dpkg-buildpackage -us -uc -ui failed * What outcome did you expect instead? contextfree can build on armel/armhf. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: armhf (armv8l) Kernel: Linux 6.1.0-18-arm64 (SMP w/8 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages contextfree depends on: pn libagg2 ii libavcodec60 7:6.1.1-3 ii libavformat60 7:6.1.1-3 ii libavutil587:6.1.1-3 ii libc6 2.37-15.1 ii libgcc-s1 14-20240315-1 ii libicu72 72.1-4+b1 pn libpng16-16 ii libstdc++6 14-20240315-1 ii libswscale77:6.1.1-3
Bug#1066519: buildd.debian.org: giveback script doesn't allow to give-back packages in "Installed" state
Package: buildd.debian.org X-Debbugs-Cc: ken...@xdump.org Severity: normal Dear Maintainer, * What led up to the situation? giveback.cgi script doen't accept giveback action in "Installed" state. e.g. https://buildd.debian.org/auth/giveback.cgi?pkg=zeromq3&arch=armhf&suite=sid * What exactly did you do (or not do) that was effective (or ineffective)? Click giveback action in above page, it raise an error. You are authenticated as kenhys. ✓ Working on package zeromq3, suite sid and architecture armhf. ✓ Package in state Installed, cannot give back. ✗ * What was the outcome of this action? Even though "Installed" state, giveback.cgi accepts given-back action. Usually "Installed" state decline given-back is correct. But there is a useful case that such a action can be accepted. Let's think about transitional dependency such as 64bit time_t. * Package A (groonga-plugin-suggest) depends on Package B (libzmq5) * Package A is "Installed" state. * Package B depends on Package C (libnorm1, libpgm-5.0-0) * Package B is "Installed" state. In this case, both of Package A and Package B is installed state. (expected) Then libnorm1 and libpgm-5.3-0 was transitioned into libnorm1t64 and libpgm-5.3-0t64. Thus, after transition, Package A becomes "BD-Uninstallable" and it requires depended Package B must be rebuilt against transitioned Package C even though Package B is "Installed" state. * What outcome did you expect instead? N/A Regards,
Bug#1066031: Your mail
Control: retitle -1 nmu: zeromq3 It seems that it should be nmu instead of gb because currently they are "Installed" state. As buildd given-back action says: > Package in state Installed, cannot giveback. ✗ nmu zeromq3_4.3.5-1+b1 . ANY . unstable . -m "Rebuild to sync with 64bit time_t runtime dependency." Regards,
Bug#1066031: Your mail
Control: retitle -1 gb: zeromq3 Regards, On Mon, 11 Mar 2024 20:59:54 +0900 Kentaro HAYASHI wrote: > Package: release.debian.org > Control: affects -1 + src:zeromq3 > X-Debbugs-Cc: zero...@packages.debian.org > User: release.debian@packages.debian.org > Usertags: binnmu > X-Debbugs-Cc: ken...@xdump.org
Bug#1066031: (no subject)
Package: release.debian.org Control: affects -1 + src:zeromq3 X-Debbugs-Cc: zero...@packages.debian.org User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: ken...@xdump.org Severity: normal libzmq5 depends on obsolete runtime libraries. $ apt-cache depends libzmq5 libzmq5 Depends: libbsd0 Depends: libc6 Depends: libgcc-s1 Depends: libgssapi-krb5-2 Depends: libnorm1 Depends: libpgm-5.3-0 Depends: libsodium23 Depends: libstdc++6 But libnorm1 and libpgm-5.3-0 already have 64 bit time_t transitioned version, (libnorm1t64 and libpgm-5.3-0t64) so It should be rebuilt against newer runtime again. gb zeromq3_4.3.5-1+b1 . ANY . unstable . -m "Rebuild to sync with 64bit time_t runtime dependency." Thanks,
Bug#1065647: lists.debian.org: Refresh list of category in https://lists.debian.org/
Package: lists.debian.org Severity: normal X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, * What led up to the situation? Currently, list of category in https://lists.debian.org are like this: * Debconf * Users * Developers * Internationalization and Translations * Ports * Bug tracking system * Miscellaneous Debian * Linux Standard Base * Software in the Public Interest * Other It seems that some of above category may be too comprehensive, so I think that updating list of category may be better. * What exactly did you do (or not do) that was effective (or ineffective)? Checked existing category and list of what mailing-list belong to each category. * What was the outcome of this action? It seems that some of existing category should be split into new one. I suggest the following two cases. * Case 1) Users category is too comprehensive, let's split it. * Case 2) Developers category is too comprehensive, let's split it. Case 1) Users category is too comprehensive, let's split it. Split Users into "Users" and "Local Community and Users". Merit of this one is making it easy to distinct regional community. Before: * Users (English) * debian-announce * debian-backports ... * debian-user ... * debian-chinese * debian-chinese-big5 * debian-chinese-gb * debian-esperanto ... After: * Users (English) * debian-announce * debian-backports ... * debian-user ... * Local Community and Users * debian-chinese * debian-chinese-big5 * debian-chinese-gb * debian-esperanto * debian-french * debian-italian * debian-japanese * debian-user-catalan * debian-user-danish ... Case 2) Developers category is too comprehensive, let's split it. Extract some mailing-list into new "Maintenance of Programming Languages" from Developpers category. Before: * Developpers * debian-academy ... After: * Developpers * debian-academy ... * Maintenance of Programming Languages * debian-ada * debian-clojure * debian-common-lisp * debian-go * debian-haskell * debian-js * debian-ocaml-maint * debian-perl * debian-python * debian-r * debian-ruby * debian-rust * debian-scheme * What outcome did you expect instead? Miscellaneous Debian may be better to re-consider, but it is out of scope. BTW, where is the source code of lists.debian.org/? Regards,
Bug#1064956: libh3-dev: Using find_package(h3) can't be resolved
Package: libh3-dev
Severity: important
X-Debbugs-Cc: ken...@xdump.org
Dear Maintainer,
* What led up to the situation?
It seems that Using find_package(h3) can't be resolved correctly.
This bug found in the following version.
$ dpkg -l |grep libh3
ii libh3-1:amd64 4.1.0-2amd64
Hexagonal hierarchical geospatial indexing system - library ii
libh3-bin 4.1.0-2amd64
Hexagonal hierarchical geospatial indexing system - CLI programs ii
libh3-dev 4.1.0-2amd64
Hexagonal hierarchical geospatial indexing system - header files
* What exactly did you do (or not do) that was effective (or
ineffective)?
$ sudo apt install -y cmake libh3-dev libh3-bin cmake
$ mkdir -p libh3-test
$ cat < libh3-test/CMakeLists.txt
cmake_minimum_required(VERSION 3.16)
project(test)
find_package(h3 REQUIRED)
EOF
$ cmake -S libh3-test/ -B libh3-test.build
-- The CXX compiler identification is GNU 13.2.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at /usr/lib/x86_64-linux-gnu/cmake/h3/h3Targets.cmake:132
(message): The imported target "h3::h3_bin" references the file
"/usr/lib/bin/h3"
but this file does not exist. Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
"/usr/lib/x86_64-linux-gnu/cmake/h3/h3Targets.cmake"
but not all the files it references.
Call Stack (most recent call first):
/usr/lib/x86_64-linux-gnu/cmake/h3/h3Config.cmake:37 (include)
CMakeLists.txt:3 (find_package)
-- Configuring incomplete, errors occurred!
* What was the outcome of this action?
cmake should not raise error in above use case.
Actually, cmake try to resolve "/usr/lib/bin/h3", but
it should be /usr/bin/h3 or /bin/h3.
$ apt-file search bin/h3
libh3-bin: /usr/bin/h3
libh3-bin: /usr/bin/h3ToComponents
libh3-bin: /usr/bin/h3ToHier
simh: /usr/bin/h316
$ cat -n /usr/lib/x86_64-linux-gnu/cmake/h3/h3Targets-none.cmake |
head -n 15 1
#
2 # Generated CMake target import file for configuration
"None". 3
# 4
5 # Commands may need to know the format version. 6
set(CMAKE_IMPORT_FILE_VERSION 1) 7
8 # Import target "h3::h3_bin" for configuration "None"
9 set_property(TARGET h3::h3_bin APPEND PROPERTY
IMPORTED_CONFIGURATIONS NONE) 10
set_target_properties(h3::h3_bin PROPERTIES 11
IMPORTED_LOCATION_NONE "${_IMPORT_PREFIX}/bin/h3" 12)
13
14 list(APPEND _cmake_import_check_targets h3::h3_bin )
15 list(APPEND _cmake_import_check_files_for_h3::h3_bin
"${_IMPORT_PREFIX}/bin/h3" )
It seems that ${_IMPORT_PREFIX} is broken.
(It should be empty or /usr)
* What outcome did you expect instead?
Using find_package(h3) doesn't raise error.
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8
(charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1064823: libvte-2.91-gtk4-0: Please enable SIXEL support when rendering regression issue was resolved in upstream
Package: libvte-2.91-gtk4-0 Version: 0.75.91-2 Severity: normal X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, * What led up to the situation? It seems that there is sixel support, but not enabled yet. https://gitlab.gnome.org/GNOME/vte/-/commits/master?ref_type=heads In vte-0-76 branch, upstream decided to remove Sixel support from stable branch. https://gitlab.gnome.org/GNOME/vte/-/commits/vte-0-76?ref_type=heads debian/latest branch on salsa.d.o follows as same. It is reasonable to follow upstream because there is blocker issue. Regression: Sixel rendering broken since native GTK4 drawing. https://gitlab.gnome.org/GNOME/vte/-/issues/2717 For the record about status of supporting Sixel, I send a bug report. * What exactly did you do (or not do) that was effective (or ineffective)? N/A * What was the outcome of this action? Sixel support will be enabled by default with VTE package in the future release. * What outcome did you expect instead? N/A -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8 (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 libvte-2.91-gtk4-0 depends on: ii libc62.37-15 ii libcairo-gobject21.18.0-1+b1 ii libcairo21.18.0-1+b1 ii libfribidi0 1.0.13-3+b1 ii libgcc-s114-20240201-3 ii libglib2.0-0 2.78.4-1 ii libgnutls30 3.8.3-1 ii libgtk-4-1 4.12.5+ds-2 ii libicu72 72.1-4+b1 ii liblz4-1 1.9.4-1+b2 ii libpango-1.0-0 1.51.0+ds-4 ii libpangocairo-1.0-0 1.51.0+ds-4 ii libpcre2-8-0 10.42-4+b1 ii libstdc++6 14-20240201-3 ii libsystemd0 255.3-2 ii libvte-2.91-common 0.75.91-2 libvte-2.91-gtk4-0 recommends no packages. libvte-2.91-gtk4-0 suggests no packages. -- no debconf information
Bug#1062131: groonga: NMU diff for 64-bit time_t transition
NOTE:
I've found the SEGV issue with 13.1.1+dfsg-1 on armhf.
With patched abi=+time64 version 13.1.1+dfsg-1.2 in experimental, the
issue was resolved.
Before: 13.1.1+dfsg-1 on armhf
groonga db/test < load-last-modified.grn
[[0,1708379668.191548,0.02317619323730469],1]
root@debian:/home/debian/bug1062131# date --set="2038-01-19 12:14:00"
Tue Jan 19 12:14:00 UTC 2038
root@debian:/home/debian/bug1062131# date
Tue Jan 19 12:14:03 UTC 2038
root@debian:/home/debian/bug1062131# groonga db/test <
update-last-modified.grn Segmentation fault
After: 13.1.1+dfsg-1.2 on armhf
date --set="2038-01-19 12:13:50"
Tue Jan 19 12:13:50 UTC 2038
root@debian:/home/debian/bug1062131# groonga db/test <
load-last-modified.grn [[0,2147516032.44891,0.01663732528686523],1]
date
Tue Jan 19 12:14:18 UTC 2038
root@debian:/home/debian/bug1062131# groonga db/test <
update-last-modified.grn [[0,2147516064.584529,0.01893329620361328],1]
Here is the schema and data:
cat bug1062131.schema
table_create --name Logs --flags TABLE_NO_KEY
column_create --table Logs --name log --type ShortText
column_create --table Logs --name level --type UInt8
column_create --table Logs --name timestamp --type Time
root@debian:/home/debian/bug1062131# cat load-last-modified.grn
# cat load-last-modified.grn
# Time.parse("2024-01-01 00:00:00").to_i
# => 1704034800
load --table Logs
[
{"_id": 1, "level": 0, "log": "check last_modified in object header",
"timestamp": 1704034800} ]
root@debian:/home/debian/bug1062131# cat update-last-modified.grn
# Time.parse("2024-02-01 00:00:00").to_i
# => 1706713200
load --table Logs
[
{"_id": 1, "level": 1, "log": "check last_modified in object header",
"timestamp": 1706713200} ]
Bug#1056354: python3-hinawa-utils depends on cruft gir1.2-hinawa-3.0
Control: fixed -1 0.4.0-1 This bug was fixed in hinawa-utils 0.4.0-1. On Tue, 21 Nov 2023 17:09:35 +0200 Adrian Bunk wrote: > Package: python3-hinawa-utils > Version: 0.3.0-3 > Severity: serious > > src:libhinawa now builds gir1.2-hinawa-4.0 instead of > gir1.2-hinawa-3.0 > >
Bug#1062131: groonga: NMU diff for 64-bit time_t transition
Thanks, According to https://github.com/groonga/groonga/discussions/1698, it will not affected during 64bit time_t transition in practical use case. There are some points. * time_t is used but the value of it was treated as 64bit value internally. (See GRN_TIME_PACK. it use int64_t) * last_modified field which stores time in object header use uint32_t, it will not break until 2106. Time.at(4294967295) => 2106-02-07 15:28:15 +0900 It may be better to use uint64_t, but it breaks database compatibility. I'll wait upstream's decision. * Time column is int64_t, even though it stores in microseconds, It is valid until 294247. Time.at(9223372036854775807 / 10**6) => 294247-01-10 13:00:54 +0900 As a result, even though before/after rebuilding 64bit time_t transtion with groonga, database itself does not require re-creating.
Bug#1061104: xtl-dev is not installed with libxsimd-dev transparently (missing Depends:)
FYI: I've created MR. debian: require xtl-dev with runtime https://salsa.debian.org/science-team/xsimd/-/merge_requests/4 Regards,
Bug#1061104: xtl-dev is not installed with libxsimd-dev transparently (missing Depends:)
Package: libxsimd-dev
Version: 10.0.0-3
Severity: important
X-Debbugs-Cc: ken...@xdump.org
Dear Maintainer,
* What led up to the situation?
libxsimd-dev requires xtl-dev with Build-Depends: but it should be
Depends: so it does not require xtl-dev:
$ apt depends libxsimd-dev
libxsimd-dev
Breaks: libxtensor-dev (<< 0.24~)
Breaks: python3-pythran (<< 0.11~)
Suggests: libxsimd-doc
Thus, when installing via apt install -y libxsimd-dev, it does not
install xtl-dev:
$ apt install -y libxsimd-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
libxsimd-doc
The following NEW packages will be installed:
libxsimd-dev
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 101 kB of archives.
After this operation, 1161 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian sid/main amd64 libxsimd-dev amd64
10.0.0-3 [101 kB]
Fetched 101 kB in 0s (2438 kB/s)
debconf: delaying package configuration, since apt-utils is not
installed Selecting previously unselected package libxsimd-dev:amd64.
(Reading database ... 5230 files and directories currently installed.)
Preparing to unpack .../libxsimd-dev_10.0.0-3_amd64.deb ...
Unpacking libxsimd-dev:amd64 (10.0.0-3) ...
Setting up libxsimd-dev:amd64 (10.0.0-3) ...
NOTE: find_dependency(xtl) in
/usr/lib/x86_64-linux-gnu/cmake/xsimd/xsimdConfig.cmake can't find
xtl correctly if xtl-dev was not installed.
There is a same bug with libxsimd-dev (8.1.0-7 on bookworm)
* What exactly did you do (or not do) that was effective (or
ineffective)?
Specify xtl-dev in Depends: field.
diff -ur xsimd-10.0.0.orig xsimd-10.0.0
diff -ur xsimd-10.0.0.orig/debian/control xsimd-10.0.0/debian/control
--- xsimd-10.0.0.orig/debian/control2023-09-25 17:40:07.0
+0900 +++ xsimd-10.0.0/debian/control 2024-01-18 20:48:05.400870085
+0900 @@ -20,7 +20,9 @@
Architecture: any
Multi-Arch: same
Section: libdevel
-Depends: ${misc:Depends}
+Depends:
+ xtl-dev,
+ ${misc:Depends}
Suggests: libxsimd-doc
Breaks: libxtensor-dev (<< 0.24~),
python3-pythran (<< 0.11~)
* What was the outcome of this action?
xtl-dev can be installable transparently with sudo apt install -y
libxsimd-dev.
* What outcome did you expect instead?
N/A
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.11-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8 (charmap=UTF-8), LANGUAGE
not set Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1059075: lltsv: Please add loong64 binary output for Loongarch
Control: close 1059075 Duplicate report of #1059025.
Bug#1059025: lltsv: add build support for loongarch64
Control: block 1059025 by 1055087 FYI: No loong64 support for golang yet. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055087 https://buildd.debian.org/status/package.php?p=golang%2d1%2e21
Bug#1052037: fixed in fasttext 0.9.2+ds-6
Control: found -1 0.9.2+ds-6 >* debian/patches/explicitly-link-libatomic.patch > - Fix import error on armel (Closes: #1052037) It was inappropriate a bit. If LD_PRELOAD was set, it was overlooked.
Bug#1059350: debian-keyring: missing update since 2023.09.24
On Sat, 23 Dec 2023 07:23:12 + Jonathan McDowell wrote: > The debian-keyring package is a convenience package and we only make > efforts to ensure it is up to date around release time. The actual > keyring used by the Debian infrastructure is served via rsync and > matches the version that is currently available via salsa. For further > details on the workflow you might find > https://keyring.debian.org/keyring-workflow.html useful. > > J. I hadn't understood the actual workflow. It's useful information. Thanks!
Bug#1059350: debian-keyring: missing update since 2023.09.24
Package: debian-keyring X-Debbugs-Cc: ken...@xdump.org Version: 2023.09.24 Severity: normal Dear Maintainer, * What led up to the situation? debian-keyring package has not updated for a while. (last update was debian-keyring 2023.09.24) * What exactly did you do (or not do) that was effective (or ineffective)? I've checked the recent activity on salsa.d.o https://salsa.debian.org/debian-keyring/keyring/-/commits/master?ref_type=heads It seems that tagged but not released yet. * What was the outcome of this action? Even though refreshed key was sent to keyring.debian.org, it was not reflected. There is a case that contained key may be expired. If there is no release in a long term, it will cause delay of uploading package for affected DD. Could you release newer version of debian-keyring? * What outcome did you expect instead? N/A. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled debian-keyring depends on no packages. Versions of packages debian-keyring recommends: ii gnupg 2.2.40-1.1 debian-keyring suggests no packages. -- no debconf information
Bug#1058535: libhinawa: FTBFS: make: *** [debian/rules:8: binary] Error 25
On Tue, 12 Dec 2023 21:51:47 +0100
Lucas Nussbaum wrote:
> Source: libhinawa
> Version: 4.0.0-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20231212 ftbfs-trixie
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
snip
[15/15] /usr/bin/gi-docgen generate --no-namespace-dir
--config=doc/hinawa.toml --output-dir=doc/hinawa
--content-dir=/<>/doc src/Hinawa-4.0.gir
> FAILED: doc/hinawa
> /usr/bin/gi-docgen generate --no-namespace-dir
> --config=doc/hinawa.toml --output-dir=doc/hinawa
> --content-dir=/<>/doc src/Hinawa-4.0.gir WARNING:
> Section domains raised Invalid version: '2.5.' INFO: Loading config
> file: doc/hinawa.toml
It need a patch somthing like:
+diff --git a/src/hinawa_enum_types.h b/src/hinawa_enum_types.h
+index 1687046..a1c1ebf 100644
+--- a/src/hinawa_enum_types.h
b/src/hinawa_enum_types.h
+@@ -98,7 +98,7 @@ typedef enum {
+ * A set of error code for [struct@GLib.Error] for operations in
[class@FwReq].
+ * The actual value is equivalent to [enum@FwRcode].
+ *
+- * Since: 2.5.
++ * Since: 2.5
+ */
+ typedef enum {
+ HINAWA_FW_REQ_ERROR_CONFLICT_ERROR =
HINAWA_FW_RCODE_CONFLICT_ERROR,
Bug#1056585: RM: hinawa-utils/0.3.0-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm X-Debbugs-Cc: ken...@xdump.org Here is the some reasons to remove hinawa-utils from testing: * The hinawa-utils depends on libhinawa (2.x), and the newer release of libhinawa (4.x) drops obsolete features. hinawa-utils depends on the obsolete (removed) features. Thus hinawa-utils is useless without it. * The newer release of libhinawa (4.x) should be in next stable release, but because of breaking dependency, it blocks migration of libhinawa (4.x) from unstable. * The upstream author develops such a obsolete feature into separate library - libhitaki, but it is not packaged yet in debian. * hinawa-utils is under maintenance mode, so I have no idea when it supports libhitaki yet. So, I decided to remove it and it should not be part of next stable release (for now) In the future, if libhitaki was packaged in debian and hinawa-utils supports it, then salvage hinawa-utils package which supports libhitaki again. Related bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056354
Bug#1042697: Your mail
Control: fixed -1 13.0.9+dfsg-1 I've forgot to close with uploaded version. On Sat, 5 Aug 2023 15:14:10 +0900 Kentaro HAYASHI wrote: > NOTE for sphinx 7 when it is landed into sid: > > * doc/files.am should be patched to eliminate jquery.js and > underscore.js dependency or use python3-sphinxcontrib.jquery and so > on. > * debian/control > * add missing libjs-sphixdoc dependency. > * debian/groonga-doc.links should be updated. > * drop jquery and underscore > * add other searchtools language_data sphihx_highlight doctools
Bug#1054433: node-puppeteer: website is build with Docusaurus not packaged for debian
Control: severity -1 important Hi, It seems that already repacked. Surely regenerating omitted content (website and docs) may be recommended in the future, so marked as important. Regards,
Bug#1050554: budgie-desktop: after logging to budgie desktop, taskbar becomes unresponsive
Package: budgie-desktop Version: 10.8-2 Severity: important X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, * What led up to the situation? Just logging into budgie desktop and wait for minutes. * What exactly did you do (or not do) that was effective (or ineffective)? 1. Just logging into budgie desktop environment 2. Launch some applications 3. Work on something else for minutes Then taskbar becomes unresponsive suddenly. * What was the outcome of this action? After logging to budgie desktop, the following strange behavior occurs. - taskbar becomes unresponsible - shortcut key (windows key) also doesn't work, so it fails to access menu. - clicking each icon on taskbar also doesn't work, so it can't launch application at all. Just after logging in, taskbar is responsive, so if you launch terminal at that time, you can shutdown/reboot from terminal, but if not, there is no way to shutdown/reboot. journalctl reports something wrong with budgie-panel: Aug 26 17:04:19 jet budgie-panel[3805]: gtk_container_remove: assertion 'GTK_IS_WIDGET (widget)' failed Aug 26 17:04:19 jet budgie-panel[3805]: gtk_container_remove: assertion 'GTK_IS_WIDGET (widget)' failed Aug 26 17:04:19 jet budgie-panel[3805]: gtk_container_remove: assertion 'GTK_IS_WIDGET (widget)' failed Aug 26 17:04:19 jet budgie-panel[3805]: gtk_container_remove: assertion 'GTK_IS_WIDGET (widget)' failed Aug 26 17:04:19 jet budgie-panel[3805]: gtk_container_remove: assertion 'GTK_IS_WIDGET (widget)' failed Aug 26 17:04:19 jet budgie-panel[3805]: gtk_container_remove: assertion 'GTK_IS_WIDGET (widget)' failed * What outcome did you expect instead? No responsible situation will be solved. I have a concern that this behavior may not reproducible because it can't be reproduced easily on clean virtual machine (unstable). so any advice is welcome. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8 (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 budgie-desktop depends on: ii budgie-control-center1.3.0-1 ii budgie-core 10.8-2 ii dconf-cli0.40.0-4 ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii network-manager-gnome1.32.0-3 ii xdotool 1:3.20160805.1-5 Versions of packages budgie-desktop recommends: ii budgie-desktop-view 1.2.1-1 ii gir1.2-budgie-1.0 10.8-2 ii gir1.2-budgieraven-1.0 10.8-2 Versions of packages budgie-desktop suggests: ii arc-theme 20221218-1 ii gnome-bluetooth-sendto 42.6-1 ii gnome-terminal 3.48.2-1 ii nautilus44.2.1-2 ii papirus-icon-theme 20230801-1 ii slick-greeter 1.8.1-0.1 -- no debconf information
Bug#1049999: vagrant: the future of packaging vagrant in Debian
Package: vagrant Version: 2.3.4+dfsg-1 Severity: normal X-Debbugs-Cc: ken...@xdump.org Dear Maintainer, * What led up to the situation? HashiCorp adopts the BSL. https://ir.hashicorp.com/news-releases/news-release-details/hashicorp-adopts- business-source-license-future-releases-its Currently, vagrant 2.3.4+dfsg-1 was packaged in debian. * What exactly did you do (or not do) that was effective (or ineffective)? Should we keep non-BSL licenced version (A) or drop it (B)? * What was the outcome of this action? Plan A. - Update to 2.3.7 and hold it. (2.3.7 is the last non-BSL licenced version) - Follow a newer version only when BSL limitation expired (4 years). - As a result, we can't use newer feature in timely manner if you stick on packaged vagrant in Debian. Plan B. - Drop vagrant because of that changed licence and no need to keep older vagrant. - No vagrant avaiable in Debian. Just use upstream's package. * What outcome did you expect instead? N/A
Bug#967462: growl-for-linux: depends on deprecated GTK 2
Thank you for contribution. It seems that the fix is reasonable. On Mon, 24 Jul 2023 14:04:03 +0200 Bastian Germann wrote: > Control: unblock 967462 by -1 > > I am uploading a NMU to DELAYED/10 to get rid of the build dependency > libayatana-appindicator, which is not needed. The debdiff is attached > and also available in git.
Bug#1042697: (no subject)
NOTE for sphinx 7 when it is landed into sid: * doc/files.am should be patched to eliminate jquery.js and underscore.js dependency or use python3-sphinxcontrib.jquery and so on. * debian/control * add missing libjs-sphixdoc dependency. * debian/groonga-doc.links should be updated. * drop jquery and underscore * add other searchtools language_data sphihx_highlight doctools
Bug#1037256: debian-installer: GUI font for Japanese was incorrectly rendered
FYI: I've updated a PoC patch. Mainly the explanation of patch was updated.
0001-frontend-avoid-han-unification-for-Japanese-take2.patch
>From b388a793b19a0afeb9110a6dd7633b1734ffb759 Mon Sep 17 00:00:00 2001
From: Kentaro Hayashi
Date: Wed, 7 Jun 2023 17:50:40 +0900
Subject: [PATCH] frontend: avoid han-unification for Japanese
Because of Han unification, wrong font typefaces are
rendered by default when you choose Japanese language
using GUI installer.
Most of typefaces are correct, but there are wrong
typefaces (Simplified Chinese) which is used for widget rendering.
This issue [1] will not be solved by using DroidSansFallback.ttf
(which is shipped by fonts-android udeb) for Japanese.
It means that we need to switch font itself which contains Japanese
typeface to fix this issue.
Prerequisite for verifying issue:
Step1: Make fonts-motoya-l-cedar-udeb
which ships MotoyaLCedar (MTLc3m.ttf)
Step2: Install fonts-motoya-l-cedar with listing it
in installer/build/pkg-lists/gtk-common.
Step3: Apply this patch for cdebconf package
[1] Your Code Displays Japanese Wrong
https://heistak.github.io/your-code-displays-japanese-wrong/
Signed-off-by: Kentaro Hayashi
---
src/modules/frontend/gtk/di.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/src/modules/frontend/gtk/di.c b/src/modules/frontend/gtk/di.c
index a6cb38f1..4c036cd5 100644
--- a/src/modules/frontend/gtk/di.c
+++ b/src/modules/frontend/gtk/di.c
@@ -355,6 +355,30 @@ static GtkTextDirection get_text_direction(struct frontend * fe)
return direction;
}
+/** Set language specific gtk-font-name explicitly
+ *
+ * @param fe
+ */
+static void set_language_specific_font_name(struct frontend *fe)
+{
+char * language = cdebconf_gtk_get_text(fe, "debconf/language",
+"Current language for installer");
+if (language && strcmp(language, "ja") == 0) {
+/* font-android-udeb is used for CJK, but because of Han unification,
+ * some of font typefaces are rendered as Simplified Chinese, not
+ * Japanese.
+ * This issue is not solved by using DroidSansFallback.ttf
+ * (fonts-android-udeb), thus another font which contains
+ * Japanese font typeface must be used for Japanese.
+ *
+ * MotoyaLCedar is suitable font which can be bundled as
+ * fonts-motoya-l-cedar-udeb.
+ * [1] https://wiki.debian.org/DebianInstaller/GUIFonts
+ */
+gtk_rc_parse_string('gtk-font-name = "MotoyaLCedar"');
+}
+}
+
/** Update various settings with the current language settings.
*
* @param fe cdebconf frontend
@@ -365,6 +389,9 @@ static void refresh_language(struct frontend * fe)
gtk_rc_reparse_all();
/* Adapt text direction. */
gtk_widget_set_default_direction(get_text_direction(fe));
+
+/* Override specific font name */
+set_language_specific_font_name(fe);
}
/** Update what needs to be updated on a new user interaction.
--
2.40.1
Bug#1037256: debian-installer: GUI font for Japanese was incorrectly rendered
FYI: I've posted a message to ML for collecting feedback. Proposal: change Japanese font for GUI installer https://lists.debian.org/debian-boot/2023/06/msg00224.html Regards,
Bug#1037256: debian-installer: GUI font for Japanese was incorrectly rendered
On Fri, 9 Jun 2023 22:02:16 +0900 Kentaro Hayashi wrote: > Prerequisite for fix issue: > > Step1: Bundle MotoyaLCedar (MTLc3m.ttf) for fonts-android-udeb. > Step2: Apply this patch for cdebconf package As MotoyaLCedar is packaged as fonts-motoya-l-cedar already, making fonts-motoya-l-cedar-udeb and using it may be better. Regards,
Bug#1038387: bookworm-pu: package groonga/13.0.0+dfsg-2~deb12u1
Package: release.debian.org Control: affects -1 + src:groonga User: release.debian@packages.debian.org Usertags: pu Tags: bookworm X-Debbugs-Cc: ken...@xdump.org Severity: normal [ Reason ] This request is aimed to fix broken symlink issue which is originally reported [1] during bookworm hard-freeze. Because of unblock migration dead-line limitation, it was closed. Now bookwork had been released, it is better to provide as bookworm-pu. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036575 [ Impact ] The installed document will not be rendered correctly. It is against upstream developer's intention. This bug only affect the Groonga's documentaion and sample application. groonga-doc will be installed by default when groonga package is installed, so it affects for all Groonga users. [ Tests ] I've added autopkgtest (debian/tests/dependency) not to cause regression. [ Risks ] * If this issue was not fixed, bundled documentation is not rendered correctly. User must explicitly install the missing libjs-* packages. * No risks to update because groonga and relative packages are almost a leaf package, so It doesn't affect other maintainer's package at all. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] debian/control * added missing javascript dependency for groonga-bin * added missing javascript dependency for groonga-doc debian/gbp.conf * update configuration for bookworm debian/tests/dependency * added test case for blocking a regression of #1036575. [ Other info ] N/A groonga_13.0.0+dfsg-2~deb12u1.debdiff Description: Binary data
Bug#1026886: watch file for packages on github
Control: tags -1 wontfix > > Anyway, it may be a trivial exceptional case, so I'll close it.
Bug#1026886: watch file for packages on github
Hi, > It is possible to write watch files dealing with pre-releases without using > fakeupstream.cgi. Here are some variants: > ... > > The 'failure scenario' describes just one of many mistakes upstream can make, > and fakeupstream.cgi isn't meant to correct such upstream human mistakes. It > is > rather meant to make it possible to track upstream versions where it otherwise > would not be. In 'failure scenario', I admire that it maybe a rare case, the problem is that tag itself doesn't have information whether pre-release or official release. (need to contains the identifier to distingish) Thus, suggested watch rule works in most cases if upstream tagged as pre-release to v0.1.97pre or something, but it will not work as expectedlly if v0.1.97 tag is given to pre-release. (it is bad practice, though) In GitHub, pre-release requires tag, so it may happen re-creating same tag for release from a sysytem point of view. Anyway, it may be a trivial exceptional case, so I'll close it. Regards,
Bug#1033407: duplicate bugs
FYI: It seems this bug was fixed in #1032989, so this bug also have to be closed. NOTE: this fix is not landed to bookworm yet. On Sat, 25 Mar 2023 13:20:27 +0100 Dominik Stadler wrote: > merge 1033407 1032989 > > -- > These two bug-reports sound very similar, #1032989 has a lot of > investigation already.
Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian
Hi, On Thu, 2 Mar 2023 09:42:36 + Simon McVittie wrote: > Control: tags -1 + moreinfo > snip > > Is there consensus among Japanese-speaking users of Debian that mozc is > a better default for all Japanese speakers, including new users who are > not familiar with GNOME or Debian? At least, there is the fact that bullseye's default choice is ibus-mozc for Japanese users. > I want to avoid changing this from anthy to mozc-jp, and then getting a > second bug report from a different Japanese user saying that we need to > change it back! > > Looking at #984875 and #983653, I also see a mention of mozc only being > available on certain architectures: it's available on x86, ARM and riscv64, > but not on mips*el, ppc64el or s390x. > > How does this interact with the default being mozc-jp? Do we need to use > a #ifdef to make the default be mozc on architectures that have it, and > anthy on architectures that don't? Surely, it may be better to modify the patch to consider non-available mozc on certain architectures. > I'm also concerned that mozc still depends on GTK 2 (a switch to GTK > 3 was tried and then reverted, see #967641). This is OK for bookworm, > but will probably not be supportable in Debian 13. I didn't noticed that issue. Thank you. > On Wed, 22 Feb 2023 at 15:09:15 +0900, ken...@xdump.org wrote: > > Thus with attached patch, gnome-initial-setup will not > > show label for mozc-jp as "日本語 (Mozc)" by default. > > What would be the best label to be displayed there? > IMHO, 日本語 (Mozc). > What is actually displayed instead? > As I mentioned already, "mozc-jp". > > To display label correctly, fetch_ibus_engines_result must be called > > in advance. > > That's probably not possible: fetch_ibus_engines_result is called > asynchronously with the result of a D-Bus method call, so it's already > called as early as possible, and before that point we don't have the > necessary information. Currently, I agree with you. Regards,
Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian
Hi, On Wed, 01 Mar 2023 16:47:22 + James Addison wrote: > Package: libgnome-desktop-4-2 > Followup-For: Bug #1029821 > X-Debbugs-Cc: yy.y.ja...@gmail.com > > I'd like to contribute by testing d-i with Japanese input (I'm not a Japanese > speaker, but can offer some time to help). > > My plan is to: > > 1. run the graphical d-i install of a fresh GNOME 43 system > 2. select 'anthy' in 'gnome-initial-setup' > 3. attempt Japanese keyboard input Need to do extra setup. * sudo apt install -y ibus-anthy * ibus restart After restarting ibus, you can switch input source to 「日本語(Anthy)」. if you change 入力モード(_A), you can type Japanese. > > 4. run the graphical d-i install of a fresh GNOME 43 system > 5. select 'mozc-jp' in 'gnome-initial-setup' > 6. attempt Japanese keyboard input After that, if you change 入力モード(A), you can type Japanese. > Also: > > My understanding is that the _only_ difference that the patch will make is > that it will change the default in 'gnome-initial-setup'. Users could still > choose 'anthy' -- or another input method -- if they want, for some reason. > Is > that correct? Yes. users can still choose their preferrable input method. The problem is conflicting with task-japanese-gnome-desktop's recommends. Regards,
