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=armel=0.7-1=1714863100=0 https://buildd.debian.org/status/fetch.php?pkg=nextpnr=armhf=0.7-1=1714849886=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#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#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 _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=armel=0.0.26-1=1714571498=0 https://buildd.debian.org/status/fetch.php?pkg=rust-coreutils=armhf=0.0.26-1=1714572014=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=armhf=0.1.29-1%2Bb2=1714283560=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=armhf=0.1.25-1%2Bb2=1714271391=0 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=armel=4.0.5-2=1688825741=0 https://buildd.debian.org/status/fetch.php?pkg=rust-servo-freetype-sys=armhf=4.0.5-2=1688826040=0 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=armhf=6.2.2401%2Bdfsg1-1.1%2Bb1=1712667539=0 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=armel=2.15.00-1=1712127698=0 https://buildd.debian.org/status/fetch.php?pkg=flexc%2B%2B=armhf=2.15.00-1=1712127750=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=armel=6.08.00-1=1712127818=0 https://buildd.debian.org/status/fetch.php?pkg=bisonc%2B%2B=armhf=6.08.00-1=1712127698=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=armel=1.3.0-3=1685884820=0 https://buildd.debian.org/status/fetch.php?pkg=fpzip=armhf=1.3.0-3=1650541490=0 https://buildd.debian.org/status/fetch.php?pkg=fpzip=i386=1.3.0-3=1685885227=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=armhf=2.8.2%2Bds1-1%2Bb4=1704669577=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=armel=1.1.2-2=1701603381=0 https://buildd.debian.org/status/fetch.php?pkg=quorum=armhf=1.1.2-2=1701603270=0 https://buildd.debian.org/status/fetch.php?pkg=quorum=i386=1.1.2-2=1701603340=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=armel=2.9.4-1.1=1711454828=0 https://buildd.debian.org/status/fetch.php?pkg=sssd=armhf=2.9.4-1.1=1711455028=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=armhf=24.0.0-2=1710988310=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=armel=24.0.0-2=1711025590=0 Regards,
Bug#1041803: [Debian-pan-maintainers] Bug#1041803: hyperspy: FTBFS test_image fails
Control: tags -1 ftbfs
Bug#1068055: ccls: FTBFS on armel (undefined reference to symbol '__atomic_load_8@@LIBATOMIC_1.0')
Control: notfound -1 2.6.0-1
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=armhf=0.20230717-1=1694985920=0 https://buildd.debian.org/status/fetch.php?pkg=ccls=i386=0.20230717-1=1694985457=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=armel=0.20230717-1=1694985537=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=armel=1.11.3-1=1710786055=0 https://buildd.debian.org/status/fetch.php?pkg=rauc=armhf=1.11.3-1=1710785845=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=armel=1.10-2.1=1710920668=0 https://buildd.debian.org/status/fetch.php?pkg=postsrsd=armhf=1.10-2.1=1710920682=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=armel=2.6.0%2Bcleaned1-4=1703355142=0 https://buildd.debian.org/status/fetch.php?pkg=openms=armhf=2.6.0%2Bcleaned1-4=1703351084=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=armhf=1.9.6-2=1711367535=0 https://buildd.debian.org/status/fetch.php?pkg=tilix=s390x=1.9.6-2=1711187230=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=armhf=1.0.1%2Bdfsg-1=1699230688=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=armel=0.0.0%7Egit20230215.21a85fe-1=1688810281=0 https://buildd.debian.org/status/fetch.php?pkg=ruy=armhf=0.0.0%7Egit20230215.21a85fe-1=1688810272=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=armhf=5.7.1-2=1708452521=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=armel=9.0-4=1685890739=0 https://buildd.debian.org/status/fetch.php?pkg=openmesh=armhf=9.0-4=1667782816=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=armhf=0.26-1=1704511792=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#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=armel=2.6.0-1=1705039418=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#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#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#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#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#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,
Bug#1014314: lvm2: Missing 69-lvm-metad.rules causes lvm2 initramfs-tools hook to fail
FYI: similar issue was reported in the past lvm2: initramfs generation fails if neither /etc/udev/rules.d/69-lvm-metad.rules nor /lib/udev/rules.d/69-lvm-metad.rules exists https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881916
Bug#1005444: ruby-webauthn: FTBFS: ERROR: Test "ruby3.0" failed: /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `rescue in block in activate_dependencies': Could not find 'openssl' (~>
FYI: upstream try to support OpenSSL gem requirement 2.2 or later, but there is a compatibility issue. Bump OpenSSL gem requirement to 2.2 #324 https://github.com/cedarcode/webauthn-ruby/pull/324 Regards,
Bug#995354: Requires to package ruby-thread-local
At least, updating to async-http 0.56.0 or later will satisfy dependency. https://rubygems.org/gems/async-http/versions/0.56.0 async-http 0.56.0 or later requires protocol-http >= 0.22.0 < 0.23, but ruby-protocol-http 0.22.5-1 is packaged in sid. It also adds new development dependency for localhost, but ruby-localhost is already packaged in sid.
Bug#997189: liboping: FTBFS: oping.c:1159:25: error: format not a string literal and no format arguments [-Werror=format-security]
FYI: For the latter case, it seems that it has already submitted a fix as a PR.
See https://github.com/octo/liboping/pull/60/files
On Sat, 23 Oct 2021 21:06:58 +0200 Lucas Nussbaum wrote:
> > oping.c: In function ‘update_host_hook’:
> > oping.c:1640:38: error: too many arguments for format
> > [-Werror=format-extra-args]
> > 1640 | HOST_PRINTF ("%zu bytes from %s (%s):
> > icmp_seq=%u ttl=%i ",
> > |
> > ^
> > oping.c:1617:45: note: in definition of macro ‘HOST_PRINTF’
> > 1617 | # define HOST_PRINTF(...) wprintw(main_win, __VA_ARGS__)
> > | ^~~
> > libtool: compile: gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2
> > -Wall -Werror -g -O2 -ffile-prefix-map=/<>=.
> > -fstack-protector-strong -Wformat -Werror=format-security -c liboping.c -o
> > liboping_la-liboping.o >/dev/null 2>&1
> > cc1: all warnings being treated as errors
> > make[4]: *** [Makefile:598: noping-oping.o] Error 1
Bug#978916: varnish: ftbfs with autoconf 2.70
FYI: It is still reproducible on unstable with: * varnish 6.5.2-1 * autoconf 2.71-2 It seems that autoreconf generates broken configure. (without autoreconf, ./configure just works) I'm not sure but in source tree, m4/ax_pthread.m4 around AC_CACHE_CHECK([for PTHREAD_PRIO_INHERIT], causes the issue. Regards,
Bug#990371: munin-node: Unit fails on startup - Runtime directory n/a
I've sent MR to fix this issue. https://salsa.debian.org/debian/munin/-/merge_requests/5 Regards,
Bug#973188: virt-top: FTBFS: Error: Cannot find file camlheader_pic
> > File "opt_csv.ml", line 36, characters 1-13:
> > 36 |Csv.save_out chan [row];
> >
> > Alert deprecated: Csv.save_out
> > Save Csv.t to a channel
> > ocamlfind ocamlc -package unix,extlib,curses,str,libvirt -package
> > gettext-stub -package xml-light -package csv -g -warn-error CDEFLMPSUVYZX-3
> > -ccopt '-g -O2 -fdebug-prefix-map=/<>=.
> > -fstack-protector-strong -Wformat -Werror=format-security' -linkpkg
> > -runtime-variant _pic -cclib '-Wl,-z,relro' \
> > -o virt-top version.cmo opt_gettext.cmo utils.cmo types.cmo collect.cmo
> > screen.cmo redraw.cmo csv_output.cmo stream_output.cmo top.cmo opt_xml.cmo
> > opt_csv.cmo main.cmo
> > File "_none_", line 1:
> > Error: Cannot find file camlheader_pic
> > make[2]: *** [Makefile:87: virt-top] Error 2
>
> The full build log is available from:
>http://qa-logs.debian.net/2020/10/27/virt-top_1.0.9-1_unstable.log
>
> A list of current common problems and possible solutions is available at
Hi,
It seems that this is caused by missing /usr/lib/ocaml/camlheader_pic.
$ find /usr/lib -name 'camlheader*'
/usr/lib/ocaml/camlheader_ur
/usr/lib/ocaml/camlheader
/usr/lib/ocaml/camlheaderd
/usr/lib/ocaml/camlheaderi
The following patch may solve above compile error because
-runtime-variant explicitly to _pic.
$ cat virt-top-1.0.9/debian/patches/fix-missing-camlheader_pic.patch
--- a/src/Makefile.in
+++ b/src/Makefile.in
@@ -65,7 +65,7 @@
XOBJS := $(OBJS:.cmo=.cmx)
OCAMLCFLAGS:= -g -warn-error CDEFLMPSUVYZX-3 -ccopt '@CFLAGS@'
-OCAMLCLIBS := -linkpkg -runtime-variant _pic -cclib '@LDFLAGS@'
+OCAMLCLIBS := -linkpkg -cclib '@LDFLAGS@'
OCAMLOPTPACKAGES := $(OCAMLCPACKAGES)
OCAMLOPTFLAGS := $(OCAMLCFLAGS)
Additionally, it may requires the following Depends.
% diff -u virt-top-1.0.9.orig/debian/control virt-top-1.0.9/debian/control
--- virt-top-1.0.9.orig/debian/control 2021-03-21 13:43:49.915299308 +0900
+++ virt-top-1.0.9/debian/control 2021-03-21 14:18:30.499744371 +0900
@@ -20,7 +20,13 @@
Package: virt-top
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}
+Depends:
+ ocaml-base-nox | ocaml-base | ocaml-nox | ocaml,
+ libcurses-ocaml,
+ libgettext-ocaml,
+ libvirt-ocaml,
+ ${misc:Depends},
+ ${shlibs:Depends}
Description: show stats of virtualized domains
virt-top is a top-like utility for showing stats of virtualized domains. Many
keys and command line options are the same as for ordinary top.
Regards,
Bug#956782: zeal: Build-Depends (unnecessarily?) on deprecated libappindicator
I've sent MR to fix. Remove needless libappindicator-dev from Build-Depends https://salsa.debian.org/debian/zeal/-/merge_requests/1
Bug#972870: Should libhal1-flash be shipped in bullseye?
It should be removed, indeed.
Bug#962615: sylfilter: glib error prevent filter working
Hi,
On Sat, 13 Jun 2020 12:13:59 +0200 Xavier Brochard
wrote:
snip
> xfilter_bayes_db_init: opening db: /home/anne/.sylfilter/junk.db
>
> ** (process:21314): WARNING **: 12:04:05.137: Cannot open database:
> /home/anne/.sylfilter/junk.db
> Database initialization error.
I've tried to check source code sylfilter 0.8.
It seems that this error is occurerd in QDBM layer. (In QDBM, system call may
be failed)
Here is the call tree of this situation:
main(src/sylfilter.c)
=> xfilter_bayes_db_init(lib/filters/bayes-filter.c)
==> xfilter_kvs_open(lib/filter-kvs.c)
===> ke.open
> qdbm_open = dpopen (QDBM layer)
"** Sylpheed-WARNING: summary_junk_func: junk filter command returned 127"
means that error was caused at src/sylfilter.c.
dbpath = xfilter_utils_get_base_dir();
if (xfilter_bayes_db_init(dbpath) < 0) {
fprintf(stderr, "Database initialization error.\n");
xfilter_done();
return 127;
}
So, as you mentioned "the problem is with db access.", it has database error.
But the reason why it has happend was not uncertain.
Hmm...
Regards,
Bug#957032: ayatana-indicator-printers: ftbfs with GCC-10
control: tags -1 patch Hi, I've send PR to the upstream https://github.com/AyatanaIndicators/ayatana-indicator-printers/pull/1
Bug#957977: xfce4-sensors-plugin: ftbfs with GCC-10
control: tags -1 fixed-upstream Hi, It seems that it was already fixed in upstream: Here is the commit: https://gitlab.xfce.org/panel-plugins/xfce4-sensors-plugin/-/commit/108ffac9eac23a5d87f142e36d162d62be0619e2
Bug#957979: xfce4-cpufreq-plugin: ftbfs with GCC-10
Control: tags -1 fixed-upstream Hi, This issue is tracked and already fixed in upstream. https://gitlab.xfce.org/panel-plugins/xfce4-cpufreq-plugin/-/issues/6 Fixed commit is here: https://gitlab.xfce.org/panel-plugins/xfce4-cpufreq-plugin/-/commit/ec0349c06c9f7e1c147b5feb825eba010da4ffef
Bug#957247: galculator: ftbfs with GCC-10
control: tags -1 patch
Hi, I've attached a patch.
I've also send PR for upstream.
https://github.com/galculator/galculator/pull/45
>From 501a9e3feeb2e56889c0ff98ab6d0ab20348ccd6 Mon Sep 17 00:00:00 2001
From: Kentaro Hayashi
Date: Sat, 1 Aug 2020 22:25:37 +0900
Subject: [PATCH] Fix multiple definition of `prefs` compile error with GCC-10
This commit fixes the following error:
libtool: link: gcc -pthread -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 -fdebug-prefix-map=/workspace/galculator-2.1.4=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wl,-z -Wl,relro -o galculator galculator-main.o galculator-math_functions.o galculator-display.o galculator-general_functions.o galculator-calc_basic.o galculator-config_file.o galculator-callbacks.o galculator-ui.o galculator-flex_parser.o -Wl,--export-dynamic -Wl,--as-n
eeded -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lm -lquadmath -pthread
/usr/bin/ld: galculator-config_file.o:./src/config_file.c:42: multiple definition of `prefs'; galculator-main.o:./src/main.c:52: first defined here
collect2: error: ld returned 1 exit status
Signed-off-by: Kentaro Hayashi
---
src/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/main.c b/src/main.c
index 10d0868..d22fea0 100644
--- a/src/main.c
+++ b/src/main.c
@@ -49,7 +49,7 @@
#define MASK_NUMLOCK GDK_MOD2_MASK
-s_preferences prefs;
+extern s_preferences prefs;
s_current_status current_status = {0, 0, 0, 0, FALSE, FALSE, TRUE};
s_arraymemory;
s_constant *constant;
--
2.28.0
Bug#957642: openrc: ftbfs with GCC-10
control tags -1 fixed-upstream Hi, It seems that this issue was already fixed in upstream. 0.42.1 was released from upstream - which is newer than packaged in Debian (0.42-1), but this fix is not included yet. so we need a patch to fix it. Here is the link to upstream fix. https://github.com/OpenRC/openrc/commit/375ef42393f3dc6edbaa2cb70c79b2366072db38 Regards, -- Kentaro Hayashi
Bug#955066: mako: FTBFS with Sphinx 2.4: Theme error: no theme named 'zzzeeksphinx' found (missing theme.conf?)
It seems that it is unreproducible on current unstable. sphinx 2.4.x was landed into unstable and python3-zzzeeksphinx was upgraded from 1.0.20-3 to 1.1.5-1 since then. In python3-zzeekessphinx 1.1.4-1, theme.conf was added as zzzeeksphinx/themes/zsbase/theme.conf and zzzeeksphinx/themes/zsmako/theme.conf. So, this issue was solved by uploaded python3-zzeekessphinx 1.1.4-1. -- Kentaro Hayashi
Bug#953533: opensc: Fails to build due to missing bash_completion files
Control: tags 953533 patch
Bug#959624: ruby-faraday: FTBFS: ERROR: Test "ruby2.7" failed: NoMethodError: undefined method `split' for nil:NilClass
Control: fixed -1 0.17.3-1 Hi, It seems that ruby-faraday 0.15.4-3 was updated, and the new version 0.17.3-1 doesn't have FTBFS issue. Regards,
Bug#877106: pinta: Pinta 1.6-2 crashes on image scaling and other image manipulation.
Hi, It doesn't resove the issue completely, but the following commit may reduce crash frequency. Fix an NRE I randomly hit. https://github.com/PintaProject/Pinta/commit/1e6197674c1dc653a76f231eb1ace7cf69cdf984 --- a/Pinta.Core/Classes/DocumentWorkspace.cs +++ b/Pinta.Core/Classes/DocumentWorkspace.cs @@ -270,7 +270,8 @@ zoom = Math.Min (zoom, 3600); - PintaCore.Chrome.Canvas.GdkWindow.FreezeUpdates (); + if (PintaCore.Chrome.Canvas.GdkWindow != null) + PintaCore.Chrome.Canvas.GdkWindow.FreezeUpdates (); PintaCore.Actions.View.SuspendZoomUpdate (); Gtk.Viewport view = (Gtk.Viewport)PintaCore.Chrome.Canvas.Parent; @@ -336,7 +337,8 @@ RecenterView (center_x, center_y); PintaCore.Actions.View.ResumeZoomUpdate (); - PintaCore.Chrome.Canvas.GdkWindow.ThawUpdates (); + if (PintaCore.Chrome.Canvas.GdkWindow != null) + PintaCore.Chrome.Canvas.GdkWindow.ThawUpdates (); } #endregion } --- a/Pinta.Core/Classes/DocumentWorkspace.cs +++ b/Pinta.Core/Classes/DocumentWorkspace.cs @@ -270,7 +270,8 @@ zoom = Math.Min (zoom, 3600); - PintaCore.Chrome.Canvas.GdkWindow.FreezeUpdates (); + if (PintaCore.Chrome.Canvas.GdkWindow != null) +PintaCore.Chrome.Canvas.GdkWindow.FreezeUpdates (); PintaCore.Actions.View.SuspendZoomUpdate (); Gtk.Viewport view = (Gtk.Viewport)PintaCore.Chrome.Canvas.Parent; @@ -336,7 +337,8 @@ RecenterView (center_x, center_y); PintaCore.Actions.View.ResumeZoomUpdate (); - PintaCore.Chrome.Canvas.GdkWindow.ThawUpdates (); + if (PintaCore.Chrome.Canvas.GdkWindow != null) +PintaCore.Chrome.Canvas.GdkWindow.ThawUpdates (); } #endregion }
Bug#954603: cyvcf2: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p "3.7 3.8" returned exit code 13
Hi, It seems this bug was already fixed by #954640, and you should use latest humanfriendly/8.1-2. python3-humanfriendly: humanfriendly.terminal module missing from package https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954640 http://qa-logs.debian.net/2020/03/21/cyvcf2_0.11.6-1_unstable.log indicates that it uses humanfriendly/8.1-1 (old version). This package lacks humanfiriendly.terminal module. FYI: Here is the d/changelog about 8.1-2 Changes: humanfriendly (8.1-2) unstable; urgency=medium . * Team upload. . [Christian Pommranz] . * Install humanfriendly.terminal module (Closes: #954640)
Bug#954496: cwltool: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.7 3.8" returned exit code 13
> /usr/lib/python3/dist-packages/coloredlogs/__init__.py:192: in > from humanfriendly.terminal import ANSI_COLOR_CODES, ansi_wrap, > terminal_supports_colors > E ModuleNotFoundError: No module named 'humanfriendly.terminal' Hi, It seems this bug was already fixed by #954640, and you should use latest humanfriendly/8.1-2. python3-humanfriendly: humanfriendly.terminal module missing from package https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954640 http://qa-logs.debian.net/2020/03/21/cwltool_2.0.20200224214940+dfsg-1_unstable.log indicates that it uses humanfriendly/8.1-1 (old version). This package lacks humanfiriendly.terminal module. FYI: Here is the d/changelog about 8.1-2 Changes: humanfriendly (8.1-2) unstable; urgency=medium . * Team upload. . [Christian Pommranz] . * Install humanfriendly.terminal module (Closes: #954640)
Bug#938874: yum-metadata-parser: Python2 removal in sid/bullseye
On Mon, 23 Sep 2019 09:36:24 -0700 Mike Miller wrote: > Much more helpful long term would be to contribute to getting > createrepo_c (#912338) and dnf (no ITP yet) into Debian so these Python > 2 packages can be dropped. It seems that waiting #912338 task is better in long term surely. Regards,
Bug#938874: yum-metadata-parser: Python2 removal in sid/bullseye
Hi,
I'm not familiar with yum-metadata-parser at all, but
I'm not willing to remove createrepo (it depends yum-metadata-parser)
So, I've tried to fix this issue by adding python3 version.
I've added debdiff patch (may be not so good in shape), but I hope
it will help.
--
Regards,
diff -Nru yum-metadata-parser-1.1.4/debian/changelog yum-metadata-parser-1.1.4/debian/changelog
--- yum-metadata-parser-1.1.4/debian/changelog 2013-06-03 00:55:17.0 +0900
+++ yum-metadata-parser-1.1.4/debian/changelog 2019-09-22 00:34:31.0 +0900
@@ -1,3 +1,15 @@
+yum-metadata-parser (1.1.4-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches/fix-python37-setup-error.patch
+- Add patch to fix setup error with Python 3.x
+ * debian/control
+- Support python3-sqlitecachec.
+ * debian/rules
+- Build python2,python3 packages.
+
+ -- Kentaro Hayashi Sun, 22 Sep 2019 00:34:31 +0900
+
yum-metadata-parser (1.1.4-1) unstable; urgency=low
* New upstream release.
diff -Nru yum-metadata-parser-1.1.4/debian/control yum-metadata-parser-1.1.4/debian/control
--- yum-metadata-parser-1.1.4/debian/control 2013-06-03 00:55:17.0 +0900
+++ yum-metadata-parser-1.1.4/debian/control 2019-09-22 00:34:31.0 +0900
@@ -1,10 +1,17 @@
Source: yum-metadata-parser
Section: python
-Priority: extra
+Priority: optional
Maintainer: Mike Miller
-Build-Depends: debhelper (>= 9), python3-all-dev, pkg-config, libglib2.0-dev, libsqlite3-dev, libxml2-dev
+Build-Depends: debhelper (>= 9),
+ python-all-dev (>= 2.6.6-3~),
+ python3-all-dev (>= 3.7.3-1~),
+ pkg-config,
+ libglib2.0-dev,
+ libsqlite3-dev,
+ libxml2-dev
Standards-Version: 3.9.4
-X-Python-Version: >= 2.4
+X-Python-Version: >= 2.7k.16
+X-Python3-Version: >= 3.7
Homepage: http://yum.baseurl.org/
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=users/mtmiller-guest/yum-metadata-parser.git
Vcs-Git: git://anonscm.debian.org/users/mtmiller-guest/yum-metadata-parser.git
@@ -16,4 +23,13 @@
Description: Fast metadata parser for yum
Python module providing a fast metadata parser for yum implemented in C.
The sqlitecachec module is used by createrepo and the yum package manager
+ to update and query local caches of RPM package repositories.
+
+Package: python3-sqlitecachec
+Architecture: any
+Depends: ${shlibs:Depends}, ${python3:Depends}, ${misc:Depends}
+Provides: ${python3:Provides}
+Description: Fast metadata parser for yum
+ Python module providing a fast metadata parser for yum implemented in C.
+ The sqlitecachec module is used by createrepo and the yum package manager
to update and query local caches of RPM package repositories.
diff -Nru yum-metadata-parser-1.1.4/debian/patches/fix-python37-setup-error.patch yum-metadata-parser-1.1.4/debian/patches/fix-python37-setup-error.patch
--- yum-metadata-parser-1.1.4/debian/patches/fix-python37-setup-error.patch 1970-01-01 09:00:00.0 +0900
+++ yum-metadata-parser-1.1.4/debian/patches/fix-python37-setup-error.patch 2019-09-22 00:29:26.0 +0900
@@ -0,0 +1,21 @@
+--- a/setup.py
b/setup.py
+@@ -2,15 +2,15 @@
+ from distutils.core import setup, Extension
+
+ pc = os.popen("pkg-config --cflags-only-I glib-2.0 libxml-2.0 sqlite3", "r")
+-includes = map(lambda x:x[2:], string.split(pc.readline()))
++includes = list(map(lambda x:x[2:], pc.readline().split()))
+ pc.close()
+
+ pc = os.popen("pkg-config --libs-only-l glib-2.0 libxml-2.0 sqlite3", "r")
+-libs = map(lambda x:x[2:], string.split(pc.readline()))
++libs = list(map(lambda x:x[2:], pc.readline().split()))
+ pc.close()
+
+ pc = os.popen("pkg-config --libs-only-L glib-2.0 libxml-2.0 sqlite3", "r")
+-libdirs = map(lambda x:x[2:], string.split(pc.readline()))
++libdirs = list(map(lambda x:x[2:], pc.readline().split()))
+ pc.close()
+
+ module = Extension('_sqlitecache',
diff -Nru yum-metadata-parser-1.1.4/debian/patches/series yum-metadata-parser-1.1.4/debian/patches/series
--- yum-metadata-parser-1.1.4/debian/patches/series 1970-01-01 09:00:00.0 +0900
+++ yum-metadata-parser-1.1.4/debian/patches/series 2019-09-22 00:26:56.0 +0900
@@ -0,0 +1 @@
+fix-python37-setup-error.patch
diff -Nru yum-metadata-parser-1.1.4/debian/python-sqlitecachec.install yum-metadata-parser-1.1.4/debian/python-sqlitecachec.install
--- yum-metadata-parser-1.1.4/debian/python-sqlitecachec.install 1970-01-01 09:00:00.0 +0900
+++ yum-metadata-parser-1.1.4/debian/python-sqlitecachec.install 2019-09-21 23:13:47.0 +0900
@@ -0,0 +1,3 @@
+usr/lib/python2.*/dist-packages/*.py
+usr/lib/python2.*/dist-packages/*.so
+
diff -Nru yum-metadata-parser-1.1.4/debian/python3-sqlitecachec.install yum-metadata-parser-1.1.4/debian/python3-sqlitecachec.install
--- yum-metadata-parser-1.1.4/debian/python3-sqlitecachec.install 1970-01-01 09:00:00.0 +0900
+++ yum-metadata-parser-1.1.4/debian/python3-sqlitecachec.install 2019-09-21 23:14:
Bug#928052: CVE-2019-11502 CVE-2019-11503
Hi,
Thank you for feedback.
On Sun, 9 Jun 2019 19:03:19 +0200 Salvatore Bonaccorso
wrote:
> Hi,
>
snip
> This should not close the bug yet as it only adresses CVE-2019-11502.
> #928052 both tracks CVE-2019-11502 CVE-2019-11503. So onless I miss
> smoething the changes to fix CVE-2019-11503 are missing yet.
I've just dropped inappropriate Closes: and attached fixed debdiff again.
Regards,
diff -Nru snapd-2.37.4/debian/changelog snapd-2.37.4/debian/changelog
--- snapd-2.37.4/debian/changelog 2019-03-01 02:21:26.0 +0900
+++ snapd-2.37.4/debian/changelog 2019-06-09 13:49:16.0 +0900
@@ -1,3 +1,12 @@
+snapd (2.37.4-1.1) unstable; urgency=medium
+
+ [ Kentaro Hayashi ]
+ * Non-maintainer upload.
+ * d/patches/CVE-2019-11502.patch: fix unintended access to a private /tmp
+directory.
+
+ -- Kentaro Hayashi Sun, 09 Jun 2019 13:49:16 +0900
+
snapd (2.37.4-1) unstable; urgency=medium
* New upstream release
diff -Nru snapd-2.37.4/debian/patches/CVE-2019-11502.patch snapd-2.37.4/debian/patches/CVE-2019-11502.patch
--- snapd-2.37.4/debian/patches/CVE-2019-11502.patch 1970-01-01 09:00:00.0 +0900
+++ snapd-2.37.4/debian/patches/CVE-2019-11502.patch 2019-06-09 13:49:16.0 +0900
@@ -0,0 +1,58 @@
+From bdbfeebef03245176ae0dc323392bb0522a339b1 Mon Sep 17 00:00:00 2001
+From: Zygmunt Krynicki
+Date: Mon, 4 Mar 2019 18:40:11 +0100
+Subject: [PATCH] cmd/snap-confine: chown private /tmp parent to root.root
+Origin: https://github.com/snapcore/snapd/commit/bdbfeebef03245176ae0dc323392bb0522a339b1
+Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928052
+Forwarded: not-needed
+
+When snap-confine creates a private /tmp directory for a given snap it
+first creates a temporary directory in /tmp/ named after the snap, along
+with a random name. Inside that directory it creates a /tmp directory
+with permissions appropriate for a future /tmp, namely 1777.
+
+Up until recently the that directory was owned by the user who first
+invoked snap-confine. Since the directory is reused by all the users on
+the system this logic makes no sense.
+
+This patch changes the related logic so that the private /tmp directory
+is owned by root, just like the real one.
+
+Signed-off-by: Zygmunt Krynicki
+
+Drop this patch when this package is upgraded to 2.38 or newer version.
+This patch includes two commit:
+
+* https://github.com/snapcore/snapd/commit/bdbfeebef03245176ae0dc323392bb0522a339b1
+* https://github.com/snapcore/snapd/commit/1d7b5d8bea96139d3d9b301e6c06534d8fc95eff
+
+--- a/cmd/snap-confine/mount-support.c
b/cmd/snap-confine/mount-support.c
+@@ -62,8 +62,6 @@
+ // TODO: fold this into bootstrap
+ static void setup_private_mount(const char *snap_name)
+ {
+- uid_t uid = getuid();
+- gid_t gid = getgid();
+ char tmpdir[MAX_BUF] = { 0 };
+
+ // Create a 0700 base directory, this is the base dir that is
+@@ -71,8 +69,7 @@
+ //
+ // Under that basedir, we put a 1777 /tmp dir that is then bind
+ // mounted for the applications to use
+- sc_must_snprintf(tmpdir, sizeof(tmpdir), "/tmp/snap.%d_%s_XX", uid,
+- snap_name);
++ sc_must_snprintf(tmpdir, sizeof(tmpdir), "/tmp/snap.%s_XX", snap_name);
+ if (mkdtemp(tmpdir) == NULL) {
+ die("cannot create temporary directory essential for private /tmp");
+ }
+@@ -99,7 +96,7 @@
+ // MS_PRIVATE needs linux > 2.6.11
+ sc_do_mount("none", "/tmp", NULL, MS_PRIVATE, NULL);
+ // do the chown after the bind mount to avoid potential shenanigans
+- if (chown("/tmp/", uid, gid) < 0) {
++ if (chown("/tmp/", 0, 0) < 0) {
+ die("cannot change ownership of /tmp");
+ }
+ // chdir to original directory
diff -Nru snapd-2.37.4/debian/patches/series snapd-2.37.4/debian/patches/series
--- snapd-2.37.4/debian/patches/series 2019-03-01 02:21:26.0 +0900
+++ snapd-2.37.4/debian/patches/series 2019-06-09 13:43:42.0 +0900
@@ -6,3 +6,4 @@
0006-systemd-disable-snapfuse-system.patch
0007-i18n-use-dummy-localizations-to-avoid-dependencies.patch
0010-man-page-sections.patch
+CVE-2019-11502.patch
Bug#928052: CVE-2019-11502 CVE-2019-11503
control: tags -1 +patch
I've tried to fix only CVE-2019-11502 as a challenge.
The debdiff patch is added.
I hope it will help to fix.
diff -Nru snapd-2.37.4/debian/changelog snapd-2.37.4/debian/changelog
--- snapd-2.37.4/debian/changelog 2019-03-01 02:21:26.0 +0900
+++ snapd-2.37.4/debian/changelog 2019-06-09 13:49:16.0 +0900
@@ -1,3 +1,12 @@
+snapd (2.37.4-1.1) unstable; urgency=medium
+
+ [ Kentaro Hayashi ]
+ * Non-maintainer upload.
+ * d/patches/CVE-2019-11502.patch: fix unintended access to a private /tmp
+directory. (Closes: #928052)
+
+ -- Kentaro Hayashi Sun, 09 Jun 2019 13:49:16 +0900
+
snapd (2.37.4-1) unstable; urgency=medium
* New upstream release
diff -Nru snapd-2.37.4/debian/patches/CVE-2019-11502.patch snapd-2.37.4/debian/patches/CVE-2019-11502.patch
--- snapd-2.37.4/debian/patches/CVE-2019-11502.patch 1970-01-01 09:00:00.0 +0900
+++ snapd-2.37.4/debian/patches/CVE-2019-11502.patch 2019-06-09 13:49:16.0 +0900
@@ -0,0 +1,58 @@
+From bdbfeebef03245176ae0dc323392bb0522a339b1 Mon Sep 17 00:00:00 2001
+From: Zygmunt Krynicki
+Date: Mon, 4 Mar 2019 18:40:11 +0100
+Subject: [PATCH] cmd/snap-confine: chown private /tmp parent to root.root
+Origin: https://github.com/snapcore/snapd/commit/bdbfeebef03245176ae0dc323392bb0522a339b1
+Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928052
+Forwarded: not-needed
+
+When snap-confine creates a private /tmp directory for a given snap it
+first creates a temporary directory in /tmp/ named after the snap, along
+with a random name. Inside that directory it creates a /tmp directory
+with permissions appropriate for a future /tmp, namely 1777.
+
+Up until recently the that directory was owned by the user who first
+invoked snap-confine. Since the directory is reused by all the users on
+the system this logic makes no sense.
+
+This patch changes the related logic so that the private /tmp directory
+is owned by root, just like the real one.
+
+Signed-off-by: Zygmunt Krynicki
+
+Drop this patch when this package is upgraded to 2.38 or newer version.
+This patch includes two commit:
+
+* https://github.com/snapcore/snapd/commit/bdbfeebef03245176ae0dc323392bb0522a339b1
+* https://github.com/snapcore/snapd/commit/1d7b5d8bea96139d3d9b301e6c06534d8fc95eff
+
+--- a/cmd/snap-confine/mount-support.c
b/cmd/snap-confine/mount-support.c
+@@ -62,8 +62,6 @@
+ // TODO: fold this into bootstrap
+ static void setup_private_mount(const char *snap_name)
+ {
+- uid_t uid = getuid();
+- gid_t gid = getgid();
+ char tmpdir[MAX_BUF] = { 0 };
+
+ // Create a 0700 base directory, this is the base dir that is
+@@ -71,8 +69,7 @@
+ //
+ // Under that basedir, we put a 1777 /tmp dir that is then bind
+ // mounted for the applications to use
+- sc_must_snprintf(tmpdir, sizeof(tmpdir), "/tmp/snap.%d_%s_XX", uid,
+- snap_name);
++ sc_must_snprintf(tmpdir, sizeof(tmpdir), "/tmp/snap.%s_XX", snap_name);
+ if (mkdtemp(tmpdir) == NULL) {
+ die("cannot create temporary directory essential for private /tmp");
+ }
+@@ -99,7 +96,7 @@
+ // MS_PRIVATE needs linux > 2.6.11
+ sc_do_mount("none", "/tmp", NULL, MS_PRIVATE, NULL);
+ // do the chown after the bind mount to avoid potential shenanigans
+- if (chown("/tmp/", uid, gid) < 0) {
++ if (chown("/tmp/", 0, 0) < 0) {
+ die("cannot change ownership of /tmp");
+ }
+ // chdir to original directory
diff -Nru snapd-2.37.4/debian/patches/series snapd-2.37.4/debian/patches/series
--- snapd-2.37.4/debian/patches/series 2019-03-01 02:21:26.0 +0900
+++ snapd-2.37.4/debian/patches/series 2019-06-09 13:43:42.0 +0900
@@ -6,3 +6,4 @@
0006-systemd-disable-snapfuse-system.patch
0007-i18n-use-dummy-localizations-to-avoid-dependencies.patch
0010-man-page-sections.patch
+CVE-2019-11502.patch
Bug#928282: filezilla: CVE-2019-5429
On Fri, 7 Jun 2019 22:20:45 +0900 Kentaro Hayashi wrote: > Hi, > > I'm not a user of filezilla, but I've picked it up fixing RC bug as a > challenge. > I've attached debdiff to fix CVE-2019-5429 using tracker information as a > hint. > > I hope it will help to close this bug. I've added +patch tag for this bug and Cc: for notification. Regards,
Bug#928282: filezilla: CVE-2019-5429
Hi,
I'm not a user of filezilla, but I've picked it up fixing RC bug as a challenge.
I've attached debdiff to fix CVE-2019-5429 using tracker information as a hint.
I hope it will help to close this bug.
Regards,
diff -Nru filezilla-3.39.0/debian/changelog filezilla-3.39.0/debian/changelog
--- filezilla-3.39.0/debian/changelog 2019-01-25 19:37:54.0 +0900
+++ filezilla-3.39.0/debian/changelog 2019-06-07 13:07:14.0 +0900
@@ -1,3 +1,12 @@
+filezilla (3.39.0-2.1) unstable; urgency=medium
+
+ [ Kentaro Hayashi ]
+ * Non-maintainer upload.
+ * d/patches/CVE-2019-5429.patch
+- Added patch to fix CVE-2019-5429 by restricting search path (Closes: 928282)
+
+ -- Kentaro Hayashi Fri, 07 Jun 2019 13:07:14 +0900
+
filezilla (3.39.0-2) unstable; urgency=medium
* Fixed debian/watch
diff -Nru filezilla-3.39.0/debian/patches/CVE-2019-5429.patch filezilla-3.39.0/debian/patches/CVE-2019-5429.patch
--- filezilla-3.39.0/debian/patches/CVE-2019-5429.patch 1970-01-01 09:00:00.0 +0900
+++ filezilla-3.39.0/debian/patches/CVE-2019-5429.patch 2019-06-07 13:07:14.0 +0900
@@ -0,0 +1,413 @@
+Subject: Restrict directories in which tools and data files are searched .
+Origin: https://svn.filezilla-project.org/filezilla?revision=9097=revision
+Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928282
+Author: Tim Kosse
+Forwarded: not-needed
+
+Apply upstream patch to fix CVE-2019-5429.
+
+ref. https://security-tracker.debian.org/tracker/CVE-2019-5429
+
+The patch is coming from:
+ https://svn.filezilla-project.org/filezilla?view=revision=9097
+ https://svn.filezilla-project.org/filezilla?view=revision=9098
+
+This patch is needless when Filezilla itself is upgraded to 3.41.0 or newer version.
+
+
+--- a/src/interface/FileZilla.cpp
b/src/interface/FileZilla.cpp
+@@ -49,6 +49,50 @@
+ #error Please build wxWidgets with support for positional arguments.
+ #endif
+
++namespace {
++std::wstring GetOwnExecutableDir()
++{
++#ifdef FZ_WINDOWS
++ // Add executable path
++ std::wstring path;
++ path.resize(4095);
++ DWORD res;
++ while (true) {
++ res = GetModuleFileNameW(0, [0], path.size() - 1);
++ if (!res) {
++ // Failure
++ return std::wstring();
++ }
++
++ if (res >= path.size() - 1) {
++ path.resize(path.size() * 2);
++ continue;
++ }
++ else {
++ path.resize(res);
++ }
++ break;
++ }
++ size_t pos = path.rfind('\\');
++ if (pos != std::wstring::npos) {
++ return path.substr(0, pos);
++ }
++#elif defined(FZ_MAC)
++ std::wstring executable = wxStandardPaths::Get().GetExecutablePath().ToStdWString();
++ size_t pos = executable.rind('/');
++ if (pos != std::wstring::npos) {
++ return path.substr(0, pos);
++ }
++#elif defined(ENABLE_BINRELOC)
++ const char* p = SELFPATH;
++ if (p && *p == '/') {
++ return fz::to_wstring(std::string(p));
++ }
++#endif
++ return std::wstring();
++}
++}
++
+ CFileZillaApp::CFileZillaApp()
+ {
+ m_profile_start = fz::monotonic_clock::now();
+@@ -356,7 +400,7 @@
+ return fz::local_filesys::get_file_type(fz::to_native(file), true) == fz::local_filesys::file;
+ }
+
+-CLocalPath CFileZillaApp::GetDataDir(std::wstring fileToFind) const
++CLocalPath CFileZillaApp::GetDataDir(std::wstring fileToFind, std::wstring const& prefixSub, bool searchSelfDir) const
+ {
+ /*
+ * Finding the resources in all cases is a difficult task,
+@@ -371,102 +415,78 @@
+
+ #ifdef __WXMAC__
+ CLocalPath path(wxStandardPaths::Get().GetDataDir().ToStdWstring());
+- if (FileExists(path.GetPath() + fileToFind)) {
++ if (searchSelfDir && FileExists(path.GetPath() + fileToFind)) {
+ return path;
+ }
+
+ return CLocalPath();
+ #else
+
+- wxPathList pathList;
+- // FIXME: --datadir cmdline
+-
+ // First try the user specified data dir.
+- pathList.AddEnvList(_T("FZ_DATADIR"));
+-
+- // Next try the current path and the current executable path.
+- // Without this, running development versions would be difficult.
+- pathList.Add(wxGetCwd());
+-
+-#ifdef ENABLE_BINRELOC
+- const char* path = SELFPATH;
+- if (path && *path) {
+- wxString datadir(SELFPATH , *wxConvCurrent);
+- wxFileName fn(datadir);
+- datadir = fn.GetPath();
+- if (!datadir.empty())
+- pathList.Add(datadir);
+-
+- }
+- path = DATADIR;
+- if (path && *path) {
+- wxString datadir(DATADIR, *wxConvCurrent);
+- if (!datadir.empty())
+- pathList.Add(datadir);
+- }
+-#elif defined __WXMSW__
+- wxChar path[1024];
+- int res = GetModuleFileName(0, path, 1000);
+- if (res > 0 && res < 1000) {
+- wxFileName fn(path);
+- pathList.Add(fn.GetPath(wxPATH_GET_VOLUME | wxPATH_GET_SEPARATOR));
++ if (searchSelfDir) {
++ wxString tmp;
++ wxGetEnv(L"FZ_DATADIR", );
++ CLocalPath path(tmp.ToStdWstring());
++ if (!path.empty() && FileExists(path.GetPath() + fileToFind)) {
++ return path;
++ }
+ }
+-#endif //ENABLE_BINRELOC and __WXMSW__ blocks
+
+- // Now scan through the path
+- pathList.AddEnvList(_T(&quo
Bug#929466: freeradius: CVE-2019-10143: privilege escalation due to insecure logration
Maybe attached patch fixes the issue. Regards, diff -Nru freeradius-3.0.17+dfsg/debian/changelog freeradius-3.0.17+dfsg/debian/changelog --- freeradius-3.0.17+dfsg/debian/changelog 2019-04-23 06:23:36.0 +0900 +++ freeradius-3.0.17+dfsg/debian/changelog 2019-05-24 22:15:19.0 +0900 @@ -1,3 +1,11 @@ +freeradius (3.0.17+dfsg-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * Cherry-Pick upstream commits to fix CVE-2019-10143 (Mitigate +privilege escalation due to insecure lotation settings) (Closes: #929466) + + -- Kentaro Hayashi Fri, 24 May 2019 13:15:19 + + freeradius (3.0.17+dfsg-1.1) unstable; urgency=high * Non-maintainer upload. diff -Nru freeradius-3.0.17+dfsg/debian/freeradius.logrotate freeradius-3.0.17+dfsg/debian/freeradius.logrotate --- freeradius-3.0.17+dfsg/debian/freeradius.logrotate 2019-04-23 06:23:36.0 +0900 +++ freeradius-3.0.17+dfsg/debian/freeradius.logrotate 2019-05-24 22:15:19.0 +0900 @@ -9,6 +9,7 @@ notifempty copytruncate + su freerad freerad } # (in order) @@ -28,6 +29,7 @@ notifempty nocreate + su freerad freerad } # There are different detail-rotating strategies you can use. One is @@ -47,4 +49,5 @@ notifempty nocreate + su freerad freerad } diff -Nru freeradius-3.0.17+dfsg/debian/patches/CVE-2019-10143.patch freeradius-3.0.17+dfsg/debian/patches/CVE-2019-10143.patch --- freeradius-3.0.17+dfsg/debian/patches/CVE-2019-10143.patch 1970-01-01 09:00:00.0 +0900 +++ freeradius-3.0.17+dfsg/debian/patches/CVE-2019-10143.patch 2019-05-24 22:15:19.0 +0900 @@ -0,0 +1,40 @@ +su to radiusd user/group when rotating logs + +The su directive to logrotate ensures that log rotation happens under the +owner of the logs. Otherwise, logrotate runs as root:root, potentially +enabling privilege escalation if a RCE is discovered against the +FreeRADIUS daemon. +--- a/redhat/freeradius-logrotate b/redhat/freeradius-logrotate +@@ -9,6 +9,7 @@ + missingok + compress + delaycompress ++su radiusd radiusd + + # + # The main server log +--- a/scripts/logrotate/freeradius b/scripts/logrotate/freeradius +@@ -17,6 +17,7 @@ + notifempty + + copytruncate ++ su radiusd radiusd + } + + # (in order) +@@ -34,6 +35,7 @@ + notifempty + + nocreate ++ su radiusd radiusd + } + + # There are different detail-rotating strategies you can use. One is +@@ -53,4 +55,5 @@ + notifempty + + nocreate ++ su radiusd radiusd + } diff -Nru freeradius-3.0.17+dfsg/debian/patches/series freeradius-3.0.17+dfsg/debian/patches/series --- freeradius-3.0.17+dfsg/debian/patches/series 2019-04-23 06:23:36.0 +0900 +++ freeradius-3.0.17+dfsg/debian/patches/series 2019-05-24 22:15:19.0 +0900 @@ -10,3 +10,4 @@ snakeoil-certs.diff CVE-2019-11234-1.patch CVE-2019-11234-2.patch +CVE-2019-10143.patch
Bug#928304: groonga-httpd: Privilege escalation due to insecure use of logrotate
Hi, On Wed, 8 May 2019 20:32:53 +0200 Salvatore Bonaccorso wrote: > Hi, > > [please always include team@security.d.o as so any team member can > reply] > I've got it, thanks. > On Wed, May 08, 2019 at 12:03:49PM +0900, Hideki Yamane wrote: > > Hi Salvatore, > > > > Can you follow his question? I guess debian revision should be > > 6.1.5-1+deb9u1, but others are okay. > > I think updating groonga via a future point release is enough for this > issue, can you go ahead for this route? (change the target > distribution to stretch instead of stretch-security for that). > Ok, I've uploaded. > In particular though I think the issue should be fixed in unstable and > buster, but I notice that testing has 9.0.0-1 and 9.0.1-1 did not > migrate. So either the release team will accept to unblock 9.0.1-1 or > buster would need a targeted fix as well via testing-proposed-updates, > cf. https://release.debian.org/buster/freeze_policy.html . I've filed as a unblock bug. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928715 Regards,
Bug#928304: groonga-httpd: Privilege escalation due to insecure use of logrotate
Hi,
I maintain Groonga package as a DM, so I want to fix #928304.
But I've never uploaded package to stable before, so I need help
to do it in a good manner.
I've attached debdiff against current version.
Is it ok to upload stretch-security?
diff -Nru groonga-6.1.5/debian/changelog groonga-6.1.5/debian/changelog
--- groonga-6.1.5/debian/changelog 2017-01-23 19:14:09.0 +0900
+++ groonga-6.1.5/debian/changelog 2019-05-07 22:33:11.0 +0900
@@ -1,3 +1,13 @@
+groonga (6.1.5-2) stretch-security; urgency=medium
+
+ * debian/groonga-httpd.logrotate
+debian/groonga-server-gqtp.logrotate
+- Mitigate privilege escalation by changing the owner and group of logs
+ with "su" option. Reported by Wolfgang Hotwagner.
+ (Closes: #928304) (CVE-2019-11675)
+
+ -- Kentaro Hayashi Tue, 07 May 2019 22:33:11 +0900
+
groonga (6.1.5-1) unstable; urgency=medium
* New upstream release.
diff -Nru groonga-6.1.5/debian/groonga-httpd.logrotate groonga-6.1.5/debian/groonga-httpd.logrotate
--- groonga-6.1.5/debian/groonga-httpd.logrotate 2016-12-10 15:18:50.0 +0900
+++ groonga-6.1.5/debian/groonga-httpd.logrotate 2019-05-07 22:33:11.0 +0900
@@ -1,11 +1,11 @@
/var/log/groonga/httpd/*.log {
+su groonga groonga
daily
missingok
rotate 30
compress
delaycompress
notifempty
-create 640 groonga groonga
sharedscripts
postrotate
. /etc/default/groonga-httpd
diff -Nru groonga-6.1.5/debian/groonga-server-gqtp.logrotate groonga-6.1.5/debian/groonga-server-gqtp.logrotate
--- groonga-6.1.5/debian/groonga-server-gqtp.logrotate 2016-12-10 15:18:50.0 +0900
+++ groonga-6.1.5/debian/groonga-server-gqtp.logrotate 2019-05-07 22:33:11.0 +0900
@@ -1,11 +1,11 @@
/var/log/groonga/*-gqtp.log {
+su groonga groonga
daily
missingok
rotate 30
compress
delaycompress
notifempty
-create 640 groonga groonga
sharedscripts
postrotate
. /etc/default/groonga-server-gqtp
Bug#925972: src:groonga: Non-working maintainer address
> A message that you sent could not be delivered to one or more of its > recipients. This is a permanent error. The following address(es) failed: > > packa...@groonga.org > host aspmx.l.google.com [2a00:1450:400c:c0c::1a] > SMTP error from remote mail server after RCPT TO:: > 550-5.1.1 The email account that you tried to reach does not exist. > Please try > 550-5.1.1 double-checking the recipient's email address for typos or > 550-5.1.1 unnecessary spaces. Learn more at > 550 5.1.1 https://support.google.com/mail/?p=NoSuchUser > p16si1506256wre.147 - gsmtp This is caused by recent mail service migration for groonga.org. The issue has fixed now.
Bug#811604: FTBFS with GCC 6: statement indented as if it were guarded by
> Hmm... I don't seem to be able to reproduce this error. Also the code > itself doesn't actually look misleading. > > Maybe it was fixed in the latest 7.1.5-1 release? It was already fixed in upstream. https://people.redhat.com/anderson/crash.changelog.html Quoted from crach 7.1.5 changelog entry: - Fixes for "[-Werror=misleading-indentation]" compiler warnings that are generated by the following files, when building X86_64 in a Fedora Rawhide environment with gcc-6.0.0: gdb-7.6/bfd/coff-i386.c gdb-7.6/bfd/coff-x86_64.c kernel.c x86_64.c lkcd_common.c Without the patch, the warnings in the bfd library files are treated as errors, and abort the build. The three instances in the top-level crash source code directory are non-fatal. There are several other gdb-specific instances that are non-fatal and are not addressed. (ander...@redhat.com) pgp_MTo2jAYe7.pgp Description: PGP signature
Bug#811758: presage: FTBFS with GCC 6: narrowing conversion
I hope that attached patch solves this issue.
The attached one is minimum patch to fix it, so it may not be ideal solution.
> This package fails to build with GCC 6. GCC 6 has not been released
> yet, but it's expected that GCC 6 will become the default compiler for
> stretch.
Description: Fix FTBFS by g++-6
Author: Kentaro Hayashi <haya...@clear-code.com>
Forwarded: No
--- a/src/lib/core/charsets.h
+++ b/src/lib/core/charsets.h
@@ -42,7 +42,7 @@
const char PAGE_DOWN = 128;
-const char DEFAULT_WORD_CHARS[]={
+const unsigned char DEFAULT_WORD_CHARS[]={
'A',
'B',
'C',
--- a/src/lib/core/context_tracker/contextTracker.cpp
+++ b/src/lib/core/context_tracker/contextTracker.cpp
@@ -37,11 +37,11 @@
ContextTracker::ContextTracker(Configuration* config,
PredictorRegistry* registry,
PresageCallback* callback,
- const char wChars[],
+ const unsigned char wChars[],
const char tChars[],
const char bChars[],
const char cChars[])
-: wordChars (wChars),
+: wordChars (reinterpret_cast(wChars)),
separatorChars (tChars),
blankspaceChars(bChars),
controlChars (cChars),
--- a/src/lib/core/context_tracker/contextTracker.h
+++ b/src/lib/core/context_tracker/contextTracker.h
@@ -157,7 +157,7 @@
ContextTracker(Configuration* config,
PredictorRegistry* predictorRegistry,
PresageCallback* callback,
- const char[]=DEFAULT_WORD_CHARS,
+ const unsigned char[]=DEFAULT_WORD_CHARS,
const char[]=DEFAULT_SEPARATOR_CHARS,
const char[]=DEFAULT_BLANKSPACE_CHARS,
const char[]=DEFAULT_CONTROL_CHARS );
--- a/test/lib/core/context_tracker/contextChangeDetectorTest.cpp
+++ b/test/lib/core/context_tracker/contextChangeDetectorTest.cpp
@@ -30,7 +30,7 @@
void ContextChangeDetectorTest::setUp()
{
-detector = new ContextChangeDetector(DEFAULT_WORD_CHARS,
+detector = new ContextChangeDetector(reinterpret_cast(DEFAULT_WORD_CHARS),
DEFAULT_SEPARATOR_CHARS,
DEFAULT_BLANKSPACE_CHARS,
DEFAULT_CONTROL_CHARS,
--- a/test/lib/predictors/predictorsTestMockObjects.cpp
+++ b/test/lib/predictors/predictorsTestMockObjects.cpp
@@ -31,7 +31,7 @@
ContextTracker::ContextTracker(Configuration* config,
PredictorRegistry* predictorRegistry,
PresageCallback* callback,
- const char wc[],
+ const unsigned char wc[],
const char sc[],
const char bc[],
const char cc[])
pgpfr6q6s1jMl.pgp
Description: PGP signature
